Hata Bütçeleri ve SLO Yönetimi

1) Neden SLO ve hata bütçesi

SLO (Hizmet Seviyesi Hedefi) - kullanıcı tarafından algılanan hedef kalite seviyesi; SLI - ölçülen metrik; Hata Bütçesi - pencere başına sapmalara tolerans (genellikle 30/90 gün).
Hata bütçesi, güvenilirliği bir "soyutlama'dan yönetilen bir kaynağa dönüştürür: bütçe hızlı bir şekilde tükendiğinde, özellikleri ve chinim'i dondururuz; Bütçe sağlıklı olduğunda - sürümleri hızlandırabilirsiniz.

2) SLI seçimi: 'iyi'olarak sayılan şey

Kriter: "Kullanıcının bakış açısından başarılı".

2. 1 Klasik SLI

Kullanılabilirlik, başarılı isteklerin yüzdesidir (müşteri tarafından iptal edilenler hariç).
'başarı = http_status ∈ {2xx, 3xx, 404} ve zaman aşımı yok' (404, anlambilim bekleniyorsa, okunan bir API başarısı olarak kabul edilebilir).
Gecikme: Isteklerin oranı eşikten daha hızlıdır (örneğin, p95 ≤ 300 ms).
'good _ latency = duration_ms ≤ 300'.
Tazelik/Sapkınlık: "X dakikadan daha eski olmayan veriler" (önbellek, dizinler, katsayılar).
Kalite: Sonucun doğruluğu (geçen iş doğrulayıcıları/arka uç değişmezleri).

2. 2 Sınırlar ve segmentler

SLI önemli dilimler tarafından sayılmalıdır: 'rota', 'kiracı/marka', 'bölge/yargı', 'ödeme _ sağlayıcı'. Böylece, sistem boyunca bir kritik tutamacın arızasını "lekelemeyeceksiniz".

3) Formüller ve bütçe

3. 1 İstek tabanlı (API için tercih edilir)

SLO_availability = good_requests / total_requests
Error_budget = 1 - SLO_target
Burn = 1 - SLO_actual

3. 2 Zaman tabanlı (arka plan hizmetleri/akış için)

SLO_uptime = good_minutes / total_minutes

3. 3 Hedefler örneği

API genel: 99. 30 günde %9 kullanılabilirlik - bütçe = 0. 1%.
Kritik ödeme kalemleri: 99. 95%; Kataloglar/arama: 99. 5%.
Gecikme: p95 ≤ 300 ms'/v1/payments ', p99 ≤ 800 ms.

4) SLI enstrümantasyonu

4. 1 İlkeler

Logs/Trails - KIRMIZI (Oran/Hatalar/Süre) metrikleri açık kovalarla.
'Kiracı', 'bölge', 'rota _ sınıfı' (PII olmadan) koyduğunuzdan emin olun.
İki metriği sayın: "başarı've" toplam've gecikme süresi için "hızlı've" toplam ".

4. 2 Prometheus örneği (5m başına oran)

promql
Availability (successes/total)
sli:success:rate5m = sum by(region, route)(
rate(http_requests_total{code=~"2..    3.."}[5m])
)
sli:total:rate5m = sum by(region, route)(
rate(http_requests_total[5m])
)
sli:availability:ratio5m = sli:success:rate5m / sli:total:rate5m

Latency (fraction faster than 300 ms)
sli:fast:rate5m = sum by(region, route)(
rate(http_request_duration_seconds_bucket{le="0. 3"}[5m])
)
sli:latency_ok:ratio5m = sli:fast:rate5m / sli:total:rate5m

5) Yanma oranına göre uyarılar (çoklu pencere, çoklu yanma)

5. 1 Fikir

Bütçenin hedefe göre ne kadar hızlı yandığına bakıyoruz. Kısa ve uzun bir pencerede hız yüksekse, sinyal veririz.

5. 2 Eşik profilleri (SLO 99 için. 9%)

Çağrı: yanma oranı ≥ 14. 4 × (1 saat için bütçenin %10'u ve 6 saat için %5).
Bilet: Yanma oranı ≥ 6 × (6 saatte %2 ve 24 saatte %1).

5. 3 Örnek kurallar (Prometheus, pseudo)

promql
Let's calculate the error_ratio on two windows short = 1 - (sum (rate (http_requests_total{code=~"2..    3.."}[5m])) /
sum(rate(http_requests_total[5m])))
long = 1 - (sum(rate(http_requests_total{code=~"2..    3.."}[1h])) /
sum(rate(http_requests_total[1h])))

For SLO = 99. 9%, error_budget=0. 001. BurnRate = error_ratio / 0. 001 burn_short = short / 0. 001 burn_long = long / 0. 001

Paging: Both windows exceed 14. 4× alert: SLOErrorBudgetBurnRateHigh expr: burn_short > 14. 4 and burn_long > 14. 4 for: 5m labels: { severity="page" }
annotations:
summary: "SLO burn rate high (short & long windows)"
runbook: "slo/runbooks/payments. md"

Benzer şekilde bilet için 6h/24h için.

6) Bütçe Ofisi: Süreçler

6. 1 Serbest bırakma kapıları

