Blue-Green va Canary relizlari

(Bo’lim: Arxitektura va Protokollar)

1) Nima uchun «xavfsiz otish» kerak?

Zamonaviy tizimlarda chiqarish nafaqat kod yetkazib berish, balki prodda boshqariladigan tajribadir: biz xavfni minimallashtiramiz (foydalanuvchilarni buzmaymiz) va fikr-mulohazalar vaqtini qisqartiramiz (samarani tezda ko’ramiz). Ikkita klassik strategiya - Blue-Green va Canary - buni turli yo’llar bilan hal qiladi, lekin umumiy maqsad bilan: nol pastlik, tezkor orqaga qaytish, SLO bo’yicha kuzatish.

2) Bazaviy ta’riflar

Blue-Green

Prod-muhitning ikkita to’liq nusxasini saqlaymiz: faol (Blue) trafikka xizmat ko’rsatadi, passiv (Green) esa yangi versiyani tayyorlaydi. Almashtirish - balanslovchi/marshrutizator darajasida atom (switch/flip). Agar yomonlashsa, darhol Blue-ga qaytamiz.

Canary

Qismlarga ajratamiz: avval trafikning kichik foizini (masalan, 1-5%), metrik/SLOni kuzatamiz, keyin ulushni bosqichma-bosqich oshiramiz (10% → 25% → 50% → 100%). Degradatsiyada - oldingi barqaror qadamda orqaga qaytish yoki to’xtash.

3) Qaysi yondashuv yaxshiroq

• Murakkab manevrlarsiz bir zumda orqaga qaytish kerak.
• Arxitektura/byudjet infratuzilmani ikki tomonlama takrorlash imkonini beradi.
• Biz keng ko’lamli migratsiya yoki platforma yangilanishlarini (OS/JDK/rantaym) alohida o’tkazmoqchimiz.
• Ilova/birikmalar pullari asta-sekin «aralash» holatga sezgir.

• Blast radiusni minimallashtirish va foydalanuvchilar ulushidagi xatti-harakatlarni ko’rish kerak.
• Relizlarning yuqori chastotasi, progressiv yetkazib berish norma sifatida.
• Etuk kuzatuv va avtomatik geytlar (error budget, latency, conversion) mavjud.
• Mahsulot guruhi gipotezalarni tekshirishni xohlaydi: konversiya, ushlab turish, LTV va hokazolarga ta’siri.

4) Muvaffaqiyatli chiqishning umumiy prinsiplari

Idempotent bild-artefaktlar: barcha bosqichlarda bir xil tasvir/paket.
Determinirlangan konfiguratsiya: kod sifatida, atrof-muhitning taqqoslanishi.
Kuzatilganlik by design: loglar, metriklar, trastirovkalar, alertlar; SLI/SLO oldindan.
Tezkor, avtomatlashtirilgan orqaga qaytish: tugma/orqaga qaytish buyrug’i - qo’l sehri emas, balki payplaynning bir qismidir.
Sxemalarning mos keladigan o’zgartirishlari: expand-migrate-contract strategiyasi (§ 10 ga qarang).
L7 darajasida marshrutlash (iloji boricha): sarlavhalar/kuklar/yoʻllar/API versiyalari boʻyicha moslashuvchanlik.

5) Blue-Green: arxitektura va jarayon

5. 1 Topologiya

Ikkita prod-stek: Blue (faol) va Green (nomzod).
Umumiy tashqi qaramliklar: CDN, tashqi API, navbatlar; DQ - alohida holat (§ 10 ga qarang).
Almashtirish nuqtasi: Balans/Ingress/Gateway.

5. 2 Bosqichma-bosqich flou

1. Green’ni yangi artefakt (vNext) ostida ko’taramiz, smok-testlar o’tkazamiz.
2. Avtotestlarni Green (e2e, kontrakt, regression) ga qarshi haydash.
3. Kesh/sessiyalarni isitib, orqa fon joblarini/navbatlarini sinxronlashtiramiz.
4. Trafikni Green ga o’tkazing: atom flip (DNS TTL past, Route/Listener swap, Ingress weight = 100%).
5. Biz SLOni dastlabki daqiqalarda/soatlarda kuzatmoqdamiz (golden signals: latency, errors, saturation + biznes metrika).
6. Muammoga duch kelganda - Blue (flip back) ga bir zumda qaytish.

5. 3 Ijobiy/salbiy tomonlari

Afzalliklari: bir zumda orqaga qaytish, oddiy aqliy model, toza izolyatsiya.
Kamchiliklar: infratuzilmani ikki baravar oshirish, stateful komponentlar va ma’lumotlar migratsiyasi bilan bog’liq murakkablik.

6) Canary: arxitektura va jarayon

6. 1 Topologiya

Yagona prod-klaster; yagona jabhada xizmatning bir nechta versiyalari (stable va canary).
Trafik tarozilar bo’yicha (1-5-10-25-50-100%) yoki targetlar bo’yicha (sarlavha/kuke/ID bo’yicha) bo’linadi.

