Go/no-go 6 czerwca 1944: z czego składa się decyzja o wdrożeniu

Desant w Normandii zaplanowano na 5 czerwca 1944. Rano 4 czerwca przesunięto go o dobę z powodu sztormu nad kanałem La Manche. Wcześnie rano 5 czerwca Eisenhower potwierdził termin 6 czerwca na podstawie prognozy głównego meteorologa, Jamesa Stagga, który przewidział krótkie okno lepszej pogody. Tego dnia w Normandii wylądowało z morza i z powietrza ponad 150 tysięcy żołnierzy.

Okno wyznaczyły ograniczenia

Datę wyznaczyły dwa warunki fizyczne. Desant powietrzny potrzebował księżyca blisko pełni, żeby w nocy widzieć strefy zrzutu. Marynarka i saperzy potrzebowali niskiej wody około świtu, żeby lądowanie zaczęło się przy rosnącej wodzie, póki zapory na plaży są odsłonięte. Oba warunki spełniało tylko kilka dni w miesiącu, w czerwcu 1944 były to 5, 6 i 7 czerwca. Następne dni z odpowiednim pływem wypadały między 18 a 20 czerwca, już bez księżyca.

Wdrożenia mają podobne okno i zwykle wyznacza je coś spoza zespołu: termin z umowy, wymóg regulatora, okres szczytowego ruchu, w którym nikt nie robi deployu, dostępność ludzi, którzy umieją zrobić rollback. Dlatego okno trzeba zapisać wcześnie, jako ograniczenie, razem z następnym oknem. Zdanie „jeśli nie zdążymy w czwartek, następny termin jest po freezie, 25-go” przyda się osobie decydującej właśnie w dniu decyzji.

Kryteria istniały przed prognozą

4 czerwca nikt z planistów nie zastanawiał się, czy pogoda wydaje się wystarczająco dobra. Limity wiatru, podstawy chmur, widoczności i stanu morza armia, marynarka i lotnictwo ustaliły z wyprzedzeniem, każde z własnych powodów. Meteorolodzy mieli powiedzieć, czy prognoza mieści się w tych limitach.

Kryteria ustalane rano w dniu wdrożenia łatwo nagiąć do terminu. Zdefiniuj je przy planowaniu zmiany i trzymaj obok niej, na przykład tak (format umowny, nie należy do żadnego konkretnego narzędzia):

release: payouts-2026-06
window:
  primary: 2026-06-18T07:00/10:00
  next: 2026-06-25T07:00/10:00
go_criteria:
  - ci_green_on_release_commit: true
  - migration_tested_on_prod_size_copy: true
  - migration_duration_max_minutes: 5
  - rollback_rehearsed: true
  - error_rate_baseline_known: true
abort_criteria:            # sprawdzane w trakcie canary
  - error_rate_above_baseline_pct: 50
  - p95_latency_above_ms: 800
  - failed_payment_jobs: 1
owner: jedna wskazana osoba

Blok abort_criteria jest tak samo ważny jak go_criteria. Przesunięcie z 4 czerwca to go_criteria w działaniu: warunki były poza limitami, więc odpowiedź brzmiała „nie”.

Kiedy pierwszy raz stawiałem produkcję własnego SaaS-a, warunki „go” spisałem przed pierwszym deployem: kopie poza serwerem z przećwiczonym odtworzeniem (zajęło 2 sekundy), restart policy, rotacja logów, TLS z monitorem i runbook kluczy. W CI siedziała zmienna DEPLOY_ENABLED, więc merge budował obraz, ale go nie wdrażał, dopóki wszystkie warunki nie były odhaczone. Sama podmiana dawała około sekundy przerwy. Przyjąłem to świadomie, bo nie było SLA, które uzasadniałoby pracę nad zero-downtime.

Blacksod Point i niemiecka prognoza

Niemieccy meteorolodzy widzieli ten sam sztorm i uznali, że sztormowa pogoda potrwa około dwóch tygodni i desant będzie niemożliwy. Z Atlantyku mieli mniej obserwacji niż alianci. Alianci mieli raporty ze statków meteorologicznych, samolotów i stacji na zachodnim krańcu Europy, w tym z latarni Blacksod Point w Irlandii, i z tych raportów wynikała przerwa między dwoma frontami. Niemieccy dowódcy działali zgodnie ze swoją prognozą. Rommel pojechał do domu pod Ulm na urodziny żony, które wypadały 6 czerwca, a część dowódców była w drodze na ćwiczenia sztabowe w Rennes.

Canary nie da się ocenić bez punktu odniesienia, więc przed deployem trzeba znać normalny poziom błędów i opóźnień dla endpointów, których dotyczy zmiana. Ryzykowne elementy trzeba zmierzyć bezpośrednio, na przykład czas migracji na kopii bazy wielkości produkcyjnej. To, że na stagingu poszło szybko, niewiele mówi o produkcji. Sygnały biznesowe powinny wisieć obok technicznych. Proces płatności może zwracać 200 i nie tworzyć żadnych zamówień.

Raz pomyliłem kolejność przy przenosinach n8n na nowy serwer. Kolejność była twarda: najpierw wyłączyć starą instancję (wyczyścić aktywne wersje workflowów i webhooki, zatrzymać), dopiero potem aktywować workflowy na nowej. Do tego kroku wycofanie nic nie kosztowało, bo stara instancja dalej pracowała. I właśnie tu się potknąłem. Zatrzymałem starą instancję, zanim rekord A naprawdę wskazywał nowy serwer, i przez kilka minut serwis zwracał 404. Od tamtej pory przed wyłączeniem źródła sprawdzam oba originy przez curl --resolve. Ten test omija DNS, więc to, dokąd wskazuje rekord A, trzeba sprawdzić osobno. Po przepięciu przetestowałem cały łańcuch: czat z odpowiedzią AI w 6,4 s, 8 aktywnych workflowów, 6 webhooków.

Sprzeczne prognozy wymagają jednego właściciela

Stagg nie dostawał jednej prognozy. Trzy zespoły (Met Office, Admiralicja i grupa z lotnictwa armii USA) pracowały różnymi metodami i w dniach przed desantem się nie zgadzały. Jego zadaniem było sprowadzić je do jednego stanowiska dla Eisenhowera, a Eisenhower miał zdecydować.

Sygnały przed wdrożeniem też potrafią się nie zgadzać. W procesie powinno być jasno zapisane, kto je zbiera i przedstawia oraz kto, z imienia i nazwiska, podejmuje decyzję. To nazwisko trafia do notatki z wdrożenia.

Czekanie też ma koszt

Alternatywą dla 6 czerwca było następne okno, między 18 a 20 czerwca. Od 19 do 22 czerwca nad kanałem przeszedł silny sztorm, który zniszczył sztuczny port Mulberry przy plaży Omaha. Gdyby desant przesunięto na to okno, trafiłby na najgorszą pogodę w miesiącu.

To wiedza po fakcie, 5 czerwca nikt nie mógł przewidzieć tego sztormu. Mimo to odłożenie wdrożenia ma własne ryzyko i trzeba je zapisać obok ryzyka wdrożenia. W oprogramowaniu opóźnienie zwykle oznacza większą paczkę zmian w kolejnym release, dłużej żyjące gałęzie, które odjeżdżają od main, i termin, który się zbliża, kiedy okno się zwęża.