Ден соолук-текшерүү механизмдери
1) Эмне үчүн
Health-текшерүүлөр каскаддык ийгиликсиздикке каршы биринчи тоскоолдук болуп саналат: алар туура айлануу түйүндөрүн алып салуу, retrais бороон-чапкындарды алдын алуу, SLO сактоо жана MTTR азайтуу, начарлоо жана калыбына келтирүү тездетүү.
2) текшерүүлөрдүн негизги түрлөрү
Liveness - жараян "тирүү" (жок deadlock/агып/паника). Ката → көчүрмөсүн кайра баштоо.
Readiness - кызмат максаттуу SLO менен трафикти тейлөөгө жөндөмдүү (көтөрүлгөн пулдар, кэш жылытуу, нормалдуу көз каранды ресурстар). Ката → баланстан алып салуу, бирок кайра эмес.
Startup - кызмат жашоо/readiness (узун bootstrap, көчүрүү, warmup) өтүүгө даяр. Мөөнөтүнөн мурда кайра куруудан коргойт.
Deep-health (домендик-спецификалык): бизнес инварианттар (коюм end-to-end өтөт, депозит активдүү PSP тарабынан авторизацияланат). Алар деградация сигналдары үчүн колдонулат, бирок дароо кайра баштоо үчүн эмес.
External/Synthetic: Сырттагы активдүү пингдер (API жолу, алдыңкы скрипт, PSP/KYC пункту) - колдонуучунун жеткиликтүүлүгүн өлчөө.
3) үлгү Дизайн: жалпы эрежелер
1. Арзан жашоо: тышкы көз каранды эмес; окуялар, heap/FD, watchdog айлампасын текшерүү.
2. SLO боюнча Readiness: тейлөө үчүн зарыл болгон жергиликтүү ресурстарды текшерүү (DD пулдар, жылуу кэш, лимиттер). Тышкы көз карандылыктар - "can-serve?" сигналдар.
3. Latency-budget: ар бир үлгү өзүнүн SLA бар (мисалы, ≤ 100-200 ms); ашып кеткенде - "degraded", бирок жашоо боюнча 5xx эмес.
4. Backoff & Jitter: үлгүлөрдүн интервалдары 5-15 сек, убакыттын өтүшү 1-2 сек, синхрондуу бороон-чапкындарды болтурбоо үчүн каталар үчүн экспоненциалдык кечигүү менен.
5. Гистерезис: Статусун өзгөртүү үчүн N ийгиликтүү/туура эмес жооптор (мисалы, 'successThreshold = 2', 'failureThreshold = 3').
6. Версиялоо: эндпоинттер '/healthz ', '/readyz', '/startupz 'туруктуу; deep-checks астында '/health/... 'аттуу текшерүүлөр менен.
7. Жашыруун жана PII жок: жооптор - статустар жана кыска коддор гана.
8. Explainability: JSON төмөнкү текшерүү тизмеси менен: '{"status ": "degraded "", checks ": [{"name ": "db"", ok": true", latencyMs": 18}, {" name":" psp. eu","ok":false,"reason":"timeout"}]}`.
4) Кабаттар боюнча deep-checks мисалдар
4. 1 BD/кэш/сактоо
DD: кыска бүтүм 'SELECT 1' боюнча окуу-реплика жана бассейн текшерүү; latency/replication-lag босоголор.
Кэш: 'GET '/' SET' тест ачкычы + hit-ratio guard (төмөн hit → warning).
Object Storage: HEAD иштеп жаткан объект (жүктөп жок).
4. 2 кезек/агымы
Брокер: ping-topic publish + жергиликтүү бөлүгүндө consume; consumer-lag босоголор.
DLQ: терезеден dead-letter кабарлар жок.
4. 3 Тышкы провайдерлер (PSP/KYC/AML)
PSP: lightweight auth-probe (non-монетардык), келишим/күбөлүк/квота текшерүү; safe-үлгүлөр жок болсо - биз прокси-метриканы колдонобуз (банктар/GEO боюнча 5-10 мүнөттө авторизациялоонун ийгилиги).
KYC/AML: ден соолук-API жана SLA кезек; деградацияда - альтернативдик агымга/провайдерге өтүү.
4. 4 API/Front
Синтетика: транзакциялык жол (логин → депозиттик-демилгелөө → "кумга" коюм) EU/LATAM/APAC.
RUM сигнал: каталар JS/HTTP жана LCP/TTFB үлүшү - триггерлер "сыртта".
5) Платформа менен интеграция
5. 1 Kubernetes / Cloud
'startupProbe' bootstrap (көчүрүү/кэш-warmup) коргойт.
'livenessProbe' минималисттик; 'readinessProbe' пулдарды/кэштерди/жергиликтүү кезектерди эске алат.
Параметры: `initialDelaySeconds`, `periodSeconds`, `timeoutSeconds`, `failureThreshold`, `successThreshold`.
PodDisruptionBudget жана maxUnavailable readiness эске алуу менен.
HPA/KEDA: кезек боюнча масштабдоо/SLI; readiness routing таасир этет.
5. 2 Балансировщиктер/шлюздар/сетка
L7 денгээлде Health-routing (HTTP 200/429/503 semantics).
Outlier detection (envoy/mesh): error-rate/latency percentiles боюнча көлмөгө алып салуу.
Circuit-breaker: Бир эле учурда суроо-талаптардын/байланыштардын чектери, ден соолук сигналдары менен интеграция.
5. 3 Автоскейлинг жана деградация
Readiness = FALSE → трафик алынып салынат, бирок pod тирүү (жылый алат).
Deep-degrade (PSP down) → Грацефул режими үчүн feature flags (мисалы, төлөө ыкмаларын убактылуу жашыруу, waiting-room күйгүзүү).
6) Тайм-ауттордун жана ретрациялардын саясаты
Убакыттын өтүшү <SLO бюджети: 'timeout = min (⅓ p99, 1-2s)' синхрондуу көз карандылыктар үчүн.
Демпотенттүүлүк: ретрайлер үчүн милдеттүү; биз idempotency-keys колдонобуз.
экспоненциалдуу backoff + jitter: синхрондуу вал эффекттерин алдын алуу.
Retray бюджеттери: caps per-request/tenant, "retry-storms" коргоо.
7) Мамлекеттик сигналдар жана алертинг
Green/Yellow/Red: Dashboard кызматы боюнча кыскача статусу.
SLO боюнча Burn-rate-алерттер: тез (1 саат) жана жай (6-24 саат).
Correlation-hints: релиздер/Fich желектери/пландаштырылган иштери жөнүндө белгилер.
Auto-actions: "кызыл" deep-check менен - fallback провайдерди күйгүзүү, тректердин семплингин жогорулатуу.
8) iGaming үчүн акылдуу стратегиялар
Payment-aware readiness: коюм кызматынын даярдыгы PSP маршрутизаторунун абалын жана банктар/GEO боюнча лимиттерди эске алат.
Odds/Lines publishing: readiness publisher cache/edge-жылы бөлүштүрүү линияларын жана убакыт булактары боюнча кыскача lag көз каранды.
Tournament spikes: агрессивдүү outlier-detection жана waiting-room убактылуу саясаты.
9) Антипаттерндер
DD/PSP барып Liveness → тышкы маселе боюнча массалык кайра.
Startup/readiness/liveness бөлүнүүсүз бир "универсалдуу" ден соолук пункту.
backoff/jitter → бороон-чапкын retrains жок катуу убакыт.
Histeresis → Fapping багыттоо жок.
Deep-check, ал кайра баштоону козгойт (анын максаты - диагностика жана багыттоо, кайра баштоо эмес).
health-end-пункттарында жашыруун 5xx (чыныгы статусту жашыруу).
10) Интерфейс үлгүлөрү
/startupz → `200 OK {"uptimeSec": ..., "version":"..."}`
Текшерүүлөр: init скрипттери, миграциялар бүттү, ачкычтар жана конфигилер жүктөлдү.
/healthz (liveness) → `200 OK {"heapOk": true,"fdOk":true,"eventLoop":"ok"}`
Текшерүү: окуялардын айлампасы, процесс ресурстары, паника/oom-желектердин жоктугу.
/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-контур сапаты (KPI/KRI)
Pod 'NotReady' дан 'Ready' ге (warmup-SLO) чыгуу убактысы.
жыштык "fapping" readiness per кызматы.
жаңылыш pod (root-cause - тышкы көз карандылык)%.
MTTR окуялар, кайда ден соолук механизмдери ролду ойногон (чейин/кийин).
On-call катышуусуз автоматтык failover/feature-degrade үлүшү.
Синтездик тактык vs RUM (жалган ишке киргизүү/өтүү).
12) Жол картасы киргизүү (4-8 жума)
Нед. 1-2: критикалык жолдорду инвентаризациялоо; startup/liveness/readiness; JSON жоопторду төмөнкү текшерүүлөр жана гистерезис менен киргизүү.
Нед. 3-4: deep-checks кошуу: BD/кэш/брокер; 2-3 GEO үчүн логин/депозит/коюм үчүн синтетика; кулпу/mesh outlier-detection кирет.
Нед. 5–6: payment-aware readiness и PSP-fallback; алдыңкы үчүн waiting-бөлмө; lag/кезек боюнча автоскейлинг; burn-rate боюнча алерталар.
Нед. 7-8: chaos-күн (PSP өчүрүү/DD көчүрмөлөрү), backoff/jitter текшерүү; fintyuning убакыт, PDB; KPI отчету жана түзөтүү.
13) Артефакттар
Health Spec (per кызматы): текшерүүлөрдүн тизмеси, убакыт бюджеттери, гистерезис, кызыл статустагы иш-аракеттер.
Runbooks: "Readiness = FALSE: эмне кылабыз? ", "PSP-fallback: кадамдар жана кайтаруу критерийлери".
Routing Policy: outlier-detection эрежелери, circuit-breakers, калем босоголору.
Synthetic Playbook: сценарийлер жана география, SLO синтетика, график.
Release Gate: кызыл deep-check негизги көз карандылыгы менен бошотуу блоктору.
Жыйынтык
Туура иштелип чыккан health-текшерүү контур бир катмарлуу сигналдар системасы болуп саналат: жараянын жөндөмдүүлүгү үчүн жарык жашоо, жол тейлөө жөндөмдүүлүгү үчүн readiness, коопсуз баштоо үчүн баштоо жана башкарылуучу деградация жана багыттоо үчүн домендик өзгөчө deep-текшерүү. Autoscaling, outlier-routing, синтетика жана SLO-alerting менен бирге, ал каскаддык каталар коркунучун азайтат, MTTR кыскартат жана iGaming платформасынын бизнес-маанилүү жолдорун турукташтырат.