SLO nedir, hata bütçesi ve burn-rate alarmları nasıl çalışır?

Önce bütçeyi hesaplayın

SLI, ölçtüğünüz şeydir (örneğin başarılı isteklerin oranı). SLO, bu ölçüm için koyduğunuz hedeftir. Hata bütçesi ise hedefin izin verdiği başarısızlık payıdır.

30 günde yüzde 99,9 hedefi kulağa sert gelir, ama aslında bir harcama hakkıdır. 30 gün 43.200 dakikadır, bunun yüzde 0,1'i tam kesintide 43,2 dakika eder. İstek bazında bakarsak, o dönemde 20 milyon istek karşılayan bir servis (örnek rakam) 20.000 isteği başarısız yapabilir.

Tablodan iki şey çıkar. Her ek dokuz, hata payını on kat azaltır; bu yüzden hedef kulağa iyi geleni değil, kullanıcının ihtiyacını yansıtmalıdır. Yüzde 99,99'da ise hiçbir insan aramaya cevap verip tam kesintiyi zamanında çözemez, bu hedef otomasyon, yedeklilik ve çok dikkatli sürüm süreci gerektirir. Savunamadığınız bir hedefe kimse saygı duymaz.

Bütçe, ürün ve mühendislik arasındaki konuşmayı da değiştirir. Sürümlere, denemelere ve geçişlere harcanabilecek ortak bir miktar olur. Bittiğinde ne olacağını önceden yazılı bir politikayla belirleyin. Kendi rakamlarınızı denemek için SLO ve burn-rate hesaplayıcı sayfasını kullanabilirsiniz.

Hata oranı eşiği neden yetmez?

"Hata oranı yüzde 0,1'in üstünde" alarmı 30 saniyelik bir sıçramayla 12 saatlik bir tükenmeyi aynı görür. Bütçenin çok küçük bir kısmını yiyen sıçrama için arar. Bunu önlemek için değerlendirme penceresini genişletirseniz ciddi bir olayda çok geç tepki verir.

Burn rate bunu şöyle çözer: bütçeyi, pencerenin sonunda tam bitirecek hıza kıyasla ne kadar hızlı harcıyorsunuz? Burn rate 1, 30 günlük bütçeyi 30 günde bitirir. Burn rate 10, 3 günde bitirir. Yüzde 99,9 hedefte burn rate 1, yüzde 0,1 hata oranına; burn rate 14,4 ise yüzde 1,44 hata oranına karşılık gelir.

Dört pencere çifti

Wrentrix SLO'ları hata bütçesi ve 4 burn-rate pencere çifti kullanır, çok pencereli alarmlar kendiliğinden kapanır. Bu tasarımın yaygın başvuru kaynağı The Site Reliability Workbook kitabıdır. Tablosu 30 günlük pencere için aşağıda, hesabıyla birlikte. Kendi kurulumunuzdaki değerleri kontrol edin, hedefiniz gerektiriyorsa uyarlayın.

Hesap şöyle: 30 gün 720 saattir. Harcanan bütçe, burn rate çarpı uzun pencere bölü 720'dir.

14,4 × 1 ÷ 720 = 0,02   (yüzde 2)
6 × 6 ÷ 720 = 0,05      (yüzde 5)
3 × 24 ÷ 720 = 0,10     (yüzde 10)
1 × 72 ÷ 720 = 0,10     (yüzde 10)
Bitme süresi = 720 saat ÷ burn rate

Her satır farklı bir soruya cevap verir. İlki şu anda hızlı bir yanma olup olmadığını sorar. Sonuncusu kimsenin fark etmeyeceği yavaş bir sızıntı olup olmadığını sorar.

Kısa pencere ne işe yarar?

Kısa pencere genellikle atlanan kısımdır ve bu alarmların iyi davranmasının nedeni odur. Alarm yalnızca hem uzun hem kısa pencere eşiği aşarsa çalışır.

İlk satır için yüzde 99,9 hedefte örnek bir zaman çizelgesi. 14.00'teki dağıtım isteklerin yüzde 4'ünü başarısız yapıyor, 14.30'da geri alma tamamlanıyor ve önceki bir saat temiz.

• Yaklaşık 14.22'de son bir saatin hata oranı yüzde 1,44'e ulaşır (4 × 21,6 ÷ 60 = 1,44). 5 dakikalık pencere de yüzde 4 ile eşiğin üstündedir. Arama gider.
• 14.30'da hatalar durur.
• Yaklaşık 14.33'te 5 dakikalık pencere eşiğin altına iner (son 5 dakikada kalan 1,8 dakikalık hata: 4 × 1,8 ÷ 5 = 1,44). Alarm kapanır. 1 saatlik pencere hâlâ yüksektir, yüzde 2 civarında kalır (4 × 30 ÷ 60 = 2).

Kısa pencere olmasaydı alarm, 1 saatlik oranın yüzde 1,44'ün altına indiği 15.08 civarına kadar kırmızı kalırdı. O an pencerede 21,6 dakikalık hata kalır, yani 15.00'ten sonra 8,4 dakika geçmesi gerekir. Geri alma yapan kişi düzeltmenin işe yarayıp yaramadığını alarmdan anlayamazdı. Kısa pencere sayesinde alarm dakikalar içinde kapanır, "bu hâlâ sürüyor mu?" gürültüsü ortadan kalkar. Otomatik müdahaleyle de iyi uyuşur: başarılı bir eylem kapanan bir alarm olarak görünür.

Neyi ölçmeli?

Alarm mekaniği işin kolay kısmıdır, zor olan göstergedir.

Kullanıcının yaşadığını kullanıcıya olabildiğince yakın ölçün. Veritabanı ayakta ama uygulama 500 dönüyorsa bu kesintidir. Uçtaki veya müşteriye en yakın servisteki istek bazlı göstergeler genellikle sunucu erişilebilirliğinden iyidir.

