Hiçbir yazılım her zaman kusursuz çalışmaz. Bu kabul, güvenilirlik konusundaki en sağlıklı başlangıç noktasıdır. Asıl soru "hiç sorun yaşanmasın" değil, "ne kadar sorun kabul edilebilir ve bunu nasıl ölçeriz?" olmalıdır. SLO ve hata bütçesi, bu soruya ölçülebilir bir yanıt vermek için kullanılan çerçevedir.
InsureHub gibi acentelere yazılım sunan bir SaaS ekibi için bu çerçeve, iki farklı baskıyı dengelemeye yarar: Bir yanda yeni özellik ve iyileştirme talepleri, diğer yanda acentenin her sabah sorunsuz çalışan bir sistem beklentisi.
Üç kavram, tek mantık
SLI: Neyi ölçüyoruz?
Hizmet düzeyi göstergesi (SLI), kullanıcı deneyimini temsil eden ölçülebilir bir değerdir. Örneğin "başarıyla tamamlanan teklif sorgularının toplam sorgulara oranı" ya da "müşteri arama isteklerinin belirlenen süre içinde yanıtlanma oranı" birer SLI'dır. İyi bir SLI, kullanıcının gerçekten hissettiği bir şeyi ölçer; sunucunun işlemci kullanımı gibi iç göstergeler bu tanıma uymaz.
SLO: Hedefimiz ne?
Hizmet düzeyi hedefi (SLO), bir SLI için belirli bir zaman penceresinde ulaşılması amaçlanan değerdir. "Son dört hafta içinde oturum açma isteklerinin büyük çoğunluğu başarılı olmalı" gibi bir ifade, sayısal bir eşikle birlikte SLO hâline gelir. Bu eşik ekip tarafından belirlenir ve bir iç hedeftir.
Hata bütçesi: Ne kadar payımız var?
Hata bütçesi, SLO'nun tamamlayıcısıdır. Hedef, isteklerin belirli bir oranının başarılı olmasıysa, geri kalan küçük oran bütçedir. Bu bütçe, yeni sürümlerin getirebileceği risk, planlı bakım ya da dış servislerdeki aksaklıklar için harcanabilecek paydır.
Hata bütçesi neden güçlü bir araçtır?
Hata bütçesi, güvenilirlik ile geliştirme hızı arasındaki tartışmayı kişisel görüşlerden çıkarıp veriye bağlar:
- Bütçe yeterliyse: Ekip yeni özellikleri yayına almaya, deneysel iyileştirmeleri kademeli olarak sunmaya devam eder.
- Bütçe azalıyorsa: Yayın sıklığı yavaşlatılır, riskli değişiklikler ertelenir, ekip kaynak ayırarak kökten iyileştirmelere odaklanır.
- Bütçe tükendiyse: Öncelik tamamen istikrara döner; yalnızca güvenilirliği artıran değişiklikler yayına çıkar.
Bu kural seti önceden üzerinde uzlaşılmış olduğunda, bir sorun yaşandığında "Bu hafta yeni sürüm çıkaralım mı?" sorusunun yanıtı tartışma gerektirmez.
Acente yazılımı için SLO örnekleri
SLO'lar, kullanıcı yolculuklarına göre tanımlandığında anlam kazanır. Aşağıdaki başlıklar, bir acente yazılımında hedef belirlenebilecek alanlara örnektir:
- Oturum açma: Başarı oranı ve tamamlanma süresi.
- Müşteri arama ve kart açma: Belirli bir süre içinde yanıtlanan istek oranı.
- Teklif başlatma: Trafik, kasko ve DASK için ayrı ayrı; sorgunun sisteme başarıyla alınma oranı.
- Arka plan bildirimleri: Yenileme hatırlatmalarının planlanan zaman aralığında gönderilme oranı.
Dış servisleri nasıl hesaba katmalı?
Teklif sonuçları sigorta şirketlerinin servislerine bağlıdır ve bu servislerin kesintileri yazılım ekibinin kontrolünde değildir. Bu nedenle SLO tanımlarında yazılımın kendi sorumluluğundaki kısım ile dış bağımlılıklar ayrılabilir. Örneğin "teklif isteğinin sisteme alınıp şirketlere iletilmesi" bir SLO, "şirketlerden yanıt gelme oranı" ise ayrı izlenen bir göstergedir. Bu ayrım, iç iyileştirme önceliklerini netleştirir ve dış kaynaklı sorunların kullanıcıya şeffaf biçimde gösterilmesini kolaylaştırır.
SLO belirlerken yapılan hatalar
- Kusursuzluk hedeflemek: Yüzde yüz hedefi, hiçbir değişikliğe izin vermeyen bir sistem demektir ve gerçekçi değildir.
- Çok fazla SLO tanımlamak: Her ekran için ayrı hedef, hiçbirinin takip edilmemesiyle sonuçlanır. Birkaç kritik yolculuk yeterlidir.
- Kullanıcıyla ilgisiz ölçümler: Sunucu kaynakları önemlidir ama SLO'nun konusu değildir.
- Hedefi hiç gözden geçirmemek: Kullanım biçimi değiştikçe SLO'lar da yeniden değerlendirilmelidir.
SLO ile sözleşmeli hizmet düzeyi arasındaki fark
SLO bir iç hedeftir; müşteriye taahhüt edilen hizmet düzeyi sözleşmesi (SLA) ise hukuki bir yükümlülüktür. Sağlıklı bir yaklaşımda iç hedefler, dışarıya verilen taahhütlerden daha sıkı tutulur. Böylece iç hedefte bir sapma olduğunda, kullanıcıya verilen sözü etkilemeden önlem almak için zaman kalır.
Acenteler için anlamı
Bir acente yazılımını değerlendirirken "Sisteminiz ne kadar güvenilir?" sorusu genellikle genel bir yanıtla karşılanır. Bunun yerine "Hangi kullanıcı yolculukları için hedef belirliyorsunuz ve bu hedeflerden sapıldığında ne yapıyorsunuz?" diye sormak çok daha bilgilendirici olur. Hedeflerini ölçen bir ekip, sorunları da daha erken fark eder. Bu yaklaşımın CRM ve teklif ekranlarındaki günlük karşılığını görmek için demo talep edebilirsiniz.
SLO'yu ölçerken iki önemli seçim
Zaman penceresi
Kayan pencere, her gün son birkaç haftaya bakar ve güvenilirliğin sürekli güncel bir resmini verir. Takvim penceresi ise ay başında sıfırlanır ve raporlama açısından daha anlaşılırdır. Kayan pencere operasyonel kararlar için, takvim penceresi ise dönemsel değerlendirmeler için daha uygundur. Önemli olan, hangisinin kullanıldığının herkes tarafından bilinmesidir.
Ölçüm noktası
SLI'yı sunucu tarafında ölçmek kolaydır; ancak kullanıcının cihazından sunucuya ulaşamayan istekler bu ölçüme hiç yansımaz. İstemci tarafında ölçmek kullanıcının gerçek deneyimine daha yakındır; ancak cihaz ve bağlantı farklılıkları gürültü ekler. Sağlıklı bir yaklaşım, SLO'yu sunucu tarafında tanımlarken istemci tarafı ölçümlerini de destekleyici gösterge olarak izlemektir. Özellikle sahada değişken bağlantıyla çalışan mobil kullanıcılar için bu ikinci bakış açısı önemlidir.
Bu iki seçim baştan netleştirildiğinde, SLO raporları ekipler arasında farklı yorumlanmaz.
SLO raporlarının düzenli olarak ürün ve yönetim toplantılarında paylaşılması da hedeflerin yalnızca teknik ekibin konusu olarak kalmamasını sağlar. Bütçenin hangi olaylar nedeniyle harcandığı görüldüğünde, güvenilirlik yatırımlarının önceliklendirilmesi çok daha kolay ve şeffaf hâle gelir.
Sonuç
SLO ve hata bütçesi, güvenilirliği soyut bir istek olmaktan çıkarıp yönetilebilir bir hedefe dönüştürür. Kullanıcı yolculuklarına göre tanımlanan birkaç anlamlı hedef ve önceden kararlaştırılmış kurallar, hem yeniliğin hem de istikrarın aynı anda korunmasını sağlar.