6. 2 Bosqichma-bosqich flou

1. Xuddi shu klaster/ASG/NSGga canary-versiya deploy.
2. Trafikning bir qismini (masalan, 1-5%) canariga yoʻnaltirish.
3. SLI/SLO va biznes-metriklarni avtomatik tekshirish; geytlar CI/CD (error rate, p95 latency, CPU/RES, konvertatsiya, rad etish/qaytarish).
4. Geytlardan o’tishda trafik ulushini bosqichma-bosqich oshirish.
5. 100% gacha to’liq rollout va eski versiyani o’chirish; degradatsiyada - avto-rollback.

6. 3 Ijobiy/salbiy tomonlari

Afzalliklar: aksariyat foydalanuvchilar uchun minimal xavf, data-driven yechimi.
Kamchiliklar: etuk kuzatuv, malakali marshrutlash, instantsiyalar o’rtasida «version skew» xavfi.

7) Trafikni yo’naltirish

L4 darajasi: IP/portlar bo’yicha balans; oddiy, lekin moslashuvchanlik kam.
L7 darajasi: HTTP/S qoidalari - yo’l, xost, sarlavha, cookie, User-Agent, GeoIP, SNI.

• Weighted routing (ogʻirligi 1-100%).
• Header-based/Cookie-based (foydalanuvchini guruhga belgilash).
• Session stickiness (stateful/keshli skriptlar uchun muhim).
• Shadow/Traffic mirroring

8) Instrumentlar va sotuvlar (misollar)

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 platformalari: Spinnaker, Argo CD, GitHub Actions + Progressive Delivery plaginlari, GitLab/CD.

9) Kuzatish darajasi, SLI/SLO va geytlar

Golden signals: Latency (p95/p99), Error rate (5xx/4xx по типам), RPS, Saturation (CPU/Memory/GC), Queue lag.
Biznes-metrika: konvertatsiya, avtorizatsiya, to’lovlar/muvaffaqiyatlar, o’rtacha chek, huni qadamlari bo’yicha rad etish.

• Xato chegarasi (masalan, error rate canary ≤ baseline + X%).
• Latentlik p95 bazeline dan bir Δ kam emas.
• Biznes chegarasi (masalan, konversiyaning pasayishi
• Error budget SLO tezda yonmasligi kerak.

Qadam davomiyligi: statistik ahamiyat uchun yetarli bo’lgan minimal vaqt (trafikka bog’liq).

10) DB migratsiyasi va sxemalarning muvofiqligi

Asosiy qoida: agar versiyalar orqaga va orqaga mos kelsa, relizlar xavfsiz.

1. Expand: Eski versiyani buzmasdan yangi ustunlar/indekslar/jadvallarni qoʻshing.

2. Deploy app vNext (yangi sxemani o’qiydi/yozadi, lekin eskisi bilan ham ishlay oladi).

3. Migrate data (backgraund/batch, idempotent, chekpindlar bilan).

4. Contract: Barqarorlashgandan soʻng eski maydonlarni olib tashlaymiz.

Anti-pattern: Blue-Green o’zgarishi paytida eksklyuziv blokirovka qilishni talab qiladigan migratsiyalar; sxemani tushirishning mumkin emasligi; «ikki baravar yozuv» da duplikatsiyasiz.

11) Qaytish (rollback) va avariyalar rejalari

Blue-Green: Blue’dagi tezkor flip; Green fon joblarining «quyruqlarini» monitoring qilamiz.
Canary: ogʻirlik orqaga qaytishi (masalan, 25% dan 5% yoki 0% ga orqaga); alertlarda avtomatik abort.
Ma’lumotlar: takrorlash/kompensatsiya qilishning puxta o’ylangan siyosati (idempotency keys, «inbox/outbox» pattern, xabarlarni deduplikatsiya qilish).
Ficheflaglar: qisman chiqarilgan imkoniyatlarni oʻchirish uchun tezkor kill switch.

12) Steyt va sessiyalar bilan ishlash

Sticky sessions kanareykalar uchun yoki versiyalar almashtirilishi uchun sessiyalarni tashqi saqlash (Redis/Memcached).
Kesh oldindan isitiladi (Green warm-up) va flip paytida invalidation hisobga olinadi.
Orqa fon vorkerlari: versiyalar o’rtasida «poygalar» ga yo’l qo’ymang - navbatlar bo’linishi yoki versiya bo’yicha «etakchilik».

13) Xavfsizlik va muvofiqlik

Green/Canary-ga kirish - Zero Trust orqali: servis hisoblari, minimal zarur rollar.
Sirlar va kalitlar - KMS/Secrets Manager orqali; rotatsiyani yoqing.
Trafik - faqat TLS; endpoint’larning versiyalari aniq belgilangan; yo’naltirish va reliz harakatlari auditi.

