Health-check механизмдері

1) Не үшін

Health-checks - каскадты істен шығуға қарсы бірінші кедергі: олар тораптарды ротациядан дұрыс шығарады, ретрациялардың дауылын болдырмайды, тозуды жеңілдетеді және SLO-ны сақтай отырып, MTTR-ді төмендете отырып, қалпына келтіруді жылдамдатады.

2) Тексерулердің базалық түрлері

Liveness - «тірі» процесі (deadlock/ағып кету/паника жоқ). Қате → дананы қайта бастау.
Readiness - сервис мақсатты SLO бар трафикке қызмет көрсетуге қабілетті (пулдар көтерілген, кэш жылыту, қалыпты тәуелділік ресурстары). Қате → теңгерімнен алып тастау, бірақ қайта жүктемеу.
Startup - сервис liveness/readiness (ұзын bootstrap, көші-қон, warmup) көшуге дайын. Мерзімінен бұрын қайта қараудан қорғайды.
Deep-health (домендік-ерекше): бизнес-инварианттар (мөлшерлеме end-to-end өтеді, депозит белсенді PSP-де авторизацияланады). Тозу сигналдары үшін пайдаланылады, бірақ дереу қайта бастау үшін емес.
External/Synthetic: сыртқы белсенді пингтер (API-жол, фронт-скрипт, PSP/KYC эндпоинт) - пайдаланушының қол жетімділігін өлшейді.

3) Сынама дизайны: жалпы ережелер

1. Арзан liveness: сыртқы тәуелділікке бармаймыз; оқиғалар ілмегін, heap/FD, watchdog тексереміз.
2. SLO бойынша Readiness: қызмет көрсету үшін қажетті жергілікті ресурстарды тексереміз (ДБ пулы, жылы кэш, лимиттер). Сыртқы тәуелділіктер - бұғатталмайтын «can-serve?» сигналдар.
3. Latency-budget: әрбір сынаманың өзіндік SLA бар (мысалы, 100-200 мс ≤); асып кеткен кезде - «degraded», бірақ 5xx liveness.
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 ДҚ/кэш/сақтау орны

БД: «SELECT 1» қысқа транзакциясы оқу репликасына және пулды тексеруге; latency/replication-lag табалдырығы.
Кэш: 'GET '/' SET' тест кілті + hit-ratio guard (төмен hit → warning).
Object Storage: Бар нысанның HEAD (жүктеусіз).

4. 2 Кезектер/стриминг

Брокер: ping-topic publish + consume жергілікті partition шегінде; consumer-lag табалдырығы.
DLQ: терезенің сыртындағы dead-letter бағдарламасында хабарлардың жарқылдауы жоқ.

4. 3 Сыртқы провайдерлер (PSP/KYC/AML)

PSP: lightweight auth-probe (non-monetary), келісімшартты/сертификатты/квотаны тексеру; егер safe-сынамалар болмаса - прокси-метриканы пайдаланамыз (банктер/GEO бойынша 5-10 минутта авторизациялаудың табысы).
KYC/AML: health-API және SLA кезектері; деградация кезінде - баламалы ағынға/провайдерге ауысу.

4. 4 API/фронт

Синтетика: транзакциялық жол (логин → депозит-бастама → «құмға» мөлшерлеме) 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 Теңгерушілер/шлюздер/mesh

L7 (HTTP 200/429/503 semantics) деңгейінде Health-routing.
Outlier detection (envoy/mesh): перцентильдер бойынша пулдан шығару.
Circuit-breaker: тәуелділікке бір мезгілде сұрау/қосылу лимиттері, health-сигналдармен интеграция.

5. 3 Автоскейлинг және тозу

Readiness = FALSE → трафик алынады, бірақ pod тірі (жылынуы мүмкін).
Deep-degrade (PSP down) → graceful режимі үшін feature flags (мысалы, төлем әдістерін уақытша жасыру, waiting-roomды қосу).

6) Тайм-ауттар мен ретрайлер саясаты

Синхронды тәуелділіктер үшін уақыт-аут <SLO бюджеті: 'timeout = min (⅓ p99, 1-2s)'.
Теңсіздік: ретрациялар үшін міндетті; idempotency-keys қолданамыз.
Экспоненциалды backoff + jitter: синхронды білік әсерлерін болдырмайды.
Ретрайлардың бюджеттері: caps per-request/tenant, «retry-storms» -тен қорғау.

