Wydania Blue-Green i Canary

(Sekcja: Architektura i protokoły)

1) Dlaczego potrzebujemy „bezpiecznych rollouts”

W nowoczesnych systemach wydanie jest nie tylko dostawą kodu, ale także kontrolowanym eksperymentem w sprzedaży: jednocześnie minimalizujemy ryzyko (nie łamiemy użytkowników) i skracamy czas sprzężenia zwrotnego (szybko zobacz efekt). Dwie klasyczne strategie - Blue-Green i Canary - rozwiązują to na różne sposoby, ale z wspólnym celem: zero przestojów, szybki zwrot, obserwowalność przez SLO.

2) Podstawowe definicje

Niebiesko-zielony

Przechowujemy dwie pełnoprawne kopie środowiska produkcyjnego: aktywny (Blue) obsługuje ruch, pasywny (Green) przygotowuje nową wersję. Przełączanie jest atomowe (przełącznik/flip) na poziomie balancera/routera. Jeśli będzie gorzej, natychmiast wrócimy do Blue.

Kanaryjski

Wprowadzamy części: najpierw do niewielkiego% ruchu (na przykład, 1-5%), obserwujemy metryki/SLO, a następnie krok po kroku zwiększamy udział (10% → 25% → 50% → 100%). Podczas degradacji - wałek lub zatrzymać się na poprzednim stabilnym kroku.

3) Kiedy najlepsze podejście

• Potrzebujemy natychmiastowego odwrotu bez skomplikowanych manewrów.
• Architektura/budżet pozwala na podwójne powielanie infrastruktury.
• Chcemy przeprowadzać migracje na dużą skalę lub aktualizacje platform (OS/JDK/runtime) w izolacji.
• Puli aplikacji/połączeń są wrażliwe na stopniowy stan „mieszany”.

• Musisz zminimalizować promień wybuchu i zobaczyć zachowanie na udział użytkowników.
• Wysoka szybkość uwalniania, progresywna dostawa jak zwykle.
• Istnieją dojrzałe obserwowalność i automatyczne bramy (budżet błędu, opóźnienia, konwersja).
• Zespół produktów chce przetestować hipotezy: wpływ na konwersję, retencję, LTV itp.

4) Ogólne zasady pomyślnego wydania

Idempotent budować artefakty: ten sam obraz/pakiet na wszystkich etapach.
Konfiguracja deterministyczna: konfiguracja jako kod, porównywalność środowisk.
Obserwowalność według projektu: kłody, mierniki, ślady, wpisy; SLI/SLO z wyprzedzeniem.
Szybki, automatyczny zwrot: przycisk/polecenie rolki jest częścią rurociągu, a nie magii ręcznej.
Kompatybilne zmiany schematu: strategia rozszerzania umowy o migrację (zob. § 10).
Routing L7 (pożądane): Elastyczność w nagłówkach/plikach cookie/ścieżkach/wersjach API.

5) Niebiesko-zielony: architektura i proces

5. 1 Topologia

Dwa stosy prod: niebieski (aktywny) i zielony (kandydat).
Wspólne zależności zewnętrzne: CDN, zewnętrzne API, kolejki; DB jest przypadkiem szczególnym (zob. § 10).
Punkt przełączania: balancer/Ingress/Gateway.

5. 2 Przepływ krok po kroku

1. Podnosimy Green pod nowy artefakt (vNext), przeprowadzamy testy dymne.
2. Autotest run against Green (e2e, kontrakt, regresja).
3. Podgrzać pamięć podręczną/sesje (jeśli dotyczy), zsynchronizować tło jabs/kolejki.
4. Przełącz ruch na Green: atomowy flip (DNS TTL low, swap trasy/słuchacza, waga Ingress = 100%).
5. Obserwujemy SLO w pierwszych minutach/godzinach (złote sygnały: opóźnienie, błędy, nasycenie + metryki biznesowe).
6. W przypadku problemów - natychmiastowy powrót do Blue (odwróć).

5. 3 Plusy/minusy

Plusy: natychmiastowy zwrot, prosty model psychiczny, czysta izolacja.
Minusy: podwojenie infrastruktury, trudności ze statycznymi komponentami i migracjami danych.

6) Architektura kanaryjska i proces

6. 1 Topologia

Pojedynczy klaster produkcyjny; kilka wersji usługi (stabilna i kanaryjska) za jednym frontem.
Ruch jest podzielony przez wagi (1-5-10-25-50-100%) lub przez cele (nagłówek/plik cookie/ID).

6. 2 Przepływ krok po kroku