14) Qiymati va unumdorligi

Blue-Green infratuzilmani ikki baravar oshiradi (chiqish vaqtida yoki doimiy ravishda) - byudjetni belgilang.
Canary tejamkor, ammo avtomatlashtirish uchun kuzatish va muhandislik vaqtini talab qiladi.
Optimallashtirish: avtoskeyling, ephemeral muhit, versiyalarning parallel mavjudligi oynasini qisqartirish.

15) Chek-varaqlar

Chiqarishdan oldin

• Rasm/bild bitta manbadan olingan, imzolar tekshirilgan.
• Test-reja, alertlar va SLO-geytlar sozlangan.
• DB migratsiyasi - expand rejimida, to’xtash rejalari mavjud.
• Qaytarish rejasi - staging/production-like da tekshirildi.

Reliz paytida

• Metrika va loglar baseline bilan solishtiriladi.
• Canary uchun - qadamlar va chegaralar qayd etilgan; Blue-Green uchun - flip-back tayyorligi.
• On-call buyruqlari fikr-mulohaza oynasini biladi.

Chiqarilgandan keyin

• SLO botmagan, error budget normal.
• Relizdan keyingi migratsiya/tozalash tugadi.
• Pleybuklarning retrospektivasi va yangilanishi.

16) Tez-tez xatolar va anti-patternlar

Metriksiz qaytarish: maʼlumot yoʻq - boshqariladigan yechim yoʻq.
Mos kelmaydigan DM sxemalarini aralashtirish, pastga tushirish strategiyasining yo’qligi.
Tasodifiy trafikni aralashtirish: stickiness yoʻq, foydalanuvchilar versiyalar orasida «sakrashadi».
Yashirin stateful-qaramliklar (lokal disklar, in-memory keshlar).
Uzoq DNS-TTL tezkor flip (Blue-Green) ga xalaqit beradi.
Avtogeytlar yo’qligi: qo’lda «ko’z bilan» yechimlar sekinlashadi va xavflarni oshiradi.

17) Kombinatsiyalangan yondashuvlar

Blue-Green + Canary: avval Green, keyin Green ichida alohida xizmatlar uchun Canary.
Shadow/migratsiya trafigi: Canary oldidan oynali trafikni yangi versiyaga haydaymiz.
Feature flags (progressive delivery): funktsional segmentlar bo’yicha «qorong’u» bayroqlar bilan barqaror versiya ustiga qo’shiladi.

18) Ssenariy namunalari (eskizlar)

1. Yangi Listener/Ingress uchun Green (v2) ni joylashtiring.

2. Keshlarni isitish, readonly-tekshirish, smoke.

3. Ogʻirlikni Green = 100% ga oʻtkazing.

4. SLOni 30-60 daqiqa davomida kuzatamiz; Agar hammasi yaxshi bo’lsa, Blue’ni o’chirib qo’yamiz.

1. Deploy canary vNext (nusxalari 5%).

2. Ichki hisoblar/sinov segmenti uchun 5% trafikni yoqing.

3. Avtogeyt: error rate ≤ baseline + 0. 3%, p95 ≤ +20ms.

4. 10% → 25% → 50% ni har N daqiqada ko’taring.

5. Ficheflagni barcha segmentlar bo’yicha 100% o’tkazamiz; eski versiyasini olib tashlaymiz.

19) Turli arxitektura uchun variatsiyalar

Monolit: Blue-Green osonroq, Canary chich bo’linmasligi sababli qiyinroq; ficheflaglardan foydalaning.
Mikroservislar: Canary tabiiy; xizmatlararo shartnomalarni (consumer-driven contracts) kuzatib boring.
Stateful Services: Diqqat bilan ishlab chiqilgan migratsiyalar va stickiness bilan Blue-Green’ni afzal koʻring.

20) Qisqacha taqqoslash (xulosa)

Orqaga qaytish tezligi: Blue-Green = bir zumda; Canary = tez, lekin ogʻirligi orqaga qaytgan holda.
Infratuzilma qiymati: Blue-Green ↑; Canary ↔︎/↓.
Foydalanuvchilar uchun xavf: Canary past (biz ulushni nazorat qilamiz).
Joriy etishning murakkabligi: Blue-Green-ni boshlash osonroq; Canary kuchli kuzatuv va avtomatlashtirishni talab qiladi.
Maʼlumotlar/sxemalarning mosligi: ikkalasi uchun ham muhim; expand-migrate-contract dasturini rejalashtiring.

21) Jami

Blue-Green va Canary - o’zaro istisno strategiyalar emas, balki progressiv etkazib berish elementlari. Tanlov qiymati, kuzatish qobiliyati va o’zgarishlar xususiyati bo’yicha cheklovlarga bog’liq. Yondashuvidan qat’i nazar, barqaror reliz to’rtta tayanchda saqlanadi: avtomatlashtirish, kuzatish, teskari moslik va tezkor orqaga qaytish.