Blue-Green және Canary релиздері

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

1) «Қауіпсіз шығу» не үшін қажет?

Қазіргі заманғы жүйелерде релиз - бұл тек кодты жеткізу ғана емес, сонымен қатар өнімдегі басқарылатын эксперимент: біз бір мезгілде тәуекелді барынша азайтамыз (пайдаланушыларды бұзбаймыз) және кері байланыс уақытын қысқартамыз (әсерді тез көреміз). Екі классикалық стратегия - Blue-Green және Canary - мұны әртүрлі шешеді, бірақ ортақ мақсатта: нөлдік даунтайм, жылдам кері қайту, SLO бойынша бақылау.

2) Базалық анықтамалар

Blue-Green

Прод-ортаның екі толыққанды көшірмесін сақтаймыз: белсенді (Blue) трафикке қызмет көрсетеді, пассивті (Green) жаңа нұсқасын дайындайды. Қайта қосу - теңгеруші/маршрутизатор деңгейіндегі атомарлық (switch/flip). Егер нашарласа, дереу Blue-ға ораламыз.

Canary

Біз бөліп шығарамыз: алдымен трафиктің аз% (мысалы, 1-5%), метриканы/SLO бақылаймыз, содан кейін үлесті біртіндеп ұлғайтамыз (10% → 25% → 50% → 100%). Деградация кезінде - алдыңғы тұрақты қадамда кері шегіну немесе тоқтау.

3) Қандай тәсіл жақсы

• Күрделі маневрлерсіз бірден қайту керек.
• Сәулет/бюджет қос инфрақұрылымдық қайталауға мүмкіндік береді.
• Ауқымды көші-қон немесе платформаны (OS/JDK/рантайм) жеке жаңартуды жүргізгіміз келеді.
• Қосылыстардың қосымшалары/пулдары біртіндеп «аралас» күйге сезімтал.

• blast radius бағдарламасын барынша азайтып, пайдаланушылардың үлесінде мінез-құлықты көру керек.
• Релиздердің жоғары жиілігі, норма ретінде прогрессивті жеткізу.
• Жетілген бақылау және автоматты гейттер (error budget, latency, conversion) бар.
• Азық-түлік командасы гипотезаларды тексергісі келеді: конверсияға, ұстап қалуға, LTV және т.б.

4) Табысты шығарудың жалпы қағидаттары

Идемпотенттік билд-артефактілер: барлық кезеңдерде бір бейне/пакет.
Детерминирленген конфигурация:, код ретінде, ортаның салыстырмалылығы.
Бақылануы by design: логи, метрика, трассировка, алерта; SLI/SLO алдын ала.
Жылдам, автоматтандырылған кері қайтару: түймешік/кері қайтару пәрмені - қол сиқыры емес, пайплайн бөлігі.
Схемалардың үйлесімді өзгерістері: expand-migrate-contract стратегиясы (қараңыз § 10).
L7 деңгейіндегі маршруттау (мүмкіндігінше): API тақырыптары/куки/жолдары/нұсқалары бойынша икемділік.

5) Blue-Green: сәулет және процесс

5. 1 Топология

Екі прод-стек: Blue (белсенді) және Green (кандидат).
Жалпы сыртқы тәуелділіктер: CDN, сыртқы API, кезектер; ДБ - ерекше жағдай (қараңыз § 10).
Ауыстырып қосу нүктесі: теңгеруші/Ingress/Gateway.

5. 2 Қадамдық флоу

1. Green-ді жаңа артефактпен (vNext) көтереміз, смок-тесттер өткіземіз.
2. Green қарсы автотестерді айдап өту (e2e, келісімшарттық, регрессиялық).
3. Кэш/сессияларды жылытамыз (егер қолданылса), фондық джобтарды/кезектерді үндестіреміз.
4. Трафикті Green-ге ауыстырып қосамыз: атомарлық flip (DNS TTL төмен, Route/Listener swap, Ingress weight = 100%).
5. SLO-ны алғашқы минут/сағатта бақылаймыз (golden signals: latency, errors, saturation + бизнес-метрика).
6. Проблемалар кезінде - Blue (flip back) қызметіне дереу оралу.

5. 3 Артықшылықтары/кемшіліктері

Артықшылықтары: жылдам қайту, қарапайым ментальды модель, таза оқшаулау.
Кемшіліктері: инфрақұрылымның екі еселенуі, stateful компоненттерімен және деректер миграциясымен күрделілігі.

6) Canary: сәулет және процесс

6. 1 Топология

Бірыңғай прод-кластер; сервистің бірнеше нұсқасы (stable және canary).
Трафик таразылар бойынша (1-5-10-25-50-100%) немесе таргеттер бойынша (тақырып бойынша/куке/ID) бөлінеді.

6. 2 Қадамдық флоу

