Zero-Downtime өрістету

(Бөлім: Сәулет және Хаттамалар)

1) Zero-Downtime дегеніміз не және ол не үшін қажет

• Клиенттер мен интеграциялар үшін нөлдік қарапайым.
• Болжамды релиздер, жылдам қайту және басқарылатын тәуекел.
• Уағдаластықтар шегінде SLO/SLI (жасырындылық, қателер, қол жетімділік) сақтау.

ZDT кілті - бір ғана «сиқырлы» техника емес, жеткізу үлгілерінің комбинациясы, деректердің үйлесімділігі және трафикті сауатты бағыттау.

2) Zero-Downtime базалық қағидаттары

1. Нұсқалардың үйлесімділігі: жаңа және ескі нұсқалар бір уақытта трафик пен деректерді дұрыс өңдеуі тиіс.
2. Операциялардың теңсіздігі: қайта өңдеу күйді бұзбауы тиіс.
3. Әдемі аяқтау (graceful shutdown) және қосылыстарды дренаждау.
4. Денсаулықты қадамдық тексеру: readiness/liveness сынамалары, health-эндпойнттар.
5. Бірінші сыныпты азамат ретінде қайту: rollback hotfix-ке қарағанда жеңіл және жылдам.
6. Байқалуы by design: релиз белгілері, бірыңғай дашбордтар, SLO бойынша алерттар.
7. Автоматтандыру: шығару және кері қайтару сценарийлері - қол нұсқаулықтары емес, код.

3) Түбіртексіз жеткізу үлгілері

3. 1 Rolling Update

Бірте-бірте ескі нұсқадағы инстанциялардың бір бөлігін трафиктен шығарып, жаңасына жаңартып, пулға қайтарамыз.

Артықшылықтары: инфрақұрылым бойынша үнемді, жай ғана k8s/ASG.
Кемшіліктері: кластер бір уақытта екі нұсқамен жұмыс істейді (version skew).

3. 2 Blue-Green

Екі толық прод-стек: белсенді (Blue) және кандидат (Green). Трафикті ауыстырып қосу - атомарлық флип.

Артықшылықтары: бірден қайту, таза оқшаулау.
Минустары: ↑ инфрақұрылымға арналған шығыстар, stateful-ден күрделі.

3. 3 Canary/Прогрессивті rollout

Жаңа нұсқадағы трафиктің аз үлесін (1-5-10-25-50-100%) метрикалар бойынша гейтпен береміз.

Артықшылықтары: ең аз blast radius, data-driven шешімдері.
Кемшіліктері: жетілген бақылау және зияткерлік бағыттау қажет.

3. 4 Shadow traffic / Dark launch

Жаңа нұсқадағы нақты сұрауларды (пайдаланушыға жауап бермей) айналаймыз немесе метриканы жинау үшін жасырын түрде іске қосамыз.

Артықшылықтары: проблемаларды ерте анықтау.
Минустар: тәуелділікке екі есе жүктеме, жанама әсерлерді бақылау қажет.

4) Трафикті және қосылыстарды басқару

4. 1 Readiness/Liveness

Liveness оркестрге «мені қайта жегіңіз» дейді.
Readiness - «трафикті жібермеңіз, мен әлі дайын емеспін».
Дұрыс readiness-логикасыз және таймаусыз шығаруға болмайды.

4. 2 Қосылыстарды дренаждау (Connection Draining)

• жаңа қосылыстарды қабылдауды тоқтатамыз,
• белсенділердің аяқталуын күтеміз,
• таймаут бойынша «ілінгендерді» үземіз.

4. 3 Sticky-сессиялар және L7 деңгейін бағдарлау

Sticky stateful сценарийлерінде пайдалы, бірақ жүктеме балансын қиындатады.
L7 ережелері (жол бойынша, тақырып бойынша, куке, API нұсқалары) canary/ring үшін ыңғайлы.

4. 4 Ұзақ өмір сүретін қосылыстар

WebSocket/gRPC streaming: жаңарту алдында drain mode + «GOAWAY» сигналын қосыңыз.
Ағындарды және клиенттердің бэкоф-ретраларын асу үшін Windows бағдарламаларын жоспарлаңыз.

5) Деректер мен көші-қонның ДБ үйлесімділігі

5. 1 Expand-Migrate-Contract

1. Expand: жаңа бағандарды/индекстерді/кестелерді ескі нұсқасын бұзбай қосыңыз.
2. Migrate: деректерді фондық және идемпотенттік түрде көшіреміз (батчилер, чек пункттері).
3. Contract: ескісін тұрақтандырғаннан кейін ғана жойамыз.

5. 2 Тәжірибелер

Шығарылым терезесіндегі эксклюзивті DDL блоктарынан аулақ болыңыз.
API/оқиғалар келісімшарттарын (schema registry, CDC) нұсқалаңыз.
Ауыр көші-қон үшін - online-құралдар, репликалар, кезең-кезеңмен ауыстырып қосу.
Екі контурлы жазба (dual-write) тек дедупликациямен және демпотентті тұтынушылармен.
Outbox/Inbox кезек арқылы сенімді біріктіру үшін.

6) Кэштер, сессиялар және фондық тапсырмалар

