SLA va SLO monitoringi

1) Atamalar va rollar

SLA (Service Level Agreement) - mijoz oldidagi tashqi shartnoma majburiyati (jarima shartlari, kreditlar).
SLO (Service Level Objective) - SLAni bajarishni qoʻllab-quvvatlovchi maqsadli ichki xizmat darajasi.
SLI (Service Level Indicator) - o’lchanadigan indikator bo’lib, uning asosida SLO/SLA baholanadi.
Error Budget -’Budget = 1 − SLO’davri uchun «mavjud emas/xato» ning ruxsat etilgan ulushi.
Scope: foydalanuvchi koʻzlari bilan oʻlchanadi (end-to-end). Mikroservislarda - komponent darajasida ham, to’liq yo’lda ham.

2) SLI tanlash: aynan nimani o’lchash kerak

Mezon - foydalanuvchi tajribasi va biznes qiymati bilan bog’liqlik.

• Foydalanish imkoniyati: muvaffaqiyatli soʻrovlar ulushi.’SLI = muvaffaqiyatli/hammasi’.
• Latentlik: so’rovlar ulushi T. chegarasidan tezroq’SLI = P (latency ≤ T)’.
• Sifati: to’g "ri javoblar ulushi (5xx/funksiyasiz) xatolar).
• Maʼlumotlarning dolzarbligi: replikatsiya/ETL kechikishi ≤ X daqiqa.
• Biznes-jarayonning natijadorligi: muvaffaqiyatli to’lovlar/ro’yxatdan o’tkazish ulushi.

Anti-pattern: biznes xatolarini e’tiborsiz qoldirib, faqat 200 ni «muvaffaqiyat» deb hisoblash; test tarmog’ida foydalanuvchi tarmog’i o’rniga o’lchash.

3) Kuzatish formulalari va oynalari

• `Availability = (OK_requests / All_requests) × 100%`.

• ’P95 ≤ T’ →’SLI =% so’rovlar ≤ T’ulushi sifatida shakllantirilishi yaxshiroqdir.
• Masalan: «Qidiruv so’rovlarining 99 foizi 28 kunda 300 ms ≤».
• Siljish oynasi: 28 yoki 30 kun (sezgirlik va barqarorlik balansi). Hodisalar uchun - qo’shimcha derazalar: 1 soat, 6 soat, 24 soat.

4) Error Budget va o’zgarishlar tezligini boshqarish

Hisob-kitob:’SLO = 99. 9%’budjet =’0. Davr mobaynida 1% xato/mavjud emas.

• Budjet> 50%: reja bo’yicha relizlar va tajribalar.
• Byudjet 10-50%: faqat past daromadli relizlar, kanareykalarni kuchaytirish.
• Byudjet <10%: relizlarni muzlatish, ildiz sababi, ishonchlilikni yaxshilash.
• Progressiv relizlar bilan aloqa: canary/feature-flags budjetni dozali, degradatsiyada avto-qaytish bilan «yeydi».

5) Alert-siyosat: ostonalardan burn rate

Nima uchun «daupal SLO - havoni ko’taring»: juda kech. Proaktivlik kerak.

• ’BR = (qisqa oynada kuzatilayotgan xato/ushbu oynada ruxsat etilgan xato)’.
• Agar’BR> 1’bo’lsa - budjet normadan tezroq sarflanadi.

• Tez alert (shovqin sezgir, falokatlarni ushlaydi): deraza 5-10 daqiqa, BR chegarasi 14-20 ×.
• Sekin alert (sudralib yuruvchi degradatsiyalarni ushlaydi): deraza 1-6 soat, BR chegarasi 2-4 ×.
• Kombinatsiya shartlari: tezkor yoki sekin ishladi - on-call peyjing.
• Darajalar: foydalanuvchi SLO uchun peyjer, ichki SLIning kulrang degradatsiyalari uchun chiptalar/xabarnomalar.

6) Kuzatuvchanlik va haqiqat manbalari

Loglar - sabablarning diagnostikasi.
Metriklar - raqamli SLI (muvaffaqiyat/xato, latentlik, ulushlar, hisoblagichlar).
Treyslar - uzluksiz yo’llar, «issiq» segmentlarni mahalliylashtirish.
Sintetika - periferiyadan olingan faol namunalar (region-aware).
Real voqealar - RUM/telemetriya mijozlari, biznes metrika (konversiya, muvaffaqiyatli to’lovlar).

Talablar: relizlar va hodisalar dashbordlaridagi yagona rasm, «versiya/kanareyka/bayroq» izohlari.

7) SLOni loyihalash: bosqichma-bosqich shablon

1. Muhim yoʻlni tasvirlang (masalan, «depozit karta»).
2. SLIni aniqlang: muvaffaqiyat/xato, yashirin chegara, toʻliqlik.
3. SLOni muvofiqlashtiring: 28 kunlik maqsad + istisnolar (rejalashtirilgan oynalar).
4. SLA bilan bog’laning: yuridik majburiyat ≦ haqiqiy SLO.
5. Egasi (service owner), RACI va alert kanalini tayinlang.
6. Alert siyosati (ikki oynali BR) va avto-otkatlar.
7. Hisobotni joriy qiling: har haftalik byudjet sharhlari, voqeadan keyingi revyu.
8. SLOni har chorakda qayta koʻrib chiqing (yuk/arxitektura oʻzgarishi).

