Error Budgets və SLO İdarəetmə

1) Niyə SLO və büdcə səhvləri

SLO (Service Level Objective) - istifadəçi tərəfindən qəbul edilən hədəf keyfiyyət səviyyəsi; SLI - ölçülə bilən metrika; Error Budget - pəncərədən kənara çıxmaq üçün icazə (adətən 30/90 gün).
Səhv büdcəsi etibarlılığı «abstraksiyadan» idarə olunan resursa çevirir: büdcə tez yandıqda - fiçləri və rütbələri dondururuq; büdcə sağlam olduqda - buraxılışları sürətləndirə bilərsiniz.

2) SLI seçimi: «yaxşı» hesab etmək üçün nə

Meyar: «istifadəçi baxımından uğurlu».

2. 1 Klassik SLI

Availability: uğurlu sorğuların payı (müştəri tərəfindən ləğv edilənlər istisna olmaqla).
'success = http_status ∈ {2xx, 3xx, 404} və taymaut olmadan' (404 gözlənilən semantika olduqda, oxu API üçün uğur sayıla bilər).
Latency: tələblərin payı astanadan daha sürətli (məsələn, p95 ≤ 300 ms).
`good_latency = duration_ms ≤ 300`.
Freshness/Staleness: «Məlumat X dəqiqədən çox deyil» (cache, kataloqlar, əmsallar).
Quality: nəticənin düzgünlüyü (biznes validatorların/arxa variantların keçməsi).

2. 2 Sərhədlər və seqmentlər

SLI-ni vacib kəsiklər üzrə saymaq lazımdır: 'route', 'tenant/brand', 'region/jurisdiction', 'payment _ provider'. Beləliklə, bütün sistem boyunca bir kritik qələmin nasazlığını «silməyəcəksiniz».

3) Düsturlar və büdcə

3. 1 Request-based (API üçün üstünlük)

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

3. 2 Time-based (fon xidmətləri/axın üçün)

SLO_uptime = good_minutes / total_minutes

3. 3 Məqsəd nümunəsi

API ümumi: 99. 9% 30 gün mövcud → büdcə = 0. 1%.
Kritik ödəniş qələmləri: 99. 95%; kataloqlar/axtarış: 99. 5%.
Gecikmə: p95 ≤ 300 ms-də '/v1/payments ', p99 ≤ 800 ms.

4) SLI instrumental

4. 1 Prinsipləri

Logi/Traces → açıq buckets ilə RED (Rate/Errors/Duration) metrik.
'tenant', 'region', 'route _ class' (PII olmadan) yazdığınızdan əmin olun.
İki metrik sayın: «uğur» və «hər şey», latency üçün isə «tez» və «hər şey».

4. 2 Nümunə Prometheus (5m üçün rate)

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) Burn rate (multi-window, multi-burn)

5. 1 Fikir

Büdcənin hədəfə nisbətdə nə qədər sürətlə yandığını görürük. Qısa və uzun pəncərədə sürət yüksəkdirsə, siqnal verin.

5. 2 Eşik profilləri (SLO 99 üçün. 9%)

Peycinq: burn rate ≥ 14. 4 × (1 saat üçün büdcənin 10% -i və 6 saat üçün 5% -i).
Sorğu: burn rate ≥ 6 × (6 saat ərzində 2% və 24 saat ərzində 1%).

5. 3 Nümunə qaydaları (Prometheus, psevdo)

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"

Analoji olaraq, bilet üçün 6 saat/24 saat.

6) Büdcə İdarəetmə: Proseslər

6. 1 Buraxılış geytaları

Büdcə balansı <25% və tendensiya mənfi olarsa - «kod-dondurma», SRE/sabitlik prioriteti.
Kanarya relizlərində ayrıca SLO kəsiyi olmalıdır ('deployment. environment="canary"`).

6. 2 Beklogun prioritetləşdirilməsi

Komandanın tutumunu yanma sürətinə və gəlirin təsirinə nisbətdə paylayın.
Texniki borcu metrlərlə əsaslandırın: «X fiksi burn rate-ni Y% azaldır».

6. 3 Post-hadisə

Hər bir hadisə - RCA və «geri çevrilə bilməyən fiks» (actionable), nəzarət «SLO-ya qayıtdı».

7) SLO bir kod kimi