Bütçenin dengesi <%25 ise ve eğilim negatif ise - özellikler üzerinde "kod dondurma", öncelik SRE/istikrardır.
Kanarya sürümleri ayrı bir SLO dilimine ('dağıtımına sahip olmalıdır. çevre =" kanarya"').

6. 2 İş yükünün önceliklendirilmesi

Komuta kapasitesini yanma oranı ve gelir etkisi ile orantılı olarak dağıtın.
Teknik borcu metriklerle haklı çıkarın: "Düzeltme X, yanma oranını % Y oranında azaltacaktır".

6. 3 Olay sonrası

Her olay - RCA ve "geri alınamayan düzeltme" (işlem yapılabilir), kontrol "SLO'ya geri döndü".

7) Kod olarak SLO

7. 1 SLO Manifesto Örneği (YAML)

yaml service: payments-api owner: team-payments slis:
- name: availability type: request_based success_query: sum(rate(http_requests_total{svc="pay",code=~"2..    3.."}[5m]))
total_query:  sum(rate(http_requests_total{svc="pay"}[5m]))
objective: 99. 95 window: 30d segments: ["region", "tenant", "route"]
- name: latency_p95_300ms type: latency_threshold good_query: sum(rate(http_request_duration_seconds_bucket{svc="pay",le="0. 3"}[5m]))
total_query: sum(rate(http_request_duration_seconds_count{svc="pay"}[5m]))
objective: 99. 0 window: 30d alerts:
- name: burn_high_page windows: ["5m", "1h"]
threshold_burn: 14. 4 severity: page

7. 2 Kural oluşturma

Otomatik olarak kurallar, panolar ve raporlar oluşturmak için jeneratörler (slo-generator, pyrra, sloth) kullanın.

8) SLO bozulması ve koruması

Load shedder: Zirvede "pahalı" bağımlılıklar olmadan hızlı cevaplar verin.
Önbellek & bayat: 'bayat-while-revalidate' для okundu.
Oran/Eşzamanlılık sınırları: arka uçları korur; Önemli yollar - öncelik.
Devre/Zaman Aşımı: hızlı zaman aşımları ve "geri dönüş" dalları.
Özellik bayrakları: Tek bir düğmeyle ağır özellikleri devre dışı bırakmak.

9) SLO için gözlemlenebilirlik

Panolar: SLO gerçek vs hedef, bütçe dengesi, yanma oranı, rotalar/sağlayıcılar tarafından katkı.
Korelasyon: SLO'nun "deliğinden" - örneklemeye - belirli bir iz - günlükler/profiller.
Raporlar: haftalık - eğilimler, bütçe tüketimi, bozulmanın en önemli nedenleri.

10) Antipatterns

Bütün için bir "küresel" SLO - maske sorunları. Bölümü.
«99. Her şeyde %99" maliyet ve gerçeklik hariç. Kullanıcı deneyiminden hedefler seçin.
Yanma hızı/SLO yerine CPU/yığın uyarıları.
UX'i bozan 4xx/long yönlendirmeleri göz ardı etme.
Opak pencere (yuvarlanma vs takvim) - "portakallı elmaların" karşılaştırılması.

11) iGaming/Finansın Özellikleri

Para yolları (para yatırma/çekme): Genel seviyenin üzerindeki bireysel SLO'lar (örn. 99. %95 kullanılabilirlik; P95 ≤ 250 ms).
PSP/KYC sağlayıcıları: Her sağlayıcı için SLO + yakmaya katkıları için uyarılar; otomatik rota değiştirme (akıllı yönlendirme).
Yargı alanları/kiracılar: SLO'lar ve bütçeler "bölge/yargı/marka'ya göre, böylece yerel bir sorun küresel metriği" taşmaz ".
Sorumlu oyun: Sınırların uygulanması/kendini dışlama (uyumluluk formülleri) dönemi için SLO.
Denetim/düzenleme: SLO ve olay raporlarını tutmak; İç denetimler için şeffaflık.

12) Prod Hazırlık Kontrol Listesi

• SLI'lar (kullanılabilirlik/gecikme/kalite/tazelik) ve segmentler (rota/kiracı/bölge) tanımlanmıştır.
• Hedefler (SLO'lar) gerçekçidir, işle uyumludur; 30/90 gün yuvarlanan pencereler vardır.
• Çoklu pencerelerle yanma oranına göre uyarılar (çağrı/bilet).
• Kod olarak SLO (kural/gösterge paneli üreticisi); bütçe raporları.
• Serbest bırakma kapıları bütçenin geri kalanına bağlıdır; kanarya bölümleri.
• Bozulma mekanizmaları (shedder, önbellek bayat, devre, limitler) uygulanır ve test edilir.
• Metrikler ↔ izler korelasyonu, açık çalışma kitapları.
• Finansal/yargı yolları - ayrı SLO'lar/uyarılar; PSP/KYC ayrıştırılmıştır.
• Düzenli olay retro ve yanık tabanlı güvenilirlik yatırımları.

13) TL; DR

SLI'ları kullanıcı değerine göre tanımlayın, gerçekçi SLO'ları ayarlayın ve Hata Bütçesi ve çoklu pencerelerle yakma oranı ile yönetin. Planlandığı gibi SLO-as-code, release gates ve degradasyonu etkinleştirin. Rota/kiracı/bölgeye göre segment; Para yolları için daha sıkı hedefler ve ayrı uyarılar tutmak.