7) Жай-күй сигналдары және алертинг

Жасыл/Сары/Қызыл: сервис-дашбордта жиынтық мәртебелер.
SLO бойынша Burn-rate-алерталар: жылдам (1 сағ) және баяу (6-24 сағ).
Correlation-hints: релиздер/фич-жалаулар/жоспарлы жұмыстар туралы белгілер.
Auto-actions: «қызыл» deep-check кезінде - провайдердің fallback-ін қосу, трассалардың семплингін арттыру.

8) iGaming үшін ақылды стратегиялар

Payment-aware readiness: мөлшерлемелер сервисінің дайындығы PSP маршрутизаторының жай-күйін және банктер/GEO бойынша лимиттерді ескереді.
Odds/Lines publishing: паблишерде readiness кэш/edge тарату уақыты мен желі көздері бойынша жиынтық lag-ге байланысты.
Tournament spikes: неғұрлым агрессивті outlier-detection және waiting-room уақытша саясаты.

9) Антипаттерндер

Liveness, ол ДБ/PSP → сыртқы проблема кезінде жаппай қайта қарауға барады.
Бір «әмбебап» health-эндпоинт startup/readiness/liveness.
backoff/jitter → дауыл ретрассыз қатты тайм-ауттар.
Гистерезистің болмауы → бағыттау флаппингі.
Қайта қарауға түрткі болатын Deep-check (оның мақсаты - диагностика және маршруттау, қайта іске қосылмайды).
Жасырын 5xx health-эндпоинттерінде (нақты мәртебені бүркемелеу).

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)

On-call қатысуынсыз автоматты failover/feature-degrade үлесі

'NotReady' дегеннен 'Ready' дегенге (warmup-SLO) шығу уақыты.
«Флаппинг» жиілігі readiness per сервис.
Қате қайта жаңартылған pod% (root-cause - сыртқы тәуелділік).
MTTR оқиғалар, мұнда health-механизмдер (дейін/кейін) рөлін атқарды.
Синтетиканың дәлдігі vs RUM (жалған іске қосылу/жіберу).

12) Енгізу жол картасы (4-8 апта)

Нед. 1-2: сындарлы жолдарды түгендеу; startup/liveness/readiness; JSON-жауаптарын төменгі тексерулермен және гистерезиспен енгізу.
Нед. 3-4: deep-checks қосу: DD/кэш/брокер; 2-3 GEO-дағы логин/депозит/ставка үшін синтетика; outlier-detection/mesh.
Нед. 5–6: payment-aware readiness и PSP-fallback; фронт үшін waiting-room; lag/кезек бойынша автоскейлинг; burn-rate бойынша алерталар.
Нед. 7-8: chaos-күндері (PSP/DB репликасын ажырату), backoff/jitter тексеру; тайм-ауттардың финтюнингі, PDB; KPI есебі және түзету.

13) Артефактілер

Health Spec (per service): тексерулер тізімі, уақыт бюджеттері, гистерезис, қызыл мәртебедегі әрекеттер.
Runbooks: "Readiness = FALSE: не істейміз? ", "PSP-fallback: қадамдар және қайтару өлшемдері".
Routing Policy: outlier-detection, circuit-breakers ережелері, перценттік табалдырықтар.
Synthetic Playbook: сценарийлер мен география, SLO синтетика, кесте.
Release Gate: негізгі тәуелділіктің қызыл deep-check кезінде релиз блоктары.

Жиынтық

Сауатты жобаланған health-checks контуры - бұл сигналдардың қабатты жүйесі: процестің өміршеңдігі үшін жеңіл liveness, трафикке қызмет көрсету қабілеті үшін readiness, қорғалған бастау үшін startup және басқарылатын деградация мен маршруттау үшін домендік-ерекше deep-checks. Autoscaling, outlier-routing, синтетика және SLO-алертингпен бірге ол каскадтық істен шығу қаупін азайтады, MTTR-ді қысқартады және iGaming-платформасының бизнес-сындарлы жолдарын тұрақтандырады.