Blue-Green və Canary buraxılışları

(Bölmə: Memarlıq və Protokollar)

1) Niyə «təhlükəsiz çıxışlar» lazımdır

Müasir sistemlərdə buraxılış yalnız kodun çatdırılması deyil, həm də prodda idarə olunan bir təcrübədir: biz eyni zamanda riski minimuma endiririk (istifadəçiləri sındırmırıq) və rəy müddətini qısaltırıq (təsiri tez görürük). İki klassik strategiya - Blue-Green və Canary - bunu fərqli şəkildə həll edir, lakin ümumi məqsədlə: sıfır geri dönüş, sürətli geri dönüş, SLO ilə müşahidə.

2) Əsas təriflər

Blue-Green

Proto-mühitin iki tam surətini saxlayırıq: aktiv (Mavi) trafikə xidmət edir, passiv (Yaşıl) yeni versiyanı hazırlayır. Keçid - balanslaşdırıcı/marşrutlaşdırıcı səviyyəsində atom (switch/flip). Daha da pisləşirsə, dərhal Blue-ya qayıdırıq.

Canary

Hissə-hissə yuvarlayın: əvvəlcə kiçik% trafik (məsələn, 1-5%), metrik/SLO müşahidə edin, sonra payı addım-addım artırın (10% → 25% → 50% → 100%). Deqradasiya zamanı - əvvəlki sabit addımda geri çəkilmə və ya dayanma.

3) Hansı yanaşma daha yaxşıdır

• Çətin manevrlər olmadan dərhal geri dönüş lazımdır.
• Memarlıq/büdcə ikili infrastruktur təkrarlanmasına imkan verir.
• Biz geniş miqyaslı miqrasiya və ya platforma yeniləmələri (OS/JDK/rantaym) təcrid etmək istəyirik.
• Əlavə/birləşmə hovuzları tədricən «qarışıq» vəziyyətə həssasdır.

• blast radius minimuma endirmək və istifadəçilərin payına davranış görmək lazımdır.
• Yüksək buraxılış tezliyi, norma kimi mütərəqqi çatdırılma.
• Yetkin müşahidə və avtomatik geytlar (error budget, latency, conversion) var.
• Məhsul qrupu hipotezləri yoxlamaq istəyir: dönüşüm, saxlama, LTV və s.

4) Uğurlu buraxılışın ümumi prinsipləri

İdempotent tarixi artefaktlar: bütün mərhələlərdə eyni şəkil/paket.
Determinik konfiqurasiya: bir kod kimi, mühitin müqayisəsi.
Müşahidə by design: log, metrika, izləmə, həyəcan; SLI/SLO əvvəlcədən.
Sürətli, avtomatlaşdırılmış geri qaytarma: düymə/geri qaytarma əmri əl sehri deyil, paylaynın bir hissəsidir.
Uyğun sxem dəyişiklikləri: expand-migrate-contract strategiyası (bax § 10).
L7 səviyyəsində marşrutlaşdırma (arzu olunur): başlıqlar/çerezlər/yollar/API versiyaları üzrə çeviklik.

5) Blue-Green: memarlıq və proses

5. 1 Topologiya

İki prod yığın: Blue (aktiv) və Green (namizəd).
Ümumi xarici asılılıqlar: CDN, xarici API, növbələr; BD - xüsusi hal (bax § 10).
Keçid nöqtəsi: Balans/Ingress/Gateway.

5. 2 Addım Flow

1. Green 'i yeni bir artefakt (vNext) altında qaldırırıq, smoking testləri aparırıq.
2. Green (e2e, müqavilə, reqressiya) qarşı avtostest qaçış.
3. Cache/seansları (mümkünsə) isidirik, fon joblarını/növbələrini sinxronlaşdırırıq.
4. Trafikin Green-ə keçməsi: atom flip (DNS TTL aşağı, Route/Listener swap, Ingress weight = 100%).
5. SLO-nu ilk dəqiqələrdə/saatlarda müşahidə edirik (golden signals: latency, errors, saturation + business metrics).
6. Problemlərdə - Mavi (flip back) üçün dərhal geri dönüş.

5. 3 Müsbət/mənfi cəhətləri

Üstünlüklər: ani geri dönüş, sadə zehni model, təmiz izolyasiya.
Dezavantajları: infrastrukturun ikiqat artması, stateful komponentləri və məlumat miqrasiyaları ilə çətinlik.

6) Canary: memarlıq və proses

6. 1 Topologiya

Vahid prod-klaster; xidmətin bir neçə versiyası (stable və canary) bir cəbhədə.
Trafik tərəziyə (1-5-10-25-50-100%) və ya hədəflərə (başlıq/kuke/ID) bölünür.

