SLO/SLA va metrika

SLO/SLA va metriklar

1) Atamalar va ierarxiya

SLI (Service Level Indicator) - o’lchanadigan ko’rsatkich «foydalanuvchi bizni qanday ko’radi»: muvaffaqiyatli so’rovlar ulushi, ma’lumotlarning yashirligi, yangiligi, muvaffaqiyatli qayta ishlangan batchlar ulushi va boshqalar.
SLO (Service Level Objective) - SLI ning kuzatuv oralig’idagi maqsadli qiymati (28/30/90 kun). Misol: "99. 9% so’rovlar/to’lovlar 400 ms ≤ yakunlanadi".
Error budget — 1 − SLO. SLO 99 da. 9% xato budjeti = 0. 1% vaqt/soʻrovlar.
SLA (Agreement) - yuridik ahamiyatga ega xizmat ko’rsatish darajasi: SLO, o’lchash, istisnolar, kompensatsiya/jarimalarni o’z ichiga oladi.

2) Loyihalashtirish prinsiplari

Simptomlar> ichki metrika. SLI haqiqiy foydalanuvchi tajribasini aks ettirishi kerak.
Kalit SLI soni kam. Servis uchun - 2-5 asosiy: muvaffaqiyat, yashirin, o’tkazish qobiliyati/yangilik, to’g "ri.
Tanqidiy yo’llarni qamrab olish. Har bir biznes stsenariy uchun (checkout, login, webhook, ETL-yuklash) - o’z SLI/SLO to’plami.
«Muvaffaqiyat» ning qattiq semantikasi. «Kod 200» emas, balki «foydalanuvchi javobni va natijani o’z vaqtida oldi».
Tashqi va ichki SLOlarni ajratish. Ichki - qattiqroq; tashqi SLA ≤ 1-2 to’qqizta pastda.

3) SLI katalogi (referens)

3. 1 API/onlayn-servislar

Muvaffaqiyat: ’SLI _ success = 1 − (5xx + timeout + business_error )/ all_requests'

Latentlik: p95/p99’http _ server _ duration _ seconds’yo’nalishlar/usullar/ijarachilar bo’yicha

O’tkazish qobiliyati: ’RPS ’/limitlar/kvotalar

To’g "rilik: valid javoblar ulushi (signaturalar, sxemalar, invariantlar)

3. 2 Vebxuki/asinxron yetkazib berish

Yetkazib berish: T soniya va ≤ N retrajda tasdiqlangan voqealar ulushi

Buyurtmachilar: uzoq kechiktirmasdan obunachilar ulushi (per-tenant)

3. 3 Maʼlumotlar/ETL/DWH

Yangilik (freshness): ’now − last_successful_ingest_ts'

Toʻliq: ’ingested _ rows/ expected_rows'

To’g "rilik: sifat tekshiruvidan o’tgan yozuvlar ulushi

Payplaynlar: muddatgacha tugallangan job ulushi

3. 4 Mobil/mijozlar SDK

Mijoz muvaffaqiyati: halokatli xatolarsiz sessiyalar ulushi

round-trip latentligi: p95 so’rovdan rendergacha

Kesh-xit: keshdan xizmat ko’rsatilganlar ulushi (spektakl belgisi sifatida)

4) Maqsadlarning formulalari va namunalari