7. 1 SLO manifestinin nümunəsi (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 Qaydaların generasiyası

avtomatik qaydaları, dashboard və hesabatlar yaratmaq üçün generatorları (slo-generator, pyrra, sloth) istifadə edin.

8) SLO-nun deqradasiyası və qorunması

Load shedder: Zirvədə «bahalı» asılılıqlar olmadan sürətli cavab vermək.
Cache & stale: `stale-while-revalidate` для read.
Rate/Concurrency limits: backends qoruyur; mühüm marşrutlar - prioritet.
Circuit/Timeout: sürətli vaxt və «fallback» filialları.
Feature flags: bir düymə ilə ağır fiquru söndürmək.

9) SLO üçün müşahidə

Daşbordlar: SLO actual vs hədəf, büdcə balansı, burn rate, marşrutlar/provayderlər üzrə əmanət.
Korrelyasiya: «dəlik» SLO → exemplar → konkret trace → log/profil.
Hesabatlar: həftəlik - tendensiyalar, büdcə istehlakı, deqradasiyanın ən yaxşı səbəbləri.

10) Antipattern

Bütün → üçün bir «qlobal» SLO problemləri maskalayır. Seqmentləşdirin.
«99. 99% bütün" dəyəri və reallığı nəzərə almadan. İstifadəçi təcrübəsindən hədəfləri seçin.
Burn rate/SLO əvəzinə CPU/heap alertləri.
UX-ni korlayan 4xx/uzun redaktorlara məhəl qoymayın.
Qeyri-şəffaf pəncərə (rolling vs təqvim) - «alma ilə portağal» müqayisə.

11) iGaming/Maliyyə Xüsusiyyətləri

Pul yolları (depozitlər/nəticələr): fərdi SLO ümumi səviyyədən yüksəkdir (məsələn, 99. 95% mövcudluğu; p95 ≤ 250 ms).
PSP/KYC provayderləri: Hər bir provayder üzrə SLO + burn-a töhfə vermək üçün risklər; avtomatik marşrutlar keçid (smart routing).
Yurisdiksiyalar/tenantlar: SLO və 'region/jurisdiction/brand' üzrə büdcələr, yerli problem qlobal metrikanı «doldurmamalıdır».
Məsuliyyətli oyun: Limitlər/özünü istisna etmə müddətində SLO (compliance-formula).
Audit/tənzimləyici: SLO və insident hesabatlarını saxlayın; daxili auditlər üçün şəffaflıq.

12) Prod hazırlıq yoxlama siyahısı

• SLIs (availability/latency/quality/freshness) və seqmentlər (route/tenant/region) müəyyən edilmişdir.
• Məqsədlər (SLO) realdır, bizneslə razılaşdırılır; 30/90 gün rolling pəncərə var.
• Burn rate çox pəncərəli alertlər (peycinq/bilet).
• kod kimi SLO (qaydalar generator/dashboard); büdcə hesabatları.
• Buraxılış geytaları büdcə qalığına bağlıdır; kanar kəsikləri.
• Deqradasiya mexanizmləri (shedder, cache stale, circuit, limitlər) həyata keçirilmiş və sınaqdan keçirilmişdir.
• Metrik treyslərin korrelyasiyası (exemplars), aydın runbooks.
• Maliyyə/yurisdiksiya yolları - ayrı SLO/alertlər; PSP/KYC genişləndirilmişdir.
• Mütəmadi retro hadisələr və burn əsaslanan etibarlılıq investisiya.

13) TL; DR

SLI-ni istifadəçi dəyərinə görə təyin edin, real SLO-ları təyin edin və multi-pəncərələrlə Error Budget və burn rate vasitəsilə idarə edin. SLO-kodunu, buraxılış geytalarını və plan üzrə deqradasiyanı daxil edin. Marşrutlar/tenantlar/regionlar üzrə seqmentləşdirin; pul yolları üçün daha sərt məqsədlər və ayrı-ayrı risklər saxlayın.