6. 2 Addım Flow

1. Eyni/ASG/NSG klasterinə canary-versiyası.
2. Trafik hissəsinin marşrutlanması (məsələn, 1-5%) canary.
3. Avtomatik SLI/SLO və biznes metrik yoxlamalar; CI/CD geytaları (error rate, p95 latency, CPU/RES, dönüşüm, uğursuzluq/geri qaytarma).
4. Gates keçərkən trafik payının addım-addım artması.
5. 100% -ə qədər tam rollout və köhnə versiyanın deaktivasiyası; deqradasiya zamanı - avto-rollback.

6. 3 Müsbət/mənfi cəhətləri

Faydaları: əksər istifadəçilər üçün minimum risk, data-driven həll.
Mənfi cəhətləri: yetkin müşahidə, səriştəli marşrutlaşdırma, instantsiyalar arasında «version skew» riski lazımdır.

7) Trafik marşrutu

L4 səviyyəsi: IP/port balansı; sadə, lakin az çeviklik.
L7 səviyyəsi: HTTP/S qaydaları - yol, host, başlıq, cookie, User-Agent, GeoIP, SNI.

• Weighted routing (çəkisi 1-100%).
• Header-based/Cookie-based (qrupda istifadəçi fiksasiyası).
• Session stickiness (stateful/cached ssenarilər üçün vacibdir).
• Shadow/Traffic mirroring (yeni versiyada sorğuları əks etdiririk).

8) Alətlər və tətbiqlər (nümunələr)

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

9) Müşahidə, SLI/SLO və geytalar

Golden signals: Latency (p95/p99), Error rate (5xx/4xx по типам), RPS, Saturation (CPU/Memory/GC), Queue lag.
Biznes metrikası: konvertasiya, avtorizasiya, ödənişlər/uğurlar, orta çek, huni addımlarından imtina.

• Səhv həddi (məsələn, error rate canary ≤ baseline + X%).
• Gecikmə p95 Δ-dən daha pis deyil.
• Biznes həddi (məsələn, dönüşümün azalması
• SLO-da Error budget sürətlə yanmamalıdır.

Addım müddəti: statistik əhəmiyyət üçün kifayət qədər minimum vaxt (trafikdən asılıdır).

10) DB miqrasiyası və sxemlərin uyğunluğu

Əsas qayda: versiyalar geri və irəli uyğun olduqda buraxılışlar təhlükəsizdir.

1. Expand: köhnə versiyanı qırmadan yeni sütunlar/indekslər/cədvəllər əlavə edin.

2. Deploy app vNext (oxuyur/yeni sxemdə yazır, lakin köhnə ilə işləməyi bilir).

3. Migrate data (background/batch, idempotent, yoxlama nöqtələri ilə).

4. Contract: sabitləşmədən sonra köhnə sahələri/fiqurları silmək.

Anti-nümunələr: Blue-Green keçid anında eksklüziv kilidləmə tələb edən miqrasiyalar; sxemdən uzaqlaşmağın mümkünsüzlüyü; duplikasiya olmadan «ikiqat qeyd».

11) Geri çəkilmə (rollback) və qəza planları

Blue-Green: Blue ani flip; Green fon joblarının «quyruqlarını» izləyirik.
Canary: çəkinin geri çəkilməsi (məsələn, 25% geri 5% və ya 0%); alert avtomatik abort.
Məlumatlar: düşünülmüş təkrarlama/kompensasiya siyasəti (idempotency keys, «inbox/outbox» pattern, mesajların təkrarlanması).
Ficheflags: qismən haddelenmiş imkanları söndürmək üçün sürətli kill switch.

12) Steyt və sessiyalarla işləmək

Kanaryalar üçün Sticky sessions, və ya xarici seansları saxlamaq (Redis/Memcached), belə ki, versiyalar dəyişdirilə bilər.
Cache əvvəlcədən qızdırmaq (Green warm-up) və flip invalidation nəzərə.
Fon işçiləri: versiyalar arasında «yarış» - növbələrin bölünməsi və ya versiyaya görə «liderlik» etməyin.

13) Təhlükəsizlik və uyğunluq

Green/Canary-ə giriş - Zero Trust ilə: xidmət hesabları, minimum lazımi rollar.
Sirlər və açarlar - KMS/Secrets Manager vasitəsilə; rotasiya daxil edin.
Trafik - yalnız TLS; endpoint 'lərin versiyaları aydın şəkildə qeyd edilmişdir; marşrutlaşdırma və buraxılış hərəkətlərinin auditi.

14) Qiymət və performans

