SLO tasarımında en sık yapılan 5 hata

SLO kurmak kolay, SLO'yla yönetmek zordur. Onlarca kurumda güvenilirlik programı kurarken aynı hataların tekrarlandığını görüyoruz. İşte en pahalı beş tanesi.

1. Sistem metriğinden başlamak

CPU, bellek ve disk doluluk SLO'su olmaz. SLO müşteri deneyiminin vekilidir: 'fatura ödeme isteklerinin %99,9'u 800ms altında başarılı dönmeli' bir SLO'dur; 'CPU %80'i geçmemeli' bir kapasite alarmıdır. Müşteri yolculuğundan geriye doğru tasarlamayan her SLO seti, alarm yorgunluğunun yeni bir biçimine dönüşür.

2. %100'e çok yakın hedefler

%99,99 hedeflemek ayda 4,3 dakikalık hata bütçesi demektir; bu bütçeyle ne deney yapabilir ne planlı bakım sığdırabilirsiniz. Hedefi müşterinin gerçekten fark ettiği eşiğe göre koyun. Çoğu iç servis için %99,5 fazlasıyla yeterlidir ve ekibe nefes alanı bırakır.

3. Hata bütçesini politikasız bırakmak

Bütçe tükendiğinde ne olacağı önceden yazılı değilse, SLO bir süs metriğidir. 'Bütçe tükenirse yeni özellik dağıtımı durur, kapasite ve dayanıklılık işleri öne alınır' gibi açık bir politika; SLO'yu mühendislikle ürün yönetimi arasında ortak bir dile çevirir.

4 ve 5: Tek seferde her şeyi ölçmek, hiç revize etmemek

İlk fazda 10-15 kritik kullanıcı yolculuğuyla sınırlı kalın; 120 SLO'luk olgun setlere giden yol, çalışan küçük bir çekirdekten geçer. Ve her çeyrekte SLO'ları gözden geçirin: iş öncelikleri değişirken sabit kalan güvenilirlik hedefi, ya fazla mühendislik ya görünmez risk üretiyordur.