SLO/SLA ve Metrikler

SLO/SLA ve metrikler

1) Şartlar ve hiyerarşi

SLI (Hizmet Seviyesi Göstergesi) - "kullanıcının bizi gördüğü gibi" ölçülebilir bir gösterge: başarılı taleplerin payı, p95 gecikmesi, verilerin tazeliği, başarıyla işlenen partilerin payı vb.

SLO (Servis Seviyesi Hedefi) - gözlem aralığında (28/30/90 gün) SLI değerini hedefleyin. Örnek: "99. Taleplerin/ödemelerin %9'u 400 ms ≤ sona ermektedir

Hata bütçesi - 1 − SLO. SLO 99'da. %9 hata bütçesi = 0. Zamanın/isteklerin %1'i.
SLA (Sözleşme) - yasal olarak önemli hizmet seviyesi: SLO, ölçüm, istisnalar, tazminatlar/para cezaları içerir.

2) Tasarım ilkeleri

Belirtiler> dahili metrikler. SLI'lar gerçek kullanıcı deneyimini yansıtmalıdır.
Az sayıda anahtar SLI. Servis için - 2-5 ana: başarı, gecikme, verim/tazelik, doğruluk.
Kritik yolların kapsamı. Her iş senaryosu (ödeme, giriş, webhook, ETL indirme) kendi SLI/SLO setine sahiptir.
Sıkı "başarı" semantiği. "Kod 200'değil," kullanıcı zamanında bir yanıt aldı ve sonuç geçerli ".
Dış ve iç SLO'ların ayrılması. Dahili - daha katı; Harici SLA ≤ 1-2 dokuz daha düşük.

3) SLI kataloğu (referans)

3. 1 API/Çevrimiçi Hizmetler

Başarı: 'SLI _ başarı = 1 − (5xx + zaman aşımı + business_error )/ all_requests'

Gecikme: p95/p99 'http _ server _ duration _ seconds' rota/yöntem/kiracı tarafından

Bant genişliği: 'RPS'/limitler/kotalar

Doğruluk: geçerli yanıtların oranı (imzalar, şemalar, değişmezler)

3. 2 Webhook/Asenkron Teslimatlar

Teslimat: T saniye ve ≤ N retrays ile teyit edilen olayların oranı

Müşteriler: Uzun bir gecikme olmadan abonelerin yüzdesi (kiracı başına)

3. 3 Veri/ETL/DWH

Tazelik: 'şimdi

Tamlık: 'yutulmuş _ satırlar/ expected_rows'

Doğruluk: Kalite kontrollerini geçen kayıtların oranı

Boru hatları: son teslim tarihinden önce tamamlanan işlerin payı

3. 4 Mobil/İstemci SDK'ları

Müşteri başarısı: Ölümcül hatalar olmadan oturumların oranı

Gidiş-dönüş gecikme süresi: Istekten işleme p95

Önbellek isabetleri: önbellekten sunulan yüzde (performans belirtisi olarak)

4) Formüller ve hedef örnekleri

• 'SLI _ req _ avail = 1 − (failed_requests/ total_requests)'
• 'SLO _ req _ avail = 99. 30 gün boyunca %95 'hata bütçesi = 0. Taleplerin %05'i.

• 'çalışma süresi = (obs_window − kapalı kalma süresi )/ obs_window'

• 'SLO _ latency = p95 (route = "/pay ") ≤ önbellek ısınma hareketleri hariç 7 günlük dilimlerde 400 ms' (%1)

• 'SLO _ tazelik (dataset = "siparişler") ≤ 24 saat içinde 10 dk' p99.

5) Hata bütçesi ve değişim yönetimi

Bütçe (B): 'B = 1 − SLO'.
Yanık - Gerçek hataların izin verilen hatalara oranı.

• Aşırı harcama (yanık> 1) - özellik donması, güvenilirliğe odaklanın.
• Yanma hızında> Kısa pencerede X - olay ve kapak. önlemler.
• Planlama: Sprint'in güvenilirlik payı, geçmiş dönemdeki yanma ile ilişkilidir.

6) Uyarı: yanma oranı ve çoklu pencere kuralları

