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» үшін төлем шлюзі. 'timeoutSeconds' сынамасының 80% ≤ уақытпен тексеруге болады.
Сындарлы емес: талдау, email, қосымша жүктеме болған кезде кэш-қабат. Оларды readiness бағдарламасына қоспаңыз; фоллбекті пайдаланыңыз.
Feature-flags: ішінара тозған кезде Readiness = OK сақтай отырып, тәуелді фичтерді өшіріңіз.

7) Кезектер және фондық өңдегіштер

• Егер брокерге жазылым/коннект орнатылған және өңдеу үшін ресурс бар болса, Readiness = OK.
• DLQ/лаге → Readiness толған кезде OK қалуы мүмкін (егер қабылдасақ және жинасақ), бірақ SLI «жаңалық/лаг» - деректер бойынша алерт жанады.
• Liveness: poll-цикл/heartbeat, дедлок-детектор.

Теңсіздік: liveness қайта қараудан кейін қалпына келуді жылдамдатады.

8) Sidecar/mesh/ingress

• sidecar мәртебесін есепке алу үшін 'readinessGate' (K8s) дегенді қосыңыз,
• Сынамалардың 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 шифрлау»
• «Құпия менеджменті»