Co to jest canary deployment? Praktyczny przewodnik dla SRE

Canary deployment to technika wdrożenia, w której nowa wersja trafia najpierw na niewielką część ruchu produkcyjnego, jest porównywana z wersją działającą obok, a zasięg zwiększa się tylko wtedy, gdy liczby się zgadzają. Co to jest canary deployment w praktyce? To wdrożenie z wbudowanym punktem decyzyjnym: zmiana najpierw dociera do 1 do 5 procent użytkowników, a kontrola metryk decyduje, czy idzie dalej, czy zostaje cofnięta.

Dalsza część przewodnika opisuje, jak to działa, gdzie zawodzi i co warto zautomatyzować.

Alarm o 3 w nocy, który canary zamieniłby w wiadomość na Slacku

Wdrożenie idzie na produkcję w czwartek o 16:40. Wskaźnik błędów w usłudze checkout rośnie z 0,2 procent do 4 procent. Nikt tego nie zauważa, aż zgłoszenie od wsparcia pojawia się dwie godziny później, a wtedy każdy użytkownik już działa na nowym buildzie. Wycofanie zajmuje 25 minut, bo migracja została zastosowana tylko w połowie.

Ta sama zmiana wdrożona jako canary na 5 procent ruchu ogranicza szkody. Około 1 na 20 użytkowników trafia na błąd, porównanie z grupą kontrolną wychodzi negatywnie w ciągu kilku minut i potok się zatrzymuje. Postmortem opisze wtedy, co canary wychwyciło, a nie to, czego nie zauważyło.

Nazwa pochodzi z kopalń węgla, gdzie kanarek przestawał śpiewać, zanim powietrze stało się śmiertelne. Mała grupa testowa pełni tę samą rolę. Nie zapobiega złemu wydaniu. Ogranicza liczbę osób, które je wdychają.

Co dokładnie robi canary deployment, krok po kroku

Google SRE Workbook definiuje canarying jako częściowe, ograniczone w czasie wdrożenie zmiany oraz ocenę, która decyduje, czy wdrażanie jest kontynuowane. Podzbiór uruchamiający zmianę to canary, a reszta floty to kontrola. Takie ujęcie ma znaczenie, bo czyni z canary test A/B na własnej niezawodności, a nie tylko wolne wdrożenie.

Typowa sekwencja wygląda tak:

• Wdróż nową wersję obok stabilnej, bez ruchu.

• Skieruj niewielki procent ruchu do nowej wersji (przykład z Workbook używa 5 procent).

• Utrzymaj stałe okno (ten sam przykład używa 30 minut), porównując canary z kontrolą.

• Przejdź do kolejnego etapu, na przykład 25, potem 50, potem 100 procent, albo przerwij i przywróć ruch.

Pętla jest prosta. Trudna jest część porównawcza, którą większość zespołów wdraża jako „ktoś patrzy na dashboard”.

Canary, blue-green i rolling: który pasuje do danego modelu awarii

Te trzy podejścia są stale mylone, dlatego warto rozróżnić je przy wyborze.

• Rolling update: wymienia instancje stopniowo. Jest tani i wbudowany w każdy orkiestrator, ale nie ma porównania z kontrolą ani czystego podziału ruchu. Stare i nowe wersje dzielą obciążenie aż do końca.

• Blue-green: dwa pełne środowiska, przełączenie całego ruchu naraz. Wycofanie jest natychmiastowe, ale promień rażenia w chwili przełączenia to 100 procent użytkowników. Płacisz za podwójną pojemność.

• Canary: kontrolowany ułamek ruchu na żywo na nowej wersji, oceniany względem starej. Najmniejszy promień rażenia, najwyższa złożoność operacyjna.

Wybierz blue-green, gdy ryzyko to zepsute wdrożenie, które wykryjesz testem dymnym i cofniesz w kilka sekund. Wybierz canary, gdy ryzyko to subtelna regresja, którą ujawnia dopiero prawdziwy ruch: wzrost p99, powolny wyciek pamięci, plan zapytania, który nie wytrzymuje kształtów danych z produkcji.

Pomiń canary, jeśli usługa ma bardzo mały ruch. Przy kilkuset żądaniach na godzinę wycinek 5 procent daje garstkę próbek i żadnego sygnału. Workbook mówi to wprost: bardzo mała liczba zapytań nie daje użytecznego sygnału dla zróżnicowanych obciążeń.

