Жашоо/Readiness үлгүлөрү

2) Дизайн принциптери

1. семантика бөлүшүү.

Readiness: тышкы жөндөмдүүлүгү (маанилүү көз карандылыкты эске алат).
Liveness: "айыккыс" процесстин абалы.
2. Fail-fast, бирок "false-fast" эмес. Таймауттарды/босогону 'failureThreshold' кыска жарылуулар ашыкча кайра баштоого алып келбеши үчүн орнотуңуз.
3. Сыноолордо оор операциялар жок. Текшерүү тез болушу керек (≤ 100-200 ms) жана эч кандай терс таасирлери.
4. Татынакай деградация. Эгерде көз карандылыктын жарым-жартылай жеткиликсиз болсо - Readiness = OK, эгерде коопсуз фоллбек (кэш/ката) болсо.
5. Deterministic I/O. Статустар "кокустук" тышкы тесттерге эмес, учурдагы абалына гана көз каранды.

3) HEALTH-END семантикасы

3. 1 HTTP ыкмасы (сунушталат)

'GET/healthz/liveness' → 200 процесс "тирүү" болсо (event-loop айланат, GC тыгылып калган жок, watchdog "жүрөк" согот).
'GET/healthz/readiness' → 200 Эгерде үлгү критикалык класстагы трафикке даяр болсо. Текшерүүлөр: байланыш бассейни, жергиликтүү кэштер, бизнес логиканын өзөгүнүн болушу.
Инициализациядан кийин 'GET/healthz/startup' → 200 (көчүрүү/кэш жылытуу/моделдерди жүктөө).

• Сиз тышкы DD/API барып жашоого мүмкүн эмес - бул көз карандылык окуялар учурунда "өзүн-өзү өлтүрүү" алып келет.
• readiness Сиз критикалык көз карандылыкты текшере аласыз, бирок убакыт жана деградация менен: Эгерде валиддик фоллбек бар болсо - кулап жок.

3. 2 gRPC Health Checking

'grpc стандартын колдонуңуз. health. v1. Health/Check's 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 ийгиликсиз: колдонмодо көз карандылыкка кайра туташтыруу үчүн экспоненциалдык 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) Көз карандылык жана деградация

Критикалык (аларсыз тейлөө мүмкүн эмес): DD authorization үчүн '/login ', төлөм шлюзы үчүн '/pay'. Сиз 'timeoutSeconds' үлгүсүнүн 80% ≤ убакыт менен readiness текшере аласыз.
Критикалык эмес: аналитика, электрондук почта, кошумча жүктөө болгон учурда кэш катмары. readiness аларды камтыбайт; follbek колдонуу.
Feature-flags: Жарым-жартылай деградация менен Readiness = OK сактоо менен көз каранды чиптерди өчүрүү.

7) кезек жана арткы иштеп чыгуучулар

• Readiness = OK, эгерде брокерге жазылуу/байланыш орнотулган жана иштетүү үчүн ресурс бар.
• DLQ/лаге → Readiness толуп, анда OK (кабыл жана бүктөп болсо), бирок SLI "сергектик/лаг" жарык болот - маалымат боюнча alert.
• Liveness: контролдоо poll-айлампасы/heartbeat, дедлок детекторунун.

Idempotentity: liveness калыбына келтирүү кийин тездетет.

8) Sidecar/mesh/ingress

• киргизүү 'readinessGate' (K8s) sidecar статусун эсепке алуу үчүн,
• Үлгүлөр mTLS тоскоолдуктарга түшпөгөнүн текшериңиз (же өзгөчөлүктөрдү кошуңуз).
• Ingress/Envoy/Nginx: Прокатка '/healthz/' жергиликтүү, ички бөлүктөрүн "чыгып" жок.

9) Коопсуздук жана купуялык

Health-EndPoints бир гана "OK/FAIL" + минималдуу себеп коду - китепканалардын, ката саптары нускасын ачыкка чыгарбашы керек.
Сырттан кирүү чектөө (NetworkPolicy/ACL). Коомдук үчүн - майда-чүйдөсүнө чейин гана жашоосуз пинг берели.
ден соолук текшерүү Логи - DEBUG деъгээлинде, Trottling менен.

