SLA, SLO və KPI etibarlılığı

1) Terminlər və fərqlər

SLI (Service Level Indicator) - ölçülə bilən keyfiyyət göstəricisi (məsələn, uğurlu sorğuların payı, gecikmə p95).
SLO (Service Level Objective) - vaxt pəncərəsi üçün SLI hədəf dəyəri (məsələn, "uğur ≥ 99. 28 gün ərzində 9%").
Büdcə səhvi (Error Budget) - SLO-nun yerinə yetirilməməsinin icazə verilən payı: '1 − SLO'.
SLA (Service Level Agreement) - cərimələr/kreditlər (xarici) ilə müqavilə öhdəlikləri.
KPI etibarlılığı - prosesin əməliyyat metrikası (MTTD/MTTA/MTTR/MTBF,% avtomatik mitiqeyt, alert örtüyü və s.).

2) SLI-ni necə seçmək olar (Golden Signals əsasında)

1. Latency - əsas end nöqtələri üçün p95/p99.
2. Trafik - RPS/RPM/mesaj axını.
3. Errors - 5xx/biznes səhvlərinin payı (məsələn, «PSP günahı ilə decline» ödəniş istisna).
4. Saturation - resursların doyması (CPU/RAM/IO/lag).

• İstifadəçi təcrübəsi ilə əlaqələndirilir (user-perceived).
• Texniki cəhətdən mövcuddur və ölçmədə sabitdir.
• Nəzarət (təkmilləşdirmək üçün tədbirlər mümkündür).
• Aşağı rüsum dəyəri.

3) Formullar və nümunələr

3. 1 Mövcudluq (availability)

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

Nümunə: SLO 99. 9% 30 gün → büdcə səhvləri = 0. 1%, 43 min 12 saniyəyə bərabərdir.

3. 2 Gecikmə

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

3. 3 Ödənişlər (biznes səviyyəsi)

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

4) Səhv büdcə və burn-rate

Büdcə səhvi - yenilik üçün «yanacaq tankı» (buraxılışlar, təcrübələr).

• sürətli kanal (1 saat ~ detekt),
• yavaş kanal (trend ~ 6-12 saat/24 saat).

• Əgər burn-rate> 14. 1 saata 4 - SEV-1 (gündəlik büdcəni 100 dəq ~ yeyəcəyik).
• burn-rate> 6 saat 6 - SEV-2 (sürətli deqradasiya).

5) SLO (multi-window, multi-burn) ilə alertinq

Səhv göstəricisi: 5xx payı və ya gecikmə pozuntuları.

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) Domenlər üzrə SLI/SLO nümunələri

6. 1 API-şlyuz/Edge

SLI-Errors: 5xx <0 cavab payı. 1% (28d).
SLI-Latency: p95 ≤ 250 ms (gün).
SLO: Availability ≥ 99. 95% (rüb).

6. 2 Ödənişlər

SLI-Success: uğurlu ödənişlər (müştəri uğursuzluqları istisna olmaqla) ≥ 99. 8% (28d).
SLI-Latency: Authorization ≤ 99% üçün 2 saniyə (gün).
SLO: Time-to-Wallet p95 ≤ 3 мин (24h).

6. 3 Verilənlər bazası (PostgreSQL)

SLI-Lag: replikasiya lag p95 ≤ 1 san (gün).
SLI-Errors: sorğu səhvlərinin payı ≤ 0. 05% (28d).
SLO: Klaster mövcudluğu ≥ 99. 95%.

6. 4 Növbələr/Axın (Kafka)

SLI-Lag: istehlakçı lag p95 ≤ N mesajlar (saat).
SLI-Dayanıqlılıq: 99 ≥. 99% (28d).
SLO: brokerlərin mövcudluğu ≥ 99. 9%.

7) KPI etibarlılıq prosesi

MTTD (Mean Time To Detect)

MTTA (… To Acknowledge)

MTTR (… To Restore)

MTBF (… Between Failures)

% avtomatik mitiqasiya hadisələri

SLO/Top Trafik Yolları ilə əhatə (hədəf ≥ 95%)

Kanarya mərhələsi ilə relizlərin payı

Komandalar/Fich üçün səhv büdcə istehlakı

8) SLO real qoymaq üçün necə

1. Cari əsas etibarlılığı ölçün (3-4 həftə).
2. «Həssas» xüsusi yolları müəyyən edin (giriş, depozit, oyun).
3. Hər bir deviasiyanın dəyərini (vaxt, pul, nüfuz) nəzərə alın.
4. Ambisiyalı, lakin əldə edilə bilən bir məqsəd seçin (bazaya 10-30% yaxşılaşdırın).
5. Rüblük nəzərdən keçirin.

