KPI infratuzilma va aptaym

Nima uchun kerak

KPI infratuzilmalari barqarorlik haqidagi «his-tuyg’ularni» o’lchanadigan maqsadlarga aylantiradi, ish xavfi va diqqat markazini boshqaradi. To’g’ri metriklar texnik SLIni biznes natijalari (konvertatsiya, Time-to-Wallet, LTV) bilan bog’laydi va rivojlanishni, yukni va innovatsiyalar ulushini ishonchlilikka qarshi rejalashtirish imkonini beradi.

Asosiy tushunchalar: SLI, SLO, SLA va xatolar byudjeti

SLI (Service Level Indicator) - o’lchanadigan sifat ko’rsatkichi: muvaffaqiyatli so’rovlar ulushi, p95 latency, bir interval uchun aptaym.
SLO (Service Level Objective) - SLI maqsadidir (masalan, "muvaffaqiyat ≥ 99. 30 kun ichida 9%").
SLA (Agreement) - neustoyka/kreditlar bilan tashqi va’da. Har doim SLOdan olingan, lekin unga teng emas.
Xatolar byudjeti =’1 − SLO’. Bu o’lchov oynasi uchun «muvaffaqiyatsizlik» ning eng ko’p yo’l qo’yiladigan ulushidir. Xavfli relizlar va eksperimentlar to’g "risida qaror qabul qilish uchun ishlatiladi.

Misol:

99 ta SLO mavjud. 30 kun ichida 95% → xatolar byudjeti 0. 05% ≈ 21. kalendar oyida 6 daqiqa «muvaffaqiyatsizlik».

To’rtta «oltin» signal va qo’shimcha

1. Latentlik (p50/p90/p95/p99, tail o’rtachadan muhimroq).
2. Xatolar (5xx/timeout/biznes xatolari).
3. Trafik/oʻtkazish (RPS/QPS, MBps).
4. To’yinganlik (CPU/RAM/IO/FD/ulanish/GC/kvotalar).
Qo’shimcha: sovuq start, navbatlar/beklog, deploy vaqti, SLO-komplayens.

Turli turdagi xizmatlar uchun SLI modeli

HTTP/API

Foydalanish imkoniyati: ’(muvaffaqiyatli 2xx/3xx − mantiqiy xatolar )/( barcha soʻrovlar) ’

Latentlik: muvaffaqiyatli soʻrovlar uchun’p95’; «issiq» yo’nalishlardagi maqsad.
Sifati:’audience/scope’toʻgʻri soʻrovlar ulushi (authZ xatosiz).

Navbatlar/asinxron

Xabarni qayta ishlash vaqti: p95 end-to-end ≤ N sek.
Backlog: mediana <X, dumi p99 <Y.
Yetkazib berish xatosi: ≤ Z ppm.

DB/kesh

Operatsiyaning maxfiyligi: p95 get/put/commit.
Toʻyinish: connection pool usage, hit-ratio kesh.
Xatolar: timeouts, deadlocks, eviction storms.

CDN/statik

Hit Ratio: maqsadli darajani ≥; degradatsiya → origin yuklamasining o’sishi.
POP foydalanish imkoniyati: Anycast-joylashtirish, nosozliklar qoʻshnilar tomonidan qoplanadi.

To’lovlar (biznes-SLI)

Time-to-Wallet p95, depozit/olib qo’yish muvaffaqiyati%, PSP rad etishlari rate.

Foydalanish imkoniyati va «aptaym» hisobi

Xizmatdan foydalanish imkoniyati = «muvaffaqiyatli so’rovlar/barcha so’rovlar» (afzalroq «aptaym daqiqalari» emas).
Infratuzilma tugunlari uchun muqobil:’vaqt yashil/vaqt oyna’.
Kalendar oyna: 28-31 kun, harakatlanuvchi oyna: oxirgi 30/90 kun.
Ish soatlari/tanqidiy derazalar: backoffice uchun jadval bo’yicha aptaym hisoblanishi mumkin (masalan, mahalliy vaqt bilan 08: 00-22: 00).

Bog’liqlik kompozitsiyasi (soddalashtirilgan): Agar A xizmati B va C ga bog’liq bo’lsa, mustaqil rad etilganda:

’Availability (A) ≈ Av (B) × Av (C) × Av (A’ B, C)’- chegaralarda SLO qurish muhimdir.

SLO-to’plam namunasi (namunasi)

API Gateway: ≥ 99. 95 %/30d; p95 latency ≤ 120 ms; xato ≤ 0. 2%.
Checkout/Payments: omonatning muvaffaqiyati ≥ 98. 5 %/30d; Time-to-Wallet p95 ≤ 90 с; PSP-timeouts ≤ 0. 3%.
Ma’lumotlar bazasi: p95 read ≤ 10 ms; p95 write ≤ 25 ms; replica lag p95 ≤ 150 мс.
Kesh: hit ratio ≥ 85%; eviction storms = 0/30д.
To’lovlar: p95 qayta ishlash ≤ 5 daqiqa; frod-fols-pozitivlar ≤ 0. 3%.

