Największe awarie IT w historii – co mogło je zapobiec?

CrowdStrike / Microsoft – lipiec 2024

Awaria CrowdStrike to prawdopodobnie największa jednorazowa awaria IT w historii pod względem liczby dotkniętych systemów. Co się stało?

Firma CrowdStrike, producent oprogramowania antywirusowego Falcon, wysłała wadliwą aktualizację pliku konfiguracyjnego (tzw. "channel file") do agentów na urządzeniach klientów. Plik zawierał błąd logiczny powodujący, że sterownik kernelowy wpadał w pętlę i crashował system – słynny niebieski ekran śmierci (BSOD).

Efekty:

• 8,5 miliona komputerów z Windows zablokowanych
• Odwołane tysiące lotów na całym świecie
• Szpitale przechodzące na procedury papierowe
• Banki i systemy płatności niedostępne przez wiele godzin
• Szacowane straty: ponad 10 miliardów dolarów

Co mogło temu zapobiec? Stopniowe wdrażanie aktualizacji (canary deployment) – wysyłanie nowej wersji najpierw do 1%, potem 10% urządzeń zamiast do wszystkich jednocześnie. Testy w środowisku izolowanym przed produkcją. Ograniczony dostęp do jądra systemu operacyjnego – Microsoft i Apple od lat ograniczają możliwość pisania sterowników kernelowych przez zewnętrznych dostawców właśnie z tego powodu.

Amazon Web Services us-east-1 – grudzień 2021

Centrum danych AWS us-east-1 (Północna Wirginia) to największy węzeł chmurowy na świecie. Przez wiele godzin 7 grudnia 2021 roku był niedostępny z powodu błędu w sieci wewnętrznej przy automatycznym skalowaniu. Skala konsekwencji była zdumiewająca.

Co przestało działać:

• Amazon.com i sklepy Amazon
• Netflix, Disney+, Slack, Twitch
• Wiele systemów Roomba (odkurzacze nie mogły się zaktualizować)
• Aplikacje dla firm działające w chmurze AWS na wschodnim wybrzeżu USA

Lekcja: Uzależnienie od jednego regionu lub jednego dostawcy chmury to ryzyko. Multi-region, multi-cloud lub hybrid cloud to nie fanaberia, ale realna strategia biznesowa dla firm, dla których ciągłość działania jest kluczowa.

Facebook / Meta – październik 2021

6 godzin całkowitej niedostępności Facebooka, Instagrama i WhatsAppa. Przyczyna: błędna zmiana konfiguracji w routerach szkieletowych firmy podczas rutynowej konserwacji usunęła trasy BGP (Border Gateway Protocol). Serwery DNS Facebooka przestały być widoczne w internecie.

Ironiczny szczegół: pracownicy Facebooka nie mogli wejść do własnych biurowców, bo systemy kontroli dostępu do drzwi też działały przez te serwery. Inżynierowie musieli fizycznie pojechać do centrum danych, żeby naprawić usterki ręcznie.

Co mogło temu zapobiec? Niezależny system kontroli dostępu fizycznego. Lepsze testowanie zmian konfiguracji sieci szkieletowej (change management). Możliwość awaryjnego dostępu do systemów zarządzania siecią spoza tej sieci.

Knight Capital Group – sierpień 2012

Jedna z najdroższych pomyłek programistycznych w historii. Firma handlująca algorytmicznie wdrożyła wadliwy kod na produkcję nie wyłączając starego, nieużywanego kodu ("dead code"). Przez 45 minut system handlował z prędkością 40 milionów transakcji – i tracił pieniądze na każdej.

Wynik: strata 440 milionów dolarów w 45 minut. Knight Capital zbankrutowała kilka miesięcy później.

Lekcja: Automatyczne wyłączniki (circuit breakers) w systemach handlowych. Code review i testy przed wdrożeniem produkcyjnym. Monitoring w czasie rzeczywistym z alertami progowymi. Możliwość natychmiastowego rollbacku.

WannaCry – maj 2017

WannaCry nie był awarią techniczną – był cyberatakiem. Ale skala jest tak imponująca, że nie może go zabraknąć na tej liście. Ransomware rozprzestrzenił się przez lukę EternalBlue w protokole SMB systemu Windows, zainfekował ponad 200 000 systemów w 150 krajach w ciągu 4 dni.

Szczególnie dotknięty był brytyjski NHS (Narodowa Służba Zdrowia) – szpitale odwoływały operacje, lekarze nie mieli dostępu do historii pacjentów.

Ironia: Patch naprawiający lukę EternalBlue był dostępny od dwóch miesięcy (MS17-010). Systemy, które nie zostały zaktualizowane – padły. To klasyczny przykład, gdzie regularne aktualizacje bezpieczeństwa dosłownie ratują życie.

Przełącznik na Marsie – 1998

Mars Climate Orbiter kosztował 327 milionów dolarów. Spłonął w atmosferze Marsa 23 września 1999 roku z powodu... jednostek miar. Jeden podsystem oprogramowania podawał dane w jednostkach imperialnych (funt-sekunda), drugi oczekiwał jednostek SI (niuton-sekunda). Nikt tego nie sprawdził.

Lekcja dla programistów: Walidacja jednostek i interfejsów między systemami. Code review przez zewnętrzny zespół. To jeden z najdroższych błędów typograficznych w historii.

Wspólny mianownik wszystkich awarii

Co z tego wynika dla Twojej firmy?

Żadna z tych katastrof nie była nieuchronna. Każda była wynikiem zaniedbania sprawdzonych praktyk, pośpiechu lub zbyt dużego uzależnienia od jednego punktu awarii (Single Point of Failure). Dla małej firmy nie chodzi o wdrażanie enterprise disaster recovery za miliony złotych – chodzi o podstawy:

• Regularne aktualizacje systemów i oprogramowania
• Backup danych z kopią poza siecią lokalną
• Testowanie odtwarzania danych co kwartał
• Plan działania na wypadek awarii (choćby jedno zdanie: "kto dzwoni do kogo i co robimy")
• Monitoring krytycznych systemów z alertami SMS/e-mail

Każda firma, która wdrożyła te pięć punktów, jest w znacznie lepszej pozycji niż te, które padły w opisanych katastrofach.