Rollback стратегиялары және атомарлық релиздер

Rollback стратегиялары мен атомарлық релиздер

1) Тез кері қайту не үшін қажет

• MTTR-ді минутқа дейін қысқарту.
• Зақымдану радиусын шектеу (ең аз әсер еткен пайдаланушылар/транзакциялар).
• Деректердің тұтастығын және келісімшарттардың үйлесімділігін сақтау.

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

2) «Атомарлық релиз» ұғымы

Атомарлық релиз - жаңа нұсқаны/мінез-құлықты қосуды бір атомарлық операциямен ұзақ жанама әсерсіз орындауға (және алып тастауға) болады.

• Иммутабельді артефакт (қол қойылған сурет/пакет).
• Нұсқаланған конфигалар (қолмен түзетулер емес, промоушен нұсқалары).
• «Жеткізу» бөлімшесі «қосудан» (маршруттау/жалаулар).
• Сыйысымды деректер схемасы (екі нұсқа бір уақытта өмір сүре алады).
• Runbook кері қайтару: бір түсінікті қадам (селекторды/салмақты/жалауды ауыстыру) + тексеру.

3) Роллбек-механизмдер мүкәммалы

3. 1 Трафик деңгейі (ең жылдам)

Blue-Green: селектор/target тобын тұрақты нұсқаға ауыстыру.
Canary: салмақты 0% -ға дейін төмендетіп, прогресті мұздату.
Gateway/NGINX/Service Mesh: бұрынғы салмақ/бағыттарды қайтарыңыз.

3. 2 Конвейер деңгейі

Helm/Argo Rollouts: 'abort/rollback' алдыңғы тексеруге.
GitOps: revert MR/commit манифест-репозиторийде (контроллер қалғанын жасайды).

3. 3 Қосымша/фич

Feature-flags/kill-switch: қауіпті жолды дереу өшіру.
Профайлдар тоггласы: алдыңғы -снапшотқа оралу.

3. 4 Деректер

Roll-forward көші-қон (артықшылықты) + сыйысымдылық.
Point-in-time recovery (PITR) және аварияларға арналған бэкаптар.
Қайтарылатын әрекеттер үшін өтемақы (Saga) және idempotency.

4) «expand → migrate → contract» (ДБ)

Кері қайту қауіпсіз болуы үшін деректер схемасы ескі және жаңа нұсқаларға бірге өмір сүруге мүмкіндік беруі тиіс.

1. Expand - ескі логиканы бұзбай жаңа өрістер/индекстер (nullable) қосу.
2. Migrate - қос жазба/оқу, бэк-филл, idempotency бар фондық job's.
3. Contract - ескі өрістерді/кодты 100% шыққаннан кейін және терезені ұстағаннан кейін жою.

5) SLO-гейтинг және авто-кері қайту

Шығарылымның әрбір сатысына кіру өлшеуіштермен «қорғалуы» тиіс.

Техникалық SLO: p95/p99 латенттілік, 5xx-rate, saturation (CPU/Memory), error-budget burn.
Бизнес-метриктер: депозитке/кассаут CR, төлемдерден бас тарту, фрод пайызы, KYC қателері.

• 5xx > 0. 5% 10 минут → rollback.
• p95 ↑> 20% базалық → hold + талдау.
• PSP> 0 қатесі. 3 т. → rollback + төлем бағытын ауыстырып қосу.

6) Мысалдар: Kubernetes/Helm/Argo/NGINX

6. 1 Blue-Green (K8s Service selector)

yaml
Service points to "blue"; switch to green - change selector apiVersion: v1 kind: Service metadata: {name: app-svc}
spec:
selector: { app: app, version: blue }
ports: [{ port: 80, targetPort: 8080 }]

Кері қайту = селекторды 'blue' -ке қайтару (атомарлы, қайта жинаусыз).

6. 2 Canary (Istio VirtualService веса)

yaml http:
- route:
- destination: { host: app, subset: stable } # 100 weight: 100
- destination: { host: app, subset: canary } # 0 weight: 0

Шегініс = weight canary → 0, stable → 100.

6. 3 Argo Rollouts — abort

yaml kubectl argo rollouts abort app # stop and return to stableService

6. 4 Helm - тексеруге rollback

bash helm history app -n prod helm rollback app 17 -n prod # revert to revision 17

6. 5 NGINX - upstream салмағы

nginx upstream app {
server blue:8080 weight=100;
server green: 8080 weight = 0; # rollback - return 100/0
}

7) Feature-flags және kill-switch «парашют» ретінде

Жоғары тәуекелді ағындар үшін Kill-switch (депозиттер/төлемдер/бонустар) - міндетті.
Stickiness: пайдаланушыларға хеш-кілт арқылы «нұсқаны» тағайындау - болжамды салыстырулар.
Fail-safe: жалаулар сервері қол жетімсіз болса - қауіпсіз дефолт.

ts const enabled = flags. bool("new_cashout_flow", false);
if (! enabled) return classicFlow () ;//instant rollback - disable the return newFlow () flag;

8) API және оқиғалар келісімшарттары: «кері қайтаруды сындырмау»

Келісімшарттарды нұсқалау (OpenAPI/gRPC/Euro): жаңа нұсқа өрістерді қосады, ескілердің семантикасын өзгертпейді.
Event-versioning: 'type = v2', тұтынушылар белгісіз өрістерді елемеуге міндетті.
Outbox + Idempotency: оқиғаның кез келген қайталануы қауіпсіз, тұтынушы - іспеттес.

