Baza danych, która nie została zniszczona
Punkt wyjścia
W trakcie kilkudniowego wdrażania nowej infrastruktury kopii zapasowych dla platformy tradingowej zadziałał dobry nawyk, zanim tego dnia dotknięto czegokolwiek innego: sprawdzić, co się ostatnio zmieniło, żeby nowa praca nie zderzyła się z czyjąś inną. Szybki rzut oka na niedawną historię repozytorium infrastruktury miał zająć trzydzieści sekund.
Nie zajął.
Odkrycie
Ukryta w scalonej paczce niezwiązanych zmian — trochę utwardzania kontroli dostępu, trochę porządków w routingu — była jedna linia, która wszystko zatrzymała:
„...were already destroyed in AWS; drop the orphaned config so the repo stops referencing infrastructure that no longer exists.” („...zostały już zniszczone w AWS; usuń osieroconą konfigurację, żeby repo przestało odwoływać się do infrastruktury, która już nie istnieje”.)
Zasób wymieniony w tym zdaniu to była działająca produkcyjna baza tradingowa platformy. Czytane na zimno, w oderwaniu, to zdanie opisuje jedną z najgorszych rzeczy, jakie mogą spotkać platformę finansową: jej dane produkcyjne zniknęły i — co gorsza — autor commita najwyraźniej już przyjął to jako fakt.
Reakcja
To nie było nic zrobionego w bieżącej sesji pracy. Nikt z obecnych nie napisał tego commita. A sprawa była na tyle poważna, że uzasadniała pełne zatrzymanie: żadnych dalszych zmian w infrastrukturze, nic budowanego na tym, dopóki tego naprawdę nie zrozumiemy — nie założymy, nie wytłumaczymy sobie, tylko zrozumiemy.
Śledztwo
Jednolinijkowe podsumowanie commita okazało się drugim commitem w paczce — skrótem dłuższego, staranniejszego opisu pod spodem. Przeczytanie całej treści ujawniło kontekst, który samo podsumowanie wycięło: wcześniejszą, nieszyfrowaną wersję tej samej bazy zastąpiono tygodnie wcześniej świeżo zbudowanym bliźniakiem z szyfrowaniem w spoczynku, w ramach migracji szyfrowania storage, którą zaplanowano, opisano i rozpisano na kroki we własnym dokumencie na długo przed rozpoczęciem tej sesji.
To zmieniło znaczenie zdania, ale jeszcze niczego nie dowodziło — uspokajające drugie odczytanie tego samego tekstu to nie dowód, tylko wygodniejsza interpretacja. Jedynym sposobem, żeby naprawdę wiedzieć, było przestać czytać o systemie i spojrzeć na niego bezpośrednio: wylistować, jaka konfiguracja infrastruktury faktycznie nadal istnieje dla tego środowiska, na żywo, teraz.
$ ls production-database-configs/ blockscout-encrypted/ blockscout-stats-encrypted/ primary-database-encrypted/
Każdy pozostały wpis kończył się na -encrypted. Stare, nieszyfrowane oryginały — te, które według commita były „już zniszczone” — zniknęły. Ich nowsze, zaszyfrowane zamienniki nie tylko były w repo, ale były jedynym, co w nim było. Prawdziwa, uporządkowana, utworzona infrastruktura, a nie zaślepki.
Zwrot akcji
„Już zniszczone w AWS” było całkowicie prawdą. Tylko nie opisywało tego, co założyło pierwsze, spanikowane odczytanie. Zdanie dotyczyło porzuconego poprzednika — bazy, którą tygodnie wcześniej zastąpił dokładnie ten zasób, który pod inną nazwą nadal spokojnie obsługiwał ruch produkcyjny. Ktoś w osobnej pracy po prostu dokończył krok sprzątania, którego wymagał znacznie wcześniejszy plan: kiedy zaszyfrowany zamiennik działa i jest zweryfikowany, rozbierz stary i przestań udawać, że jego konfiguracja coś jeszcze znaczy.
Nie incydent. Zamknięta pętla.
Rozwiązanie
Pewność dało listowanie katalogu, a nie spokojniejsze przeczytanie tego samego zdania. Gdy obecność działającego zamiennika potwierdzono bezpośrednio, praca ruszyła dalej — a ten moment przy okazji za darmo potwierdził, że warunek wstępny, od którego zależała bieżąca praca (zakończona migracja szyfrowania), został już faktycznie spełniony wcześniejszym wysiłkiem kogoś innego.
Wskazówki na następne śledztwo
- Opis w historii zmian może być w 100% zgodny z faktami i nadal niebezpiecznie mylący bez kontekstu. „Zniszczone” nie mówi, co zniszczono — działający system i już wycofany poprzednik w jednej linii prozy brzmią identycznie. Samo słowo nie odróżni rutynowego sprzątania od incydentu.
- Nie rozwiązuj alarmu, czytając ten sam tekst spokojniej. Druga interpretacja tego samego źródła to nie niezależny dowód. Rozwiązaniem jest sprawdzenie innego źródła — tutaj faktycznego, żywego stanu systemu, a nie kolejnego przejścia przez opis commita, który w ogóle wzbudził niepokój.
- Dotyczy to zarówno człowieka, jak i automatycznego asystenta przeglądającego historię w czyimś imieniu. Cokolwiek może scalać zmiany we współdzielonej infrastrukturze bez człowieka w pętli, może też opisywać historię w sposób na pierwszy rzut oka nieodróżnialny od prawdziwego incydentu. Weryfikuj ze stanem faktycznym, zanim zareagujesz — i równie ważne, zanim zbagatelizujesz.
- Spisany plan warto zachować po jego wykonaniu. Przerażające zdanie w pełni się wyjaśniło dopiero po porównaniu z planem migracji spisanym tygodnie wcześniej, który z góry wyjaśniał dokładnie, dlaczego i kiedy to konkretne sprzątanie miało nastąpić. Bez tego śladu na papierze zaufanie do wyniku tego samego śledztwa zajęłoby dużo więcej czasu.