Bir yazılım sorununun en pahalı şekilde fark edilmesi, ilk bildirimi kullanıcıdan almaktır. Acente çalışanı teklif ekranının açılmadığını fark ettiğinde, sorun büyük olasılıkla birkaç dakikadır sürmekte, belki de başka kullanıcıları da etkilemektedir. İyi kurgulanmış bir izleme sistemi bu sırayı tersine çevirir: Sorun teknik ekip tarafından fark edilir, çoğu zaman kullanıcı bir şey yaşamadan müdahale başlar.
Bu yazıda acente yazılımı gibi iş açısından kritik bir hizmette izlemenin hangi katmanlarda yapılması gerektiğini, alarmların nasıl tasarlanacağını ve acentenin bu süreçten nasıl fayda görebileceğini ele alıyoruz.
İzlemenin üç katmanı
Altyapı izleme
Sunucuların işlemci, bellek ve disk kullanımı, ağ bağlantısı ve veritabanı durumu bu katmanda izlenir. Diskin dolmaya yaklaşması ya da belleğin sürekli yüksek seyretmesi, henüz kesinti yaşanmadan önlem alınmasını sağlayan erken uyarılardır.
Uygulama izleme
Uygulamanın kendisinin nasıl davrandığı bu katmanın konusudur: İsteklerin ne kadar sürede yanıtlandığı, hata oranı, arka planda çalışan işlerin tamamlanıp tamamlanmadığı. Sunucular sağlıklı görünürken uygulamanın belirli bir ekranda hata vermesi ancak bu katmanda yakalanabilir.
Kullanıcı deneyimi izleme
Gerçek bir kullanıcının yapacağı işlemleri düzenli aralıklarla taklit eden sentetik kontroller bu katmanda yer alır. Örneğin bir test hesabıyla giriş yapmak, müşteri listesini açmak ve arama yapmak gibi adımlar belirli aralıklarla otomatik olarak çalıştırılır. Bu kontroller, "sistem açık ama kullanılamıyor" durumlarını yakalamanın en güvenilir yoludur.
Acente yazılımında neyi izlemeli?
Her ürünün kritik noktaları farklıdır; ancak sigorta acentelerine yönelik bir yazılımda öne çıkan izleme başlıkları şunlardır:
- Giriş akışı: Kullanıcıların oturum açabilmesi, iki aşamalı doğrulama adımının çalışması.
- Teklif akışları: Trafik, kasko ve DASK sorgularının ayrı ayrı izlenmesi; her branşın ve her sigorta şirketi bağlantısının yanıt süresi ve hata oranı.
- Araç ve adres sorguları: Teklif öncesinde kullanılan dış sorgu servislerinin yanıt verip vermediği.
- Belge üretimi: PDF teklif formlarının oluşturulma süresi ve başarısız üretimler.
- Bildirim ve hatırlatmalar: Yenileme hatırlatmalarını gönderen zamanlanmış işlerin çalışıp çalışmadığı.
- Mobil uygulama: Uygulamanın kullandığı servislerin yanıt süreleri ve uygulama çökme bildirimleri.
Teklif akışlarının branş ve şirket bazında ayrı izlenmesi özellikle önemlidir. Tek bir sigorta şirketinin servisinde yaşanan sorun genel bir arıza gibi görünmemeli, doğru yere ve doğru öncelikle iletilmelidir.
Alarm tasarımı
İzleme verisinin değeri, doğru zamanda doğru kişiye ulaşan alarmlarla ortaya çıkar. Kötü tasarlanmış alarmlar iki şekilde zarar verir: Ya çok geç gelir ya da o kadar sık gelir ki ekip alarmları görmezden gelmeye başlar.
Belirti odaklı alarmlar
Kullanıcıyı doğrudan etkileyen durumlar için alarm kurmak önceliklidir: hata oranının artması, yanıt sürelerinin belirgin şekilde uzaması, sentetik kontrollerin başarısız olması. İşlemci kullanımının kısa süreli yükselmesi gibi nedenlere dayalı alarmlar ise çoğu zaman bilgi seviyesinde tutulabilir.
Süreye bağlı eşikler
Tek bir başarısız istek alarm gerektirmez; belirli bir süre boyunca devam eden sorun gerektirir. Eşiklerin süreyle birlikte tanımlanması gereksiz alarmları azaltır.
Önem seviyeleri
Her alarm aynı aciliyette değildir. Gece saatlerinde nöbetçi mühendisi uyandıracak alarm ile ertesi sabah incelenebilecek uyarı birbirinden ayrılmalıdır.
Sahiplik
Her alarmın kime gideceği ve alarm geldiğinde ilk olarak ne yapılacağı tanımlanmalıdır. Kısa bir müdahale notu, alarmı alan kişinin dakikalar kazanmasını sağlar.
İzleme acenteye nasıl yansır?
İzleme sisteminin acente tarafından görülen kısmı genellikle küçüktür, ama etkisi büyüktür:
- Sorunlar kullanıcı bildiriminden önce fark edildiği için kesinti süresi kısalır.
- Sağlayıcı, sorunun kapsamını bildiği için acenteye daha net bilgi verebilir: "Panel çalışıyor, yalnızca belirli bir şirketin kasko sorgusunda gecikme var" gibi.
- Yavaşlama gibi sinsi sorunlar, kullanıcılar alışıp şikâyet etmeyi bırakmadan yakalanır.
- Geçmiş izleme verisi, kesinti sonrası değerlendirmede neyin ne zaman başladığını gösterir.
İzleme verisinde kişisel veri dengesi
İzleme ve kayıt sistemleri, doğası gereği çok miktarda veri toplar. Bir acente yazılımında bu veri, dikkat edilmezse müşterilerin kimlik numaraları, plaka bilgileri ya da iletişim bilgileri gibi kişisel verileri de içerebilir. Sorunu anlamak için gereken bilgi ile gereğinden fazla toplanan bilgi arasındaki denge, izleme tasarımının parçası olmalıdır.
Bu dengeyi kurmak için yaygın olarak uygulanan yöntemler şunlardır:
- Kayıtlarda kişisel veri alanlarının maskelenmesi ya da hiç yazılmaması.
- İzleme verisine erişimin yalnızca ihtiyacı olan teknik ekiple sınırlandırılması.
- Ayrıntılı kayıtların belirli bir süre sonra otomatik olarak silinmesi, özet metriklerin ise daha uzun süre tutulması.
- Hata ayıklama amacıyla geçici olarak açılan ayrıntılı kayıt seviyesinin iş bitince kapatılması.
Böylece izleme, bir yandan sürekliliği desteklerken diğer yandan veri koruma ilkeleriyle çelişmeyen bir yapıda kalır.
Acentenin kendi gözlemleri de veridir
İzleme sistemleri ne kadar gelişmiş olursa olsun, kullanıcı geri bildirimi değerli bir sinyal olmaya devam eder. Acente çalışanlarının bir sorunu bildirirken hangi ekranda, hangi işlemi yaparken ve hangi saatte sorun yaşadıklarını paylaşması, teknik ekibin izleme verisiyle eşleştirme yapmasını kolaylaştırır. Kısa ama somut bir bildirim, uzun bir şikâyetten daha hızlı sonuç verir.
InsureHub bakış açısı
InsureHub, acentelere sunduğu web acente paneli ve iOS/Android uygulamada trafik, kasko ve DASK teklif akışlarını ayrı süreçler olarak ele alır. Bu ayrım, izleme açısından da her akışın kendi sağlık göstergeleriyle takip edilebilmesine imkân tanır. Ürün yapısını sigorta teklif programı ve mobil sigorta uygulaması sayfalarından inceleyebilir, hizmet sürekliliğine ilişkin sorularınızı demo talebi üzerinden iletebilirsiniz.
Sonuç
İzleme, iş sürekliliğinin görünmeyen ama en çok iş yapan parçalarından biridir. Katmanlı izleme, belirti odaklı alarmlar ve net sahiplik bir araya geldiğinde sorunlar daha kısa sürer, daha az kullanıcıyı etkiler ve daha iyi anlaşılır.