SLO nedir? Hata bütçesi, burn rate ve rollout kapısı

SLO nedir? Hizmet seviyesi hedefi (SLO), belirli bir kullanıcıya dönük davranışın sabit bir süre boyunca ne kadar güvenilir olması gerektiğini tanımlayan hedeftir. "Ödeme isteklerinin %99.9'u 30 gün boyunca 800 ms altında başarılı olmalı" bir SLO'dur. "Site hızlı olmalı" ise bir dilektir. Sayının kendisi, neyi kontrol ettiği kadar önemli değildir: SLO, ne zaman yayın yapmaya devam edeceğinize ve ne zaman duracağınıza karar verir.

Saat 03:12. PagerDuty ödeme akışındaki gecikmenin "yükseldiğini" bildiriyor. Dashboard'u açıyorsunuz ve kırk dakikadır yukarı tırmanan bir p99 çizgisi görüyorsunuz. Bunun bir sorun olup olmadığını kimse söyleyemiyor, çünkü ne kadar gecikmenin fazla olduğu daha önce hiç yazıya dökülmemiş. Telefonda, bir gözünüz Slack'te, süren tartışma SLO'su olmamanın bedelidir.

SLI, SLO, SLA: üç kelime, üç sahip

İnsanlar bu üç terimi birbirinin yerine kullanıyor. Oysa aynı şey değiller ve bunları karıştırmak, yerine getiremeyeceğiniz bir sözleşmeyle baş başa kalmanın en kısa yoludur.

• SLI (hizmet seviyesi göstergesi) ölçümdür. Geçerli olayların iyi olaylara oranıdır: 800 ms altında 2xx dönen istekler bölü olması gereken tüm istekler.

• SLO (hizmet seviyesi hedefi) bu oran için bir pencere boyunca konan hedeftir. 30 gün boyunca %99.9.

• SLA (hizmet seviyesi anlaşması) bir müşteriyle yapılan sözleşmedir ve hedef kaçırılırsa parasal bir bedeli vardır. Her zaman SLO'dan daha gevşek olmalıdır. SLA'nız %99.9 diyorsa ve SLO'nuz da %99.9 diyorsa, kredi ödemeden önce bir sorunu fark etmek için hiç alanınız kalmaz.

Google SRE kitabındaki hizmet seviyesi hedefleri bölümü aynı ayrımı yapar: SLO, dışarıya verdiğiniz her sözden daha sıkı olan iç bir hedeftir. SLI ve SLO'nun sahibi mühendislik ekibidir, SLA'nın sahibi ise ürün ve hukuk ekibidir.

Topladığınız her metrik için dördüncü bir kelime uydurma dürtüsüne direnin. CPU, bellek ve kuyruk derinliği hata ayıklamada işe yarar. Ama SLI değildirler, çünkü hiçbir müşteri bunları doğrudan deneyimlemez.

İyi bir SLI pratikte nasıl görünür?

İyi bir SLI bir orandır, kullanıcıya mümkün olduğunca yakın ölçülür ve "iyi"nin ne olduğu açıkça tanımlanmıştır.

İstek odaklı bir servis için varsayılan olarak iki SLI yeterlidir: erişilebilirlik (geçerli isteklerin 5xx olmayan yanıtları) ve gecikme (geçerli isteklerin belirli bir eşiğin altında kalanları). Ortalama değil, eşik kullanın. Ortalama kuyruğu gizler ve destek biletleri tam olarak kuyruktan gelir.

Ölçümü servisin içinde değil, load balancer'da ya da edge katmanında yapın. Açılışta çöken bir servis, hiç almadığı istekler için mükemmel bir hata oranı raporlar. Sunucu tarafı metrikleri bu hatayı göremez, kullanıcı ise onu kesinti olarak yaşar.

Hariç tutulanları açıkça yazın. Sağlık kontrolleri, kendi izlemenizden gelen sentetik probe'lar ve kötü istemci girdisinden kaynaklanan 4xx yanıtları genellikle hedefinizi düşürmemelidir. Bunları SLO'nun yanına yazın. Bir olay incelemesinde biri sayı üzerine tartışmaya başladığında, tartışma dashboard'un ne gösterdiği üzerine değil, tanım üzerine olmalıdır.

