Albastru-verde și Canare lansează

(Secțiunea: Arhitectură și protocoale)

1) De ce avem nevoie de „rulouri sigure”

În sistemele moderne, eliberarea nu este doar livrare de cod, ci și un experiment controlat în vânzări: reducem simultan riscul (nu spargem utilizatorii) și reducem timpul de feedback (vedem rapid efectul). Două strategii clasice - Blue-Green și Canary - rezolvă acest lucru în moduri diferite, dar cu un scop comun: downtime zero, rollback rapid, observabilitate de SLO.

2) Definiții de bază

Albastru-Verde

Păstrăm două copii complete ale mediului de producție: activul (albastru) servește traficul, pasivul (verde) pregătește o nouă versiune. Comutarea este atomică (comutator/flip) la nivelul de echilibru/router. Dacă s-a înrăutăţit, ne întoarcem instantaneu la Blue.

Canare

Ne lansăm în părți: în primul rând la un mic% din trafic (de exemplu, 1-5%), observa metrici/SLO, apoi pas cu pas crește cota (10% → 25% → 50% → 100%). În timpul degradării - rollback sau oprire la pasul anterior stabil.

3) Când abordarea este cea mai bună

• Avem nevoie de o revenire instantanee fără manevre complexe.
• Arhitectura/bugetul permite dublarea infrastructurii duale.
• Dorim să efectuăm migrații pe scară largă sau actualizări de platformă (OS/JDK/runtime) în mod izolat.
• Bazinele de aplicare/conectare sunt sensibile la o stare treptată „mixtă”.

• Aveți nevoie pentru a minimiza raza de explozie și a vedea comportamentul pe cota de utilizatori.
• Rata mare de eliberare, livrare progresivă ca de obicei.
• Există observabilitate matură și porți automate (buget de eroare, latență, conversie).
• Echipa de produse dorește să testeze ipoteze: impactul asupra conversiei, retenției, LTV etc.

4) Principii generale pentru o eliberare de succes

Artefacte Idempotent build: aceeași imagine/pachet în toate etapele.
Configurație deterministă: configurare ca cod, comparabilitatea mediilor.
Observabilitate prin design: busteni, metrici, urme, alerte; SLI/SLO în avans.
Rollback rapid, automat: Butonul/comanda rollback face parte din conductă, nu magie manuală.
Schema compatibilă se schimbă: strategia extinde-migrează-contract (a se vedea § 10).
Rutare L7 (de dorit): Flexibilitate pe antete API/cookie-uri/căi/versiuni.

5) albastru-verde: arhitectură și proces

5. 1 Topologie

Două stive prod: albastru (activ) și verde (candidat).
Dependențe externe comune: CDN, API-uri externe, cozi; DB este un caz special (a se vedea § 10).
Punct de comutare: balansor/intrare/gateway.

5. 2 Curgere pas cu pas

1. Vom ridica verde sub un nou artefact (vNext), vom efectua teste de fum.
2. Autotest se execută împotriva Green (e2e, contract, regresie).
3. Încălziți memoria cache/sesiuni (dacă este cazul), sincronizați jabs de fundal/cozi.
4. Comutați traficul la Green: flip atomic (DNS TTL scăzut, Route/Listener swap, Greutate de intrare = 100%).
5. Observăm SLO în primele minute/ore (semnale de aur: latență, erori, saturație + valori de afaceri).
6. În caz de probleme - revenirea instantanee la albastru (înapoi).

5. 3 argumente pro/contra

Pro: rollback instantaneu, model mental simplu, izolare pură.
Contra: dublarea infrastructurii, dificultatea cu componentele statale și migrarea datelor.

6) Arhitectura și procesul Canare

6. 1 Topologie

Cluster unic de producție; mai multe versiuni ale serviciului (stabil și canar) în spatele unui singur front.
Traficul este împărțit la greutăți (1-5-10-25-50-100%) sau la obiective (prin antet/cookie/ID).

6. 2 Curgere pas cu pas

