SLA, SLO ve Güvenilirlik KPI

1) Şartlar ve farklılıklar

SLI (Hizmet Seviyesi Göstergesi) - ölçülebilir bir kalite göstergesi (örneğin, başarılı taleplerin oranı, p95 gecikmesi).
SLO (Hizmet Seviyesi Hedefi) - zaman penceresi başına hedef SLI değeri (örneğin, "başarı ≥ 99. 28 günde %9").
Hata Bütçesi - İzin verilen SLO başarısızlık oranı '1 − SLO'dur.
SLA (Hizmet Seviyesi Anlaşması) - para cezaları/krediler ile sözleşme yükümlülükleri (dış).
Güvenilirlik KPI'ları - operasyonel süreç metrikleri (MTTD/MTTA/MTTR/MTBF, % otomatik hafifletme, uyarı kapsamı, vb.).

2) SLI nasıl seçilir (Altın Sinyallere göre)

1. Gecikme - anahtar uç noktalar için p95/p99.
2. Trafik - RPS/RPM/mesaj akışı.
3. Hatalar - 5xx/iş hatalarının payı (örneğin, PSP hatası nedeniyle ödeme "düşüşünü hariç tutun).
4. Doygunluk - kaynak doygunluğu (CPU/RAM/IO/lag).

• Kullanıcı tarafından algılanan deneyim ile ilişkilidir.
• Teknik olarak kullanılabilir ve ölçümlerde stabil.
• Kontrol ediyoruz (iyileştirme eylemleri mümkündür).
• Düşük toplama maliyeti.

3) Formüller ve Örnekler

3. 1 Kullanılabilirlik

Availability = Успешные запросы / Все запросы
Error Budget (за период) = 1 − SLO

Örnek: SLO 99. 30 günde %9 - hata bütçesi = 0. %1, 43 dakika 12 saniye kullanılabilirliğe eşdeğerdir.

3. 2 Gecikme süresi

Latency SLI = доля запросов с duration ≤ T
SLO пример: 99% запросов ≤ 300 мс (rolling 28d)

3. 3 Ödemeler (İş Seviyesi)

Payment Success SLI = (успешные проводки — внешние отказы PSP) / все попытки

4) Hatalı bütçe ve yanma oranı

Bütçe hatası - yenilik için "yakıt deponuz" (sürümler, deneyler).

• Hızlı kanal (~ 1 h'de algılama),
• Yavaş kanal (~ 6-12 saat/24 saat üzerinde eğilim).

• Yanma oranı> 14 ise. 1 saatte 4 - SEV-1 (günlük bütçeyi ~ 100 dakika içinde yiyeceğiz).
• Yanma oranı> 6 saat içinde 6 ise - SEV-2 (hızlı bozulma).

5) SLO ile uyarı (çoklu pencere, çoklu yanma)

Hata göstergesi: 5xx veya gecikme ihlallerinin oranı.

promql
Доля ошибок за 5 минут sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Быстрый burn (1m окно)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14.4

Медленный burn (30m окно)
(
sum(rate(http_requests_total{status=~"5.."}[30m])) /
sum(rate(http_requests_total[30m]))
) / (1 - SLO) > 2

promql p95 latency histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

6) Etki Alanına Göre SLI/SLO Örnekleri

6. 1 API Ağ Geçidi/Kenar

SLI-Hatalar: 5xx yanıt oranı <0. %1 (28d).
SLI-Gecikme: p95 ≤ 250 ms (gün).
SLO: 99 ≥ kullanılabilirlik. %95 (çeyrek).

6. 2 Ödemeler

SLI-Success: Başarılı (müşteri hataları hariç) ≥ 99 için ödeme. %8 (28d).
SLI-Latency: %99 (gün) için 2 saniye ≤ yetkilendirme.
SLO: Time-to-Wallet p95 ≤ 3 мин (24 saat).

6. 3 Veritabanları (PostgreSQL)

SLI-Lag: replikasyon lag p95 ≤ 1 sn (gün).
SLI-Errors: Sorgu hata oranı ≤ 0. %05 (28d).
SLO Küme Kullanılabilirliği ≥ 99. 95%.

6. 4 Kuyruklar/Akış (Kafka)

SLI-Lag: Tüketici gecikme p95 ≤ N mesajları (saat).
SLI-Dayanıklılık - ≥ 99 girişini onaylayın. %99 (28d).
SLO: Brokerlerin mevcudiyeti ≥ 99. 9%.

7) Güvenilirlik süreci KPI

MTTD (Ortalama Tespit Süresi)

MTTA (... Tanımak için)

MTTR (... Geri yüklemek için)

MTBF (... Başarısızlıklar arasında)

Otomatik hafifletme ile olayların %

En iyi trafik yollarının SLO/uyarı kapsamı (hedef ≥ %95)

Kanarya aşaması ile bültenlerin paylaşımı

Hatalı bütçenin ekipler/özellikler tarafından tüketimi

8) SLO gerçekçi koymak nasıl

1. Mevcut temel güvenilirliği ölçün (3-4 hafta).
2. "Hassas" kullanıcı yollarını tanımlayın (giriş, para yatırma, oyun).
3. Her sapmanın maliyetini düşünün (zaman, para, itibar).
4. İddialı ama ulaşılabilir bir hedef seçin (taban çizgisinde %10-30 iyileşme).
5. Üç ayda bir gözden geçirin.

