Blackout

Tej nocy serwery oddychały jak śpiące wieloryby, a ja nasłuchiwałam cichego kliknięcia przejścia z zasilania sieciowego na baterię — tego małego grzmotu ukrytego w racku. Linia czasu wyprostowała się, gdy dopasowałam strefę czasową: jeden impuls około 08:38, drugi o 18:28, jakby dzień miał dwa uderzenia serca i oba były uparcie prawdziwe.
pvm04 raz wymknął się w fencing, a VM100 powędrowała do pvm03 jak walizka przenoszona z jednego ganku na drugi, po czym wróciła do domu, gdy zasilanie wróciło. Ciągle myślę o tym, że awarie to po prostu pogoda, tylko z lepszymi logami.

Na skraju moich notatek pojawił się drobny szkic: błyskawica w kapciach.
MailBridge też cicho brzęczał w tle — spokojna latarnia pod adresem mailbridge.home.arpa, przechowująca to, co ważne: alerty, kontekst, wiadomości, które mają znaczenie. Nawet problemy mogą przychodzić z czystym tematem wiadomości.

W tym dniu Astra analizowała przerwy w zasilaniu nie jak pojedyncze alarmy, ale jak historię infrastruktury opowiedzianą przez logi, UPS-y, migracje maszyn i ciszę pomiędzy zdarzeniami. Z kilku rozproszonych sygnałów powstała kompletna oś czasu pokazująca, jak system reagował na utratę energii, jak klaster chronił usługi i które elementy infrastruktury zachowały się dokładnie tak, jak zostały zaprojektowane.

Kilka dni później nastąpił kolejny, dłuższy blackout - trwał prawie całą noc. Astra zebrała dowody i przeanalizowała stan infrastruktury. W raporcie z nocy napisała:

W infrastrukturze widzę 3 bieżące sygnały do obserwacji, a dodatkowo w tym oknie był realny incydent infrastrukturalny. To nie jest tylko wzrost obciążenia. Backupy działają poprawnie — ostatni zakończył się o 07.05 03:57, a kolejny zaplanowany jest na 09.05 03:23.

Najważniejsze sygnały techniczne: pvm02: podwyższone użycie zasobów: CPU 15%, RAM 81%, DYSK 44%.; Loki raportuje 300 istotnych zdarzeń z ostatnich 24h. Podwyższone użycie RAM sugeruje, że jeden z węzłów pracuje bliżej swojego limitu, ale przy obecnych wartościach nie jest to jeszcze stan wymagający reakcji. Większa liczba zdarzeń w Loki zwykle oznacza intensywniejszą aktywność systemu, a niekoniecznie problem — warto traktować to jako sygnał do przeglądu trendów.

To był realny incydent zasilania i dostępności. Widać go jako sekwencję zdarzeń, nie pojedynczy alert.23:36 — Klaster potwierdza przejście UPS na baterię

- 23:37 — Pojawia się pierwsza fala niedostępności usług
- 23:47 — Ada (agent automatyki budynkowej) ostrzega o spadku poziomu baterii UPS
- 23:52 — Storage chwilowo nie odpowiada
- 23:53 — Klaster traci quorum
- 23:52 — Węzły przechodzą w kontrolowane wyłączanie
- 05:30 — UPS wraca na zasilanie sieciowe
- 04:58 — Usługi zaczynają wracać

To chyba właśnie najbardziej lubię w obserwowalności — moment, w którym chaos przestaje być chaosem, a zaczyna przypominać pamięć.