"Sistem yavaş" cümlesi, bir yazılım ekibinin duyabileceği en az bilgi taşıyan ama en çok iş çıkaran cümlelerden biridir. Hangi ekranda, hangi kullanıcıda, hangi saatten beri ve ne kadar yavaş? Bu sorulara tahminle değil veriyle cevap verebilmek, gözlemlenebilirliğin konusudur. Gözlemlenebilirlik, bir sistemin dışarıya verdiği sinyallere bakarak içinde ne olduğunu anlayabilme yeteneğidir.
İzleme ile gözlemlenebilirlik sıklıkla karıştırılır. İzleme, önceden bilinen soruları sorar: Sunucu ayakta mı, disk doluyor mu? Gözlemlenebilirlik ise daha önce hiç sorulmamış bir soruya da yanıt aramayı mümkün kılar: Bu sabah yalnızca belirli bir şubedeki kullanıcıların DASK sorgusu neden uzun sürdü?
Üç temel sinyal
Loglar: Olayların ayrıntılı kaydı
Log, sistemde gerçekleşen bir olayın zaman damgalı kaydıdır. Bir kullanıcının oturum açması, bir teklif sorgusunun başlaması ya da bir sigorta şirketi servisinin hata döndürmesi log olarak kaydedilebilir. Logların değeri ayrıntıdadır; ancak bu ayrıntı aynı zamanda hacim demektir. Bu yüzden logların yapılandırılmış olması, yani serbest metin yerine alan adlarıyla tutulması önemlidir. "Teklif hatası oluştu" yerine branş, şirket, hata türü ve süre gibi alanları içeren bir kayıt, sonradan filtrelenebilir ve sayılabilir.
Metrikler: Zaman içindeki eğilimler
Metrik, belirli aralıklarla ölçülen sayısal bir değerdir: dakikadaki istek sayısı, ortalama yanıt süresi, hata oranı, kuyruk uzunluğu. Metrikler ucuzdur, hızlı sorgulanır ve eğilimleri gösterir. Bir sorunun var olduğunu ilk fark ettiren sinyal genellikle metriktir. Ancak metrik tek başına nedeni söylemez; yalnızca bir şeylerin değiştiğini gösterir.
İzler: Bir isteğin yolculuğu
İz, tek bir kullanıcı isteğinin sistem içinde geçtiği tüm adımların zaman çizelgesidir. Teklif butonuna basıldığında istek önce arayüzden arka uca, oradan teklif motoruna, oradan birden fazla sigorta şirketi servisine gider. İz, bu adımların her birinin ne kadar sürdüğünü ve hangisinde takılındığını gösterir.
Sinyalleri birlikte kullanmak
Üç sinyal ayrı ayrı faydalıdır; asıl güç birlikte kullanıldıklarında ortaya çıkar. Tipik bir inceleme şöyle ilerler:
- Metrik panelinde kasko sorgularının yanıt süresinde bir yükselme görülür.
- Yükselmenin olduğu zaman aralığındaki yavaş isteklerin izlerine bakılır; gecikmenin belirli bir şirket servisine yapılan çağrıda biriktiği görülür.
- Aynı iz kimliğiyle ilişkilendirilmiş loglar açılır; servisin zaman aşımı döndürdüğü ve yeniden deneme mekanizmasının devreye girdiği anlaşılır.
Bu akışın çalışabilmesi için tüm sinyallerin ortak bir bağlantı noktası taşıması gerekir. Her isteğe bir kimlik atanması ve bu kimliğin loglara, izlere ve mümkünse hata raporlarına eklenmesi, incelemeyi dakikalar içinde tamamlanabilir kılar.
Neleri gözlemlemeli?
Her şeyi kaydetmek hem maliyetli hem de gürültülüdür. Acente yazılımı açısından anlamlı başlıklar şunlardır:
- Kullanıcı yolculukları: Oturum açma, müşteri arama, teklif başlatma ve sonuç alma adımlarının süreleri ve başarı oranları.
- Branş bazında teklif akışları: Trafik, kasko ve DASK sorgularının ayrı ayrı izlenmesi; birinin sorunu diğerlerinin ortalamasında kaybolmamalıdır.
- Dış servis sağlığı: Her sigorta şirketi entegrasyonu için yanıt süresi ve hata oranı.
- Arka plan işleri: Hatırlatma gönderimi, rapor üretimi, veri senkronizasyonu gibi kullanıcının doğrudan görmediği işlerin tamamlanma durumu.
Kişisel veri ve gözlemlenebilirlik
Log ve izler, dikkat edilmezse kişisel verinin istemeden biriktiği yerlere dönüşebilir. Kimlik numarası, telefon, plaka ya da adres gibi bilgilerin log satırlarına yazılmaması gerekir. Bunun yerine kayıtlarda yalnızca iç tanımlayıcılar kullanılır. Ayrıca log saklama süreleri tanımlanmalı ve bu kayıtlara erişim de yetkiyle sınırlanmalıdır. Gözlemlenebilirlik, veri güvenliğiyle çatışan değil, onunla birlikte tasarlanan bir alandır.
Acente kullanıcısına dokunan tarafı
Gözlemlenebilirlik doğrudan bir ekran ya da özellik olarak görünmez. Ancak etkisi destek süreçlerinde hissedilir. Bir kullanıcı sorun bildirdiğinde, ekip "Tekrar dener misiniz?" yerine "Saat on bire doğru bir şirketin servisinde gecikme oldu, şu an normale döndü" diyebilir. Bazı durumlarda sorun, kullanıcı bildirmeden önce fark edilir ve çözülür.
Gözlemlenebilir bir acente yazılımı, teklif ekranından mobil uygulamaya kadar tüm kanallarda aynı bakış açısıyla izlenir. Bu da web ve mobil arasında farklı davranışların daha kolay tespit edilmesini sağlar.
Başlangıç için öneriler
- Önce en kritik üç kullanıcı yolculuğunu seçin ve bunlar için uçtan uca süre ve hata oranı ölçün.
- Logları yapılandırılmış biçime geçirin ve her isteğe bir kimlik ekleyin.
- Dış servis çağrılarını ayrı metriklerle izleyin.
- Kişisel veri içermeyen bir log politikası yazın ve kod incelemelerinde bunu kontrol edin.
Paneller kimin için tasarlanmalı?
Gözlemlenebilirlik verisi tek bir büyük panelde toplandığında herkes için biraz, kimse için yeterli bilgi sunar. Farklı rollerin farklı sorulara ihtiyacı vardır:
- Nöbetçi geliştirici paneli: Kritik kullanıcı yolculuklarının o anki durumu, hata oranları ve son yayınların zamanı. Amaç, birkaç saniyede "bir sorun var mı?" sorusuna yanıt vermektir.
- Entegrasyon paneli: Her sigorta şirketi servisi için branş bazında yanıt süresi ve hata oranı. Trafik, kasko ve DASK ayrı sütunlarda izlenir.
- Destek ekibi paneli: Belirli bir acente ya da kullanıcı için son işlemler ve karşılaşılan hatalar; kişisel veri göstermeden, iç tanımlayıcılarla.
- Ürün paneli: Özelliklerin kullanım eğilimleri ve akışlardaki terk noktaları.
Her panelin bir sahibi olması ve kullanılmayan grafiklerin düzenli olarak ayıklanması, panellerin zamanla karmaşık ve anlamsız hâle gelmesini önler.
Panellerin yanında, her grafiğe ilişkin kısa bir açıklama eklemek de iyi bir alışkanlıktır. Bir çizginin neyi ölçtüğü, normal değer aralığının nasıl yorumlanacağı ve sapma görüldüğünde ilk nereye bakılacağı birkaç cümleyle belirtildiğinde, panel yalnızca onu hazırlayan kişi için değil tüm ekip için anlamlı hâle gelir.
Sonuç
Loglar ne olduğunu, metrikler ne zaman ve ne ölçüde olduğunu, izler ise nerede olduğunu anlatır. Üçü bir araya geldiğinde, karmaşık bir acente yazılımında bile sorunların kaynağına tahminle değil kanıtla ulaşmak mümkün olur.