Chociaż minęły już ponad 3 miesiące od pamiętnego pożaru w serwerowni OVH w Strasbourgu, w której mieliśmy znaczną część naszych zasobów oraz zasobów klientów, nadal odczuwamy dumę i radość z faktu, że nawet tak wielka awaria nie zdołała “przewrócić” naszej infrastruktury, a żadna z kluczowych usługi nie została zatrzymana.

Incydent z punktu naszego widzenia

Obudziłem się parę minut po 5 rano i spojrzałem na telefon - spokojnie. Jeszcze wtedy nie wiedziałem, że nasz administrator Michał jest “na nogach” od 2:30, sprawdzając działanie poszczególnych aplikacji i wprowadzając niezbędne poprawki. Wszedłem na komunikator zespołowy, później na Twittera i oczom nie wierzyłem. Następnie sprawdziłem wyrywkowo aplikacje, które były hostowane w Strasburgu i pomyślałem co jest do cholery? W mediach piszą o wielkiej awarii, a nam wszystko działa jak gdyby nigdy nic… W systemie do monitorowania produkcji operatorzy rejestrują kolejne paczki wyrobów gotowych, w systemie transportowym wózkowi dowożą komponenty na linie produkcyjne, mechanicy w aplikacji wspierającej utrzymanie ruchu obsługują zlecenia z działu produkcji. To jak w końcu? Jest awaria w OVH czy nie ma?

Otóż jest i to bardzo poważna. Szybki call do Michała i wszystko staje się jasne. W kilka minut po tym jak serwery stają się niedostępne, Michał otrzymuje serię wiadomości z systemu monitoringu autorstwa Ruby Logic, sprawdza newsy i podejmuje decyzję o przełączeniu aplikacji na serwery zapasowe. Serwery, które przez 4 lata czekały “bezczynnie” na 10 marca 2021r. Cała operacja trwa kilkanaście minut i jest niezauważalna dla większości użytkowników.

Stabilna infrastruktura

Na te kilkanaście krytycznych minut złożyły się miesiące, jeśli nie lata, przygotowań oraz polityka ciągłej poprawy procesów i przewidywania sytuacji takich jak ta.

Podobno ludzi można podzielić na 2 grupy: tych co robią backupy i tych co będą robić backupy. W Ruby Logic nie tylko zaliczamy się do tej pierwszej grupy, ale także podejmujemy dodatkowe działania, żebyśmy oraz nasi klienci mogli spać spokojnie.

Od zawsze stosowana jest zasada geograficznego rozdzielenia kluczowych, z punktu widzenia danych, elementów infrastruktury. Serwer produkcyjny znajduje się w innym kraju niż serwer zapasowy, a kopia zapasowa danych jeszcze w innym kraju. Dzięki zastosowaniu takiego podejścia zawsze jesteśmy gotowi wypełnić parametry SLA oferowane klientom. W przypadku utraty serwera produkcyjnego (np. pożar serwerowni) jego rolę przejmuje serwer zapasowy hostowany w data center w inny kraju. W przypadku utraty obu serwerów, produkcyjnego i zapasowego, dane przechowywane w innym kraju są nadal bezpieczne i można na ich podstawie przywrócić działanie aplikacji. Dodatkowo dla klientów, którzy oczekują rozwiązań HA (ang. High Availability) oferujemy strukturę z load balancerem i kilkoma node’ami działającymi równolegle.

Całość jest objęta systemem monitoringu, który spina pod sobą oprogramowanie komercyjne takie jak Rollbar i autorskie skrypty czy mikroserwisy dopasowane do specyfiki rozwiązań Ruby Logic.

Chociaż, jak pewnie się domyślasz, jesteśmy grupą geeków zakochanych w rozwiązaniach IT, mamy świadomość, że nic nie zastąpi człowieka, a każdy automat może przestać działać w najgorszym możliwym momencie. Ostatnim klockiem w układance tworzącej stabilną infrastrukturę jest interwencja człowieka. Raz na tydzień przeprowadzany jest tzw. weekly check, w ramach którego sprawdzane są wszystkie mechanizmy i automaty, a raczej rezultat ich działania. “Czy wszystkie backupy odkładają się na odrębnym zasobie?”, “Czy wszystkie instancje zapasowe działają?”, “Czy wszystkie certyfikaty SSL są ważne?” to tylko niektóre pytania z checklisty, na które musi udzielić odpowiedzi osoba przeprowadzająca audyt.

