4 dobre praktyki jako wnioski z błędów, które wpłynęły na niedostępność usług Atlassian

W zeszłym miesiącu firma Atlassian doświadczyła poważnego incydentu, który wpłynął na dostępność usług dla ponad 400 firm spośród niemal 200 tys. klientów dostawcy wyspecjalizowanego m.in. w rozwiązaniach do zarządzania projektami programistycznymi. Całkowite przywrócenie dostępności trwało dwa tygodnie. Po usunięciu skutków incydentu producent przygotował szczegółową analizę popełnionych błędów. Stanowi ona zbiór dobrych praktyk pomocnych w zapobieganiu analogicznym sytuacjom w wielu środowiskach IT.

Przeprowadzone dochodzenie pokazało, że niedostępność infrastruktury firmy Atlassian była wynikiem serii błędów wewnętrznych popełnionych przez pracowników, a nie ataku hakerów czy działania złośliwego oprogramowania. Wpłynęła jednak na działanie popularnych rozwiązań tego producenta, w tym oprogramowania Jira, Confluence, Atlassian Access, Opsgenie i Statuspage. Jej skutki odczuło ponad 400 firm spośród niemal 200 tys. klientów. Przez całe dwa tygodnie tylko kilku klientów firmy Atlassian odczuwało problemy związane z tym incydentem, kilkaset firm korzystających z rozwiązań tego dostawcy odnotowało kilkuminutową niedostępność usług, a zdecydowana większość klientów nie odnotowała żadnych przestojów.

Szczegółowe wyjaśnienie przyczyn oraz przebiegu i powiązań między zdarzeniami, które ostatecznie doprowadziły do odczuwalnej dla grupy klientów przerwy w dostępności usług zamieszczono na blogu firmy Atlassian.

Wartościowe podsumowanie wniosków z niedostępności sieci firmy Atlassian znalazło się też na łamach serwisu NetworkWorld. Czytamy w nim, że pierwotne źródła incydentu sięgają podjętej w 2021 decyzji o usunięciu ze środowisk klientów aplikacji “Insight – Asset Management” dostępnej wcześniej dla oprogramowania Jira. Funkcjonalność tej samodzielnej aplikacji została bowiem zintegrowana z rozwiązaniem Jira Service Management.

Fatalnym błędem okazało się wyznaczenie w tym celu dwóch zespołów z odrębnymi, chociaż podobnymi obowiązkami. Jeden zespół odpowiadał za zlecenie żądania usunięcia aplikacji z konkretnego środowiska, a drugi odpowiadał za jego realizację oraz ocenę, w jaki sposób należy tą zmianę przeprowadzić. Oba zespoły bazowały też na opracowanych wcześniej procedurach. Co więcej, jak się okazało, zespołom tym zabrakło spójnych reguł komunikacji – pierwszy zespół używał identyfikatora aplikacji do określenia oprogramowania, które ma zostać usunięte, drugi zaś zespół założył, że chodzi o identyfikator całej instancji chmury, w której znajdowały się aplikacje klientów. Z kolei interfejs API wykorzystywany do realizacji zleceń usunięcia przestarzałej aplikacji akceptował i przetwarzał zarówno ID aplikacji, jak i całego środowiska klienta. W efekcie, jeśli podane ID dotyczyło aplikacji – była ona usuwana, jeżeli jednak dotyczyło całego środowiska klienta – ono również było kasowane.