9) Өтемдік транзакциялар (Saga)

• Есептен шығаруды жүргіздік - өтемақы: қайтару, түзетуші жазба.
• Өтемдік операциялар журналына және табысқа дейінгі ретраға жазу.
• Әрбір операцияға арналған идемпотенттік кілттер.

json
{
"sagaId": "b7d2...",
"action": "withdraw. execute",
"idempotencyKey": "user123:withdraw:7845",
"compensation": "withdraw. refund"
}

10) Конфиги және құпиялар: нұсқа ретінде кері қайтару

Конфигаларды (semver/commit-sha) нұсқалары бар артефакттар ретінде сақтаңыз.
Кері қайту = «қолмен түзету» емес, алдыңғы нұсқаға (GitOps revert) қайтару.
Құпиялар - сақтау орны арқылы (KMS/Vault); ротациялау және нұсқалау шығарылымға енгізілді.

11) Runbook кері қайтару (ең аз)

1. Прогресс үзілісі (canary/rollouts).
2. Трафикті қайтару (салмақ/селектор).
3. SLO/бизнес-метрикті тексеру негізгі сызыққа оралды.
4. Фондық job 'oларды тұрақтандыру (қажет болған жағдайда көші-қонды/бэк-филді тоқтату).
5. Инцидент және пост-фактум: артефактілер (логтар/трейстер/метриктер), гипотезалар, түзету.
6. Тазалау: жалаушаларды жабу, қалдырылған кодты алып тастау, кестелерді қайтару.

12) Автоматты қорғау саясаты

Кескіндер үшін 'latest' және мутабельді тегтерге тыйым салу.
Admission-бақылау: қол қойылған артефактілер ғана.
CI-қақпасы: SAST/SCA/Policy-checks насихаттау үшін жасыл болуы тиіс.
Freeze терезелері: тәуекел кезеңдерінде релиздерге/салмаққа тыйым салу> X%.

13) Жиі қарсы үлгілер

Үйлесімділіктің орнына DDL-төмен базаны «домалату» - ұзақ блоктау/қарапайым.
idempotency және бэк-филлсіз «маңдайына» жылдам көшу.
«Жеткізу» және «қосу» араластыру - трафикті тез қайтару мүмкін емес.
Аудитсіз прод-конфигадағы қолмен түзетулер.
Төлемдерде/қорытындыларда kill-switch болмауы.
Артефактіні prod үшін қайта жинау («build once - run many» бұзылуы).
Бірыңғай қайтару түймешігі/өңделмеген runbook жоқ.

14) Енгізу чек-парағы (0-45 күн)

0-10 күн

Blue-Green/Canary негізгі сервистерде қосу.
'latest' дегенге тыйым салу, сурет қолтаңбасы мен Helm/Argo тарихын қосу.
SLO-тақталарды қосу (latency, 5xx, негізгі бизнес-сигналдар).

11-25 күн

Қатер-флоу үшін kill-switch бағдарламасын іске асыру.
БД көші-қонын expand-migrate-contract + idempotency-ке ауыстыру.
SLO (Argo AnalysisTemplate/алерта) бойынша авто-тоқта/rollback қосу.

26-45 күн

Конфигаларды (GitOps) MR-revert арқылы кері қайтару.
Runbook бағдарламасында «game-day» (оқиғаны және кері қайтаруды симуляциялау).
Saga-өтемақыны «төмен» кері қайтару мүмкін емес жерлерде енгізу.

15) Жетілу метрикасы

MTTR шегініс: мақсаты <5 мин.
% релиздері, мұнда кері қайту = маршрутты/жалауды ауыстырып қосу (қайта жинаусыз)> 90%.
expand-migrate-contract схемасы бойынша көші-қон үлесі> 90%.
kill-switch қызметтерін жалаулармен жабу> 95%.
Сәйкес келмейтін схемалар/келісімшарттар салдарынан болған оқыс оқиғалардың саны → 0.

16) Қосымшалар: шағын үлгілер

Argo AnalysisTemplate: 5xx бойынша тоқта

yaml apiVersion: argoproj. io/v1alpha1 kind: AnalysisTemplate metadata: { name: guard-5xx }
spec:
metrics:
- name: http_5xx_rate interval: 1m successCondition: result < 0. 005 provider:
prometheus:
address: http://prometheus. monitoring:9090 query:
sum(rate(http_requests_total{app="app",status=~"5.."}[5m])) /
sum(rate(http_requests_total{app="app"}[5m]))

Kubernetes: Deployment жылдам қайту

bash kubectl rollout undo deploy/app -n prod

Helm: атомдық шығарылым

bash helm upgrade --install app chart/ \
--atomic \
--timeout 5m \
--set image. tag=v1. 9. 3

NGINX: канареялар үшін «кран»

nginx map $cookie_canary $weight {
default 0;
"~ on" 10; # enable 10% by cookie
}

17) Қорытынды

Сенімді кері қайту - бұл «өрт түймесі» емес, архитектураның қасиеті: иммутабельді артефактілер, жеткізу мен қосуды бөлу, деректердің үйлесімді схемасы, фича-жалаулар және SLO-гейтинг. Релиздерді атомарлы етіп жасаңыз, runbook-ты жаттықтырыңыз және қорғаныс қақпасын автоматтандырыңыз - және кез келген релиз бизнес пен пайдаланушылар үшін ауыртпалықсыз минуттар ішінде кері қайтарылады.