Hedef seçmeden önce dokuzların hesabını yapın

Her ek dokuz, izin verilen kesinti süresini on kat azaltır. Bu listeyi dokümanınızda saklayın:

• %99, 30 günde: %1 hata bütçesi, yani 7.2 saat tam kesinti.

• %99.9: %0.1 bütçe, 43.2 dakika.

• %99.95: %0.05 bütçe, 21.6 dakika.

• %99.99: %0.01 bütçe, 4.32 dakika.

Son satırı bir daha okuyun. %99.99'da, tespit edilmesi ve geri alınması beş dakika süren tek bir kötü deploy bile ayın bütçesini çoktan bitirmiş olur. İnsanların çağrıya yanıt verip dizüstü bilgisayarı açması ve dört dakikadan kısa sürede geri alması mümkün değildir. Bu hedef yalnızca otomasyonla ulaşılabilir: bütçe bitmeden rollout'u durduran otomatik bir kapı gerekir.

Bu yüzden servisin gerçekten ihtiyaç duyduğu sayıyı seçin. Çoğu dahili API %99.9'da rahatça yaşar. Bir ödeme yolu daha fazlasını gerektirebilir. Gece çalışan bir toplu iş %99 ile de idare edebilir. Kulağa ciddi geldiği için %99.99 seçmek, dolduramayacağınız bir nöbet rotasyonuna imza atmak demektir.

Hata bütçesi, SLO'nun kendisinden daha önemli

%99.9'luk bir SLO, zamanın %0.1'inde başarısız olmanıza izin verdiğiniz anlamına gelir. Bu %0.1 hata bütçenizdir ve bu disiplinin en kullanışlı fikridir.

Bütçe bir tartışmayı bir sayıya çevirir. Ürün riskli bir migration'ı yayınlamak ister, SRE bunun riskli olduğunu söyler. Bütçe yoksa bu iki görüş arasında kıdem kazanır. Bütçe varsa soru şuna döner: ne kadarı kaldı ve bu değişiklik makul bir şekilde ne kadarını harcar?

İki kural bunu işletir:

1. Bütçe kaldıysa: yayınlayın. Risk almak serbesttir, o yüzden alın. Bütçesini hiç harcamayan bir ekip, kullanıcıların istemediği güvenilirliğe fazla yatırım yapıyordur.

2. Bütçe bittiyse: dondurun. Güvenilirlik işi SLI'yi yeniden hedefin üstüne çıkarana kadar özellik geliştirme durur. Bu kural ancak liderlik ilk olay yaşanmadan önce kabul ettiyse işler, olay sırasında kabul edilirse işlemez.

Bu ikinci kural önceden kararlaştırılmamışsa, ortada bir SLO yoktur. Yeşil ve kırmızı bölgeli bir dashboard vardır.

Doğrudan SLI'ya değil, burn rate'e alarm kurun

Çoğu ilk denemenin takıldığı yer burasıdır. Biri erişilebilirlik %99.9'un altına düştüğünde alarm kurar. Alarm ya zarar verildikten sonra çalar ya da her küçük dalgalanmada titrer. Bazen ikisi birden olur.

Daha iyi sinyal burn rate'tir: bütçeyi, pencere sonunda tam olarak tüketecek tempoya kıyasla ne kadar hızlı harcadığınız. Burn rate 1, ayı sıfır bütçeyle bitireceğiniz anlamına gelir. Burn rate 14.4 ise bir aylık bütçeyi yaklaşık iki günde yakacağınız anlamına gelir.

Google SRE Workbook'un SLO alarmları bölümü uzun ve kısa bir pencereyi birlikte kullanmayı önerir. Böylece alarm hem anlamlı olur hem de sorun hâlâ sürüyor olur. 30 günlük bir SLO için iki sayfa iyi bir başlangıç noktasıdır:

• 1 saatlik pencerede burn rate 14.4, 5 dakikalık pencereyle doğrulanmış: aylık bütçenin %2'sini tüketir. Birini çağırın.

• 6 saatlik pencerede burn rate 6, 30 dakikalık pencereyle doğrulanmış: aylık bütçenin %5'ini tüketir. Birini çağırın.