Xatolar budjeti va o’zgarishlarni boshqarish

Agar xatolar byudjeti oynaning o’rtasidan 50% + oldin tugagan bo’lsa, fich/relizlarni «muzlatish» joriy etiladi, diqqat barqarorlikka qaratiladi.
Agar byudjet sekin sarflansa, tajriba/kanareykalarni tezlashtirish mumkin.
Byudjet isteʼmolini «release _ id» orqali aniq relizlar/hodisalar bilan bogʻlang.

Alerting: qanday qilib «tunda qo’ng’iroq qilmaslik» behuda

Alertlar har bir metrik emas, balki faqat SLO degradatsiyasi va hayotiy alomatlar bo’yicha.
Multi-window, multi-burn rate: qisqa darcha (5-15 daqiqa) + uzun darcha (1-6 soat).
Misol: «Burn rate 14 × 5 daqiqada Va 6 × 1 soatda» → on-call sahifasi.
P1 signallari uchun sokin soatlar; javobgarlik yo’nalishi (ownership).

Dashbordlar va vizualizatsiya amaliyoti

SLO-panel: xizmatlar bo’yicha komplayens, qolgan byudjet, qaramlik xaritalari.
Latency paneli: p50/p90/p95/p99, yo’nalishlar/tenantlar/mamlakatlar/ASN bo’yicha parchalanish.
Error paneli: kodlar/sabablar, relizlar/fichflaglar bilan bogʻlanish.
Capacity paneli: kesma CPU/RAM/IO/network/FD/konnektlar, trendlar va prognozlar.
Biznes-panel: konvertatsiya, Time-to-Wallet, depozitlar/xulosalar, himoya ta’siri (WAF/antibot).

Hodisalar, MTTR va postmortemlar

KPI reaksiyalar:

MTTD (aniqlash), MTTA (akkept), MTTR/MTTC (tiklash/ushlab turish), o’z vaqtida RCAsiz hodisalar%.
Pleybuklar: kim eskalatsiya qiladi, fichflaglar/bloklarni qanday yoqish, relizni qanday qaytarish, biznes bilan aloqa qilish.
Postmortem (blameless): faktlar, vaqt chizig’i, asosiy sabablar (tex/jarayonlar), harakatlar: darhol/uzoq muddatli, regressiya testlari, SLOga ta’siri.

Unumdorlik, to’yinganlik va degradatsiya

Headroom: maqsadli resurslar zaxirasi (masalan, CPU <70% p95, RAM <75% p95).
Hot paths: tanqidiy yo’nalishlarni profillash;’p99’o’rtacha yo’nalishdan ko’ra muhimroqdir.
Degradation modes: kesh-faqatgina, read-only, muhim bo’lmagan so’rovlarni drop-silliqlash, «stavkalarni cheklash «/kvotalar.

Formulalar va hisob-kitoblar namunalari

1) So’rovlar bo’yicha foydalanish


availability = (total_requests - error_requests) / total_requests

bu yerda’error _ requests’= 5xx + timeouts + biznes xatolari (sozlanadi).

2) Xatolar budjeti (daqiqa)


error_budget_minutes = window_minutes (1 - SLO)

Misol: 30 kun (43 200 min), SLO 99. 95% → 21. 6 daqiqa

3) Burn rate


burn_rate = observed_error_ratio / (1 - SLO)

Agar SLO 99 bo’lsa. 9% (budjet 0. 1%), xato esa 1% → burn_rate = 10 ×.

4) Tarkibiy foydalanish


A_total ≈ A_gw × A_auth × A_db × A_psp

Kichik tushishlar umumiy A.ga multiplikativ ta’sir ko’rsatadi.

O’lchash va istisnolar siyosati

Rejadan tashqari derazalar (hodisalar) hisobga olinadi.
Rejalashtirilgan xizmat ko’rsatish oynalari - faqat SLA shunday yozilgan bo’lsa hisobga olinadi; SLO uchun ko’pincha chegirilmaydi (yoki alohida’planned _ downtime’deb belgilanadi).
Sintetika vs haqiqiy foydalanuvchilar: ikkala kanalga ega bo’lish foydalidir (RUM + sintetik tekshiruvlar).

Artefaktlar namunalari

KQL/PromQL (gʻoyalar)

SLI (5xx + timeouts) xatosi 5 daqiqada:

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

p95 latency по route:

promql histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))

Burn rate 5m/1h:

promql
(
sum(rate(errors_total[5m])) / sum(rate(requests_total[5m]))
) / (1 - 0. 999)

SQL (to’lovlar bo’yicha biznes-SLI)