• Bir anda «beş doqquz» heç bir əsas olmadan.
• SLO istifadəçi tərəfindən görünməyən metriklərə görə (məsələn, UX ilə əlaqəsi olmayan CPU).
• Çox SLO → fokus püskürtmə.

9) SLO və büdcələr üzrə hesabat

• Hər SLO üçün icra: fakt vs məqsəd, trendlər, confidence.
• Səhv istehlakının xülasəsi: nə qədər büdcə «yandırıldı», kim tərəfindən (azad/hadisə).
• Deqradasiyanın ən yaxşı beş səbəbi, CAPA planı və vəzifələrin statusu.
• Biznesə təsir: dönüşüm, ND, saxlama, LTV.

10) Reliz siyasəti ilə əlaqə

Səhv büdcəsi <50% → pulsuz buraxılışlar.
50-80% → «ehtiyatlı rejim»: yalnız aşağı risk/kanarya hesablamaları.

11) SLA (müqavilə) - bəndlərin şablonları

Mövcudluq öhdəliyi: məsələn, 99. 9 %/ay.
istisnalar (Force Majeure): DDoS ağlabatan nəzarət xaricində, üçüncü tərəf provayderləri.
Ölçmə pəncərəsi və məsuliyyət sahəsi: metrik mənbələr, hesablama metodu.
Kreditlər/cərimələr: səviyyələr cədvəli (məsələn, əlçatmazlıq 60-120 min → kredit X%).
Eskalasiya prosedurları və bildirişlər: müddətlər, kanallar.
Data və gizlilik: maskalama, saxlama, Legal Hold.
Pozuntu halında təkrarların qarşısının alınması üzrə iş planı (CAPA).

12) Ölçmə alətləri

Passiv metriklər: Prometheus/Mimir/Thanos, ixracatçılar.
Loki: Loki/ELK biznes səviyyəsində uğurların/səhvlərin hesablanması üçün.
Sintetik: cron aktiv nümunələri (giriş/depozit/oyun).
Tracking: Tempo/Jaeger üçün «dar yerlər» p99.
Ödəniş/maliyyə: SLI ödəniş üçün ground həqiqət mənbələri.

13) Sorğu nümunələri (ş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]))

14) FinOps və etibarlılıq

Cost per 9: «doqquz» əlavə dəyəri eksponent artır.
Mənfəət əyrisi: gəlirin artımı/itkilərin azaldılması ≥ əlavə «9» dəyərinin olduğu optimum.
SLO portfeli: müxtəlif yollar üçün müxtəlif səviyyələr (kritik ödənişlər «daha bahalı», hesabat «daha ucuz»).

15) SLO/alertlərin keyfiyyəti - yoxlama siyahısı

• SLI UX və biznes metrləri ilə əlaqəlidir.
• Pəncərə və aqreqasiya razılaşdırılır (28d/kvartal rolling).
• Alert multi-window, heç bir flapping, roll marşrutlaşdırma ilə.
• Sənədləşmə: sahibi, formula, mənbələr, runbook.
• Səhv büdcə və burn göstəriciləri ilə SLO demo paneli.
• Məqsədlərə müntəzəm yenidən baxılması (rüblük).
• Əsas ssenarilər üzrə sintetik testlər.

16) Tətbiq planı (4 iterasiya)

1. Həftə 1: istifadəçi yollarının inventarlaşdırılması, SLI layihələri, əsas daşbordlar.
2. Həftə 2: SLO rəsmiləşdirilməsi, büdcələrin hesablanması, alertlər (fast/slow burn).
3. Həftə 3: Hadisə/buraxılış prosesi ilə inteqrasiya, freeze qaydaları.
4. Həftə 4 +: müqaviləli SLA, rüblük revyu, «cost per 9» finops modeli.

17) Mini-FAQ

Xidmətə bir SLO lazımdır?
Daha yaxşı 2-3 əsas (müvəffəqiyyət + gecikmə) əvəzinə onlarla ikinci dərəcəli.

Büdcə tükənsə nə etməli?
Relizlərin dondurulması, sabitləşdirmə və CAPA-ya diqqət yetirilməsi, eksperimental xüsusiyyətlərin aradan qaldırılması.

Buraxılış sürəti və etibarlılıq arasında münaqişədən necə qaçmaq olar?
«Büdcə ilə» buraxılışları planlaşdırın, kanarya hesablamaları və feature-flags tətbiq edin.

Yekun

Etibarlılıq müxtəlif metrlər dəsti ilə deyil, sistem ilə idarə olunur: SLI → SLO → büdcə xətası → burn-alerting → hadisə prosesi → CAPA → SLA. Tərifləri, məlumat mənbələrini və hesabatları standartlaşdırın, məqsədləri istifadəçi təcrübəsinə və iqtisadiyyata bağlayın və real ROI-dən asılı olaraq mütəmadi olaraq «doqquz» səviyyəsini nəzərdən keçirin.