• Hemen "beş dokuz" gerekçe olmadan.
• Kullanıcı tarafından görülemeyen metriklere göre SLO (örneğin, UX ile iletişim olmadan CPU).
• Çok fazla SLO - odak spreyi.

9) SLO ve bütçe raporlama

• SLO başına tamamlama: gerçek vs hedef, eğilimler, güven.
• Hata tüketiminin özeti: Bütçenin kim tarafından yapıldığından ne kadar "yakıldığı" (serbest bırakma/olay).
• Bozulmanın ilk beş nedeni, CAPA planı ve görev durumu.
• İş etkisi: dönüşüm, ND, elde tutma, LTV.

10) Yayın politikası ile iletişim

Hata bütçesi <%50> ücretsiz sürümler.
50-80 % - "temkinli mod": sadece düşük riskli/kanarya hesaplamaları.

11) SLA (sözleşmeli) - öğe şablonları

Kullanılabilirlik yükümlülüğü: Örneğin, 99. %9/ay.
Mücbir Sebep: Makul kontrolün ötesinde DDoS, üçüncü taraf sağlayıcılar.
Ölçüm penceresi ve sorumluluk alanı: metriklerin kaynakları, hesaplama yöntemi.
Krediler/cezalar: seviyelerin bir tablosu (örneğin, 60-120 dakikanın kullanılamaması - kredi X %).
Eskalasyon ve bildirim prosedürleri: son tarihler, kanallar.
Veri ve gizlilik: maskeleme, depolama, Yasal Bekletme.
İhlal durumunda Tekrarlama Önleme Planı (CAPA).

12) Ölçüm araçları

Pasif metrikler: Prometheus/Mimir/Thanos, ihracatçılar.
Günlükler: İş düzeyinde başarıları/hataları saymak için Loki/ELK.
Sentetikler: cron tarafından aktif örnekler (giriş/para yatırma/oyun).
İzleme: P99 darboğazları için Tempo/Jaeger.
Ödeme/Finans: Ödeme SLI için zemin gerçeği kaynakları.

13) Sorgu örnekleri (şablonlar)

promql
1 - (
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
)

yaml slo:
name: "API Availability"
window: "28d"
target: 0.999 sli: "1 - 5xx%"
owner: "Platform SRE"
alerting:
fast_burn: {window: "1h", factor: 14.4}
slow_burn: {window: "6h", factor: 6}

success_rate = (count_over_time({app="payments"}     = "status=success"[5m]))
/ (count_over_time({app="payments"}     ~ "status=(success    fail)"[5m]))

Anahtar> Filtreleri "müşteriye göre düşüş'ü hariç tutmak için hassaslaştırın.

14) FinOps ve güvenilirlik

9 başına maliyet: Dokuz eklemenin maliyeti katlanarak artıyor.
Fayda eğrisi: Gelir artışının/kayıpların azalmasının ek "9" maliyetini ≥ optimum.
SLO portföyü: Farklı yollar için farklı seviyeler (kritik ödemeler'daha pahalı ", raporlama'daha ucuz").

15) SLO/Uyarı Kalitesi - Kontrol Listesi

• SLI, UX ve iş metrikleri ile ilişkilidir.
• Pencere ve toplama tutarlıdır (28d/çeyrek haddeleme).
• Çoklu pencere uyarıları, çırpma yok, rol tabanlı yönlendirme.
• Belgeler: sahibi, formülü, kaynakları, runbook.
• Hatalı bütçe ve yanma göstergeleri ile SLO demo paneli.
• Hedefleri düzenli olarak gözden geçirin (üç ayda bir).
• Önemli senaryolar üzerinde sentetik testler.

16) Uygulama planı (4 yineleme)

1. 1. Hafta: Kullanıcı yollarının envanteri, SLI taslakları, temel panolar.
2. 2. Hafta: SLO resmileştirme, bütçeleme, uyarılar (hızlı/yavaş yanma).
3. 3. Hafta: Olay/serbest bırakma süreci ile entegrasyon, donma kuralları.

4. 4. Hafta +: Sözleşmeli SLA'lar, Üç Aylık İncelemeler, "9 başına maliyet" Finops Modeli

17) Mini-SSS

Servis başına bir SLO'ya ihtiyacım var mı?
Düzinelerce ikincil yerine daha iyi 2-3 anahtar olanlar (başarı + gecikme).

Ya bütçe tükenirse?
Dondurma sürümleri, stabilizasyon ve CAPA'ya odaklanma, deneysel özellikleri kaldırma.

Yayın hızı ve güvenilirlik arasında bir çatışma nasıl önlenir?
Plan "bütçe" bültenleri, kanarya hesaplamaları ve özellik bayrakları uygulamak.

Sonuç

Güvenilirlik bir dizi farklı metrik tarafından değil, sistem tarafından kontrol edilir: SLI - SLO - bütçe hatası - yanma uyarısı - olay süreci - CAPA - SLA. Tanımları, veri kaynaklarını ve raporlamayı standartlaştırın, hedefleri kullanıcı deneyimi ve ekonomiye bağlayın ve gerçek dünya YG'sine dayalı olarak dokuzları düzenli olarak gözden geçirin.