Fikir: hızlı sızıntıları ve yavaş sürüklenmeyi yakalarız.

• Kritik: "1 saatte %2 bütçe" (hızlı ateş).
• Uyarı: "6 saatte bütçenin %5'i" (sürünen bozulma).

• Hızlı olaylar için kısa pencere (dakika-saat).
• Trendler için uzun pencere (6-24 saat).
• Gecikme: p99> eşik ≥5 dakika ile uyarı, kanat çırpma ve iz örnekleriyle iletişimin bastırılmasıyla.

error_ratio_5m = errors[5m] / requests[5m]
error_ratio_1h = errors[1h] / requests[1h]
burn_5m     = error_ratio_5m / error_budget_fraction burn_1h     = error_ratio_1h / error_budget_fraction alert_critical if burn_1h > 14 and burn_5m > 14 alert_warning  if burn_6h > 6 and burn_30m > 6

7) Çok kiracı ve segmentasyon

SLI/SLO kiracılara/planlara/bölgelere göre sayılır, aksi takdirde medyan arızaları "örter".
İstatistiksel anlamlılık için minimum olay sayısı (guard-rails).
SLA tarifelerde değişebilir (örneğin, "Pro 99. %9, Ücretsiz 99. 5%»).

8) Gözlemlenebilirlik ve izler ile ilişki

SLI metrikleri - histogramlardan/sayaçlardan örneklerle - "kötü" parkurlara geçiş.
Günlükler nedenlerin kaynağıdır: zaman aşımları, iş hata kodları, limitler.
Veri için - soy ile bir bağlantı:'hangi iş tazelik metriğini geciktirdi ".

9) Sözleşmeler ve SLA'lar

• SLI/ölçüm yöntemi/pencere tanımları.
• İstisnalar (planlı iş, mücbir sebepler).
• Olay ve iletişim prosedürü (durum sayfası, RFO/RCA).
• Hizmet kredileri ve talep emri.
• Yargı yetkisi, geçerlilik süresi, revizyon şartları.

• SLO'ları asla mimarinin ve operasyonel uygulamaların izin verdiğinden daha katı bir şekilde halka açık bir şekilde vaat etmeyin.
• Ayrı dahili SLO'lar ve harici SLA'lar.

10) Maliyet ve önceliklendirme

Dokuzların fiyatı doğrusal olarak artmıyor. «99. 9% → 99. %99" = farklı mimari sınıfı (N + 1, multi-zone, asset-to-asset).
SLO'ları en değerli kullanıcı eylemlerine yerleştirin.
Telemetri maliyetini kontrol edin - alt örnekleme, kotalar, çoğaltma ve sınıfa göre depolama.

11) Prosedürler ve Raporlama

Haftalık raporlar: Hizmet/kiracı tarafından SLO yürütme, bütçe harcamaları, en önemli nedenler, iyileştirme planları.
Olay sonrası RCA: bütçenin parçalarıyla ilişkilendiririz; Kök nedenleri ortadan kaldırmak için görevler belirledik.
Fichfriz: dahil etme/geri çekme kriterleri.

12) Şablonlar (hızlı bir başlangıç için)

12. 1 SLO kartı (örnek)

Service: Checkout API
SLI:
success: 1 - (5xx+timeouts+biz_failures)/all latency_p95: p95(http_server_duration_seconds{route="/pay"})
SLO:
success: 99. 95% / 30d latency_p95: ≤ 400ms / 7d
Windows:
primary: 30d rolling secondary: 7d rolling
Burn Alerts:
critical: use 1h/5m > 14 warning: use 6h/30m > 6
Owner: Team Checkout
Tenancy: per-tenant (≥ 1k req/day threshold)
Dashboards: RED + trace exemplars

12. 2 SLO Olgunluk Tablosu

13) Kural örnekleri (fragmanlar)

promql
Error rate (5xx + timeout) for the sum (rate (http_requests_total{route="/pay",code=~"5. route.    599"}[5m]))
/ sum(rate(http_requests_total{route="/pay"}[5m]))

