Baza zniknęła. Kopie milczały
Pomyłka administratora uruchomiła kryzys GitLaba. Powrót usługi ujawnił, dlaczego trzeba kontrolować także sam mechanizm kopii zapasowych.
31 stycznia 2017 roku GitLab.com utracił dane głównej bazy wskutek przypadkowego usunięcia. Awaria zamieniła pytanie o działanie serwisu w pytanie o to, co da się odzyskać. Repozytoria kodu nie zostały objęte tą utratą danych.
Zabezpieczenie też może zawieść
Według raportu automatyczne zrzuty bazy nie działały, a powiadomienia o błędach nie docierały. Do odtworzenia wykorzystano kopię przygotowaną wcześniej do testów. Części późniejszych zmian nie odzyskano.
Cisza nie jest potwierdzeniem
Wniosek NetOpiekuna: brak alarmu może oznaczać zarówno poprawną pracę, jak i niesprawne alarmowanie. Odbiorca raportu powinien wiedzieć, kiedy ostatnio powstała użyteczna kopia, a nie tylko czy pojawił się komunikat błędu.
Brak alarmu nie dowodzi, że kopia istnieje.
Sprawdzić cały łańcuch
Zalecamy mierzyć wiek ostatniej poprawnej kopii i potwierdzać zakończenie zadania niezależnie od jego uruchomienia. Przetestować dostarczenie kontrolnego alarmu do osoby odpowiedzialnej. Brak raportu w oczekiwanym terminie również powinien wymagać wyjaśnienia.
Próbne odtworzenie trzeba przeprowadzać poza produkcją, sprawdzając strukturę bazy i przykładowe operacje aplikacji. Sam rozmiar pliku nie potwierdza, że zawartość da się odczytać.
Pomyłka nie powinna mieć ostatniego słowa
Przed nieodwracalną operacją administrator potwierdza serwer, środowisko i zakres działania. Przy szczególnie ryzykownych zmianach warto wymagać sprawdzenia przez drugą osobę.
Firma powinna także uzgodnić dopuszczalną utratę ostatnich zmian. Kopia sprzed doby może być technicznie poprawna, a mimo to nie spełniać potrzeb zespołu pracującego na bieżących zamówieniach.
O tej historii
Opracowanie publicznego raportu wskazanego poniżej. Opis zdarzenia dotyczy wskazanego w nim okresu; zalecenia NetOpiekuna wyróżniono osobno. Nie jest to nasza realizacja ani opis obecnego stanu systemów organizacji.
Źródła: GitLab — Postmortem of database outage of January 31, 10 February 2017