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. Readiness по SLO: перевіряємо локальні ресурси, необхідні для обслуговування (пули БД, кеш теплий, ліміти). Зовнішні залежності - через неблокуючі «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» на read-репліку і перевірка пулу; 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-проб - використовуємо проксі-метрики (успіх авторизацій за 5-10 хв по банках/GEO).
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

Health-routing на рівні L7 (HTTP 200/429/503 semantics).
Outlier detection (envoy/mesh): виведення з пулу по error-rate/latency перцентилях.
Circuit-breaker: ліміти одночасних запитів/підключень до залежності, інтеграція з health-сигналами.

5. 3 Автоскейлінг і деградація

Readiness = FALSE → трафік знімається, але pod живий (може грітися).
Deep-degrade (PSP down) → feature flags для graceful-режиму (наприклад, тимчасово приховати методи оплати, включити waiting-room).

6) Політики тайм-аутів і ретраїв

Тайм-аут <бюджет SLO: 'timeout = min (⅓ p99, 1-2s)'для синхронних залежностей.
Ідемпотентність: обов'язкова для ретраїв; використовуємо idempotency-keys.
Експоненціальний backoff + jitter: запобігає синхронним вал-ефектам.
Бюджети ретраїв: caps per-request/tenant, захист від «retry-storms».

7) Сигнали стану та алертинг

Зелений/Жовтий/Червоний: зведені статуси на сервіс-дашборді.
Burn-rate-алерти по SLO: швидкі (1 год) і повільні (6-24 год).
Correlation-hints: позначки про релізи/фіч-прапори/планові роботи.
Auto-actions: при «червоному» deep-check - включити fallback провайдера, підвищити семплінг трас.

8) Розумні стратегії для iGaming

Payment-aware readiness: готовність сервісу ставок враховує стан маршрутизатора PSP і ліміти по банках/GEO.
Odds/Lines publishing: readiness у паблішера залежить від зведених lag за джерелами ліній і часу поширення в кеш/edge.
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)

Час виходу pod з'NotReady'в'Ready'( warmup-SLO).
Частота «флапінгу» readiness per сервіс.
% помилково рестартованих pod (root-cause - зовнішня залежність).
MTTR інцидентів, де health-механізми зіграли роль (до/після).
Частка автоматичних failover/feature-degrade без участі on-call.
Точність синтетики vs RUM (помилкові спрацьовування/пропуски).

12) Дорожня карта впровадження (4-8 тижнів)

Нед. 1–2: інвентаризація критичних шляхів; рознести startup/liveness/readiness; ввести JSON-відповіді з під-перевірками і гістерезис.
Нед. 3–4: додати deep-checks: БД/кеш/брокер; синтетика для логіну/депозиту/ставки в 2-3 GEO; включити outlier-detection в шлюзі/mesh.
Нед. 5–6: payment-aware readiness и PSP-fallback; waiting-room для фронту; автоскейлінг по lag/чергах; алерти по burn-rate.
Нед. 7–8: chaos-дні (відключення PSP/репліки БД), перевірка backoff/jitter; фінтюнінг тайм-аутів, 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-checks - це шарувата система сигналів: легкий liveness для життєздатності процесу, readiness для здатності обслуговувати трафік, startup для захищеного старту і доменно-специфічні deep-checks для керованої деградації і маршрутизації. У зв'язці з autoscaling, outlier-routing, синтетикою і SLO-алертингом він знижує ризик каскадних відмов, скорочує MTTR і стабілізує бізнес-критичні шляхи iGaming-платформи.