p99 histogram_quantile latency (0. 99, sum(rate(http_server_duration_seconds_bucket{route="/pay"}[5m])) by (le))

promql error_budget_fraction = 0. 001 for 99. 9%
(err_rate_5m / 0. 001 > 14) and (err_rate_1h / 0. 001 > 14) # critical
(err_rate_30m / 0. 001 > 6) and (err_rate_6h / 0. 001 > 6)  # warning

promql
Data order lag (minutes)
(max(time()) - max(last_ingest_ts_seconds{dataset="orders"})) / 60

14) Veri ve ML için SLO (özellikler)

Uçtan uca veri SLO'ları: p99 tazelik, p99 bütünlük, çökme sonrası "yeniden işleme" süresi.
Veri sözleşmeleri: beklenen planlar, hacimler, son tarihler; veri ihlali - olay.
ML: Çıkarım gecikmesi için SLO, özellik stor kullanılabilirliği için SLA, sürüklenme izleme (model kalitesi, SLA dışında ayrı bir konudur).

15) Güvenlik ve gizlilik ile entegrasyon

PII/sırlar olmadan SLI günlükleri; tokenization/maskeleme.
SLO/SLA'lardaki değişiklikleri denetleyin ve yayınları değişmez günlüklerde raporlayın.
Düzenleyici yollar için (ödemeler/PII) - ayrı, daha sıkı SLO'lar.

16) Kontrol listeleri

Hizmete/özelliklere başlamadan önce

• Başarı/Gecikme/Verim/Tazelik SLI'leri tanımlanmıştır.
• SLO ve pencereler tanımlı; hata bütçesi hesaplanır.
• Yanma hızı uyarılarını ayarlayın (kısa + uzun).
• Gösterge Tabloları KIRMIZI + örnekler - yolları; Olay runibooks.
• Çoklu kiralama bölümleri ve önem eşikleri.
• Fichfreeze ve raporlama prosedürü.

Operasyon

• SLO/haftalık rapor, sertleştirme planları yakmak.
• Mimari/yük değiştiğinde SLO'yu yeniden değerlendirin.
• Periyodik "matkap olayları've runibook güncellemeleri.
• Monitör telemetri maliyeti ve SLI sayısı.

17) Runbook'и

Runbook: Hızlı büyüme p99/ödeme

1. Alert p99> threshold - Bir pano açın - izlemek için örnek üzerinden gidin.
2. Dar bir CLIENT/SERVER aralığı bulun, bölgeleri/sürümleri karşılaştırın.
3. Bozulmayı etkinleştir (önbellek/limit/geri dönüş), bağımlılık komutunu bildir.
4. Dengelemeden sonra - RCA, optimizasyon görevleri, SLO ölçümlerini güncelleme.

Runbook: bütçe harcamaları> hafta için %50

1. Özellikleri dondurun, güvenilirlik önceliğini artırın.
2. Hataların kümelenmesi: rotalara/kiracılara/bağımlılıklara göre.
3. Düzeltmeleri dağıtın - trend kurtarmayı onaylayın.
4. Geriye dönük ve uyarı/eşik ayarı.

18) SSS

S: Kaç tane SLO'ya ihtiyacınız var?
C: Kritik kullanıcı senaryolarında minimum: başarı + gecikme. Diğer her şey ihtiyaç dışıdır.

S: Hangisi daha iyi - zamana göre mi yoksa isteğe göre mi kullanılabilirlik?
A: Talep üzerine - daha fazla kullanıcı metriği. Zaman ağ bileşenleri/infra için uygundur.

S: Neden p95, ortalama değil?
C: Ortadaki kuyruğu gizler; Kullanıcı p95/p99 hisseder.

S: "Vidaları çok fazla sıkmamak" nasıl?
C: Gerçekçi hedeflerle (geçmiş veriler) başlayın, sonra olgunlaştıkça sıkın.

• "Gözlemlenebilirlik: günlükler, metrikler, izler"
• "Dağıtılmış İzler"
• "Denetim ve değişmez günlükler"
• "Webhook teslimat garantisi"
• "Transit/Dinlenme Şifrelemesinde"
• "Veri Kökeni (Lineage)"