• `SLI_req_avail = 1 − (failed_requests / total_requests)`
• `SLO_req_avail = 99. 95%’30 kunga → error budget = 0. 05% soʻrovlar.

• `uptime = (obs_window − downtime) / obs_window`

• ’ SLO _ latency = p95 (route = »/pay») ≤ 400 ms’ 7 kunlik kesmalarda, kesh-isitmalardan tashqari (1%)

• ’ SLO _ freshness (dataset =» orders») ≤ 10 min’ p99 24 soat.

5) Error budget va o’zgarishlarni boshqarish

Budjet (B):’B = 1 − SLO’.
Budjet sarfi (burn): haqiqiy xatolarning yo’l qo’yiladigan xatolarga nisbati.

• Ortiqcha sarflash (burn> 1) → fichfriz, ishonchlilikka eʼtibor qaratish.
• burn rate> X qisqa oynada - hodisa va kapital. chora-tadbirlar.
• Rejalashtirish: sprintning ishonchlilik ulushi o’tgan davr uchun burn bilan bog’liq.

6) Alerting: burn rate va ko’p oynali qoidalar

G’oya: tezkor oqish va sekin driftni ushlaymiz.

• Tanqidiy: «1 soat ichida 2% byudjet» (tez yong’in).
• Ogohlantirish: «6 soat ichida 5% budjet» (sudralib yuruvchi degradatsiya).

• Tezkor hodisalar uchun qisqa oyna (daqiqa-soat).
• Trendlar uchun uzun darcha (6-24 soat).
• Latentlik: p99 bo’yicha alert ≥ 5 daqiqa, flappingni bostirish va trassalar bilan aloqa.

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) Ko’p ijara (multi-tenant) va segmentatsiya

SLI/SLO ijarachilar/rejalar/hududlar bo’yicha hisoblanadi, aks holda mediana muvaffaqiyatsizliklarni «qoplaydi».
Statistik ahamiyat uchun minimal hodisa soni (guard-rails).
SLA tariflar bo’yicha farq qilishi mumkin (masalan, "Pro 99. 9%, Free 99. 5%»).

8) Kuzatish va trassirovkalar bilan aloqa

SLI metrikasi - gistogrammalardan/exemplars hisoblagichlaridan → «yomon» treyslarga o’tish.
Logi - sabablar manbai: taymautlar, biznes xato kodlari, limitlar.
Ma’lumotlar uchun - lineage bilan bog’langan: «qanday joba yangilik metrikasini ushlab qoldi».

9) Kontraktlar va SLA

• SLI/oʻlchash usuli/oynani aniqlash.
• Istisnolar (rejali ishlar, fors-major).
• Hodisalar va kommunikatsiyalar tartibi (status-sahifa, RFO/RCA).
• Kompensatsiyalar (service credits) va so’rov tartibi.
• Yurisdiksiya, amal qilish davri, qayta ko’rib chiqish shartlari.

• Hech qachon ochiq SLOni arxitektura va operatsion amaliyotlar imkon berganidan qattiqroq va’da qilmang.
• Ichki SLO va tashqi SLAlarni ajrating.

10) Qiymati va ustuvorligi

To’qqiztaning narxi chiziqli o’smaydi. «99. 9% → 99. 99%" = arxitekturaning boshqa klassi (N + 1, multizona, aktiv-aktiv).
SLOni eng qimmatli foydalanuvchi harakatlariga qoʻying.
Telemetriya narxini nazorat qiling: downsampling, kvotalar, replika va sinflar bo’yicha saqlash.

11) Tartib-taomillar va hisobotlar

Haftalik hisobotlar: servis/ijarachilar bo’yicha SLO bajarilishi, budjet xarajatlari, top-sabablar, yaxshilash rejalari.
Post-insident RCA: budjet bo’laklari bilan bog’laymiz; asosiy sabablarni bartaraf etish vazifalarini qo’yamiz.
Fichfriz: kiritish/olib tashlash mezonlari.

12) Shablonlar (tezda boshlash uchun)

12. 1 SLO kartochkasi (misol)

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 yetukligi» jadvali

13) Qoidalar namunalari (parchalar)

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) Ma’lumotlar va ML uchun SLO (o’ziga xos xususiyatlar)

To’liq SLO ma’lumotlari: p99 yangilik, p99 to’liqligi, muvaffaqiyatsizlikdan keyin qayta ishlash vaqti.
Ma’lumotlar kontraktlari: kutilayotgan sxemalar, hajmlar, muddatlar; ma’lumotlarning buzilishi → hodisasi.
ML: Infeners latentligi uchun SLO, fich-stor mavjudligi uchun SLA, dreyf monitoringi (model sifati - alohida mavzu, SLAdan tashqari).

15) Xavfsizlik va maxfiylik bilan integratsiya

PII/sirsiz SLI loglari; tokenlash/maskalash.
SLO/SLA o’zgarishlari va hisobotlarni o’zgarmas jurnallarda e’lon qilish auditi.
Tartibga solish yo’llari uchun (to’lovlar/PII) - alohida, qattiqroq SLO.

16) Chek varaqlari

Servisni ishga tushirishdan oldin

• SLI aniqlangan «muvaffaqiyat/yashirin/o’tkazish qobiliyati/yangilik».
• SLO va oynalar oʻrnatilgan; xatolar budjeti hisoblab chiqilgan.
• Burn-rate alertlari sozlangan (qisqa + uzun).
• Dashbordlar RED + exemplars → trassalar; runibuki hodisalar.
• Ko’p ijarali kesmalar va ahamiyat chegaralari.
• Fichfriz va hisobot tartib-taomillari.

Foydalanish

• SLO/burn bo’yicha haftalik hisobot, hardening rejalari.
• Arxitektura/yuk o’zgarganda SLOni qayta baholash.
• Davriy «hodisa-mashqlar» va runibuklarni yangilash.
• Telemetriya qiymati va SLI miqdorini nazorat qilish.

17) Runbook’и

Runbook: p99/pay

1. Alert p99> chegara → dashbord ochish → exemplar orqali treysga oʻtish.
2. Tor CLIENT/SERVER spanini topish, mintaqalarni/versiyalarni solishtirish.
3. Tanazzulni yoqish (kesh/limit/follbek), bogʻliqlik buyrugʻini xabardor qilish.
4. Barqarorlashgandan so’ng - RCA, optimallashtirish vazifalari, SLO o’lchovlarini yangilash.

Runbook: haftalik byudjet xarajatlari> 50%

1. Chichlarni muzlatish, ishonchlilikning ustuvorligini oshirish.
2. Xatolarni klasterlash: yo’nalishlar/ijarachilar/qaramliklar bo’yicha.

3. Trendning tiklanganligini tasdiqlash

4. Retrospektiv va alertlar/chegaralarni tuzatish.

18) FAQ

S: Qancha SLO kerak?
O: Tanqidiy foydalanuvchi stsenariylarida minimal: muvaffaqiyat + yashirin. Qolganlari - kerak bo’lganda.

S: Nima yaxshiroq - vaqt yoki so’rovlar bo’yicha?
O: So’rovlar bo’yicha - ko’proq foydalanuvchi metrikasi. Vaqt boʻyicha tarmoq komponentlari/infra uchun qulay.

V: Nima uchun o’rtacha emas, balki p95?
O: O’rta dumini yashiradi; foydalanuvchi p95/p99 ni sezadi.

V: Qanday qilib «gaykalarni» haddan tashqari kuchaytirmaslik kerak?
O: Haqiqiy maqsadlardan boshlang (tarixiy ma’lumotlar), keyin etuk bo’lganingizda qattiqlashtiring.

• «Kuzatilganlik: loglar, metriklar, trastirovkalar»
• «Taqsimlangan trassalar»
• «Audit va o’zgarmas jurnallar»
• «Vebxuklarni yetkazib berish kafolatlari»
• «In Transit/At Rest shifrlash»
• «Ma’lumotlarning kelib chiqishi (Lineage)»