1. Wdrożenie wersji kanaryjskiej do tego samego klastra/ASG/NSG.
2. Trasa ruchu (na przykład 1-5%) do kanarka.
3. Automatyczne kontrole SLI/SLO i mierników biznesowych; bramy w CI/CD (wskaźnik błędu, opóźnienie p95, CPU/RES, konwersja, odmowa/zwrot).
4. Krok po kroku wzrost udziału ruchu podczas przechodzenia bram.
5. Pełne uruchomienie do 100% i dezaktywacja starej wersji; w przypadku degradacji - auto-rollback.

6. 3 Plusy/minusy

Plusy: minimalne ryzyko dla większości użytkowników, rozwiązanie oparte na danych.
Minusy: potrzebujemy dojrzałej obserwacji, kompetentnej trasy, ryzyka „skew wersji” między instancjami.

7) Przebieg ruchu

Warstwa L4: równowaga według IP/portów; prosta, ale niewielka elastyczność.
Poziom L7: zasady HTTP/S - na ścieżce, host, nagłówek, pliki cookie, User-Agent, GeoIP, SNI.

• Trasa ważona (wagi 1-100%).
• Oparty na nagłówku/na plikach cookie.
• Lepkość sesji (ważna dla skryptów stacjonarnych/buforowanych).
• Lusterko cieni/ruchu (prośby lustrzane do nowej wersji „cicho”).

8) Narzędzia i implementacje (przykłady)

Kubernetes: Ingress (NGINX, Contour), Service Mesh (Istio/Linkerd), Argo Rollouts, Flagger.
Овлака: AWS ALB/ELB, trasa 53 ważona zapisami, ECS/EKS; Równoważenie obciążenia GCP + NEG; Drzwi przednie/brama aplikacji Azure.
Platformy CD: Spinnaker, Argo CD, GitHub Actions + Progressive Delivery plugins, GitLab/CD.

9) Obserwowalność, SLI/SLO i bramy

Złote sygnały: Latency (p95/p99), Szybkość błędów (5xx/4xсктисаz), RPS, Saturate (CPU/Memory/GC), Queue lag.
Metryki biznesowe: konwersja, autoryzacje, płatności/sukcesy, średnia kontrola, odmowa według kroków lejka.

• Próg błędu (na przykład wskaźnik błędu kanaryjskiego ≤ wartość wyjściowa + X%).
• Opóźnienie p95 nie jest gorsze od wartości wyjściowej o więcej niż Α.
• Próg operacyjny (np. spadek konwersji
• Budżet błędu SLO nie powinien spalić się szybciej.

Czas trwania etapu: minimalny czas wystarczający dla znaczenia statystycznego (zależy od ruchu).

10) Migracja bazy danych i kompatybilność schematu

Główna zasada: wydania są bezpieczne, jeśli wersje z tyłu i z powrotem są kompatybilne.

1. Rozwiń: dodaj nowe kolumny/indeksy/tabele bez łamania starej wersji.

2. Wdrożyć aplikację vNext (czyta/pisze do nowego schematu, ale wie, jak pracować ze starym).

3. Migruj dane (tło/partia, idempotent, z punktami kontrolnymi).

4. Kontrakt: usunąć stare pola/funkcje po stabilizacji.

Anty-wzorce: migracje wymagające wyłącznego blokowania w punkcie przełącznika Blue-Green; niezdolność do obniżenia klasyfikacji systemu; „podwójne pisanie” bez deduplikacji.

11) Plany wsteczne i awaryjne

Niebiesko-zielony: błyskawiczne odwrócenie Blue; monitorować ogony zielonych miejsc pracy.
Kanarka: waga wsteczna (na przykład od 25% do 5% lub 0%); automatyczne przerywanie wpisów.
Dane: dobrze przemyślana polityka powtarzania/kompensacji (klucze idempotencji, wzór „skrzynki odbiorczej/skrzynki zewnętrznej”, deduplikowanie wiadomości).
Ficheflags: Szybki przełącznik zabijania, aby wyłączyć częściowo zwinięte możliwości.

12) Praca z państwem i sesje

Sticky sesje dla kanarków, lub przechowywanie sesji zewnętrznie (Redis/Memcached) tak, że wersje są wymienne.
Cache rozgrzać z wyprzedzeniem (Zielony rozgrzewka) i wziąć pod uwagę unieważnienie podczas odwrócenia.
Pracownicy tła: nie zezwalają na „wyścigi” między wersjami - rozdzielenie kolejki lub „przywództwo” według wersji.

13) Bezpieczeństwo i zgodność

Dostęp do Green/Canary - przez Zero Trust: konta serwisowe, minimalne wymagane role.
Sekrety i klucze - poprzez KMS/Secrets Manager; Włącz obrót.
Ruch - tylko TLS; wersje punktów końcowych są wyraźnie zaznaczone; Routing audytu i działania uwolniające.