"İyi" kelimesini açıkça tanımlayın. Yaygın bir gecikme göstergesi, eşiğin altında karşılanan isteklerin oranıdır: "POST /basvuru isteklerinin yüzde 99'u 800 ms altında biter". Bu, hata oranı gibi davrandığı için aynı bütçe hesabına uyar. Doğrudan p99 üzerine yazılan SLO'yu yorumlamak daha zordur, farklı pencerelerin yüzdelikleri birleştirilemez.

Neyin hariç olduğuna karar verin. 4xx yanıtlar hata mı? Yük altında döndürdüğünüz 429 genellikle aleyhinize sayılır, yanlış yazılmış adres için 404 sayılmamalı. Sonradan sorulacağı için yazın.

Uç nokta başına bir SLO yazmayın. Kullanıcının yapmaya çalıştığı işe göre gruplayın: giriş, arama, ödeme. İnsanların baktığı birkaç SLO, kimsenin bakmadığı yüzlercesinden iyidir. Çok az trafik alan serviste yüzdeler zıplar, 50 istekte bir hata zaten yüzde 2'dir. Bu servislerde daha uzun pencereler veya sentetik probların trafiğini kullanın.

Örneklemeye dikkat edin. Gösterge örneklenmiş veriden hesaplanıyorsa bunu hesaba katmalısınız. Tüm hataları ve başarılıların yüzde 5'ini saklayan bir örnek, doğrudan sayılırsa hata oranını çok şişirir. Sözleşmesel bir amaçla kullanmadan önce metriğin nereden geldiğini doğrulayın. Örneklemenin nasıl çalıştığını dağıtık izleme nedir yazısında anlattık.

SLO'dan nedene

Tek başına SLO bir yerin acıdığını söyler. Alarmdan nedene gitmek ürünün diğer parçalarıyla olur. Tracing tarafındaki uç nokta yüzdelikleri ve hata gruplarıyla başlarsınız, taban çizgilerinden sapmalara bakarsınız. Problem motoru sinyalleri topolojiye göre tek olayda toplar, böylece tek arıza üst servislerin her birinde ayrı SLO ihlali gibi görünmez. Yapay zekâ açıksa yerel model ile SLO üzerinde "bu ekranı açıkla" da kullanılabilir. Özellikle maaş günü veya son başvuru günü gibi takvime bağlı yüklerde SLO, taban çizgisinin söyleyemediğini söyler. Örnek için bankacılıkta uygulama izleme sayfasına bakın. Akışı canlı demoda örnek veriyle görebilirsiniz.

Kurumsal bir sınır da var. Araçlar bütçeyi hesaplayıp doğru zamanda arayabilir. Ama sürümü kimin dondurabileceğine veya ürün sahibinin bir hedefi kabul edip etmeyeceğine karar veremez. Bu anlaşma olmadan burn-rate alarmı kuran ekipler hiçbir şeyi değiştirmeyen doğru rakamlar elde eder.

SLO'nun doğru başlangıç olmadığı durumlar

Servisinizin gerçek kullanıcı trafiği yoksa ya da temel enstrümantasyon eksikse önce onları yazın. Her gece çalışan bir toplu iş için SLO, istek oranından çok "06.00'ya kadar tamamlandı" biçiminde ifade edilmelidir. Yeni açılmış, davranışı bilinmeyen bir sistem de bir rakama söz vermeden önce birkaç hafta gözlemden faydalanır. Bir ekibin güvendiği, az arama üreten alarmları varsa hepsini hemen yenilemeye gerek yoktur. Değişikliği servis servis yapın.

Sık sorulan sorular

SLO nedir?

SLO (service level objective), bir servisin belirli bir dönemde ulaşmayı hedeflediği hizmet düzeyidir, örneğin 30 günde isteklerin yüzde 99,9'unun başarılı olması. SLI bunu ölçen göstergedir. SLA ise sözleşmeye yazılmış ve genellikle yaptırımı olan taahhüttür.

Hata bütçesi nedir?

Bir SLO'nun penceresi içinde izin verdiği başarısızlık miktarıdır. 30 günde yüzde 99,9 hedef, isteklerin yüzde 0,1'inin başarısız olmasına izin verir; bu da tam kesintide 43,2 dakikaya eşittir. Ekipler bu payı sürümlere ve riske harcayabilir, bittiğinde ne olacağına yazılı bir politika karar verir.

Burn rate 14,4 ne demek?

Bütçeyi, pencerenin sonunda tam bitirecek hızın 14,4 katı hızla harcadığınız anlamına gelir. 30 günlük pencerede bütçe 50 saatte biter, bir saat bu hızda gitmek bütçenin yüzde 2'sini yer. Yüzde 99,9 hedefte bu, yüzde 1,44 hata oranına karşılık gelir.

Tek alarm için neden iki pencere kullanılır?

Uzun pencere bütçenin anlamlı bir kısmının gerçekten harcandığını gösterir, böylece kısa sıçramalar arama yaptırmaz. Kısa pencere sorunun hâlâ sürdüğünü gösterir, böylece alarm düzeltmeden kısa süre sonra kapanır. İkisi birlikte hem doğruluk hem de hızlı toparlanma sağlar.

Başlangıç için iyi bir SLO hedefi nedir?

Servisin son dönemde gerçekten sağladığına ve kullanıcının ihtiyacına dayandırın, daha çok dokuzlu yuvarlak bir rakama değil. Mevcut ölçülmüş performansınızdan biraz daha sıkı bir hedef pratik bir başlangıçtır. Bir iki ay sonra gözden geçirin, ilk hedef nadiren doğru çıkar.