1. Implementați versiuni canare la același cluster/ASG/NSG.
2. Ruta unele trafic (de exemplu, 1-5%) la canar.
3. Verificări automate ale măsurătorilor SLI/SLO și business; porti in CI/CD (rata de eroare, p95 latenta, CPU/RES, conversie, refuz/retur).
4. Pas cu pas creșterea ponderii traficului la trecerea porților.
5. Lansare completă la 100% și dezactivarea versiunii vechi; în caz de degradare - auto-rollback.

6. 3 argumente pro/contra

Pro: risc minim pentru majoritatea utilizatorilor, soluție bazată pe date.
Contra: avem nevoie de observabilitate matură, rutare competentă, riscul de „înclinare a versiunii” între instanțe.

7) Rutarea traficului

Strat L4: echilibru prin IP/porturi; simplă, dar puţină flexibilitate.
Nivelul L7: Regulile HTTP/S - pe cale, gazdă, antet, cookie-uri, User-Agent, GeoIP, SNI.

• Rutare ponderată (ponderi 1-100%).
• Header-based/Cookie-based.
• Stickiness sesiune (important pentru scripturi statteful/cached).
• Oglindirea umbrelor/traficului (cereri în oglindă la noua versiune „în liniște”).

8) Instrumente și implementări (exemple)

Kubernetes: Ingress (NGINX, Contour), Service Mesh (Istio/Linkerd), Argo Rollouts, Flagger.
Облака: AWS ALB/ELB, Route 53 înregistrări ponderate, ECS/EKS; GCP Load Balancing + NEG; Usa din fata Azure/Gateway App.
Platforme CD: Spinnaker, Argo CD, GitHub Actions + plugin-uri progresive de livrare, GitLab/CD.

9) Observabilitate, SLI/SLO și porți

Semnale de aur: latență (p95/p99), rată de eroare (5xx/4xx по типам), RPS, saturație (CPU/Memory/GC), lag coadă.
Valori de afaceri: conversie, autorizații, plăți/succese, verificare medie, refuz prin pași de pâlnie.

• Pragul de eroare (de exemplu, rata de eroare canar ≤ linia de bază + X%).
• latenţa p95 nu este mai rea decât valoarea iniţială cu mai mult de Δ.
• Pragul de afaceri (ex. picătură de conversie
• Bugetul de eroare SLO nu ar trebui să ardă mai repede.

Durata etapei: timp minim suficient pentru semnificația statistică (depinde de trafic).

10) Migrarea bazelor de date și compatibilitatea schemelor

Regula principală: versiunile sunt sigure dacă versiunile înainte și înapoi sunt compatibile.

1. Extindeți: adăugați coloane/indexuri/tabele noi fără a rupe versiunea veche.

2. Implementați aplicația vNext (citește/scrie la noua schemă, dar știe cum să lucreze cu cea veche).

3. Migrați date (fundal/lot, idempotent, cu puncte de control).

4. Contract: ștergeți câmpurile/caracteristicile vechi după stabilizare.

Anti-modele: migrații care necesită blocare exclusivă la punctul de comutare albastru-verde; incapacitatea de a retrograda sistemul; „scriere dublă” fără deduplicare.

11) Rollback și planuri de urgență

Albastru-verde: flip instant pe albastru; monitoriza cozile de locuri de muncă fundal verde.
Canare: rollback în greutate (de exemplu, de la 25% înapoi la 5% sau 0%); anularea automată a alertelor.
Date: o politică bine gândită de repetare/compensare (chei de idempotență, model „inbox/outbox”, eliminare de mesaje).
Ficheflags: Un kill switch rapid pentru a închide oportunitățile parțial laminate.

12) Lucrul cu statul și sesiunile

Sesiuni lipicioase pentru canari, sau stocarea sesiuni extern (Redis/Memcached), astfel încât versiunile sunt interschimbabile.
Cache să se încălzească în avans (Green warm-up) și să ia în considerare invalidarea atunci când flip.
Lucrătorii de fundal: nu permit „curse” între versiuni - separarea cozii sau „leadership” după versiune.

13) Siguranță și conformitate

Acces la Green/Canary - de Zero Trust: conturi de servicii, roluri minime necesare.
Secretele și cheile - prin KMS/Secrets Manager; porniți rotația.
Trafic - numai TLS; versiunile criteriului final sunt marcate în mod clar; Audit de rutare și activități de eliberare.