Hesap açık: 30 günlük pencere 720 saattir. 14.4 kat hızla bir saat yanmak, 14.4 / 720 = %2 bütçe demektir. Kısa pencere, sorun bittikten bir saat sonra alarmın çalmasını engeller.

İlk kuralı, pencere başına bir hata oranı kaydettiğinizi varsayarak bir Prometheus alarmı olarak yazalım:

groups:
  - name: checkout-slo-burn
    rules:
      - alert: CheckoutErrorBudgetFastBurn
        expr: |
          job:checkout_error_ratio:rate1h > (14.4 * 0.001)
          and
          job:checkout_error_ratio:rate5m > (14.4 * 0.001)
        labels:
          severity: page
        annotations:
          summary: "Checkout, 30 günlük hata bütçesinin saatte %2'sini tüketiyor"

Koddaki 0.001, %99.9 SLO için izin verilen hata oranıdır. Hedefi değiştirirseniz bu sabit de onunla birlikte değişmelidir. Bunu tek bir yerde tutun, yoksa alarm ve SLO kimse fark etmeden birbirinden uzaklaşır.

Yavaş yanışlar sayfa gerektirmez. Üç gün boyunca sürdürülen burn rate 1, bir sonraki iş sabahı için bir bilet konusudur. Yavaş bir sızıntı için birini uyandırmak, nöbet ekiplerinin çağrı cihazını görmezden gelmeyi öğrenmesinin yoludur.

SLO'yu rollout'a bağlamak ve SLI'yı nerede ölçmeli?

SLI'yı ikinci bir platform satın almadan ölçebilirsiniz. Başlamak için özel bir SLO ürününe ihtiyacınız yok. İyi olay sayacına, toplam olay sayacına ve bu verileri 30 gün saklayacak bir yere ihtiyacınız var.

Metrikleriniz zaten barındırılan bir platformdaysa, SLO özelliği çoğu zaman zaten ödediğiniz verinin üzerindeki ince bir katmandır.

Datadog, SLO'ları burn rate alarmlarıyla birlikte yerel olarak sunar. Trace'leriniz ve metrikleriniz zaten oradaysa en kolay yoldur. Tuzak faturadır: özel metrikler ve yüksek kardinaliteli etiketler hızla çoğalır, bu yüzden taahhüt etmeden önce SLI serilerinin fiyatını kontrol edin.

Prometheus kullanıyorsanız Grafana, recording rule'lar ve kendi SLO araçlarıyla aynı alanı kapsar. Bunun bedeli daha fazla kurulum ve kendi zamanınızdır.

Dürüst karşılaştırma, ilk işe yarar alarma kadar geçen süre ile ölçek büyüdüğünde maliyet arasındadır. İlkinde Datadog, ikincisinde genellikle Grafana ile Prometheus öne çıkar. Ekibinizin neyi kıt olduğuna bakarak seçin.

Yalnızca rapor üreten bir SLO yarım kullanılmıştır. Davranışı değiştiren adım, bütçeyi deploy yoluna bağlamaktır. Böylece yayın kendini durdurur.

SLO kapılı bir aşamalı rollout şöyle çalışır: bir flag arkasında trafiğin %1'ine gönderin. Bu kohortun SLI'sını baseline ile karşılaştırarak izleyin. Canary kohortunun burn rate'i eşiği aşarsa otomatik olarak geri alın. Eşik tutuyorsa %5'e, sonra %25'e, sonra %100'e geçin.

Bu, saat 03:12'de birinin izlemesi gereken bir dashboard'dan farklıdır. 03:12'de düşünmek istemezsiniz. Bir düğmeye ihtiyacınız vardır, ya da daha iyisi hiç düğmeye ihtiyacınız olmaz.

Feature flag'ler burada hak ettiği değeri verir. Flag, geri almayı on dakika süren bir redeploy yerine saniyeler süren bir konfigürasyon değişikliğine dönüştürür.

LaunchDarkly ve benzeri platformlar yüzde bazlı rollout ve kill switch sunar. Çoğunun size bıraktığı şey ise kararın kendisidir: hangi SLI okunacak, hangi eşiğin kötü sayılacağı ve kimin geçersiz kılabileceği. upstreamapi'nin, SLO üzerinde otomatik geri almayla çalışan bir AI pilot ile kapatmaya çalıştığı boşluk tam olarak budur. LaunchDarkly, SDK kapsamı ve kurumsal kontrollerde önde. Bunu da açıkça söylüyoruz.

