Aptaymni kuzatish

1) Nima uchun aptaymni kuzatish

Aptaym - xizmat foydalanuvchiga taqdim etilgan vaqtning ulushi. Bu kuzatishning «birinchi chizig’i»: kirish imkoniyati yo’qligi, tarmoqdagi buzilish, DNS/TLS nosozligi, yo’nalish muammolari yoki CDN. Yuqori yuklangan va tartibga solinadigan tizimlar (fintech, iGaming) uchun aptaym tushumga, SLAni bajarishga va jarima xavfiga bevosita taʼsir qiladi.

2) Atamalar va formulalar

’SLI = (muvaffaqiyatli tekshirish/barcha tekshirishlar) × 100%’.
SLO: oynadan maqsadli foydalanish imkoniyati (odatda 28-30 kun), masalan, 99. 9%.
SLA: tashqi majburiyat; har doim ichki SLO ≤.
MTBF/MTTR: nosozliklar orasidagi oʻrtacha vaqt/tiklashning oʻrtacha vaqti.

99. 0% → ~ 432 daqiqa

99. 9% → ~ 43 min

99. 99% → ~4. 3 min

99. 999% → ~ 26 sek

3) Qanday tekshirishlar kerak (qora quti)

Xizmatni «mijoz nigohida» koʻrish uchun tashqi nuqtalardan (turli mintaqalar/provayderlar) ishga tushiriladi.

1. ICMP (ping) - asosiy tarmoq/tugun mavjudligi. Tezkor, lekin biznes muvaffaqiyatini aks ettirmaydi.
2. TCP connect - port tinglaydimi? Brokerlar/DB/SMTP uchun foydalidir.
3. HTTP/HTTPS - status-kod, sarlavhalar, oʻlcham, tahririyatlar, birinchi baytgacha boʻlgan vaqt.
4. TLS/sertifikatlar - amal qilish muddati, zanjir, algoritmlar, SNI, protokollar.
5. DNS - A/AAAA/CNAME, NS-salomatlik, tarqatish, DNSSEC.
6. gRPC - qoʻngʻiroq holati, deadline, meta maʼlumotlar.
7. WebSocket/SSE - qo’l siqish, ulanishni saqlash, xabar-aks.
8. Proksi/marshrutlash/CDN - har xil PoP, kesh xesh-testi, geo-variantlar.
9. Tranzaksion sintetik ssenariylar (klik/shakl): «login → qidiruv → depozit (qum qutisi)».
10. Heartbeat/cron-monitoring - servis «pulsatsiya» qilishi shart (xuk N daqiqada bir marta); signal yo’q - signal.

• Taymautlarni haqiqiy UX ga yaqinlashtiring (masalan, TTFB ≤ 300 ms, total ≤ 2 s).
• 200 OK xatosi muvaffaqiyatli boʻlmasligi uchun kontent assertini (kalit soʻzi/JSON maydoni) tekshiring.
• Mustaqil provayderlar va tarmoqlar (multihop, turli ASN) orqali tekshirishlarni takrorlang.

4) Oq quti va servis salomatligi

Orkestrator uchun Liveness/Readiness namunalari (jarayonlar jonlimi? trafikni qabul qilishga tayyormi?).
Qaramlik salomatligi: DB, kesh, voqealar brokeri, tashqi API (to’lovlar/KYC/AML).
Fich-bayroqlar/degradatsiya: muammolar yuzaga kelganda, muammosiz yo’llarni yumshoq o’chirib qo’yamiz.

Oq namunalar tashqi tekshiruvlarning o’rnini bosmaydi: xizmat «ichkarida sog’lom» bo’lishi mumkin, ammo DNS/TLS/yo’nalish tufayli foydalanuvchi uchun mavjud emas.

5) Geografiya va ko’p mintaqalik

Trafikning asosiy hududlaridan va tanqidiy qaramlik provayderlari yonidan sintetikani ishga tushiring.
Kvorum: agar N. mintaqalardagi nosozlik (masalan, 3 ta ≥ 2 tasi) mahalliy anomaliyalarni bartaraf etish uchun hodisani qayd etamiz.
Kogortlar bo’yicha chegara: muhim segmentlar (mamlakatlar, VIP, aloqa operatorlari) uchun alohida SLI/SLO.

6) Alertlar siyosati (minimal shovqin)

Multi-region + multi-test: faqat kelishilgan muvaffaqiyatsizlikka uchragan paytdagina peyjer (masalan, HTTP va TLS bir vaqtning o’zida, ≥ 2 mintaqa).
Debauns: Ketma-ket muvaffaqiyatsizliklar yoki peyjdan 2-3 daqiqa oldin oyna.

• L1: on-call (prodakshen-servislar).
• L2: nosozlik belgisiga qarab tarmoq/platforma/xavfsizlik.
• Avtomatik yopilish: barqaror M muvaffaqiyatli tekshiruvlardan so’ng.
• Sokin soatlar/imtiyozlar: tanqidiy bo’lmagan ichki xizmatlar uchun - faqat chiptalar, peyjersiz.

7) Maqom-sahifa va kommunikatsiya

Ommaviy (mijoz) va xususiy (ichki) maqom sahifalari.
Sintetikadan avtomatik hodisalar + qo’l izohlari.
Xabar namunalari: aniqlandi - aniqlandi - ta’sir - aylanma yo’l - ETA - hal qilindi - post-mordem.
Rejalashtirilgan oynalar: oldindan e’lon qilish, istisnolarni SLOdan alohida hisobga olish.