1. Сол кластерге/ASG/NSG canary-нұсқасын жіберу.
2. Трафиктің бір бөлігін (мысалы, 1-5%) canary-ге бағыттау.
3. SLI/SLO және бизнес-метриктерді автоматты тексеру; CI/CD гейтс (error rate, p95 latency, CPU/RES, конверсия, бас тарту/қайтару).
4. Гейттерден өту кезінде трафик үлесін қадамдық ұлғайту.
5. 100% -ға дейін толық rollout және ескі нұсқасын өшіру; деградация кезінде - авто-rollback.

6. 3 Артықшылықтары/кемшіліктері

Артықшылықтары: көптеген пайдаланушылар үшін ең аз тәуекел, data-driven шешім.
Кемшіліктері: жетілген бақылау, сауатты бағыттау, инстанциялар арасында «version skew» тәуекелі қажет.

7) Трафикті бағыттау

L4 деңгейі: IP/порттар бойынша теңгерім; қарапайым, бірақ икемділігі аз.
L7 деңгейі: HTTP/S-ережелері - жол бойынша, хост, тақырып, cookie, User-Agent, GeoIP, SNI.

• Weighted routing (салмағы 1-100%).
• Header-based/Cookie-based (топқа пайдаланушыны тіркеу).
• Session stickiness (stateful/кешенделген сценарийлер үшін маңызды).
• Shadow/Traffic mirroring (сұрауларды «жасырын» жаңа нұсқасына айналаймыз).

8) Құралдар және іске асыру (мысалдар)

Kubernetes: Ingress (NGINX, Contour), Service Mesh (Istio/Linkerd), Argo Rollouts, Flagger.
Облака: AWS ALB/ELB, Route 53 weighted records, ECS/EKS; GCP Load Balancing + NEG; Azure Front Door/App Gateway.
CD платформалары: Spinnaker, Argo CD, GitHub Actions + Progressive Delivery плагиндер, GitLab/CD.

9) Бақылау, SLI/SLO және гейталар

Golden signals: Latency (p95/p99), Error rate (5xx/4xx по типам), RPS, Saturation (CPU/Memory/GC), Queue lag.
Бизнес-метриктер: конверсия, авторизация, төлемдер/табыстар, орташа чек, құйғыштың қадамдары бойынша бас тарту.

• Қате шегі (мысалы, error rate canary ≤ baseline + X%).
• p95 жасырындылығы Δ артық baseline кем емес.
• Бизнес шегі (мысалы, конверсияның төмендеуі
• SLO бойынша Error budget тез жанбауы тиіс.

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

10) ДБ көші-қоны және схемалардың үйлесімділігі

Басты ереже: егер нұсқалар артқа және алға үйлесімді болса, релиздер қауіпсіз.

1. Expand: жаңа бағандарды/индекстерді/кестелерді ескі нұсқасын бұзбай қосыңыз.

2. Deploy app vNext (жаңа схеманы оқиды/жазады, бірақ ескісімен де жұмыс істей алады).

3. Migrate data (бэкграунд/батч, іспеттес, чек пункттері бар).

4. Contract: тұрақтандырудан кейін ескі өрістерді/өрістерді жойамыз.

Анти-үлгілер: Blue-Green ауыстырып қосу сәтінде эксклюзивті бұғаттауды талап ететін көші-қон; схеманы түсірудің мүмкін еместігі; «қос жазба» дедупликациясыз.

11) Кері шегіну (rollback) және авариялардың жоспарлары

Blue-Green: Blue жылдам флип; Green фондық джобтарының «қалдықтарын» мониторингілейміз.
Canary: салмақ шегінісі (мысалы, 25% артқа 5% немесе 0%); алерттер кезінде автоматты abort.
Деректер: қайталаудың/өтемақының ойластырылған саясаты (idempotency keys, «inbox/outbox» паттерн, хабарламаларды дедупликациялау).
Фичефлагтар: ішінара шығарылған мүмкіндіктерді ажырату үшін жылдам kill switch.

12) Стейтпен және сессиялармен жұмыс

Канареялар үшін Sticky sessions немесе нұсқалар бірін-бірі алмастыру үшін сырттай сессияларды сақтау (Redis/Memcached).
Кэшті алдын ала жылыту (Green warm-up) және flip кезінде invalidation есепке алу.
Фон воркерлері: нұсқалар арасында «жарыс» - кезектерді бөлуге немесе нұсқа бойынша «көшбасшылыққа» жол бермеңіз.

13) Қауіпсіздік және сәйкестік

Green/Canary - Zero Trust бойынша қол жеткізу: сервистік шоттар, ең аз қажетті рөлдер.
Құпиялар мен кілттер - KMS/Secrets Manager арқылы; ротацияны қосыңыз.
Трафик - тек TLS; endpoint 'дердің нұсқалары анық белгіленген; бағыттау және релиздік іс-қимылдар аудиті.