Kapının TypeScript'teki şekli şöyle. Hangi feature flag sistemini kullanırsanız kullanın, karar mantığını kendiniz yazmaya değer:

type Cohort = { good: number; total: number };

const SLO_TARGET = 0.999;
const BUDGET = 1 - SLO_TARGET; // 0.001
const PAGE_BURN_RATE = 14.4;

function burnRate(c: Cohort): number {
  if (c.total === 0) return 0;
  const errorRatio = 1 - c.good / c.total;
  return errorRatio / BUDGET;
}

export function rolloutDecision(canary: Cohort): "advance" | "hold" | "revert" {
  if (canary.total < 500) return "hold"; // trafik az, karar için yeterli veri yok
  return burnRate(canary) > PAGE_BURN_RATE ? "revert" : "advance";
}

hold dalına dikkat edin. Sakin bir servisin %1'lik canary'si on dakikada kırk istek görebilir ve kırk istekte tek bir hata, %2.5'lik bir hata oranı demektir. Minimum örneklem olmadan kapı gürültüye tepki verir ve geri alır. Ekibiniz de ona güvenmeyi bırakır.

80 mühendisli ekiplerde gördüğümüz hatalar ve bu hafta nereden başlanacağı

Aynı birkaç hata ekipler arasında tekrar ediyor. Bunların neredeyse hiçbiri teknik değil.

Çok fazla SLO. Servis başına yirmi hedef, kimsenin birini bile hatırlamaması demektir. Kullanıcı yolculuğu başına iki ya da üç hedef yeterlidir.

Kimsenin kabul etmediği SLO'lar. Bir mühendis hafta sonu tek başına yazar. Ürün ekibi hiç görmemiştir, bu yüzden bütçe politikası ilk "hayır" cevabında çöker.

Mevcut performansa göre belirlenen hedefler. Servis bugün %99.97'de çalışıyorsa, hedefi %99.97 koymak bütçe bırakmaz ve kaçırmayı garanti eder. Hedefi, kullanıcıların memnuniyetsizliğe başladığı noktaya koyun. Bu neredeyse her zaman daha düşüktür.

SLO'yu kalıcı sanmak. Sayıyı her çeyrek gözden geçirin. Bütçeyi hiç harcamıyorsanız hedefi sıkılaştırın ya da daha hızlı yayın yapın. Her ay kaçırıyorsanız sistemi düzeltin ya da hedefin bir hayal olduğunu kabul edin.

Hissedileni değil, kolay ölçüleni saymak. Boş sepetle dönen bir 200 yanıtı loglarınızda başarıdır, müşteri için ise başarısızlıktır. "İyi"yi kullanıcının gözünden tanımlayın.

Bir programa ihtiyacınız yok. Bozulduğunda CEO'nun birini aradığı tek bir yolculuk seçin. Bunun için bir erişilebilirlik SLI'si ve bir gecikme SLI'si tanımlayın. İlk çeyrek için hedefi %99.9 koyun, dondurma politikasını iki cümleyle yazın ve ürün ekibinden yazılı olarak "kabul ediyoruz" yanıtı alın.

Sonra bir burn rate alarmı ekleyin ve kalan bütçeyi tüm ekibin görebileceği bir yere koyun.

Tam bir platforma geçmeden önce hafif bir başlangıç arıyorsanız Better Stack, daha küçük bir kurulumla uptime izleme ve olay çağrısı yönetir. Ama bütçe matematiğini sizin yerinize yapmaz.

İlk sürüm yanlış olacaktır. Bu kabul edilebilir. Önemli olan, bir sonraki olay incelemesinin bir hisle değil, önceden yazılmış bir sayıyla başlamasıdır.

Peki şimdi 03:12'niz nasıl görünüyor?

Ekibinizin son olayını düşünün. Önemli olup olmadığını söyleyen yazılı bir sayı var mıydı? Dürüst cevap hayırsa, işte ilk SLO'nuz. Post-mortem de size neyi ölçmeniz gerektiğini zaten söyledi.