8) Tashqi qaramliklarni hisobga olish

Har bir provayder uchun (to’lovlar, KYC, tarqatish, CDN, bulutlar) - bir nechta hududlardan o’z tekshiruvlari.
Failover-yo’nalishlar: sintetika signali bo’yicha muqobil provayderga avto-o’tish.
Provayder darajasidagi alohida SLO va integral e2e-SLO.
SLA haqida provayderlar bilan kelishish (status-vebxuklar, qo’llab-quvvatlash ustuvorligi).

9) Dashbordlar va asosiy vidjetlar

Tekshirish holati bilan dunyo xaritasi (HTTP, DNS, TLS turlari bo’yicha).
Relizlar/bayroqlar izohlari bilan vaqtinchalik hodisalar.
hududlar bo’yicha TTFB/TTL/latency P50/P95/P99.
Kogortlar boʻyicha foydalanish imkoniyati (mamlakat/provayder/qurilma).
MTTR/MTBF, bir oy mobaynida foydalanish uchun mo’ljallangan budjetning «nuqson» va «burn-down» trendlari.
Muvaffaqiyatsizliklarning asosiy sabablari (TLS-expiry, DNS-resolving, 5xx, timeouts).

10) Hodisa jarayoni (tezkor stsenariy)

1. Ko’p mintaqa/ko’p turdagi alert ishga tushadi.
2. Navbatchi tasdiqlaydi, relizlarni muzlatishni o’z ichiga oladi, egalarini xabardor qiladi.
3. Tezkor diagnostika: DNS/TLS/CDN holati, oxirgi relizlar, xato jadvali.
4. Aylanib chiqish: yo’nalishni o’zgartirish, folbek-kontent/provayder, degradatsiya rejimini yoqish.
5. Qayta tiklash: sintetika/haqiqiy trafik yashil ekanligini tekshirish.
6. Status-sahifadagi kommunikatsiya; hodisani yopish.
7. RCA va action items: tuzatishlar, testlar, alertlar, pleybuklar.

11) SLA/SLO bo’yicha hisobot

Har oylik hisobotlar: servislar/hududlar bo’yicha aptaym, nuqson daqiqalari, MTTR, sabablari.
SLA bilan taqqoslash: kreditlar/kompensatsiyalar, agar qo’llanilsa.
Choraklik revyu: ostonalarni dolzarblashtirish, sintetikani taqsimlash, qaramliklar ro’yxati.

12) Tekshirish shablonlari (misol)

• Usul:’GET/healthz/public’(sirsiz).
• Vaqt: 2 s, retry: 1.
• Muvaffaqiyat:’2xx’,’X-App-Version’sarlavhasi mavjud, JSON’status’:’ok’.

• Muddati> 14 kun, valid zanjiri, TLS protokollari 1. 2 +’, to’g "ri SNI.

• Javob vaqti ≤ 100 ms, A/AAAA yozuvlari rejaga mos keladi, SERVFAIL/REFUSED yo’q.

• Vebxuk ’/beat/{ service}’har 5 daqiqada bir marta; ketma-ket 2 ta signal yo’qligi - L2 alertlari (fon vazifalari/ETL).

13) Joriy etish chek-varaqasi

• Ko’p mintaqaviy tashqi tekshiruvlar (HTTP/TCP/DNS/TLS/chuqur stsenariylar).
• Orkestrator uchun oq namunalar readiness/liveness.
• Tanqidiy/tanqidiy bo’lmagan yo’llarni ajratish, degradatsiya fich bayroqlari.
• Alerta, eskalatsiya va avto yopishlarda kvorum va debauns.
• Ommaviy va ichki maqom sahifalari, xabar namunalari.
• Tashqi provayderlar uchun alohida tekshiruvlar va SLO + avtomatik failover.
• Dashbordlar: xarita, taymline, parsentili, tinish daqiqalari, MTTR/MTBF.
• SLA/SLO va hodisadan keyingi RCA bo’yicha muntazam hisobotlar.

14) Tez-tez xatolar

Faqatgina MTTR/kontentsiz ping/port - amalda mavjud bo’lmaganda «yashil».
Bitta monitoring nuqtasi - soxta ijobiy/salbiy xulosalar.
TLS/DNS nazoratining yo’qligi - kechikish/miskonfig tufayli to’satdan ishlamay qolish.
Ortiqcha shovqin: bitta mintaqadan/tekshirish turidan bitta muvaffaqiyatsizlikka uchragan alertlar.
Oʻzgarishlar bilan bogʻliq emas - dashbordlarda relizlar va bayroqlarning izohlari yoʻq.
Hisobga olinmagan qaramliklar - to’lov provayderi tushib ketdi, umumiy maqomi esa «yashil».

15) Jami

Aptaymni kuzatish nafaqat URLni yuklash. Bu haqiqiy hududlardan sintetik tekshiruvlar tizimi, shovqinsiz oqilona alertlar, status-sahifalar orqali shaffof aloqa, tashqi qaramlikni hisobga olish va qatʼiy hisobot berish. To’g’ri qurilgan monitoring MTTRni kamaytiradi, SLAni himoya qiladi va foydalanuvchi tajribasini oldindan aytib bo’lmaydigan darajada saqlaydi.