Relizlar strategiyasi: blue-green va canary

(Bo’lim: Texnologiyalar va infratuzilma)

Qisqacha xulosa

Blue-green ikkita to’liq oyna (Blue/Green) o’rtasida bir zumda o’tish imkonini beradi. Canary asta-sekin SLO-geytlar (yashirin, error-rate, biznes-metrika) nazorati ostida yangi versiyaga trafik ulushini oshirmoqda. iGaming uchun bu turnirlar va aksiyalarning eng yuqori cho’qqisida, barqaror p99 va sifatini saqlab qolgan holda, downtaymsiz chiqarishning bir usuli.

1) Qachon nimani tanlash

Blue-green - tezkor relizlar, minimal murakkablik, «ikki baravar» klaster/resurs byudjeti kerak. Murakkab state-migratsiyasiz API/front uchun yaxshi.
Canary - yuqori xavfli relizlar (yangi flou, tanqidiy o’zgarishlar), 1-5% trafikdagi tanazzullarni «ushlash» imkonini beradi. Telemetriya va avtomatik geytlarni talab qiladi.

2) Arxitektura prinsiplari

1. L7 darajasida marshrutlash: balanslovchi/Ingress/servis-mesh (muvozanatli trafik modullari, cookie/flag-routing).
2. Izolyatsiya qilingan qaramliklar: konfiguratsiyalar, fizeflaglar, sirlar, keshlar - taftishlar uchun alohida.
3. Ma’lumotlarning mosligi: oldinga mos keladigan DB migratsiyasi (expand → migrate → contract).
4. Kuzatilganlik: metrik/loglar/treyslardagi alohida yorliqlar/leybllar.
5. Avtogeytlar: p95/p99 taqqoslash, error-rate, biznes-KPI; avtomatik rollback.

3) Blue-green: bazaviy pattern

Oqim

1. Green (Blue nusxasi) → kesh/ulanishlarni isitish.
2. Health-/smoke-testlarni ishga tushiring.
3. Trafikni (DNS/LB/Ingress) Green ga oʻtkazish.
4. Blue’ni oynaning oxirigacha fallback holatida ushlab turamiz.

Misol: Ingress darajasida o’zgartirish (g’oya)

yaml
Annotated/Backend Option - In Prod, it is usually controlled by the spec operator/rollout:
rules:
- host: api. example. com http:
paths:
- path: /
backend:
service:
name: api-green # used to be api-blue port:
number: 80

Ijobiy/salbiy tomonlari

Oddiy orqaga qaytish (Blue qaytarildi).
Chiqish vaqti.
Resurslarni takrorlashni talab qiladi.
Kanar o’lchovisiz «katta portlash» xavfi.

4) Canary: bosqichma-bosqich o’sish

Oqim

1. Shadow-trafikning progoni (ixtiyoriy) → real trafikning 1% → 5% → 25% → 50% → 100%.
2. Har bir bosqichda - SLO/biznes metriklar bo’yicha geytlar.
3. Degradatsiyada - avto-qaytish va diagnostika artefaktlarini saqlash.

Masalan: Argo Rollouts (parcha)

yaml apiVersion: argoproj. io/v1alpha1 kind: Rollout metadata: { name: payments-api }
spec:
strategy:
canary:
canaryService: payments-canary stableService: payments-stable steps:
- setWeight: 5
- pause: { duration: 5m }
- analysis:
templates:
- templateName: slo-latency
- setWeight: 25
- pause: { duration: 10m }
- analysis:
templates:
- templateName: error-rate
- setWeight: 50
- pause: { duration: 20m }
- setWeight: 100

Misol: Flagger + Istio/NGINX (g’oya)

yaml apiVersion: flagger. app/v1beta1 kind: Canary metadata: { name: games-api }
spec:
targetRef:
apiVersion: apps/v1 kind: Deployment name: games-api service:
port: 80 analysis:
interval: 1m threshold: 5 metrics:
- name: request-success-rate thresholdRange: { min: 99 }
- name: request-duration thresholdRange: { max: 300 }
webhooks:
- name: smoke url: http://tester/smoke

5) Isitish va holatni boshqarish

Kesh/manbalar: Redis/HTTP-kesh/CDN ni isiting, warm-pool ulanishlarini DB/PSP ga tayyorlang.
ML/LLM/modellari: tarozilarni/indekslarni/embeddinglarni yuklash, KV-kesh, «isitish» uchun birlamchi so’rovlar.
Fayllar/artefaktlar: statik kontent, shablonlar, konfiglar - lokal volume/sidecarga oldindan topshiring.
Ficheflaglar: auditoriya/segmentning 1-5 foiziga rollout, emergency-kill imkoniyati.

6) Ma’lumotlar bazasi: «expand → migrate → contract» strategiyasi

1. Expand: nullable/yangi ustunlar/indekslar qoʻshish, ikkala versiyada ham qoʻllab-quvvatlash.
2. Migrate: kod yangi sxemadan foydalanadi; eski yo’llar haqiqiy bo’lib qolmoqda.
3. Contract: Eski maydonlarni/indekslarni toʻliq yoyilgandan keyin olib tashlaymiz.

Jurnallarda sxema va mijozning versiyasini qayd qiling; barcha o’zgarishlar idempotentdir.
Og’ir migratsiyalar uchun - fon joblari, throttling va kelishuv bo’yicha «stop-the-world» derazalari.

7) Kuzatish va geytlar (SLO/SLA)