Blue-Green infrastrukturu ikiqat artırır (buraxılış zamanı və ya daimi) - büdcə qoyun.
Canary daha qənaətlidir, lakin avtomatlaşdırma üçün müşahidə və mühəndislik vaxtı alətləri tələb edir.
Optimizasiya: avtoskeylinq, ephemeral mühit, paralel varlıq versiyalarının pəncərəsinin qısaldılması.

15) Çek vərəqləri

Buraxılışdan əvvəl

• Şəkil/bild bir mənbədən tanıtılır, imzalar yoxlanılır.
• Test planı, risklər və SLO geytləri konfiqurasiya edilmişdir.
• DB miqrasiyası - expand rejimində, downgrade planları mövcuddur.
• Geri çəkilmə planı - staging/production-like-də yoxlanılır.

Buraxılış zamanı

• Metrik və log baseline ilə müqayisə olunur.
• Canary üçün - addımlar və eşiklər sabit; Blue-Green üçün - flip-back hazırlığı.
• On-call komandaları geribildirim pəncərəsi var.

Buraxıldıqdan sonra

• SLO batmadı, error budget normal.
• Post-reliz miqrasiya/təmizləmə tamamlandı.
• Retrospektiv və playbook yeniləmə.

16) Tez-tez səhvlər və anti-nümunələr

Metrsiz geri çəkilmə: məlumat yoxdur - idarə edilə bilən həll yoxdur.
Uyğun olmayan DD sxemlərinin qarışdırılması, aşağı düşmə strategiyasının olmaması.
Təsadüfi trafik qarışdırma: heç bir stickiness, istifadəçilər versiyaları arasında «atlama».
Gizli stateful asılılığı (yerli disklər, in-memory caches).
Uzun DNS-TTL sürətli flip (Blue-Green) mane olur.
Avtoqeytlərin olmaması: əl «göz» həlləri yavaşlayır və riskləri artırır.

17) Kombinə yanaşmalar

Blue-Green + Canary: əvvəlcə Green-i yuvarlayın, sonra ayrı-ayrı xidmətlər üçün Green-də Canary-i yuvarlayın.
Shadow/miqrasiya trafiki: Canary-dən əvvəl güzgü trafikini yeni versiyaya sürün.
Feature flags (progressive delivery): funksionallıq seqmentlər üzrə «qaranlıq» bayraqlarla sabit versiyanın üstündə açılır.

18) Ssenari nümunələri (eskizlər)

1. Yeni Listener/Ingress üçün Green (v2).

2. Cache qızdırmaq, readonly-yoxlamalar, smoke.

3. Çəkini Green = 100% -ə keçirin.

4. SLO 30-60 dəqiqə müşahidə; hər şey yaxşıdırsa, Blue-ni söndürün.

1. Deploy canary vNext (5% replikalar).

2. Daxili hesablar/test seqmenti üçün 5% trafik daxildir.

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

4. 10% → 25% → 50% -ni hər N dəqiqədə qaldırın.

5. Bütün seqmentlər üzrə 100% ficheflag köçürürük; köhnə versiyasını silirik.

19) Müxtəlif arxitekturalar üçün variasiyalar

Monolit: Blue-Green daha asan, Canary bölünməzlik üzündən daha çətindir; ficheflags istifadə edin.
Mikroservislər: Canary təbiidir; xidmətlərarası müqavilələrə (consumer-driven contracts) nəzarət edin.
Stateful Services: diqqətlə hazırlanmış miqrasiya və stickiness ilə Blue-Green üstünlük.

20) Qısa müqayisə (xülasə)

Geri dönüş sürəti: Blue-Green = anında; Canary = sürətli, lakin geri çəkilmə.
Infrastruktur dəyəri: Blue-Green ↑; Canary ↔︎/↓.
İstifadəçilər üçün risk: Canary aşağıda (pay nəzarət).
Tətbiqi çətinlik: Blue-Green başlamaq daha asandır; Canary güclü müşahidə və avtomatlaşdırma tələb edir.
Verilənlərin/sxemlərin uyğunluğu: hər ikisi üçün kritik; expand-migrate-contract planlaşdırın.

21) Yekun

Blue-Green və Canary qarşılıqlı istisna strategiyaları deyil, mütərəqqi çatdırılma elementləridir. Seçim dəyər məhdudiyyətləri, müşahidə yetkinliyi və dəyişikliklərin xarakterindən asılıdır. Yanaşmadan asılı olmayaraq, sabit buraxılış dörd dayaqda saxlanılır: avtomatlaşdırma, müşahidə, əks uyğunluq və sürətli geri dönüş.