14) Koszt i wydajność

Blue-Green podwaja infrastrukturę (w momencie zwolnienia lub stale) - budżet.
Canary jest bardziej ekonomiczne, ale wymaga narzędzi obserwacji i czasu inżynierii do automatyzacji.
Optymalizacja: autoskalowanie, efemeryczne środowisko, skracanie okna równoległego istnienia wersji.

15) Listy kontrolne

Przed zwolnieniem

• Image/build promowane z jednego źródła, podpisy zweryfikowane.
• Plan testów, alerty i bramy SLO są skonfigurowane.
• Migracje w bazie danych - w trybie rozszerzenia dostępne są plany obniżenia jakości.
• Plan wsteczny - sprawdzony w postoju/produkcji podobnej.

W momencie zwolnienia

• Wskaźniki i kłody porównuje się z poziomem odniesienia.
• Dla Kanaryjczyków kroki i progi są ustalane; dla Blue-Green - gotowość do odwrócenia.
• Polecenia dyżurów są w wiedzy, istnieje okno zwrotne.

Po zwolnieniu

• SLO nie zatonął, budżet błędu jest normalny.
• Zakończono migrację/oczyszczenie po zwolnieniu.
• Aktualizacja retrospektywna i playbook.

16) Częste błędy i anty-wzory

Rollout bez metryki: brak danych - brak rozwiązania zarządzanego.
Mieszanie niekompatybilnych systemów baz danych, brak strategii obniżenia jakości.
Losowe mieszanie ruchu: brak lepkości, użytkownicy „skok” między wersjami.
Ukryte statyczne zależności (lokalne dyski, pamięci podręczne).
Długi DNS-TTL zakłóca szybką szybkość (Blue-Green).
Brak autogatów: ręczne rozwiązania „z oka” spowalniają i zwiększają ryzyko.

17) Podejście połączone

Blue-Green + Canary: Roll out Green najpierw, a następnie wewnątrz Green roll out Canary dla indywidualnych usług.
Cień/ruch migracyjny: przed Canary, prowadzimy lustrzany ruch do nowej wersji.
Flagi funkcyjne (progresywna dostawa): funkcjonalność jest wliczana na szczycie stabilnej wersji przez „ciemne” flagi według segmentów.

18) Przykładowe scenariusze (szkice)

1. Wdrożyć Green (v2) dla nowego Listener/Ingress.

2. Podgrzać bufory, sprawdzić, palić.

3. Przełączamy ciężar na zielony = 100%.

4. Obserwować SLO przez 30-60 minut; jeśli wszystko jest w porządku - wyłącz Blue.

1. Wdrożyć kanaryjski vNext (repliki 5%).

2. Uwzględniamy 5% ruchu dla wewnętrznych kont/segmentu testowego.

3. Autogate: wskaźnik błędu ≤ wartość wyjściowa + 0. 3%, p95 ≤ + 20 ms.

4. Podnosimy 10% → 25% → 50% co N minut przy przechodzeniu bram.

5. Tłumaczymy ficheflag 100% dla wszystkich segmentów; usunięcie starej wersji.

19) Zmiany dla różnych architektur

Monolith: niebiesko-zielony jest prostszy, kanaryjski jest trudniejszy ze względu na niepodzielność funkcji; używać ficheflagów.
Mikroservice: Kanarka jest naturalna; monitorowanie umów konsumenckich.
Usługi Stateful: Preferuj Blue-Green z starannie wykonanych migracji i lepkości.

20) Krótkie porównanie (streszczenie)

Prędkość wsteczna: niebiesko-zielona = chwilowa; Canary = szybki, ale z pullback w wadze.
Koszt infrastruktury: Niebiesko-Zielony; Kanaryjski ↔︎/↓.
Ryzyko dla użytkowników: Kanaryjski jest niższy (kontrolujemy udział).
Trudności z wdrożeniem: Blue-Green jest łatwiejszy do uruchomienia; Canary wymaga silnej obserwacji i automatyzacji.
Kompatybilność danych/obwodów: krytyczna dla obu; plan rozszerzania umowy o migrację.

21) Najważniejsze

Niebiesko-zielone i kanaryjskie nie są wzajemnie wykluczającymi się strategiami, ale elementami stopniowej realizacji. Wybór zależy od ograniczeń kosztów, dojrzałości obserwacji i charakteru zmian. Niezależnie od podejścia, trwałe uwalnianie opiera się na czterech filarach: automatyzacji, obserwowalności, kompatybilności wstecznej i szybkim odwróceniu.