14) Costul și performanța

Blue-Green dublează infrastructura (la momentul lansării sau în mod constant) - buget.
Canare este mai economic, dar necesită instrumente de observabilitate și timp de inginerie pentru a automatiza.
Optimizare: autoscalare, mediu efemer, scurtarea ferestrei de existență paralelă a versiunilor.

15) Liste de verificare

Înainte de eliberare

• Imagine/build promovat dintr-o singură sursă, semnături verificate.
• Planul de testare, alerte și porți SLO sunt configurate.
• Migrarea bazelor de date - în modul de extindere, planurile de downgrade sunt disponibile.
• Plan rollback - verificat în stadiu/producție-like.

În momentul eliberării

• Măsurătorile și jurnalele sunt comparate cu valoarea inițială.
• Pentru Canare, treptele și pragurile sunt fixe; pentru Blue-Green - flip-back.
• Comenzile de gardă sunt în știre, există o fereastră de feedback.

După eliberare

• SLO nu sa scufundat, bugetul de eroare este normal.
• Migrații post-eliberare/curățare finalizate.
• Retrospectivă și actualizare playbook.

16) Erori frecvente și anti-modele

Rollout fără măsurători: fără date - fără soluție gestionată.
Amestecarea schemelor de baze de date incompatibile, lipsa strategiei de downgrade.
Amestecarea traficului aleatoriu: fără lipiciozitate, utilizatorii „sar” între versiuni.
Dependențe statale ascunse (discuri locale, cache-uri de memorie).
DNS-TTL lung interferează cu flip rapid (albastru-verde).
Lipsa autogatelor: soluțiile manuale „cu ochi” încetinesc și cresc riscurile.

17) Abordări combinate

Blue-Green + Canary: Roll out Green mai întâi, apoi în interiorul Green roll out Canare pentru servicii individuale.
Trafic de umbre/migrare: înainte de Canare, rulăm traficul în oglindă la noua versiune.
Caracteristici steaguri (livrare progresivă): funcționalitatea este inclusă pe partea de sus a versiunii stabile de steaguri „întunecate” pe segmente.

18) Scenarii de probă (schițe)

1. Implementați Green (v2) pentru noul Listener/Ingress.

2. Încălziți cache-urile, efectuați controale readonly, fumați.

3. Trecem greutatea la Green = 100%.

4. Observați SLO timp de 30-60 de minute; dacă totul este în regulă - opriți Blue.

1. Implementați canar vNext (replici 5%).

2. Includem 5% trafic pentru conturile interne/segmentul de testare.

3. Autogate: rata de eroare ≤ linia de bază + 0. 3%, p95 ≤ + 20ms.

4. Ridicăm 10% → 25% → 50% la fiecare N minute la trecerea porților.

5. Traducem ficheflag 100% pentru toate segmentele; ștergerea versiunii vechi.

19) Variații pentru diferite arhitecturi

Monolit: albastru-verde este mai simplu, Canare este mai dificil datorită indivizibilității caracteristicilor; utilizați ficheflags.
Microservicii: Canarul este natural; monitorizarea contractelor conduse de consumatori.
Servicii Statful: Prefera Blue-Green cu migrații atent artizanale și lipiciozitate.

20) Scurtă comparație (rezumat)

Viteza de întoarcere: albastru-verde = instantaneu; Canare = rapid, dar cu un pullback în greutate.
Costul infrastructurii: ↑ albastru-verde; Canare ↔︎/↓.
Risc pentru utilizatori: Canare este mai mic (controlăm cota).
Dificultate de implementare: Blue-Green este mai ușor de început; Canare necesită observabilitate puternică și automatizare.
Compatibilitatea date/circuit: critică pentru ambele; plan extinde-migra-contract.

21) Linia de jos

Albastru-verde și Canare nu sunt strategii reciproc exclusive, ci elemente de livrare progresivă. Alegerea depinde de constrângerile de costuri, de maturitatea observabilității și de natura schimbărilor. Indiferent de abordare, lansarea durabilă se bazează pe patru piloni: automatizare, observabilitate, compatibilitate înapoi și rollback rapid.