Szybkie działania naprawcze

Ranek po awarii. Wszystko działa i niby nic złego się nie stało. Biorę telefon i dzwonię do klientów z informacją/pytaniem/przeprosinami i tu kolejne zaskoczenie - nikt nie zauważył, że jego/jej system właśnie przeżył największą awarię od chwili uruchomienia. Wygląda na to, że wyszliśmy z tego pożaru “o własnych nogach”. Teraz jednak trzeba przejść do szacowania rzeczywistych strat.

Szybka zmiana priorytetów na dzisiaj i większość zespołu zostaje zaangażowana w analizę strat i inwentaryzację zasobów. W końcu straciliśmy 2 z głównych serwerów produkcyjnych i działamy na zapasowych. Czym prędzej należy przywrócić pełną infrastukturę, a mając w głowie, że to co się stało w Strasburgu mogło być atakiem na OVH, trzeba to zrobić szybko.

Nie mając nadziei na odzyskanie czegokolwiek ze zgliszczy i nie czekając na oficjalną informację z OVH kupujemy nowe serwery i przenosimy się do nowego data center. Chcąc uniknąć lekarstwa gorszego od choroby proces jest przeprowadzany etapowo ze sprawdzeniem dostępności aplikacji po każdym etapie. Całe przenosiny zajęły nam 4 dni, a najbardziej krytyczne procesy zostawiliśmy na weekend, czyli na okres najmniejszego ruchu. W poniedziałek rano wszystkie aplikacje dostarczają wszystkich funkcjonalności z zapewnieniem poziomu bezpieczeństwa jak sprzed awarii. Kolejny sukces!

Wnioski i działania

Mimo, że zbudowana i utrzymywana przez nas infrastruktura fantastycznie spełniła swoją rolę w obliczu największej awarii, z którą mieliśmy do czynienia w Ruby Logic, nie spoczęliśmy na laurach, wyciągnęliśmy odpowiednie wnioski i stworzyliśmy plan dalszej poprawy stabilności i bezpieczeństwa infrastruktury aplikacyjno-serwerowej, którą oferujemy klientom.

Najważniejsze etapy planu, takie jak choćby transfer aplikacji pomiędzy serwerowniami celem uzyskania większej przejrzystości, zostały zrealizowane w przeciągu miesiąca od wystąpienia awarii, a kolejne sukcesywnie realizujemy.

Jedną z ciekawszych innowacji było wykorzystanie aplikacji Action Plan Pulse do przeprowadzania cyklicznych audytów weekly check. Dzięki niej osoba przeprowadzająca audyt jest informowana o takiej konieczności i postępuje ściśle z wcześniej określonym planem audytu. W przypadku stwierdzenia jakiejkolwiek nieprawidłowości, osoba odpowiedzialna za działania korekcyjne, czyli administrator, jest informowana ze szczegółami co wymaga poprawy.

Podsumowanie

W myśl zasady “A crisis is a terrible thing to waste” co w wolnym tłumaczeniu może oznaczać “głupotą jest zmarnowanie kryzysu” należy być wdzięcznym za wszelkie tego typu lekcje od losu. Kryzysy się zdarzają i głupotą jest nie wyciąganie lekcji i odpowiednich wniosków. Wydaje się, ze wykorzystaliśmy pożar w OVH całkiem rozsądnie i z korzyścią dla naszych klientów.

Jeśli chodzi o dostawcę usług hostingowych - OVH - to zgodnie z powiedzeniem “nie myli się tylko ten co nic nie robi” nie żywimy negatywnego sentymentu wobec nich. Obsługa incydentu była co najmniej poprawna. Nie zaprzestaliśmy współpracy z OVH i nadal jest to 1 dostawców usług hostingowych, z których korzystamy, ale zachowujemy większą przezorność.