Wskutek niezrozumienia pomiędzy zespołami z platformy Atlassian w dniu 5 kwietnia 2022 roku omyłkowo usunięte zostało niemal 900 środowisk klienta, z czego niemal 200 wykorzystywano jedynie na użytek wewnętrzny. Jak deklarują przedstawiciele firmy Atlassian, spora część usuniętych środowisk była nieaktywna lub udostępniana nieodpłatnie. W efekcie błędna organizacja procesu usuwania przestarzałej aplikacji wpłynęła na środowiska wykorzystywane przez ok. 400 klientów komercyjnych. Co ważne, wraz z usunięciem danych części klientów, utracili oni dostęp do systemu wsparcia technicznego, firma straciła także dane kontaktowe do administratorów korzystających z rozwiązań Atlassian po stronie klientów. Komunikację awaryjną próbowano więc prowadzić z osobami wskazanymi jako kontakt w celach rozliczeniowych lub technicznych, dane te w wielu wypadkach okazały się jednak nieaktualne. Ostatecznie podjęto starania o jak najszybsze przywrócenie usuniętych środowisk, co – jak twierdzą przedstawiciele Atlassian – ze względu na złożoność architektury całego środowiska było niemożliwe do przeprowadzenia w krótkim czasie. Pierwszy zestaw środowisk klientów został przywrócony po trzech dniach, zaś dostępność wszystkich usług przywrócono 18 kwietnia, a więc po dwóch tygodniach. Firma Atlassian nie osiągnęła więc zakładanego czasu przywracania danych, ale zdołała osiągnąć cele dotyczące punktów przywracania – odzyskano bowiem dane aktualne na kilka minut przed zaistnieniem incydentu.

Przedstawiciele kierownictwa Atlassian deklarują, że aby uniknąć podobnych sytuacji w przyszłości, w strukturach firmy wprowadzony zostanie szereg zmian organizacyjnych. Będą to m.in. powszechne wprowadzenie mechanizmów tymczasowego, miękkiego usuwania (soft delete) danych klientów we wszystkich środowiskach, rozbudowa, usprawnienie i zautomatyzowanie systemu awaryjnego przywracania danych, zmiana procesu zarządzania incydentami o dużej skali, a także – opracowanie i wdrożenie reguł komunikacji awaryjnej, w tym wczesne informowanie o poważnych incydentach za pośrednictwem wielu kanałów.

Jak nie doprowadzić do takiej sytuacji w przyszłości?

Uniwersalne wnioski pozwalające eliminować tego typu sytuacje we wszystkich środowiskach IT formuuje David Strom na łamach wspomnianego artykułu NetworkWorld. Według niego 4 kluczowe wnioski pozwalające uniknąć analogicznych sytuacji to:

1. Usprawnienie komunikacji między zespołami i w zespołach
Zespoły, które żądają zmian w sieci i zespół, który je faktycznie wdraża, powinny być jednym i tym samym zespołem. Jeśli rozwiązanie takie nie jest możliwe, należy wdrożyć solidne narzędzia komunikacji, aby zapewnić, że oba zespoły działają w sposób zsynchronizowany, używają tego samego języka i przestrzegają tych samych procedur.

2. Szczególna troska o dane klientów
Dane klientów korzystających z oferowanych usług powinny być aktualne i dokładne, a ich kopie zapasowe przechowywane w wielu oddzielnych miejscach. Całe środowisko powinno być zaś przygotowane na wypadek punktowej, ale także krytycznej awarii, okresowo kontrolowane i wyposażone w sprawne rozwiązania pozwalające przywrócić dane oraz dostępność najważniejszych usług.

3. Testowanie nawet najbardziej złożonych scenariuszy odzyskiwania po awarii
Należy upewnić się, że programy odzyskiwania, instrukcje i procedury awaryjne – także w wymiarze komunikacyjnym – spełniają określone cele. Co więcej, należy testować scenariusze obejmujące wszystkie rozmiary infrastruktury klienta, ze szczególnym uwzględnieniem i przewidywaniem reakcji na incydenty na większą skalę oraz zrozumieniem złożonych zależności pomiędzy usługami i aplikacjami wykorzystywanymi przez klientów. Zweryfikować należy także funkcjonowanie narzędzi i rozwiązań automatyzujących newralgiczne operacje na danych klientów, a w razie potrzeby uzupełnić je o funkcje ostrzegające o ewentualnych skutkach podejmowanych działań.

4. Zabezpieczenie danych konfiguracjnych
Na koniec należy wspomnieć o problemie usuwania danych, który w przypadku Atlassian zapoczątkował całą awarię. Chodzi o nadmiernie proste usuwanie całych środowisk czy witryn. W analizowanym przypadku zabrakło m.in. ostrzeżenia o skutkach podejmowanych decyzji, a także funkcji tymczasowego wycofania środowiska oraz maskowania danych zamiast ich natychmiastowego usunięcia.