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

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

1) Эмне үчүн тез артка кайтаруу керек

• MTTR мүнөт кыскартуу.
• Кыйроонун радиусун чектөө (колдонуучулар/транзакциялар таасир эткен минималдуу).
• Маалыматтардын бүтүндүгүн жана келишимдердин шайкештигин сактоо.

Ачкыч: релиздерди артка кайтаруу мини-долбоор эмес, майда-чүйдө иш-аракет болуп тургандай кылып куруу.

2) "Атомдук релиз" түшүнүгү

Атомдук релизи - жаңы версия/жүрүм-турум кошуу узак мөөнөттүү терс таасирлери жок бир атомдук операция менен аткарылышы (жана жокко чыгаруу) мүмкүн болгондо.

• Иммундук артефакт (кол коюлган сүрөт/пакет).
• Версияланган конфигалар (промоушен версиялары, кол менен оңдоолор эмес).
• "Жүктү" "күйгүзүүдөн" бөлүү (багыттоо/желектер).
• Шайкеш берилиштер схемасы (эки версия бир эле учурда жашай алат).
• Runbook артка: бир түшүнүктүү кадам (селектор/салмагы/желеги өзгөртүү) + текшерүү.

3) Rollback-механизмдерин жабдуулар

3. 1 Traffic деңгээл (тез)

Blue-Green: туруктуу версия селектор/максаттуу топту которуу.
Canary: 0% га чейин салмагын төмөндөтүү жана прогрессти тоңдуруу.
Gateway/NGINX/Service Mesh: мурунку салмагы/жолдорун кайтарып.

3. 2 Конвейер-деңгээл

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

3. 3 тиркеме/чүчүкулак

Feature-flags/kill-switch: ошол замат кооптуу жол өчүрүү.
Toggle конфигурациялары: мурунку -снапшотко кайтуу.

3. 4 Маалыматтар

Roll-forward көчүрүү (артыкчылык) + шайкештик.
Point-in-time recovery (PITR) жана кырсыктар үчүн backaps.
ордун толтуруу (Saga) жана кайра иш-аракеттер үчүн idempotency.

4) Pattern "expand → migrate → contract" (БД)

Артка кайтаруу коопсуз болушу үчүн, маалыматтар схемасы эски жана жаңы версияларга жашоого мүмкүндүк бериши керек.

1. Expand - жаңы талааларды/индекстерди (nullable) эски логиканы бузбастан кошуу.
2. Migrate - кош жазуу/окуу, бэк-fill, idempotency менен фон job's.
3. Contract - 100% жана туруктуу терезеден чыккандан кийин эски талааларды/кодду алып салуу.

5) SLO-Gating жана Auto-Roll

Релиздин ар бир баскычына кирүү метриктер менен "корголушу" керек.

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

• 5xx > 0. 5% 10 мүнөт → rollback.
• p95 ↑> 20% негизги → hold + талдоо.
• PSP катасы> 0. 3 p.p. → rollback + которуу маршруту төлөмдөр.

6) мисалдар: Kubernetes/Helm/Арго/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: желек Server жеткиликсиз болсо - коопсуз дефолт.

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: иш-чаранын ар кандай кайталоо коопсуз, керектөөчү - idempotent.

9) Компенсациялык транзакциялар (Сага)

• Биз эсептен чыгарууну жүргүздүк - компенсация: кайтаруу, сторнинг, оңдоочу жазуу.
• Компенсациялык операциялардын жана ийгиликке чейинки ретрациялардын журналына жазуу.
• Ар бир операция үчүн Idempotent ачкычтар.

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

10) Конфиги жана сырлар: версия катары артка кайтаруу

Config (semver/commit-sha) нускалары менен экспонаттар катары сактаңыз.
Артка кайтаруу = мурунку нускасына (GitOps кайра), ордуна "колу менен чечүү".
Secrets - сактоо аркылуу (KMS/Vault); ротация жана версиялоо бошотууга киргизилген.

11) Runbook кайра (минималдуу)

1. Прогресстин тыныгуусу (canary/rollouts).
2. Трафикти кайтаруу (салмак/селектор).
3. SLO/бизнес-метр текшерүү негизги сызыкка кайтып келди.
4. Өбөлгөлөрдү турукташтыруу (зарыл болсо миграцияны/бэк-филди токтотуу).
5. Окуя жана пост-фактум: артефакттар (логи/трейс/метрика), гипотезалар, оңдоо.
6. Тазалоо: желектерди жабуу, калган кодду алып салуу, графиктерди кайтаруу.

12) Автоматтык коргоо саясаты

Тыюу 'latest' жана сүрөттөр үчүн туура тегдер.
Admission-Control: кол коюлган экспонаттар гана.
CI-дарбаза: SAST/SCA/Policy-текшерүү жылдыруу үчүн жашыл болушу керек.
Freeze терезелер: релиздер/салмагы тыюу> X% тобокелдик мезгилинде.

13) Тез-тез каршы үлгүлөрү

"Rolling" DDL-ылдый ордуна шайкештиги базасы - узак кулпу/жөнөкөй.
Көз ирмемдик миграция "чекеге" idempotency жана бэк-филл жок.
"Жеткирүү" жана "киргизүү" аралаштыруу - трафикти тез кайтарууга мүмкүнчүлүк жок.
Аудит жок прод-конфигада кол менен оңдоо.
Төлөмдөрдө/корутундуларда kill-switch жок.
Прод үчүн артефактты кайра чогултуу ("build once - run many" бузуу).
Эч кандай бирдиктүү кайра баскычы/иштетилбеген runbook.

14) киргизүү чек-тизмеси (0-45 күн)

0-10 күн

Негизги кызматтарда Blue-Green/Canary кирет.
Тыюу салуу 'latest', сүрөттөрдүн кол тамгасын жана Helm/Argo тарыхын киргизүү.
SLO такталарын туташтыруу (latency, 5xx, негизги бизнес сигналдары).

11-25 күн

тобокелдик Flow үчүн kill-switch ишке ашыруу.
БДнын миграциясын expand-migrate-contract + idempotency которуу.
SLO (Argo AnalysisTemplate/alerty) боюнча auto-stop/rollback кошуу.

26-45 күн

Version config (GitOps), MR-revert аркылуу артка.
Runbook "game-day" боюнча чуркап (окуя жана артка жылдыруу).
Артка "төмөн" мүмкүн эмес жерде Saga-ордун толтуруу киргизүү.

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

MTTR кайра: максаты <5 мин.
% Releases, бул жерде артка кайтуу = маршрут/желекти которуу (кайра чогултуу жок)> 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 жана коргоо дарбазасын автоматташтыруу үчүн машыгуу - жана ар бир бошотуу бизнес жана колдонуучулар үчүн эч кандай оору, мүнөт ичинде кайра болот.