SLA, SLO va KPI ishonchliligi

1) Atamalar va farqlar

SLI (Service Level Indicator) - o’lchanadigan sifat indikatori (masalan, muvaffaqiyatli so’rovlar ulushi, latentlik p95).
SLO (Service Level Objective) - vaqt oynasi uchun SLI maqsadli qiymati (masalan, "muvaffaqiyat ≥ 99. 28 kunda 9%").
Budjet xatosi (Error Budget) - SLO bajarilmasligining yo’l qo’yiladigan ulushi:’1 − SLO’.
SLA (Service Level Agreement) - jarimalar/kreditlar bilan kontrakt majburiyatlari (tashqi).
KPI ishonchlilik - jarayonning operatsion metrikalari (MTTD/MTTA/MTTR/MTBF,% avtomatik mitigeytlar, alertlar bilan qoplash va boshqalar).

2) SLI ni qanday tanlash kerak (Golden Signals asosida)

1. Latency - asosiy endpointlar uchun p95/p99.
2. Traffic - RPS/RPM/xabar oqimi.
3. Errors - 5xx/biznes xatolari ulushi (masalan, «PSP aybi bilan decline» to’lovlari chiqarib tashlansin).
4. Saturation - resurslarni to’ldirish (CPU/RAM/IO/lag).

• Foydalanuvchi tajribasi bilan bogʻlanadi (user-perceived).
• Texnik jihatdan arzon va o’lchovda barqaror.
• Nazorat qilamiz (yaxshilash uchun harakatlar mumkin).
• Yig’imning past qiymati.

3) Formulalar va misollar

3. 1 Foydalanish imkoniyati

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

Misol: SLO 99. 9% 30 kunda → xatolar byudjeti = 0. 1%, bu 43 min 12 soniyaga teng.

3. 2 Latentlik

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

3. 3 To’lovlar (biznes darajasi)

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

4) Noto’g "ri budjet va burn-rate

Byudjet xatosi - innovatsiyalar uchun «yoqilg’i baki» (relizlar, eksperimentlar).

• tezkor kanal (detekt 1 soat ~),
• sekin kanal (trend ~ 6-12 soat/24 soat).

• Agar burn-rate> 14. 1 soat uchun 4 - SEV-1 (kunlik budjetni 100 daqiqa ~ iste’mol qilamiz).
• Agar burn-rate> 6 soat ichida 6 - SEV-2 (tez degradatsiya).

5) SLO bo’yicha alerting (multi-window, multi-burn)

Xatolar indikatori: 5xx yoki latentlik buzilishlari ulushi.

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) Domenlar bo’yicha SLI/SLO namunalari

6. 1 API-shlyuz/Edge

SLI-Errors: javoblar ulushi 5xx <0. 1% (28d).
SLI-Latency: p95 ≤ 250 ms (kun).
SLO: Availability ≥ 99. 95% (chorak).

6. 2 To’lovlar

SLI-Success: muvaffaqiyatli to’lovlar (mijozlarning rad etishlari bundan mustasno) ≥ 99. 8% (28d).
SLI-Latency: avtorizatsiya ≤ 99% uchun 2 soniya (kun).
SLO: Time-to-Wallet p95 ≤ 3 мин (24h).

6. 3 Maʼlumotlar bazasi (PostgreSQL)

SLI-Lag: replikatsion lag p95 ≤ 1 sek (kun).
SLI-Errors: soʻrov xatolari ulushi ≤ 0. 05% (28d).
SLO: klaster mavjudligi ≥ 99. 95%.

6. 4 Navbatlar/Striming (Kafka)

SLI-Lag: iste’mol lag p95 ≤ N xabarlar (soat).
SLI-Durability: yozuvni tasdiqlash ≥ 99. 99% (28d).
SLO: brokerlarning mavjudligi ≥ 99. 9%.

7) Ishonchlilik jarayonining KPI

MTTD (Mean Time To Detect)

MTTA (… To Acknowledge)

MTTR (… To Restore)

MTBF (… Between Failures)

Avtomatik mitigatsiya hodisalari%

Trafikning top-yo’llarini SLO/alertlar bilan qoplash (maqsadli ≥ 95%)

Kanareya bosqichi bilan relizlar ulushi

Buyruqlar/fichlar bo’yicha noto’g "ri budjet iste’moli

8) SLOni qanday qilib real qo’yish kerak

1. Joriy bazaviy ishonchlilikni (3-4 hafta) o’lchang.
2. «Sezgir» foydalanuvchi yoʻllarini (login, depozit, oʻyin) aniqlang.
3. Har bir deviatsiyaning qiymatini (vaqt, pul, obroʻ) hisobga oling.
4. Shuhratparast, ammo erishish mumkin bo’lgan maqsadni tanlang (bazaga nisbatan 10-30% yaxshilash).
5. Har chorakda qayta koʻrib chiqing.

