Bir acente yazılımının sigorta şirketleriyle kurduğu bağlantılar, dışarıdan bakıldığında görünmez bir altyapıdır. Kullanıcı yalnızca sorgu sonucunu görür. Oysa her sonucun arkasında zaman aşımına uğrayan istekler, geç gelen yanıtlar, yeniden denemeler ve bazen sessizce başarısız olan çağrılar vardır. Bu altyapının sağlığını görebilmek, sorunları kullanıcılar şikâyet etmeden önce fark etmenin tek yoludur. Bu yazıda bir entegrasyon sağlık panelinin hangi metrikleri içermesi ve nasıl düzenlenmesi gerektiğini ele alıyoruz.
Neden genel sunucu metrikleri yetmez?
İşlemci kullanımı, bellek ve disk doluluğu gibi altyapı metrikleri önemlidir ama entegrasyon sağlığını anlatmaz. Sunucular tamamen sağlıklı görünürken bir sigorta şirketinin kasko servisi yarım saattir hata veriyor olabilir. Entegrasyon sağlığı, sunucunun değil, sunucunun dış dünyayla kurduğu ilişkinin sağlığıdır. Bu yüzden dış çağrılara özgü metrikler ayrıca toplanmalı ve ayrı bir panelde sunulmalıdır.
Temel çerçeve: Dört altın sinyal
Servis izlemede yaygın kabul gören bir çerçeve, dört temel sinyale odaklanmayı önerir. Bu çerçeve entegrasyon katmanına da rahatlıkla uyarlanabilir.
1. Gecikme
Bir çağrının yanıt alana kadar geçen süresidir. Ortalama değer yanıltıcıdır; çünkü çoğu çağrı hızlıyken az sayıda çok yavaş çağrı kullanıcı deneyimini belirler. Bu nedenle yüzdelik dilimler izlenmelidir: Medyan, yüzde doksan beşlik ve yüzde doksan dokuzluk değerler, yavaşlığın kaç kullanıcıyı etkilediğini gösterir. Başarılı ve başarısız çağrıların gecikmeleri ayrı ölçülmelidir; hızlı dönen hatalar ortalamayı yapay olarak iyileştirebilir.
2. Trafik
Belirli bir sürede yapılan çağrı sayısıdır. Trafik tek başına sorun göstermez ama diğer metrikleri yorumlamanın bağlamını oluşturur. Ani düşüş de ani artış kadar dikkat gerektirir; trafiğin sıfıra inmesi, isteklerin hiç gönderilemediği bir hataya işaret edebilir.
3. Hatalar
Başarısız çağrıların oranıdır. Burada kritik olan, hataları anlamlı kategorilere ayırmaktır: Ağ hataları, zaman aşımları, karşı servisin döndüğü sistem hataları, kimlik doğrulama hataları ve iş kuralı redleri. İş kuralı redleri, örneğin bir aracın ilgili teminata uygun bulunmaması, teknik hata değildir ve hata oranına katılmamalıdır.
4. Doygunluk
Sistemin kapasitesine ne kadar yaklaştığını gösterir. Entegrasyon katmanında bu; kuyruk derinliği, meşgul işçi oranı, bağlantı havuzu kullanımı ve şirket başına eşzamanlı istek sayısı olarak ölçülür.
İş düzeyindeki metrikler
Teknik sinyallerin yanında, kullanıcının gözünden başarıyı anlatan metrikler de gerekir:
- Sorgu tamamlanma oranı: Başlatılan sorguların ne kadarında en az bir şirketten geçerli sonuç alındığı.
- Şirket yanıt kapsamı: Bir sorguda hedeflenen şirketlerin kaçından yanıt geldiği.
- İlk sonuca kadar geçen süre: Kullanıcının ekranında ilk teklifin belirmesi için geçen süre.
- Poliçeleştirme başarı oranı: Poliçeleştirme isteklerinin başarıyla sonuçlanma oranı.
Bu metrikler, teknik ekibin gözünden kaçabilecek ama kullanıcıyı doğrudan etkileyen sorunları görünür kılar.
Boyutlar: Metrikleri nasıl kırmalı?
Tek bir toplam hata oranı neredeyse hiçbir şey anlatmaz. Her metrik şu boyutlarda kırılabilmelidir:
- Sigorta şirketi: Sorunun hangi bağlantıda olduğunu gösterir.
- Branş: Trafik, kasko ve DASK ayrı akışlar olduğu için aynı şirketin bir branşı sağlıklıyken diğeri sorunlu olabilir.
- İşlem türü: Sorgu, poliçeleştirme, belge alma ve durum sorgulama gibi işlemler ayrı izlenmelidir.
- Kanal: Web paneli ve mobil uygulamadan gelen isteklerin davranışı farklılaşabilir.
Boyut sayısı arttıkça veri hacmi de artar. Kullanıcı bazında veya müşteri bazında kırılım gibi çok yüksek çeşitlilikteki boyutlar metrik sistemine değil, log ve iz sistemlerine bırakılmalıdır.
Panel düzeni: Yukarıdan aşağıya
İyi bir sağlık paneli, bakan kişiyi genelden özele doğru yönlendirir:
- Üst bölüm: Bütün entegrasyonların tek bakışta durumunu gösteren bir özet ızgara. Her şirket ve branş birleşimi için sağlıklı, dikkat ve sorunlu durumlarını gösteren renkli hücreler.
- Orta bölüm: Seçilen bağlantı için zaman serisi grafikleri: gecikme yüzdelikleri, hata oranı ve trafik.
- Alt bölüm: Kuyruk derinliği, devre kesici durumları ve yeniden deneme oranları gibi altyapı göstergeleri.
Her grafikte yayın zamanlarının işaretlenmesi, bir sorunun yeni bir sürümle başlayıp başlamadığını hızlıca anlamayı sağlar.
Alarm tasarımı: Gürültüden kaçınmak
Panel, ancak birisi baktığında işe yarar. Alarmlar ise kimse bakmadığında devreye girer. Etkili alarm tasarımı için şu ilkeler önerilir:
- Alarmlar nedenlere değil belirtilere dayanmalıdır. "İşlemci yüksek" yerine "kasko sorgularının tamamlanma oranı düştü" daha anlamlıdır.
- Tekil sıçramalar yerine belirli bir süre devam eden sapmalar alarm üretmelidir.
- Her alarmın bir sahibi ve kısa bir müdahale notu olmalıdır.
- Düzenli olarak tetiklenip kimsenin aksiyon almadığı alarmlar ya düzeltilmeli ya da kaldırılmalıdır.
Hizmet seviyesi hedefleri
Metrikleri anlamlı kılmanın yolu, onları hedeflere bağlamaktır. Örneğin "sorguların büyük çoğunluğunda ilk sonuç belirli bir süre içinde ekrana gelmeli" gibi bir hedef tanımlandığında, panel artık yalnızca veri göstermez, hedefe ne kadar yakın olunduğunu da gösterir. Hedefler gerçekçi belirlenmeli ve sigorta şirketi servislerinin acente yazılımının kontrolü dışında olduğu unutulmamalıdır. Dış bağımlılıklar için hedefler, kendi kontrolündeki katmanlardan ayrı tanımlanmalıdır.
Sentetik kontroller: Trafik yokken de görmek
Gerçek kullanıcı trafiğine dayalı metrikler, trafiğin az olduğu saatlerde yetersiz kalır. Gece veya hafta sonu bir şirket servisinde başlayan sorun, sabah ilk kullanıcılar sorgu yapana kadar fark edilmeyebilir. Sentetik kontroller, belirli aralıklarla otomatik olarak çalışan ve bilinen test verileriyle bağlantının ayakta olup olmadığını doğrulayan küçük işlerdir. Bu kontrollerin gerçek poliçe veya ücretli işlem üretmemesi, yalnızca bağlantı ve kimlik doğrulama adımlarını sınaması gerekir. Sonuçları panelde ayrı bir satır olarak gösterilir.
InsureHub'da izleme anlayışı
InsureHub, sigorta acentelerine yazılım sağlayan bir platform olarak entegrasyon sağlığını yalnızca teknik ekibin değil, ürün kararlarının da girdisi olarak görür. Hangi bağlantıların ne sıklıkla sorun yaşadığını bilmek, sigorta teklif programı kullanıcılarına doğru bilgi vermeyi ve sigorta acentesi yazılımı içindeki iyileştirmeleri önceliklendirmeyi kolaylaştırır.