SRE-metriklar: p50/p95/p99, error-rate, saturation (CPU/GPU/IO), queue-depth, sovuq boshlash vaqti.
Biznes-metrika: to’lovlarni konvertatsiya qilish, stavkalarning muvaffaqiyati, olib qo’yish vaqti (TTW), reklama javoblari.
Kontent sifati/LLM: tokens/s, javob uzunligi, toksiklik, RAG-score.
Geytlar: avto-promosyon/ostonadan chiqishda va/yoki «foydali metrika» qulaganida orqaga qaytish.

gate:
p95_latency_ms <= 250 error_rate %  <= 1. 0 payment_conv  >= baseline - 0. 3%
action:
promote      rollback

8) Reliz-orkestrlash va CI/CD bilan integratsiya

GitOps: versiya/og’irlikni o’zgartirish - PR orqali manifest-repozitoriyaga.
Avtoprovka: trafikni boshlashdan oldin smoke/e2e.
Reliz rejasi: canary bosqichlari jadvali, mas’ul, ChatOps kanallari, orqaga qaytish oynalari.
Artefaktlarni arxivlash: marshrutlash konfigi, dashbordlarning snepshotlari, metrikalarni taqqoslash loglari.

9) Multiregion va edge

Tartib: avval «eng kam tanqidiy» mintaqa/XTR, so’ngra asosiy mintaqalar.
Latency-based routing: lokal SLOni kuzating; sababsiz trafikni aralashtirmang.

DR-ko’rinish: Mintaqadagi Blue-A mintaqadagi Green uchun DR-platformasi bo’lishi mumkin

10) Reliz xavfsizligi va komplayens

Imzolangan tasvirlar/chartlar, SBOM; admission-siyosatlardagi ko’rsatkichlarni tekshirish.
Sirlar: faqat tashqi menejerlar; Blue/Green uchun mustaqil versiyalar.
PII/hududiylik: trafikni PII bilan «begona» mintaqa orqali olib bormang; taqqoslashda loglarni yashiring.
Audit: Kim, qanday geytlar ishladi, qayerda orqaga qaytish.

11) Konfiguratsiya namunalari

NGINX: kuki/sarlavha bo’yicha kanareyka filiali (g’oya)

nginx map $http_x_canary $canary {
default 0;
"1"   1;
}

upstream api_stable { server stable:80; }
upstream api_canary { server canary:80; }

server {
location / {
if ($canary) { proxy_pass http://api_canary; }
proxy_pass http://api_stable;
}
}

Feature-flag «fractional rollout» (psevdo)

yaml feature: new_checkout rollout:
percentage: 5 criteria:
country: ["TR", "BR", "MX"]
cohort: "new-users"
kill_switch: true

12) Runbooks (namunaviy stsenariylar)

Kanarda p99 o’sishi: reklama qilishni to’xtatish → batch/timeout ko’paytirish, bayroqlar orqali og’ir chiziqlarni o’chirish → podalarning bir qismini qayta ishga tushirish.
To’lovlar konversiyasining pasayishi: PSP yo’nalishlarini solishtirish, shadow-logirovkani yoqish, barqaror qaytarish.
DB migratsiyasi bilan bog’liq muammo: yozuvdagi trafikni muzlatish, read-only rejimini yoqish, sxemani qaytarish (agar mumkin bo’lsa), avariya joblarini tuzatish.
PII hodisasi: kanar versiyasini kesish, sirlarni takrorlash, hisobot va audit.

13) Joriy etish chek-varaqasi

1. Siyosatni aniqlang: qayerda blue-green, qayerda canary; «tanqidiy» deb hisoblanadi.
2. Tortilgan marshrutizatsiyani (Ingress/mesh/router) moslashtiring.
3. SLO chegara geytlari va avto-qaytishlarni tuzating.
4. expand → migrate → contract migratsiya testlari.
5. Kesh/modellar va warm-pool ulanishlarini isitishni yoqing.
6. GitOps’ni kiriting va barcha relizlarni jurnalga kiriting.
7. Metriklarni solishtirishni tasavvur qiling (kanareyka vs barqaror).
8. O’yinni o’tkazing: qaytish/xato/DB muammosini taqlid qiling.
9. Runbooks va qizil tugmani (kill-switch) hujjatlashtiring.
10. Bir vaqtning o’zida emas, balki ketma-ket ko’p mintaqali relizlarni rejalashtiring.

14) Anti-patternlar

Geytsiz va telemetriyasiz kanar relizi → keyinchalik degradatsiyalarni aniqlash.
MB sxemasini aralashtirish: kod yoyilgunga qadar buzuvchi migratsiyalar.
Blue va Green uchun bitta umumiy kesh/navbat izolyatsiyasiz → o’zaro ta’sir.
Past TTL bilan tekshirmasdan DNS almashtirish - trafikning «flapping».
Ikkala taftish uchun ham umumiy bo’lgan sirlar/konfigirlar → murakkab orqaga qaytish.
Shadow/smoke bo’lmagan prodga trafik - «katta portlash» xavfi.
Tezda oʻchirish uchun kill-switch/feature-flag mavjud emas.

Yakunlar

Blue-green tezda va oson o’zgarishni ta’minlaydi, canary - boshqariladigan xavf va muammolarni erta aniqlash. iGaming’da ikkala pattern bir-biriga mos keladi: «o’tkir» o’zgarishlardagi kanar + blue-green asosiy mexanizm sifatida dauntaymsiz. SLO geytlari, GitOps, isitish, BD mosligi va qaramlik izolyatsiyasini qo’shing - va relizlar oldindan aytib bo’lmaydigan bo’ladi, tezkor qaytish va p99 va biznes metrikalari eng yuqori davrlarda ham barqaror bo’ladi.