Podsumowanie
19 stycznia 2026, między 14:02 a 14:28 UTC, mniej więcej dwie trzecie wszystkich prób logowania do panelu lub uwierzytelnienia przez API zakończyło się niepowodzeniem. Istniejące sesje były również losowo unieważniane. Działające instancje, ich sieć i ruch były nietknięte przez cały czas. Provisioning zatrzymał się na dwadzieścia sześć minut, a następnie się opróżnił; żadne zamówienie nie zostało utracone.
Harmonogram
Wszystkie czasy UTC, 19 stycznia 2026.
| Czas | Zdarzenie |
|---|---|
| 14:02 | Zastosowano zmianę schematu tokena sesji w panelu sterowania. Wdrożenie oznaczono jako konfigurację, więc trafiło do wszystkich sześciu węzłów panelu naraz. |
| 14:03 | Wskaźnik błędów logowania rośnie z bliskiego zera do sześćdziesięciu jeden procent. Automatyczne alerty mają okno dwuminutowe i jeszcze nie wyzwalają. |
| 14:06 | Alert wyzwala. On-call engineer jest powiadamiany. |
| 14:08 | Pierwsza osoba reagująca pojawia się online. Widzi wskaźnik błędów, brak wdrożenia w dzienniku zmian kodu i zaczyna sprawdzać bazę danych. |
| 14:14 | Drugi inżynier dołącza, sprawdza dziennik zmian konfiguracji zamiast dziennika kodu i znajduje wpis z 14:02. |
| 14:16 | Przyczyna zrozumiała: dwa węzły walidują tokeny za pomocą poprzedniego czytnika. |
| 14:19 | Rozpoczyna się rollback. |
| 14:24 | Tokeny są wydawane i walidowane poprawnie na wszystkich sześciu węzłach. Wskaźnik błędów spada do zera. |
| 14:28 | Kolejka zadań provisioning się opróżnia. Odzyskiwanie zakończone. |
| 15:10 | Strona statusu zaktualizowana. Czterdzieści dwie minuty po fakcie, co jest osobną awarią i jest omówione poniżej. |
Przyczyna źródłowa
Token sesji zyskał nowe pole. Writerzy natychmiast emitowali nowy format; czytnik na dwóch z sześciu węzłów panelu nie został zrestartowany i odrzucał wszystko, co zawierało nowe pole. Żądania są rozdzielane między wszystkie sześć węzłów, więc sesja utworzona na nowym węźle miała mniej więcej jedną na trzy szanse na walidację przez stary węzeł przy każdym żądaniu. Wynik wyglądał na losowy, dlatego pierwsze sześć minut diagnozy poszło na bazę danych, a nie na dziennik wdrożeń.
Głębsza przyczyna to reguła, którą napisaliśmy w 2023 roku. Zmiany dotyczące plików schematu, a nie kodu aplikacji, były klasyfikowane jako konfiguracja, a konfiguracja omijała etap canary, ponieważ była, cytuję, tylko wartościami. Ta reguła była rozsądna, gdy jedynymi plikami schematu były flagi funkcji. Nikt jej nie zrewidował, gdy definicja pliku schematu się rozszerzyła, a ta zmiana została poprawnie zaklasyfikowana według reguły, która po cichu stała się błędna.
To nie był błąd inżyniera, który ją zastosował. Klasyfikacja została wykonana dokładnie zgodnie z zapisem.
Promień rażenia
- Logowania do panelu: sześćdziesiąt jeden procent błędów przez dwadzieścia sześć minut.
- Tokeny API: ten sam wskaźnik błędów, to samo okno. Klucze idempotencji sprawiły, że ponowione tworzenie nie powielało się.
- Działające instancje: bez wpływu. Żadna utrata pakietów, żadne restarty, żaden wpływ na magazyn.
- Provisioning: wstrzymany, nie nieudany. Cztery zamówienia zakończone w tym oknie i wszystkie cztery ukończone do 14:28.
Co zmieniliśmy
- Etap canary jest teraz bezwarunkowy. Wszystko, co jest wdrażane, niezależnie od klasyfikacji, idzie do jednego węzła na pięć minut z syntetycznym ruchem, zanim pójdzie gdziekolwiek indziej. Zrobione 21 stycznia.
- Czytniki akceptują poprzedni format przez trzydzieści dni. Walidacja tokenów jest teraz jawnie wersjonowana z oknem nakładania, więc częściowo wdrożona zmiana degradowana jest do braku efektu. Zrobione 23 stycznia.
- Syntetyczne logowanie uruchamiane co piętnaście sekund z zewnątrz naszej sieci, w trzech regionach, i alarmuje przy drugim kolejnym niepowodzeniu, a nie po dwuminutowym oknie uśredniania. Zrobione 22 stycznia.
- Strona statusu publikuje automatycznie, gdy syntetyczne logowanie nie powiedzie się dwukrotnie, bez czekania na człowieka, który napisze zdanie. Ludzkie zdanie następuje. Zrobione 26 stycznia.
Czego nie zmieniliśmy i dlaczego
Nadal nie logujemy adresów IP klientów ani treści żądań dla ruchu panelu. Posiadanie ich pokazałoby rozkład jeden-na-trzy między węzłami natychmiast i prawdopodobnie zaoszczędziłoby dziewięć minut. Dziewięć minut nie jest warte trwałego rekordu o tym, skąd każdy klient się loguje. Tabela retencji na stronie logowania pozostaje bez zmian.
Nie przenieśliśmy sesji do współdzielonego sklepu między witrynami. Pojedynczy sklep sesji obejmujący wszystkie witryny uniknąłby problemu mieszanych czytników dzięki jednemu czytnikowi. Stworzyłby również dokładnie ten scentralizowany, zawsze gorący rejestr tego, kto jest połączony z czym, czego nie budowaliśmy przez sześć lat.
Nie dodaliśmy kanału ogłoszeń o awarii poza stroną statusu. Kilka osób zasugerowało media społecznościowe. Strona statusu jest jedyną rzeczą, którą prowadzimy, o której możemy obiecać, że jest dokładna, a dodanie drugiej powierzchni oznacza drugą powierzchnię, która się dezaktualizuje.
Kredyt
SLA obejmuje dostępność instancji. Instancje były dostępne przez wszystkie dwadzieścia sześć minut, więc zgodnie z umową nikt nie był nic winien. Przyznaliśmy jednodniowy kredyt każdemu kontu, które miało nieudane uwierzytelnienie w tym oknie, co wyniosło około trzech tysięcy stu euro, ponieważ spieranie się o rozróżnienie z ludźmi, którzy nie mogli dotrzeć do swoich serwerów, jest gorszym wykorzystaniem popołudnia wszystkich.