Liveness/Readiness проби

2) Принципи дизайну

1. Розділяйте семантики.

Readiness: зовнішня здатність обслужити запити (враховує критичні залежності).
Liveness: детект «невиліковного» стану процесу.
2. Fail-fast, але не «false-fast». Налаштуйте таймаути/поріг'failureThreshold'так, щоб короткі сплески не приводили до зайвих рестартів.
3. Ніяких важких операцій в пробах. Перевірка повинна бути швидкою (≤100 -200 мс) і без побічних ефектів.
4. Граціозна деградація. При частковій недоступності залежностей - Readiness = OK, якщо є безпечний фоллбек (кеш/огрубіння).
5. Deterministic I/O. Статуси залежать тільки від поточного стану, а не від «випадкових» зовнішніх тестів.

3) Семантика HEALTH-ендпоінтів

3. 1 HTTP-підхід (рекомендується)

'GET/healthz/liveness'→ 200 якщо процес «живий» (event-loop крутиться, GC не застряг, watchdog «серце» б'ється).
'GET/healthz/readiness'→ 200 якщо екземпляр готовий до трафіку критичного класу. Перевірки: пул з'єднань, локальні кеші, доступність ядра бізнес-логіки.
'GET/healthz/startup'→ 200 після ініціалізації (міграції/прогрів кешу/завантаження моделей).

• Не можна в liveness ходити в зовнішні БД/API - це призведе до «самогубств» під час інцидентів залежностей.
• У readiness можна перевіряти критичні залежності, але з таймаутами і деградацією: якщо є валідний фолбек - не валити.

3. 2 gRPC Health Checking

Використовуйте стандарт'grpc. health. v1. Health/Check'з service-scoped станами ('SERVING','NOT _ SERVING'). Для Kubernetes - grpc-проби (або http-проксі).

3. 3 Внутрішні тригери

Watchdog «м'якої» зупинки: при SIGTERM виставляти Readiness = FAIL → вичікувати'terminationGracePeriodSeconds'→ завершуватися, відпрацьовуючи черги.

4) Таймінги і пороги (tuning)

• `initialDelaySeconds`, `periodSeconds`, `timeoutSeconds`, `successThreshold`, `failureThreshold`.

• readiness: `period=5s, timeout=0. 2–0. 5s, failure=2`
• liveness: `period=10s, timeout=0. 2–0. 5s, failure=3`

• startup: 'period = 5s, failure = 60'( до ~ 5 хв)
• readiness/liveness активуються після успіху startup

• readiness відображає готовність до обробки (підключення до брокера, чи є DLQ-деградація),
• liveness - внутрішній heartbeat loop.

Бекоф на відмовах: у додатку використовуйте експоненційний backoff на перепідключення до залежностей, інакше readiness буде «пиляти».

5) Конфігурації (фрагменти)

5. 1 Kubernetes, HTTP-проби

yaml livenessProbe:
httpGet: { path: /healthz/liveness, port: 8080 }
periodSeconds: 10 timeoutSeconds: 1 failureThreshold: 3

readinessProbe:
httpGet: { path: /healthz/readiness, port: 8080 }
periodSeconds: 5 timeoutSeconds: 1 failureThreshold: 2

startupProbe:
httpGet: { path: /healthz/startup, port: 8080 }
periodSeconds: 5 failureThreshold: 60

5. 2 Kubernetes, gRPC-проба

yaml readinessProbe:
grpc:
port: 9090 service: my. app. Service periodSeconds: 5 timeoutSeconds: 1

5. 3 Graceful shutdown

yaml terminationGracePeriodSeconds: 30 lifecycle:
preStop:
exec:
command: ["/bin/sh","-c","curl -s localhost:8080/healthz/drain && sleep 5"]

'/healthz/drain'всередині сервісу переводить Readiness = FAIL (stop-accepting), дає часу завершити активні запити.

6) Залежності та деградація

Критичні (без них не можна обслужити): БД авторизації для '/login', платіжний шлюз для '/pay'. Можна перевіряти в readiness з таймаутом ≤80% від'timeoutSeconds'проби.
Некритичні: аналітика, email, кеш-шар при наявності довантажу. Не включайте їх в readiness; Використовуйте фолбек.
Feature-flags: при частковій деградації відключайте залежні фічі, зберігаючи Readiness = OK.

7) Черги та фонові обробники

• Readiness = OK, якщо підписка/конект до брокера встановлений і є ресурс для обробки.
• При переповненні DLQ/лаге → Readiness може залишатися OK (якщо приймаємо і складаємо), але SLI «свіжість/лаг» загоряється - алерт за даними.
• Liveness: контролюйте poll-цикл/heartbeat, дідлок-детектор.

Ідемпотентність: прискорює відновлення після рестартів liveness.

8) Sidecar/mesh/ingress

