Health-check mexanizmlari

1) Nima uchun

Health-checks - kaskadli nosozliklarga qarshi birinchi to’siq: ular tugunlarni rotatsiyadan to’g’ri chiqaradi, retray bo’ronlarining oldini oladi, degradatsiyani soddalashtiradi va tiklanishni tezlashtiradi, SLOni saqlab qoladi va MTTRni kamaytiradi.

2) Tekshiruvlarning bazaviy turlari

Liveness - «tirik» jarayon (deadlock/oqish/vahima yo’q). Nusxani qayta boshlash muvaffaqiyatsiz tugadi.
Readiness - xizmat maqsadli SLO bilan trafikka xizmat ko’rsatishga qodir (pullar ko’tarilgan, kesh isitilgan, bog’liq resurslar normal). Xato → muvozanatdan chiqarib tashlash, lekin qayta tiklash.
Startup - xizmat liveness/readiness (uzun bootstrap, migratsiya, warmup) ga oʻtishga tayyor. Muddatidan oldin restartlardan himoya qiladi.
Deep-health (domenga xos): biznes invariantlar (stavka end-to-end o’tadi, depozit aktiv PSPda avtorizatsiyalanadi). Degradatsiya signallari uchun ishlatiladi, lekin darhol qayta boshlash uchun emas.
External/Synthetic: tashqi faol pinglar (API-yo’l, front-skript, PSP/KYC endpoint) - foydalanuvchining foydalanuvchanligini o’lchaydi.

3) Namunalar dizayni: umumiy qoidalar

