Error Budgets va SLO boshqaruvi

1) Nima uchun SLO va xatolar byudjeti

SLO (Service Level Objective) - foydalanuvchi tomonidan qabul qilinadigan maqsadli sifat darajasi; SLI - o’lchanadigan metrika; Error Budget - oynadan chetga chiqish uchun ruxsat (odatda 30/90 kun).
Xatolar byudjeti ishonchlilikni «abstraksiya» dan boshqariladigan resursga aylantiradi: byudjet tez yonib ketganda - chi va chinimni muzlatamiz; agar byudjet sog’lom bo’lsa, relizlarni tezlashtirish mumkin.

2) SLIni tanlash: «yaxshi» deb nima hisoblash kerak

Mezon: «foydalanuvchi nuqtai nazaridan muvaffaqiyatli».

2. 1 Klassik SLI

Availability: muvaffaqiyatli so’rovlar ulushi (mijoz tomonidan bekor qilinganlarni hisobga olmaganda).
’success = http_status ∈ {2xx, 3xx, 404} va taymautsiz’ (404 agar kutilgan semantika boʻlsa, oʻqish API uchun muvaffaqiyat deb hisoblanishi mumkin).
Latency: so’rovlar ulushi ostonadan tezroq (masalan, p95 ≤ 300 ms).
`good_latency = duration_ms ≤ 300`.
Freshness/Staleness: «ma’lumotlar X daqiqadan oshmaydi» (kesh, kataloglar, koeffitsiyentlar).
Quality: natijaning to’g "riligi (biznes-validatorlardan/bekend-invariantlardan o’tish).

2. 2 Chegara va segmentlar

SLI’route’,’tenant/brand’,’region/jurisdiction’,’payment _ provider’bo’limlari bo’yicha hisoblanishi kerak. Shunday qilib, butun tizim bo’ylab bitta tanqidiy tutqichning ishlamay qolishiga yo’l qo’ymaysiz.

3) Formulalar va budjet

3. 1 Request-based (API uchun afzal)

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

3. 2 Time-based (fon xizmatlari/striming uchun)

SLO_uptime = good_minutes / total_minutes

3. 3 Maqsadlar misoli

Umumiy API: 99. 30 kun ichida 9% foydalanish imkoniyati → byudjet = 0. 1%.
Tanqidiy to’lov qalamlari: 99. 95%; kataloglar/qidiruv: 99. 5%.
Latentligi: p95 ≤ 300 ms ga ’/v1/payments’, p99 ≤ 800 ms.

4) SLIni asboblash

4. 1. Prinsiplar

Loglar/treyslar → aniq buckets bilan RED (Rate/Errors/Duration) metrikalari.
’tenant’,’region’,’route _ class’(PIIsiz).
Ikkita metrikani hisoblang: «muvaffaqiyat» va «hamma narsa», latency uchun esa «tez» va «hamma narsa».

4. 2 Prometheus misoli (5m uchun 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) Alertlar bo’yicha burn rate (multi-window, multi-burn)

5. 1 G’oya

Byudjet maqsadga nisbatan qanchalik tez yonayotganini koʻrib chiqamiz. Agar tezlik qisqa va uzun oynada yuqori boʻlsa, signal beramiz.

5. 2 Chegara profillari (SLO uchun 99. 9%)

Peyjing: burn rate ≥ 14. 4 × (1 soat uchun budjetning 10 foizi va 6 soat uchun 5 foiz).
Tix: burn rate ≥ 6 × (6 soat uchun 2% va 24 soat uchun 1%).

5. 3 Qoidalar misoli (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"

Xuddi shunday 6 soat/24 soat uchun.

6) Budjet boshqarmasi: jarayonlar

6. 1 Reliz geytlari