• Увімкніть'readinessGate'( K8s) для врахування статусу sidecar,
• Переконайтеся, що проби не потрапляють в mTLS-бар'єри (або додайте винятки).
• Ingress/Envoy/Nginx: проксируйте '/healthz/' локально, не «виводьте назовні» внутрішні деталі.

9) Безпека і приватність

Health-ендпоінти не повинні розкривати конфіги, версії бібліотек, рядки помилок - тільки «OK/FAIL» + мінімальний код причини.
Доступ ззовні обмежте (NetworkPolicy/ACL). Для публічних - давайте тільки liveness-пінг без деталей.
Логи health-перевірок - на рівні DEBUG, з тротлінгом.

10) Спостережуваність і SLO

Експортуйте метрики: 'health _ readiness {status}','health _ liveness {status}', час обробки проби.
Зв'язуйте Readiness-флапи з SLO доступності (випадання з ендпоінтів → 5xx/connection reset).

• «Часті рестарти по liveness> N/год» - симптом дедлоків/витоків.
• «Флап Readiness> X/15 хв» - симптом залежності/мережевих проблем.
• Кореляція з деплоєм ('service. version`).

11) Тестування

Unit/Contract: ендпоінти '/healthz/' повертають коректні статуси при виключенні кожної залежності.
Chaos: відключення БД/кешу/брокера: Readiness повинен падати або включати фоллбек строго за моделлю. Liveness - не тригериться, якщо процес «живий».
Load/Soak: під навантаженням health-ендпоінти повинні залишатися швидкими (не прокидати контеншн).
Canary: перевіряйте стабільність Readiness перед збільшенням трафіку.

12) Часті помилки і як їх уникнути

Liveness перевіряє БД/зовнішні API. Підсумок - нескінченні рестарти при інцидентах. Рішення: обмежити liveness «життям процесу».
Важкі перевірки в пробах. Веде до помилкових відмов. Рішення: легкі перевірки + окремі background-health монітори.
Немає Startup Probe. Повільні старти «вбиваються» liveness. Рішення: додати startup з широким вікном.
Відсутність graceful shutdown. Рідкісні 5xx при деплої. Рішення: preStop + зняття з балансування.
Флап-шторми. Занадто агресивні пороги. Рішення: підняти'failureThreshold', збільшити'timeoutSeconds', додати backoff.
Однакові ендпоінти для всього. Змішування семантик. Рішення: окремі'liveness/readiness/startup'.

13) Міні-патерни реалізації

python
@app. get("/healthz/liveness")
def liveness():
return 200

@app. get("/healthz/readiness")
def readiness():
ok_core = core_is_ready () # local pools/caches/initialization ok_db = db. ping (timeout = 50 _ ms) # only if the DB is critical return 200 if (ok_core and ok_db) else 503

@app. get("/healthz/startup")
def startup():
return 200 if INIT_DONE else 503

@app. post("/healthz/drain")
def drain():
set_readiness(False); return 200

go
// use google. golang. org/grpc/health/grpc_health_v1 healthServer. SetServingStatus("my. app. Service", SERVING) // or NOT_SERVING

yaml spec:
readinessGates:
- conditionType: "proxy. istio. io/ready"

14) Чек-листи

Перед продом

• Розділені ендпоінти liveness/readiness/startup, описана їх семантика.
• Liveness не чіпає зовнішні залежності; Readiness перевіряє тільки критичні з таймаутами і фоллбеком.
• Налаштовані'initialDelay/period/timeout/failureThreshold'під профіль сервісу.
• Включений graceful shutdown: 'preStop'+ зняття з балансування.
• Метрики/логи здоров'я підключені; алерти на рестарти/флап.
• Тести відмов залежностей і повільних стартів пройдені.

Експлуатація

• Щотижневий звіт по рестартам і флапам readiness.
• Тюнінг порогів після інцидентів; зв'язок з релізами.
• Регулярні chaos-тести вимикання залежностей.
• Актуальність семантик при зміні критичності залежностей.

15) FAQ

В: Чи можна однією пробою закрити все?
ПРО: Небажано. Розділяйте'startup','readiness','liveness'- це знижує помилкові спрацьовування і прискорює RCA.

В: Чи перевіряти кеш в readiness?
ПРО: Якщо без кеша є коректний (хоч і повільний) режим - не валіть readiness, просто увімкніть деградацію.

В: Що робити при частих рестартах по liveness?
ПРО: Спочатку виключіть дідлок/витік; потім послабте пороги і додайте watchdog в додатку.

В: Як врахувати багатоарендність?
ПРО: Readiness повинен відображати здатність обслужити будь оренда-трафік. Для приватних проблем конкретного орендаря - не змінюйте readiness, а сигналізуйте окремими SLI/алертами.

• "Спостережуваність: логи, метрики, трасування"
• «Розподілені трасування»
• «SLO/SLA і метрики»
• «Гарантії доставки вебхуків»
• «Шифрування In Transit»
• «Менеджмент секретів»