sql
SELECT date_trunc('minute', finished_at) AS ts,
100. 0 sum((status='SUCCESS')::int)::float / count() AS payment_success_pct,
percentile_cont(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (finished_at - started_at))) AS ttw_p95_sec
FROM payments
WHERE finished_at > now() - interval '30 days'
GROUP BY 1 ORDER BY 1;

Qaramliklar va kaskadlarni boshqarish

Jamoalar o’rtasidagi SLO shartnomalari: gateway, auth, wallet, PSP.
Degradation policies: Agar bogʻliqlik pasaysa, xizmat «soddalashtirilgan» rejimga oʻtadi.
Feature flags: kritik boʻlmagan funksiyalarni oʻchirish, latency dumlarini pasaytirish uchun «kulrang chiqarish».

Capacity Planning va prognozlar

Schomes. trendlar va voqealar bo’yicha RPS/MBps prognozi (turnirlar, o’yinlar, aksiyalar).
«Oltin yo’llar» bo’yicha load testing, PSP/to’lovlar uchun alohida testlar.
Eng yuqori darajadagi zaxira: maqsadli koeffitsiyent 1. 3×–2. 0 × kutilayotgan yuklamadan.

SLO/KPI joriy etish chek-varaqasi

1. Tanqidiy foydalanuvchi yoʻllarini aniqlash va «mijoz nuqtai nazaridan» SLIga kelishish.
2. SLO maqsadlarini va oynani tanlash (30/90 kun); xatolar budjetini hisoblash.
3. Metriklarni shlyuzlarga/xizmatlarga kiritish, kodlarni/sabablarni normallashtirish.
4. Burn-rate alert (qisqa + uzun oyna), marshrutlash va on-call moslamalarini moslash.
5. SLO-komplayensni vizualizatsiya qilish, relizlar/fichflaglar bilan bog’lash.
6. «O’zgarishlarga qarshi byudjet» siyosatini va muzlatish jarayonini boshlash.
7. Retrospektivlar va har bir ortiqcha RCA, regressiya testlari.
8. Har chorakda SLOni byudjetdan amalda foydalanish va biznes maqsadlari boʻyicha qayta koʻrib chiqsin.

Tipik xatolar

Dastur xatolarini e’tiborsiz qoldirib, «ping bo’yicha aptaym» ni o’lchaydilar.
SLO «zaxiraga» qo’yilgan (99. 999%), lekin erishib bo’lmaydigan va hech narsani hal qilmaydi.
Foydalanuvchi alomatlari o’rniga past darajali metriklar bo’yicha alertlar.
Qaramlik xaritasi yo’q → qayerda yonayotgani aniq emas.
SLOning relizlar bilan aloqasi yo’q → Byudjetni kim «yutgani» aniq emas.
p99 → yaxshi o’rtacha, ammo yomon UX VIP foydalanuvchilari.

iGaming/fintech uchun o’ziga xos

Jadval bo’yicha cho’qqilar: o’yinlar/tadbirlar/aksiyalar - capacity-ni oldindan oshirish, kesh/CDN-ni isitish, maxsus limit profillarini kiritish.
Biznes-SLI: Time-to-Wallet, depozit/chiqarish muvaffaqiyati, «to’lov tezligi» p95; dashbordlarning ildizida.
PSP/hamkorlar: provayderlar bo’yicha alohida SLO/dashbordlar, yo’nalishlarni avtomatik ravishda o’zgartirish.
Antibot/antifrod: xatolar byudjetini yemaslik kerak - «qonuniy bloklar» ni «texnik xatolar» dan ajrating.
Regulyator: jurnallarni saqlash, SLO/SLA hisob-kitoblarining takrorlanuvchanligi, hodisalar bo’yicha hisobotlar.

FAQ

Rejalashtirilgan ishlarni SLOdan olib tashlash kerakmi?
Odatda yoʻq: SLO foydalanuvchi tajribasini aks ettiradi. SLA uchun istisnolarni ko’rsatish mumkin.

Nima uchun o’rtacha emas, balki p95?
O’rta dumlarini yashiradi; UX quyruqlarni aniqlaydi (p95/p99).

Butun mahsulot uchun bitta SLO mumkinmi?
Sizga SLO daraxti kerak: mahsulot bo’yicha agregat va kritik yo’llar/komponentlar bo’yicha qizlari.

Jami

Kuchli infratuzilma KPI tizimi - bu foydalanuvchi SLI, real SLO, o’zgarishlarni boshqarish vositasi sifatida xato byudjeti, aqlli alerting va hodisalar intizomi va RCA. Texnik ko’rsatkichlarni biznes ko’rsatkichlar bilan bog’lang, yig’ish va vizualizatsiyani avtomatlashtiring - infratuzilmani oldindan aytib bo’ladi, va aptaym hatto eng yuqori stsenariylarda ham boshqariladi.