14) Құны және өнімділігі

Blue-Green инфрақұрылымды екі есе арттырады (шығу уақытында немесе үнемі) - бюджетті белгілеңіз.
Canary үнемді, бірақ автоматтандыру үшін бақылау құралдары мен инженерлік уақытты талап етеді.
Оңтайландыру: автоскейлинг, ephemeral орта, параллель нұсқалардың терезесін қысқарту.

15) Чек парақтары

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

• Бейне/билд бір көзден алынған, қолтаңбалар тексерілді.
• Тест-жоспар, алерттар және SLO-гейттер теңшелген.
• DD көші-қоны - expand режимінде, жеткізу жоспарлары қол жетімді.
• Кері қайтару жоспары - staging/production-like бағдарламасында тексерілді.

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

• Метриктер мен логтар baseline-мен салыстырылады.
• Canary үшін - қадамдар мен табалдырықтар тіркелген; Blue-Green үшін - flip-back дайындығы.
• On-call командалары біледі, кері байланыс терезесі бар.

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

• SLO батпады, error budget қалыпты.
• Релизден кейінгі көшіру/тазарту аяқталды.
• Ретроспектива және ойнатқыштарды жаңарту.

16) Жиі қателер және қарсы үлгілер

Метрикасыз шығару: деректер жоқ - басқарылатын шешім жоқ.
БД-ның үйлеспейтін схемаларын араластыру, даунгрейд стратегиясының болмауы.
Трафикті кездейсоқ араластыру: stickiness жоқ, пайдаланушылар нұсқалар арасында «секіреді».
Жасырын stateful-тәуелділік (жергілікті дискілер, in-memory кэштер).
Ұзақ DNS-TTL тез flip (Blue-Green) кедергі келтіреді.
Автогейттердің жоқтығы: қолмен «көзге» шешімдер тежейді және тәуекелдерді арттырады.

17) Құрамдастырылған тәсілдер

Blue-Green + Canary: алдымен Green-ді домалату, содан кейін жеке қызметтер үшін Green-дің ішінде Canary-ді домалату.
Shadow/көші-қон трафигі: Canary алдында айналық трафикті жаңа нұсқаға айдаңыз.
Feature flags (progressive delivery): функционал сегменттер бойынша «қара» жалаушалармен тұрақты нұсқаның үстінен қосылады.

18) Сценарий үлгілері (эскиздер)

1. Green (v2) жаңа Listener/Ingress.

2. Кэштерді жылытамыз, readonly-тексерулерді, smoke орындаймыз.

3. Салмақты Green = 100% -ға ауыстыру.

4. SLO 30-60 минут бақылаймыз; егер бәрі жақсы болса, Blue бағдарламасын өшіреміз.

1. vNext деплой canary (5% репликасы).

2. Ішкі аккаунттар/тест-сегмент үшін 5% трафигін қосамыз.

3. Автогейт: error rate ≤ baseline + 0. 3%, p95 ≤ +20ms.

4. 10% → 25% → 50% көтереміз әрбір N минут сайын.

5. Фичефлагты барлық сегменттер бойынша 100% аударамыз; ескі нұсқасын жойамыз.

19) Әр түрлі сәулеттерге арналған вариациялар

Монолит: Blue-Green оңай, Canary бөлінбейтіндіктен қиынырақ; фичефлагтарды пайдаланыңыз.
Микросервистер: Canary табиғи; сервистік келісімшарттарды (consumer-driven contracts) қадағалаңыз.
Stateful Services: Blue-Green-ді мұқият пысықталған миграциялармен және stickiness-пен таңдаңыз.

20) Қысқаша салыстыру (түйіндеме)

Кері қайту жылдамдығы: Blue-Green = бірден; Canary = тез, бірақ салмақ шегінісімен.
Инфрақұрылымның құны: Blue-Green ↑; Canary ↔︎/↓.
Пайдаланушылар үшін тәуекел: Canary төмен (үлесті бақылаймыз).
Енгізу күрделілігі: Blue-Green бастау оңай; Canary күшті бақылау мен автоматтандыруды талап етеді.
Деректердің/схемалардың үйлесімділігі: екеуі үшін де сыни; expand-migrate-contract бағдарламасын жоспарлаңыз.

21) Қорытынды

Blue-Green және Canary - бір-бірін жоққа шығаратын стратегиялар емес, прогрессивті жеткізу элементтері. Таңдау құн бойынша шектеулерге, бақылаудың жетілуіне және өзгерістердің сипатына байланысты. Жақындауына қарамастан, тұрақты босату төрт тіректе ұсталады: автоматтандыру, бақылау, кері үйлесімділік және тез қайту.