8) SLO namunalari (shablonlar)

• Foydalanish imkoniyati:’99 ≥. 95% (28d, e’lon qilingan oynalar bundan mustasno ≤ 30 daqiqa/oy).
• Latentlik:’99% ≥’≤ 400 ms’.
• Biznes-operatsiyalarning muvaffaqiyati:’98 ≥. 5% muvaffaqiyatli avtorizatsiya (fraud-filterlar hisobga olingan).

• Maxfiylik:’99% soʻrovlar ≥’≤ 300 ms.
• Keshning dolzarbligi:’5 ≤’99% hollarda orqada qolish.

• Yetkazib berish:’99 ≥. 9%’ichida’≤ 60 s’(end-to-end, retryalar bilan).
• Yo’qotish:’≤ 0. 01%’xabarlar (idempotentlik/deduplikatsiya kiritilgan).

9) Ko’p mintaqa va ko’p tenant

SLO «kogortlar bo’yicha»: mamlakat, to’lov provayderi, VIP-segment, qurilma.
Chegaradagi lokal SLO: Foydalanuvchiga eng yaqin nuqtalarning metrikasi (edge/PoP).
Agregatsiya: Umumiy SLO muhim kogortlar boʻyicha muvaffaqiyatsizliklarni yashirmasligi kerak.
Provayderlarni almashtirish: SLO-geytlar darajasidagi avtomatik fallback-yo’nalishlar.

10) Dashbordlar va hisobotlar

Reliz dashbord: versiya, kanareyka (% trafik), SLI (muvaffaqiyat/yashirin), BR, bayroqlarning izohlari.
Operatsion dashbord: kunlar bo’yicha budjet burn-down, top-hodisalar, MTTR, muammoli kogortlar.
Haftalik hisobotlar: budjet qoldig’i, BR trendlari, texnik qarz (tor joylar), yaxshilash rejasi.

11) Jarayonlar: hodisalar, RCA va yaxshilanishlar

Hodisa-menejment: alert → BR bahosi → kanareykalar/bayroqlar ko’lami → qaytish/fix.
RCA (ildiz sababi): faktlar/taymline/gipotezalar/tuzatishlar/SLI ta’sirini tekshirish.
Olingan saboqlar: cheklanmagan post-mortemlar, egalari va muddatlari bilan majburiy action items.
Siklning yopilishi: testlar, fich-bayroqlar, limitlar, keshlar, retrajlar, kvotalardagi o’zgarishlar.

12) Komplayens va audit

SLO/SLI nazorat artefaktlari sifatida (policy-as-code, o’zgarmas loglar).
Talablarga bog’liqlik (masalan, to’lov operatsiyalarining mavjudligi).
Dalillar: alertlar bayonnomalari, budjet bo’yicha hisobotlar, relizlar/qaytarmalar jurnallari.

13) Tez - tez xatolar va ulardan qanday qochish mumkin

“99. 99% yoki o’lim": erishib bo’lmaydigan maqsadlar → doimiy shovqin. Real SLOlarni tanlash.
Global o’rta mahalliy muvaffaqiyatsizliklarni yashiradi → kogortlarni kiritish.
Ko’rsatkichlar e2e emas: mijozning haqiqiy degradatsiyasida yuqori SLO → RUM/sintetika qo’shish.
Alertlar bitta ostonada → ikki oynali burn rate ga o’tish.
O’zgarishlar bilan bog’liq emas → relizlar izohlanmagan, avto-qaytarish yo’q.

14) Joriy etishning mini-chek-varaqasi

• Tanqidiy yo’llar va ularning SLI/SLOlari tasvirlangan.
• Kuzatuv va istisno oynasi oʻrnatilgan.
• Ikki oynali BR-alertlar (tez va sekin) sozlangan.
• Versiyalar/bayroqlar izohlari bilan relizlar va operatsiyalar dashbordlari.
• Error budget siyosati relizlarga ta’sir qiladi.
• Muntazam byudjet sharhlari va hodisadan keyingi RCA.
• Hujjatlar va ko’rsatkichlar egalari.

15) Hisob-kitob misoli (aniqlik)

API foydalanish imkoniyati: 99. 28 kun uchun 9% → budjet = 0. 1%.
7 kun ichida 0 ta to’plangan. Xatolarning 06 foizi → Haftalik byudjetning 60 foizi sarflandi.
15 daqiqalik qisqa derazada 2% xato kuzatiladi. Ushbu oynada ruxsat berilgan:’0. 1% × (15 min/40320 min) ≈ 0. 000037%`.
Burn Rate ≫ 1 (o’nlab ×) → tezkor peyjer ishga tushadi, kanareyka 1% gacha aylanadi, «degrade-payments-UX» ficha-bayrog’i yoqiladi, RCA ishga tushiriladi.

16) Jami

SLA/SLO monitoringi - bu hisobotdagi raqamlar emas, balki xizmat sifati va oʻzgarish xavfini boshqarish mexanizmi. To’g’ri SLI, realistik SLO, error budget boshqaruvi, ikki oynali burn-rate alertlari va e2e-kuzatuv metrikani ish yechimlariga aylantiradi: tezroq qiymatni chiqarish va foydalanuvchi tajribasini oldindan aytib bo’lmaydigan darajada ushlab turish.