Agar budjet qoldig’i <25% va trend salbiy bo’lsa - fichiga «kod-muzlatish», SRE/barqarorlik ustuvorligi.
Kanar relizlari alohida SLO kesimiga ega bo’lishi kerak (’deployment. environment="canary"`).

6. 2 Beklogning ustuvorligi

Buyruq sig’imini yonish tezligi va tushumga ta’siriga mutanosib ravishda taqsimlang.
Texnik qarzni metriklar bilan asoslang: «X fix burn rate ni Y% ga kamaytiradi».

6. 3 Voqeadan keyingi

Har bir hodisa - RCA va «qaytarib bo’lmaydigan fix» (actionable), nazorat «SLOga qaytganmi».

7) SLO kod sifatida

7. 1 SLO-manifest misoli (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 Qoidalar generatsiyasi

Qoidalar, dashbordlar va hisobotlarni avtomatik ravishda yaratish uchun generatorlardan (slo-generator, pyrra, sloth) foydalaning.

8) SLOning degradatsiyasi va himoyasi

Load shedder: choʻqqida «qimmat» bogʻliqliklarsiz tez javob berish.
Cache & stale: `stale-while-revalidate` для read.
Rate/Concurrency limits: orqa tomonlarni himoya qiladi; muhim yo’nalishlar - ustuvor yo’nalish.
Circuit/Timeout: tezkor taymautlar va «fallback» shoxobchalari.
Feature flags: ogʻir chiziqlarni bitta tugma bilan oʻchirish.

9) SLO uchun kuzatish

Dashbordlar: SLO actual vs target, budjet qoldig’i, burn rate, yo’nalishlar/provayderlar bo’yicha hissa.
Korrelyatsiya: SLO → dan exemplar → aniq trace → logi/profillar.
Hisobotlar: har hafta - trendlar, budjet iste’moli, tanazzulning top-sabablari.

10) Antipatternlar

Hamma narsa uchun bitta «global» SLO muammolarni yashiradi. Segmentlash.
«99. 99% to’liq" qiymati va haqiqatdan tashqari. Foydalanuvchi tajribasidan maqsadlarni tanlang.
Burn rate/SLO o’rniga CPU/heap bo’yicha alertlar.
UXni buzadigan 4xx/uzoq tahririyatlarni e’tiborsiz qoldirish.
Shaffof bo’lmagan oyna (rolling vs kalendar) - «olma va apelsin» ni taqqoslash.

11) iGaming/Moliya xususiyatlari

Pul yo’llari (depozitlar/xulosalar): alohida SLOlar umumiy darajadan yuqori (masalan, 99. 95% foydalanish; p95 ≤ 250 ms).
PSP/KYC provayderlari: har bir provayder bo’yicha SLO + ularning burnga qo’shgan hissasi uchun alertlar; yo’nalishlarni avtomatik ravishda o’zgartirish (smart routing).
Yurisdiksiyalar/tenantlar: SLO va’region/jurisdiction/brand’bo’yicha byudjetlar, mahalliy muammo global metrikani «to’ldirmasligi» uchun.
Mas’uliyatli o’yin: limitlarni qo’llash/o’z-o’zini istisno qilish vaqtidagi SLO (compliance-formula).
Audit/regulyator: SLO va hodisalar hisobotlarini saqlang; ichki auditlar uchun shaffoflik.

12) Prod-tayyorlik chek-varaqasi

• SLIs (availability/latency/quality/freshness) va segmentlar (route/tenant/region) aniqlangan.
• Maqsadlar (SLO) real, biznes bilan kelishilgan; 30/90 kunlik rolling oynalar mavjud.
• Ko’p oynali burn rate bo’yicha alertlar.
• SLO kod sifatida (qoidalar/dashbordlar generatori); budjet bo’yicha hisobotlar.
• Reliz geytlari budjet qoldig’i bilan bog’langan; kanareya kesmalari.
• Degradatsiya mexanizmlari (shedder, cache stale, circuit, limitlar) amalga oshirildi va sinovdan o’tkazildi.
• Metrik treyslarning (exemplars) korrelyatsiyasi, aniq runbooks.
• Moliyaviy/yurisdiksiya yo’llari - alohida SLO/alertlar; PSP/KYC yiriklashtirilgan.
• Hodisalar bo’yicha muntazam retro va burn asosidagi ishonchlilikka investitsiyalar.

13) TL; DR

Foydalanuvchi qiymatiga ko’ra SLIni aniqlang, real SLOlarni belgilang va boshqaruvni ko’p oynali Error Budget va burn rate orqali amalga oshiring. SLO-kodni, reliz geytlarini va rejadagi degradatsiyani yoqing. Yo’nalishlar/tenantlar/mintaqalar bo’yicha segmentlang; Pul yo’llari uchun qattiqroq maqsadlar va alohida alertlarni saqlang.