1. Arzon hayot: tashqi qaramlikka bormaymiz; hodisa halqasi, heap/FD, watchdog.
2. SLO bo’yicha Readiness: xizmat ko’rsatish uchun zarur bo’lgan mahalliy resurslarni (DB pullari, issiq kesh, limitlar) tekshiramiz. Tashqi qaramliklar - bloklanmagan «can-serve?» signallar.
3. Latency-budget: har bir sinov o’zining SLAsiga ega (masalan, 100-200 ms ≤); oshganda - «degraded», lekin 5xx liveness bo’yicha emas.
4. Backoff & Jitter: sinxron bo’rondan qochish uchun 5-15 sek, 1-2 sek vaqt oralig’i, xatolarda eksponensial kechikish bilan.
5. Gisterezis: Maqom oʻzgarishi uchun N muvaffaqiyatli/notoʻgʻri javoblar (masalan,’successThreshold = 2’,’failureThreshold = 3’).
6. Versiyalash: endpointlar ’/healthz’, ’/readyz’, ’/startupz’barqaror; deep-checks ostida ’/health/...’nomli tekshiruvlar bilan.
7. Sirsiz va PII: javoblar - faqat maqom va qisqa kodlardir.
8. Explainability: JSON:’{"status ": "degraded "", checks ": [{"name ": "db"", ok": true", latencyMs": 18}, {" name":" psp. eu","ok":false,"reason":"timeout"}]}`.

4) Qatlamlar bo’yicha deep-checks namunalari

4. 1 DB/kesh/saqlash

DQ: o’qish-nusxa olish uchun «SELECT 1» qisqa tranzaksiya va pulni tekshirish; latency/replication-lag chegarasi.
Kesh:’GET ’/’ SET’test kaliti + hit-ratio guard (past hit → warning).
Object Storage: Mavjud obʼektning HEAD (yuklamasdan).

4. 2 Navbatlar/striming

Broker: ping-topic publish + consume lokal partition doirasida; consumer-lag ostonalari.
DLQ: deraza orqasida dead-letterda xabarlar koʻpaymaydi.

4. 3 Tashqi provayderlar (PSP/KYC/AML)

PSP: lightweight auth-probe (non-monetary), kontrakt/sertifikat/kvotalarni tekshirish; agar safe-namunalar bo’lmasa, proksi-metrikadan foydalanamiz (banklar/GEO bo’yicha 5-10 daqiqada avtorizatsiyalarning muvaffaqiyati).
KYC/AML: health-API va SLA navbatlar; degradatsiyada - muqobil oqimga/provayderga o’tish.

4. 4 API/front

Sintetika: EU/LATAM/APAC da tranzaksion yo’l (login → depozit-tashabbus → «qumga» stavka).
RUM signali: JS/HTTP va LCP/TTFB xatolari ulushi - «tashqarida» triggerlar.

5) Platforma bilan integratsiya

5. 1 Kubernetes / Cloud

’startupProbe’ bootstrap (migratsiya/kesh-warmup) ni himoya qiladi.
’livenessProbe’ minimalist;’readinessProbe’polar/kesh/lokal navbatlarni hisobga oladi.
Параметры: `initialDelaySeconds`, `periodSeconds`, `timeoutSeconds`, `failureThreshold`, `successThreshold`.
PodDisruptionBudget va maxUnavailable readiness.
HPA/KEDA: navbat boʻyicha masshtablash/SLI; readiness routingga taʼsir qiladi.

5. 2 Balanschilar/shlyuzlar/mesh

L7 (HTTP 200/429/503 semantics) darajasida health-routing.
Outlier detection (envoy/mesh): puldan error-rate/latency persentillari boʻyicha chiqarish.
Circuit-breaker: bir vaqtning o’zida bog’lanish uchun so’rovlar/ulanishlar limitlari, health-signallar bilan integratsiya.

5. 3 Avtoskeyling va degradatsiya

Readiness = FALSE → trafik olib tashlanadi, lekin pod tirik (isishi mumkin).
Graceful rejimi uchun Deep-degrade (PSP down) → feature flags (masalan, to’lov usullarini vaqtincha yashirish, waiting-roomni yoqish).

6) Taym-autlar va retraylar siyosati

Vaqt-out <SLO budjeti:’timeout = min (⅓ p99, 1-2s)’sinxron qaramliklar uchun.
Idempotentlik: retraylar uchun majburiy; idempotency-keys.
Eksponensial backoff + jitter: sinxron val effektlarining oldini oladi.
Retray budjetlari: caps per-request/tenant, «retry-storms» dan himoya qilish.

7) Holat va alerting signallari

Yashil/Sariq/Qizil: servis-dashborddagi yig’ma maqomlar.
SLO bo’yicha Burn-rate-alertlar: tez (1 soat) va sekin (6-24 soat).
Correlation-hints: relizlar/fich bayroqlar/rejali ishlar haqida belgilar.
Auto-actions: «qizil» deep-check - provayderning fallbackini yoqish, sampling trassalarini oshirish.

8) iGaming uchun aqlli strategiyalar

Payment-aware readiness: stavkalar xizmatining tayyorligi PSP marshrutizatorining holatini va banklar/GEO limitlarini hisobga oladi.
Odds/Lines publishing: publisher’dagi readiness liniyalar manbalari va/edge’dagi tarqatish vaqtiga bogʻliq.
Tournament spikes: ko’proq tajovuzkor outlier-detection va waiting-room vaqtinchalik siyosati.

9) Antipatternlar

Liveness, DB/PSPga boradi → tashqi muammoga qarshi ommaviy restartlar.
Bitta «universal» health-endpoint startup/readiness/liveness bo’linmasdan.
Qattiq taym-autlar backoff/jitter → boʻron retraylarisiz.
Gisterezis yo’qligi → yo’nalish flapping.
Restartlarni tetiklovchi Deep-check (uning maqsadi - diagnostika va marshrutlash, qayta ishga tushirish emas).
Health-endpointlarda yashirin 5xx (haqiqiy holatni yashirish).

10) Interfeys namunalari

/startupz → `200 OK {"uptimeSec": ..., "version":"..."}`

Tekshirish: init skriptlar, migratsiyalar tugadi, kalitlar va konfiklar yuklandi.

/healthz (liveness) → `200 OK {"heapOk": true,"fdOk":true,"eventLoop":"ok"}`

Tekshiruvlar: voqealar davri, jarayon resurslari, vahima/oom-bayroqlarning yo’qligi.

/readyz (readiness) →

`200 OK/503 {"canServe": true,"db":{"ok":true,"latencyMs":12},"cache":{"ok":true},"queue":{"ok":true,"lag":0},"localQuota":{"ok":true}}`

/health/payments (deep) →

`200/206/503 {"psp. eu": {"ok":false,"reason":"timeout"}, "psp. alt":{"ok":true}, "routerMode":"failover"}`

11) Health-kontur sifati metrikasi (KPI/KRI)

Pod’NotReady’dan’Ready’ga (warmup-SLO) chiqish vaqti.
«Flapping» chastotasi readiness per servis.
Xato qayta tiklangan pod (root-cause - tashqi qaramlik).
MTTR hodisalar, bunda health-mexanizmlar rol o’ynadi (oldin/keyin).
On-call ishtirokisiz avtomatik failover/feature-degrade ulushi.
Sintetikaning aniqligi vs RUM (soxta ishga tushirish/o’tkazib yuborish).

12) Joriy etish yo’l xaritasi (4-8 hafta)

Ned. 1-2: kritik yo’llarni xatlovdan o’tkazish; startup/liveness/readiness; JSON-javoblarni quyi tekshirishlar va gisterezis bilan kiritish.
Ned. 3-4: deep-checks qo’shish: DB/kesh/broker; 2-3 GEOdagi login/depozit/stavkalar uchun sintetika; / mesh shlyuzida outlier-detection-ni yoqish.
Ned. 5–6: payment-aware readiness и PSP-fallback; front uchun waiting-room; lag/navbatlar bo’yicha avtoskeyling; burn-rate bo’yicha alertlar.
Ned. 7-8: chaos-kunlar (PSP/DB replikasini uzib qo’yish), backoff/jitterni tekshirish; taym-autlarning fintyuningi, PDB; KPI hisoboti va tuzatish kiritish.

13) Artefaktlar

Health Spec (per servis): tekshirishlar roʻyxati, vaqt byudjetlari, gisterezis, qizil holatdagi harakatlar.
Runbooks: "Readiness = FALSE: nima qilyapmiz? ", "PSP-fallback: qadamlar va qaytarish mezonlari".
Routing Policy: outlier-detection, circuit-breakers qoidalari.
Synthetic Playbook: ssenariylar va geografiya, sintetikaning SLO, jadval.
Release Gate: asosiy qaramliklar qizil deep-check bo’lganda reliz bloklari.

Jami

Health-checks - bu signallarning qatlamli tizimi: jarayonning hayotiyligi uchun oson hayot, trafikka xizmat ko’rsatish qobiliyati uchun readiness, xavfsiz boshlash uchun startup va boshqariladigan degradatsiya va marshrutlash uchun domenga xos deep-checks. Autoscaling, outlier-routing, sintetika va SLO-alerting bilan birgalikda u kaskadli nosozliklar xavfini kamaytiradi, MTTRni qisqartiradi va iGaming-platformaning biznes-muhim yo’llarini barqarorlashtiradi.