Jak to zwykle bywa ze zdarzeniami losowymi przychodzą one najczęściej nieoczekiwanie, a w każdym razie na tyle szybko, że jeżeli nie posiadamy odpowiednich planów na takie sytuacje może się okazać, iż nie jesteśmy w stanie odpowiednio szybko na nie zareagować. Przykładem takiej sytuacji była tegoroczna powódź, która w przypadku Onet.pl postawiła wiele osób na nogi i na pewno miała rangę sytuacji kryzysowej.

Po obfitych opadach deszczu zagrożenie powodziowe stało się realne dla jednego z naszych centrów danych, które w przypadku przerwania wałów przeciwpowodziowych mogłoby zostać odcięte od świata i/lub pozbawione zasilania, a w najgorszym przypadku zalane. W związku z tym, zaraz po pojawieniu się zagrożenia zdecydowaliśmy się żeby do czasu odwołania zagrożenia powodziowego utrzymywać w zagrożonym DC zwiększony stan osobowy, oraz postawić w stan gotowości liczną grupę administratorów oraz developerów, którzy mogą być potrzebni gdyby doszło do przerwania wałów. W międzyczasie sytuacja powodziowa zmieniała się z każdą chwilą – niestety na gorsze. Następnym krokiem, jaki został podjęty w związku z zagrożeniem było przepięcie wszystkich usług i systemów działających produkcyjnie na infrastrukturę zapasową w innych centrach danych. Decyzja była trudna, ponieważ architektura części z przepinanych systemów powodowała, że przepięcie możliwe było „w jedną stronę” a w każdym razie powrót z danym systemem z powrotem do lokalizacji początkowej wiązałby się z dużym nakładem pracy.

Niestety niekorzystne przewidywania się sprawdziły i Wisła przerwała wały przeciwpowodziowe. Woda zaczęła zalewać kolejne tereny i zbliżyła się do data center a jej poziom stale się podnosił. Bardzo realna stała się możliwość wyłączenia zasilania serwerowni. W tej sytuacji zdecydowaliśmy się na wyłączenie core’owych macierzy dyskowych i serwerów, ponieważ nagła utrata zasilania mogła doprowadzić do uszkodzenia danych lub samych urządzeń. Jako że poziom wody cały czas się zwiększał kolejnym krokiem był demontaż wyłączonych urządzeń (głownie macierzy dyskowych) i przeniesienie ich na wyższe kondygnacje budynku żeby zabezpieczyć się przed utratą danych w przypadku zalania data center. W międzyczasie poziom wody wokół data center podniósł się na tyle, że zostało ono odcięte od świata wraz z całym zespołem, który tam pracował. W tej sytuacji urządzenia zeszły na dalszy plan a problemem stała się ewakuacja ludzi z podtopionego budynku. Na szczęście po kilku godzinach wyrwa w wale przeciwpowodziowym została zatamowana i poziom wody zaczął opadać. W końcu opadł na tyle, że ludzie mogli wydostać się z budynku. Sytuacja została opanowana a po tym jak poziom wody w Wiśle opadł do bezpiecznego poziomu zaczęło się wielkie sprzątanie i sukcesywny powrót z usługami do pierwotnego data center.

Reasumując cała akcja spowodowała wiele dodatkowej pracy i nieprzespane noce dla wielu osób, ale udało się „uratować” zarówno urządzenia jak i kontent, który się na nich znajdował.
Ten przypadek pokazuje, że warto odrobić lekcję polegającą na przygotowaniu odpowiednich planów na takie sytuacje jak utrata jednego z centrów danych, nawet jeżeli jest to sytuacja bardzo mało prawdopodobna. Oczywiście żyjemy w realnym świecie i zwykle nie mamy aż tak komfortowej sytuacji, że cała nasza infrastruktura jest podwojona i połowa urządzeń czeka tylko w zapasowej lokalizacji żeby się na nie przełączyć. Dlatego też trzeba sobie na etapie przygotowywania planów BCP (Business Continuity Planning) powiedzieć wyraźnie dla których usług posiadamy failover a dla których nie. Następnie tą świadomość muszą mieć też biznesowi właściciele usług i systemów żebyśmy w razie sytuacji awaryjnej nie zostali zasypani pytaniami „dlaczego moja usługa nie działa?”. Dodatkowo biznes mając tą świadomość może sam zdecydować czy przeznaczyć dodatkowe nakłady finansowe na podniesienie poziomu redundancji własnych usług.

I na koniec jeszcze jedna ważna uwaga: choćbyśmy mieli najlepsze i najbardziej szczegółowe plany są one niewiele warte, jeżeli nie są przetestowane. Tylko regularne testy zapewnią nas, że plan jest realny i wykonalny, oraz że żadne zmiany, które wykonaliśmy w infrastrukturze nie spowodowały, że stał się on nieaktualny. W tak szybkozmiennym środowisku jak w Onet.pl jest to duże wyzwanie, ale jak pokazał nam przykład powodzi warto to robić żeby spać spokojniej. W każdym razie u nas zadziałało.

Kilka zdjęć z akcji ewakuacyjnej możecie oglądnąć w albumie niżej:

Marcin Kluczewski
Kierownik Zespołu Administratorów Drugiej Linii Wsparcia