Dlaczego canary na 1 procent prawdopodobnie kłamie

Oto awaria, która dotyka zespoły w pierwszych trzech miesiącach. Canary dostaje 5 procent ruchu i zawodzi w 20 procentach swoich żądań. Wskaźnik błędów dla całej usługi rośnie z 0,2 do około 1,2 procent. Próg alertu to 2 procent. Nic się nie uruchamia.

Monitoring zagregowany ukrywa awarie canary. Ta sama arytmetyka pojawia się w SRE Workbook: canary zawodzące w 20 procentach żądań na 5 procentach ruchu pokazuje tylko 1 procent błędów w skali całości. Metryki trzeba rozbić na populacje, canary kontra kontrola, inaczej sygnał znika w mianowniku.

Są jeszcze trzy pułapki warte znajomości:

• Porównania przed i po. Porównanie okna canary z poprzednią godziną myli zmianę z czasem. Sam ruch z dni roboczych i weekendu potrafi przykryć prawdziwą regresję. Porównuj z równoległą kontrolą.

• Wspólne zależności. Jeśli canary i kontrola uderzają w ten sam cache lub bazę, złe canary może pogorszyć obie grupy i porównanie nic nie pokaże. Sprawdź domeny awarii.

• Hałaśliwe metryki. Zużycie CPU to słaba bramka. Kody błędów i latencja odzwierciedlają to, co odczuwają użytkownicy. Workbook radzi uszeregować kandydatów według tego, jak dobrze pokazują problemy widoczne dla użytkownika, i zostawić kilka najlepszych, najwyżej około tuzina.

Metryki bramkujące wybierz przed wdrożeniem, nie w trakcie incydentu

Zacznij od swoich SLI. Jeśli usługa ma już SLI dostępności i SLI latencji, to są pierwsze dwie bramki. Zestaw startowy dla usługi obsługującej żądania może wyglądać tak:

• Wskaźnik błędów (5xx) canary kontra kontrola w oknie utrzymania

• p99 latencji canary kontra kontrola

• Sygnał nasycenia przypisywalny zmianie, na przykład wzrost pamięci na pod

• Jedna metryka bliska biznesowi, na przykład zakończenie zamówienia, jeśli da się ją wyizolować per grupa

Progi to miejsce, w którym zespoły tracą tygodnie. Ustawione zbyt ciasno, każde canary przerywa się na szumie, więc inżynierowie uczą się omijać bramkę. Ustawione zbyt luźno, złe wydanie przepływa bez przeszkód. Przeglądaj je według harmonogramu. Bramka, która nie przerwała niczego przez sześć miesięcy, jest albo doskonała, albo dekoracyjna, i warto sprawdzić, która z tych opcji zachodzi.

Pilnuj też, by interwał agregacji metryk nie był dłuższy niż okno canary. Rollup co 10 minut przy 5-minutowym canary zamazuje wszystko.

Canary w konfiguracji: jak wyglądają etapy w Argo Rollouts

Na Kubernetesie specyfikacja canary w Argo Rollouts opisuje sekwencję jako listę etapów. Oto skondensowana wersja w kształcie opisanym w dokumentacji:

strategy:
  canary:
    steps:
      - setWeight: 5
      - pause: { duration: 30m }
      - analysis:
          templates:
            - templateName: error-rate-vs-baseline
      - setWeight: 25
      - pause: { duration: 30m }
      - setWeight: 50
      - pause: {}

Dwa szczegóły z dokumentacji zasługują na uwagę. Bez routera ruchu wagę przybliża się liczbą podów, w najlepszym wysiłku: 10 replik przy 10 procentach to jeden pod canary i dziewięć stabilnych. To matematyka replik, nie matematyka żądań. Z kolei pause: {} bez czasu trwania czeka w nieskończoność, aż ktoś uruchomi kubectl argo rollouts promote. To ludzka bramka, którą można chcieć, ale nie trzeba.

Jeśli etap analizy zawiedzie, wdrożenie się przerywa. W tę część warto zainwestować.

Feature flagi to druga połowa bezpiecznego canary

Canary infrastrukturalne dzieli ruch według instancji lub poda. Canary oparte na flagach dzieli według użytkownika, konta lub dowolnego atrybutu, który da się wskazać. Odpowiadają na różne pytania. Pierwsze pyta, czy nowy build jest zdrowy. Drugie pyta, czy nowe zachowanie jest akceptowalne, i pozwala je wyłączyć bez ponownego wdrożenia.

