Health-check механизмы

1) Зачем

Health-checks — первый барьер против каскадных отказов: они корректно выводят узлы из ротации, предотвращают шторма ретраев, упрощают деградацию и ускоряют восстановление, сохраняя SLO и снижая MTTR.

2) Базовые типы проверок

Liveness — процесс “жив” (нет deadlock/утечки/паники). Ошибка → рестарт экземпляра.
Readiness — сервис способен обслуживать трафик c целевыми 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-платформы.