Сеанстар мен кэш - сыртқы (Redis/Memcached), осылайша нұсқалар өзара алмастырылатын болады.
Кэшті/джиттерді/қарқын индекстерін пулға қосар алдында жылыту.
Өң кезектерін нұсқа бойынша бөліңіз немесе жарысты болдырмау үшін көшбасшылықты пайдаланыңыз.

7) Бақылау және SLO бойынша гейталар

Golden signals: латентность p95/p99, error rate, RPS, saturation, лаг очередей.
Бизнес-SLA: авторизация, конверсия, сәтті төлемдер, құйғыштың қадамдарынан бас тарту.
Гейтс: rollout тек canary ≤ baseline + деградация табалдырығы жылжытылады, ал error budget жанбайды.

8) Қауіпсіз аяқтау және кері шегіну

Кері қайту - бұл сол пайплайн, тек кері бағытта: бекітілген командалар, «қол крафты» емес.
blue-green үшін - flip back; canary үшін - 0% немесе алдыңғы тұрақты қадамға дейін салмақ түсіру.
Деректер: өтемдік транзакциялар, қайта өңдеу, оқиғаларды дедупликациялау.

9) Zero-Downtime чек-парақтары

Шығару алдында

• Қол қойылған бір артефакт (immutable), SBOM және тәуелділікті тексеру жиналды.
• Readiness/liveness іске асырылды және сынақтан өткізілді.
• expand режиміндегі көші-қон жоспары, қайтарымдылығы расталды.
• Дашбордтар мен алерталар жаңа нұсқаға дайын, релиз белгілері тасталды.
• Кері қайту staging/pre-prod бағдарламасында тексерілді.

Шығару кезінде

• Қосылыстардың дренажы қосылған, таймауттар барабар.
• Трафик бірте-бірте аударылады (canary/ring) немесе flip (blue-green).
• Метриктер baseline-мен салыстырылады, гейт табалдырықтары сақталады.

Шығарылғаннан кейін

• N сағат пост-мониторинг, инциденттер жоқ.
• contract көші-қоны аяқталды, уақытша жалаушалар/бағыттар алынып тасталды.
• Ретроспектива, ойнатқыштарды жаңарту.

10) Қарсы үлгілер

Дренажсыз Recreate-deploy және readiness ⇒ сұрау үзілістері.
Дайындалмаған DDL ⇒ прайм-таймдағы блоктар мен таймауттар.
Қызмет нұсқалары арасында үйлеспейтін схемаларды араластыру.
Өңдегіштер мен воркерлерде іспеттіліктің болмауы.
«Сезіммен ұрып шығару» гейтсіз және baseline-мен салыстырусыз.
blue-green кезінде ұзын DNS-TTL, сондықтан flip сағаттап созылады.
rolling/canary кезіндегі жергілікті сессиялар/кэш.

11) Енгізу сценарийлері

11. 1 Kubernetes (rolling + canary)

Deployment с `maxUnavailable=0`, `maxSurge=25%`.
Readiness жылынуды күтеді (кэшті баптандыру, minor көші-қоны).
Сервис-меш/Ingress weighted routing (1-5-10-25-50-100%).
Алерталар: p95, 5xx, кезек артта, бизнес-шұңқыр.

11. Бұлтта 2 Blue-Green

Теңгерушіден кейін екі стек: 'blue. example. com` и `green. example. com`.
Жылыту green, smoke/регресс, содан кейін listener/route swap (немесе төмен TTL-мен DNS-ауыстырып қосу).
Проблемалар кезінде - жедел flip back.

11. 3 Stateful-сервис

Деректер репликасы + online-көші-қон; валидациямен екі рет оқу.
Фондық джобтар «көшбасшылық» нұсқа немесе бөлінген кезектер бойынша көшіріледі.
Инстанциядан тыс сессиялар/кэш; sticky тек уақытша қосылған.

12) Фичефлагтар және клиенттік қосымшалар

Жаңа фичтер жалаулармен іске қосылады (сегменттер: қызметкерлер → бета → барлығы).
Мобильді/десктоп клиенттері үшін хаттаманың сыйысымдылық шегін және ескі нұсқалардың өміршеңдігін ескеріңіз (deprecation policy, server-side fallback).

13) Өнімділік және құн

Rolling арзан, бірақ мұқият үйлесімділікті талап етеді.
Blue-Green шығарылым кезінде қымбат, бірақ жылдам қайту.
Canary тәуекелдер мен құнды теңестіреді, бірақ күшті байқауды талап етеді.
Ephemeral-prevyu және стендтерді автоматты түрде тазалау арқылы үнемдеңіз.

14) Минималды референс-пайплайн ZDT

1. Build: бірыңғай артефакт, қолтаңба, SBOM.
2. Test: unit/integration/contract + security.
3. Staging: smoke, жүктеме, expand режимінде көші-қон, кері қайтаруды тексеру.
4. Prod: shadow → canary (гейт) немесе blue-green flip.
5. Post-deploy: бақылау, contract-cleanup, ретро.

15) Қысқаша түйіндеме

Zero-Downtime - бұл пән: үйлесімді нұсқалар + дұрыс бағыттау + басқарылатын көші-қон + бақылау және тез кері қайту. Контекст үшін үлгіні таңдаңыз (rolling, blue-green, canary), SLO бойынша гейттерді автоматтандырыңыз, деректерді демпотентті ұстаңыз - және релиздер сенімді дағдылы процеске айналатын оқиға болмайды.