Przy wdrożeniach sterowanych flagami narzędzie ma znaczenie. LaunchDarkly ma najdojrzalsze reguły targetowania i ślad audytu, i wygrywa szerokością ekosystemu. Jego cena w skali enterprise to typowa skarga liderów platform.

Statsig łączy eksperymenty z flagami, co pasuje zespołom, które chcą osądu opartego na metrykach na tej samej platformie. Słabiej pasuje, jeśli potrzebny jest tylko wyłącznik awaryjny.

Uczciwy kompromis: platforma flag daje wdrożenia procentowe, ale większość z nich sama nie czyta SLO. Ktoś nadal musi podpiąć metrykę do decyzji.

Potrzebujesz źródła porównawczego, które potrafi dzielić po wersji

Niezależnie od tego, co steruje wdrożeniem, werdykt pochodzi z telemetrii. Każda metryka potrzebuje etykiety wersji lub kohorty, a backend musi po niej odpytywać bez 10-minutowego opóźnienia.

Datadog robi to dobrze dzięki podziałom po tagach, a śledzenie wdrożeń koreluje wydania ze skokami błędów. Koszt przy wysokiej kardynalności to coś, co trzeba zamodelować, zanim otaguje się wszystko.

Grafana z Prometheus działa, jeśli już ją uruchamiasz i etykietujesz metryki numerem rewizji wdrożenia. Daje pełną kontrolę, a utrzymanie spoczywa na zespole.

Automatyzacja przerwania: skąd bierze się pomysł AI Pilot

Ręczna analiza canary słabo się skaluje. Przy dziesięciu wdrożeniach dziennie nikt nie wpatruje się w dashboard przez 30 minut przy każdym z nich, więc bramka cicho staje się „wyglądało dobrze”. Wzorzec, który się sprawdza, to zautomatyzowany sędzia: zdefiniuj SLO, zdefiniuj porównanie, a kontroler przerwie i cofnie wdrożenie, gdy canary spala budżet błędów szybciej niż kontrola.

To problem, który celuje AI Pilot upstreamapi: czyta sygnał SLO w trakcie wdrożenia i uruchamia auto-rollback, gdy wskaźnik błędów przekroczy ustawiony próg. Mierzy wskaźnik błędów i latencję względem stabilnej kohorty, nic więcej i nic mistycznego. Jeśli masz już szablony analizy Argo Rollouts z dobrym zapytaniem Prometheus, masz większość tej samej zdolności i warto to powiedzieć każdemu, kto sprzedaje magię. Hostowany pilot ma sens tam, gdzie stosy są niejednorodne i każdy zespół musiałby utrzymywać własne szablony analizy.

Częsty wzorzec awarii: zespoły automatyzują etap promocji i nigdy nie automatyzują przerwania. Potok, który umie tylko iść do przodu, to taśmociąg.

Co mierzyć, by wiedzieć, że proces canary działa

Program canary ma własne metryki. Śledź je przez kwartał:

• Wskaźnik przerwań canary: udział canary zatrzymanych przez bramkę. Zero oznacza, że bramka jest ślepa. Powyżej 20 do 30 procent zwykle oznacza chwiejne progi albo słabe testy przed mergem.

• Czas wykrycia na canary: minuty od pierwszego złego żądania do przerwania. To realne MTTD dla wydań.

• Regresje, które przeszły canary: incydenty wywiedzione z wydania, które przeszło bramkę. Każdy powinien zmienić jakąś bramkę.

• Średni czas wycofania: od decyzji o przerwaniu do 100 procent ruchu na stabilnej wersji.

Uruchamiaj tylko jeden canary naraz na usługę. Workbook zdecydowanie to zaleca, a powód jest praktyczny: dwie nakładające się zmiany uniemożliwiają atrybucję i nie wiadomo, która z nich zaszkodziła.

Od czego zacząć w tym tygodniu

Wybierz jedną bezstanową usługę z wystarczającym ruchem, by dać sygnał w 15 minut. Dodaj etykietę wersji do jej metryk błędów i latencji. Napisz jedno zapytanie porównawcze: canary kontra kontrola. Uruchom canary na 5 procent z ręczną promocją i zapisz, co byś wychwycił w ostatnich trzech incydentach.

Potem zadaj niewygodne pytanie: gdyby canary zawiodło o 02:00, czy cokolwiek by je zatrzymało bez człowieka czuwającego?