• Bir vaqtning o’zida «besh to’qqizlik» asossiz.
• Foydalanuvchi ko’rinmaydigan metriklar bo’yicha SLO (masalan, UX bilan aloqasiz CPU).
• Juda koʻp SLO → fokusni purkash.

9) SLO va budjetlar bo’yicha hisobot

• Har bir SLOni bajarish: fakt vs maqsad, trendlar, confidence.
• Xatolar iste’moli ma’lumotlari: qancha byudjet «yoqib yuborilgan», kim tomonidan (reliz/hodisa).
• Tanazzulning beshta sababi, CAPA-reja va vazifalarning maqomi.
• Biznesga ta’sir: konvertatsiya, ND, ushlab qolish, LTV.

10) Reliz siyosati bilan aloqa

Xatolar byudjeti <50% → boʻsh relizlar.
50-80% → «ehtiyot rejim»: faqat low-risk/kanareik hisob-kitoblar.

11) SLA (shartnomaviy) - bandlar shablonlari

Foydalanish majburiyati: masalan, 99. 9 %/oy.
Istisnolar (Force Majeure): DDoS oqilona nazoratdan tashqari, uchinchi tomon provayderlari.
O’lchov oynasi va javobgarlik zonasi: metrik manbalar, hisoblash usuli.
Kreditlar/jarimalar: darajalar jadvali (masalan, 60-120 min → kredit X%).
Eskalatsiya va bildirishnomalar tartib-taomillari: muddatlar, kanallar.
Ma’lumotlar va maxfiylik: yashirish, saqlash, Legal Hold.
Qoidabuzarlik holatlarida takrorlanishning oldini olish bo’yicha ishlar rejasi (CAPA).

12) O’lchash vositalari

Passiv metriklar: Prometheus/Mimir/Thanos, eksportchilar.
Logi: Biznes darajasidagi muvaffaqiyatlar/xatolarni hisoblash uchun Loki/ELK.
Sintetika: cron bo’yicha faol namunalar (login/depozit/o’yin).
Trastirovka: Tempo/Jaeger uchun «tor joylar» p99.
To’lov/moliya: to’lov SLI uchun ground truth manbalari.

13) So’rovlar namunalari (shablonlar)

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 va ishonchlilik

Cost per 9: «To’qqiz» qo’shish qiymati eksponensial ravishda o’sib bormoqda.
Foyda egri chizig’i: daromad o’sishi/yo’qotishlarni kamaytirish ≥ qo’shimcha «9» qiymati bo’lgan optimum.
SLO portfeli: turli yo’llar uchun turli darajalar (tanqidiy to’lovlar «qimmatroq», hisobot «arzonroq»).

15) SLO/alertlarning sifati - chek-ro’yxat

• SLI UX va biznes metriklar bilan bog’liq.
• Oyna va agregatsiya kelishilgan (rolling 28d/chorak).
• Alertlar multi-window, flappingsiz, rolli yo’naltirilgan.
• Hujjatlar: egasi, formulasi, manbalari, runbook.
• Noto’g’ri byudjet va burn indikatorli SLO demo paneli.
• Maqsadlarni muntazam ravishda qayta ko’rib chiqish (har chorakda).
• Asosiy stsenariylar bo’yicha sintetika testlari.

16) Joriy etish rejasi (4 ta iteratsiya)

1. 1-hafta: foydalanuvchi yo’llarini inventarizatsiya qilish, SLI loyihalari, bazaviy dashbordlar.
2. 2-hafta: SLOni rasmiylashtirish, byudjetlarni hisoblash, alertlar (fast/slow burn).
3. 3-hafta: hodisalar/relizlar jarayoni bilan integratsiya, freeze qoidalari.
4. 4 + hafta: shartnomaviy SLA, choraklik revyu, «cost per 9» finops modeli.

17) Mini-FAQ

Xizmat uchun bitta SLOga ega boʻlish kerakmi?
O’nlab ikkinchi darajali narsalar o’rniga 2-3 ta kalit (muvaffaqiyat + yashirin) yaxshiroqdir.

Agar byudjet tugagan boʻlsa - chi?
Relizlarni muzlatish, barqarorlashtirish va CAPAga e’tibor qaratish, eksperimental fichlarni olib tashlash.

Relizlar tezligi va ishonchlilik oʻrtasidagi ziddiyatni qanday oldini olish mumkin?
«Byudjet bo’yicha» relizlarni rejalashtiring, kanareykalarni va feature-flagsni joriy qiling.

Jami

Ishonchlilik SLI → SLO → byudjet xatosi → burn-alerting → hodisa jarayoni → CAPA → SLA tizimi bilan boshqariladi. Ta’riflar, ma’lumotlar manbalari va hisobotlarni standartlashtiring, maqsadlarni foydalanuvchi tajribasi va iqtisodiyotiga bog’lang va haqiqiy ROIga qarab «to’qqiz» darajasini muntazam ravishda qayta ko’rib chiqing.