10) Байкоо жана SLO

Export metrics: 'health _ readiness {status}', 'health _ liveness {status}', үлгү иштетүү убактысы.
Readiness Flap менен SLO жеткиликтүүлүгүн байланыштыруу (End Points → 5xx/connection reset).

• "Жашоодогу тез-тез рестарттар> N/саат" - дедлок/агып кетүү белгиси.
• "Flap Readiness> X/15 мин" - көз карандылык/тармактык көйгөйлөрдүн белгиси.
• Деплой менен корреляция ('service. version`).

11) Сыноо

Unit/Contract: End Points '/healthz/' ар бир көз карандылыкты өчүргөндө туура статусун кайтарып берет.
Chaos: DD/кэш/брокерди өчүрүү: Readiness жыгылып же модель боюнча катуу фоллбек камтышы керек. Liveness - процесс "тирүү" болсо, триггер эмес.
Load/Soak: health-end-point жүктөмү тез болушу керек (continshn ыргытып эмес).
Canary: трафикти көбөйткөнгө чейин Readiness туруктуулугун текшериңиз.

12) Көп каталар жана аларды алдын алуу үчүн кантип

Liveness DD/тышкы API текшерет. натыйжасы - окуяларды чексиз кайра. Чечим: жашоону "процесстин жашоосу" менен чектөө.
Оор сыноолор. жалган баш тартууга алып келет. Solution: Easy текшерүү + жеке background-ден соолук монитор.
Жок Startup Probe. Жай баштоо "өлтүрүп" liveness. Чечим: кенен терезе менен баштоо кошуу.
graceful shutdown жок. Сейрек кездешүүчү 5xx деплой менен. Чечим: preStop + балансты алып салуу.
Flap-бороон. Өтө агрессивдүү босоголор. Чечим: 'failureThreshold' жогорулатуу, 'timeoutSeconds' жогорулатуу, backoff кошуу.
Баары үчүн бирдей эндпоинттер. Семантика аралашмасы. Чечим: өзүнчө 'liveness/readiness/startup'.

13) Mini сатуу үлгүлөрү

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, алардын семантика сүрөттөлөт.
• Жашоо тышкы көз карандылыкты тийгизбейт; Readiness гана Таймауттар жана follbek менен сын текшерет.
• 'initialDelay/period/timeout/failureThreshold' кызматтын профилине ылайыкташтырылган.
• graceful shutdown кирет: 'preStop' + балансты алып салуу.
• Ден соолук метрика/Логи туташтырылган; калыбына келтирүү/флап үчүн алерта.
• Көз карандылыктан баш тартуу жана жай баштоо тесттери өттү.

Иштетүү

• Restarts жана Flap жумалык отчет readiness.
• Инциденттерден кийин босоголорду тюнинг; релиздер менен байланыш.
• Үзгүлтүксүз chaos көз карандылыкты өчүрүү тесттер.
• Көз карандылыктын критикалуулугун өзгөртүүдө семантиканын актуалдуулугу.

15) FAQ

В: Бир сыноо менен баарын жабууга болобу?
О: Бул жагымсыз. 'Startup', 'readiness', 'liveness' деп бөлүңүз - бул жалган таасирлерди азайтат жана RCAны тездетет.

С: Кэш текшерүү readiness?
О: Эгерде кэшсиз туура (жай болсо да) режим болсо - readiness жок, жөн гана деградацияны күйгүзүңүз.

S: liveness боюнча тез-тез кайра менен эмне кылуу керек?
О: Биринчиден, дедлок/агып жок; андан кийин босоголорду бошотуп, тиркемеге watchdog кошуу.

S: Кантип көп ижара эске алуу керек?
A: Readiness ар кандай ижара-жол тейлөө жөндөмүн чагылдырышы керек. Белгилүү бир ижарачынын жеке көйгөйлөрү үчүн - readiness эмес, өзүнчө SLI/alerts менен сигнал бериңиз.

• "Байкоо: Логи, метрика, трек"
• "Бөлүштүрүлгөн жолдор"
• "SLO/SLA жана метрика"
• "Webhook жеткирүү кепилдиктери"
• "In Transit шифрлөө"
• "Сыр менеджменти"