Wszystko się czasem psuje: sprzęty domowe, samochody, motocykle, komputery i – oczywiście – oprogramowanie. Co jakiś czas wśród wyszukiwanych haseł w Google pojawia się “is <serwis> down?”, kiedy dla grupy użytkowników jakiś serwis internetowy staje się niedostępny bądź też bardzo wolno działa. A jak to wygląda z drugiej strony? Co dzieje się w siedzibach firm w trakcie awarii takiego serwisu, kto odpowiada za “gaszenie pożarów” i czym jest tytułowa “oncall rotation”?
Na te i parę innych pytań postaram się odpowiedzieć w tym tekście. Otwiera on poniekąd serię wpisów “Dzień z życia Programistki”, w której postaram się przedstawić typowe zadania z pracy programistki (choć możliwe, że nie zawsze związane z samym programowaniem!).
Co może pójść nie tak?
W chwili pisania tego tekstu (piątek, 16 kwietnia) aplikacja Robinhood miała problemy z przetwarzaniem transakcji giełdowych swoich użytkowników. 8 kwietnia można było zaobserwować awarię Facebooka i Messengera, a 17 marca na Youtubie zaczęły znikać “lajki” spod filmów… Jak widać – problemów nie brakuje i każdy, nawet największy tech-gigant musi się z nimi liczyć.
Błędów i awarii – tak jak i różnych rodzajów oprogramowania – jest wiele. Są takie, z którymi można żyć i na spokojnie uporać się z nimi w późniejszym czasie. Są takie, które dotykają tylko kilku użytkowników. Niektóre dotyczą aplikacji zainstalowanych na komputerze bądź innym urządzeniu użytkownika. A są też takie, które nazwać można “pożarem w burdelu”, kiedy to serwis online przestaje działać, bądź poważnie spowalnia swoje działanie, serwuje niepoprawne dane i w jakikolwiek inny sposób przejawia degenerację. I takich sytuacji raczej nie należy zostawiać na “po weekendzie”…
Każdą z tych sytuacji traktować należy poważnie, jednak dzisiaj skupię się w szczególności na wspomnianym “pożarze w burdelu”.
Awaria takiego systemu produkcyjnego może dotyczyć wszystkiego – zaczynając od tego, że pada host, na którym uruchomiony jest serwis; przez błędy w bazie danych; po DDoS – czyli zewnętrzny atak, który poprzez nagłe zwiększenie ruchu, skutecznie unieruchamia daną aplikację. Wymienić można też zwyczajne bugi – błędy w oprogramowaniu, które niefortunnie wydostały się z repozytorium, by ujrzeć światło dziennie i przysporzyć programistom problemów! Moje ulubione są jednak piątkowe testy na produkcji (aż mi się przypomniała niedawna akcja mBanku, kiedy wszyscy klienci przypadkowo dostali powiadomienia ze środowiska testowego).
Pożar w burdelu – i co teraz?
Spróbuję teraz naszkicować Ci, jak takie awarie wyglądają z tej drugiej strony. Co się dzieje, kiedy np. taki Facebook przestaje działać?
Z reguły – w pierwszych sekundach awarii – nie dzieje się zupełnie nic.
Czasem mogą to być nawet minuty (albo i dziesiątki minut!), kiedy użytkownicy danego systemu wyraźnie cierpią, jednak programiści nie mają zielonego pojęcia, że coś z serwisem jest nie w porządku. No, chyba że ktoś z pracowników akurat przypadkiem wejdzie na stronę – choć to też nie zawsze gwarantuje wykrycie awarii (np. jeśli wersja produkcyjna systemu różni się od wersji dostępnej dla pracowników). Taki stan nazywamy etapem “discovery”, czyli etapem wykrywania awarii.
Jeśli mamy szczęście – to system co jakiś czas raportuje swój stan zdrowia. Tak jak my – ludzie – dzwonimy co jakiś czas do rodziców, by powiedzieć, że u nas wszystko w porządku; tak serwisy internetowe również monitorują swój stan. I jeśli jakiś raport się nie pojawi lub też znajdzie się w nim niepokojące informacje – to sygnał do działania. W świecie IT – w przeciwieństwie do telefonów do rodziców – jest to zautomatyzowane. Popularnymi rozwiązaniami stosowanymi do tych celów w branży są:
- Prometheus – open-sourcowy system do raportowania stanu zdrowia serwisów i aplikacji;
- Grafana – kolejne open-sourcowe rozwiązanie, tym razem do przeglądania metryk raportowanych przez Prometheus (a także innych systemów) oraz logów; Grafana oferuje również funkcje monitorowania poszczególnych metryk i wysyłania powiadomień w chwili wykrycia anomalii;
- PagerDuty – mimo że pager, jako urządzenie, przeminął wraz z latami 90 XX wieku, to jednak idea wciąż ma się dobrze! PagerDuty odbiera powiadomienia o wykrytych anomaliach z serwisów takich jak Grafana, a następnie w sposób bardzo – ale to bardzo – głośny i nachalny powiadamia odpowiednią osobę. A jeśli ta osoba nie jest gotowa rzucić wszystko i ratować sytuację – powiadamia kolejną osobę z listy…
Jakie rzeczy warto monitorować? Monitorowanie serwisów i aplikacji to temat rzeka. Sama spędziłam ponad rok, pracując w zespole odpowiedzialnym za dostarczenie i wdrożenie systemu podobnego w działaniu do Prometheusa. Poza klepaniem kodu byliśmy też odpowiedzialni za edukowanie innych programistów, jak monitorować kod. Do najważniejszych punktów zaliczyłabym:stan serwisu (czy online, czy offline), a także liczba działających hostów, jeśli jest ich wiele;czas działania danej opcji, czy requestu (im więcej takich danych tym lepiej! Daje to np. możliwość porównywania średniego czasu ładowania się aplikacji z danymi historycznymi, a także obliczanie percentyli i ostatecznie wykrycia anomalii, jeśli z jakiegoś powodu aplikacjia znacznie spowalnia);statusy HTTP zwracane do klientów – łatwo wtedy sprawdzić, czy np. konkretny URL zaczął nagle zwracać błędy częściej niż zwykle; liczba przetwarzanych requestów – żeby określić, czy aplikacja w ogóle wyrabia z obecnym obciążeniem i móc zareagować, zanim dojdzie do przeciążenia systemu; liczba restartów i wersje systemu. Oczywiście, w zależności od sytuacji potrzebne będą jeszcze inne dane. Te powinny dać Ci dobry “kickstart” do monitorowania Twojego projektu, a o szczegółach być może rozpiszę się więcej innym razem |
I wtedy wchodzi “oncall”, cała na biało!
Oncall – potocznie, przynajmniej w Dolinie Krzemowej, tak nazywa się osoby, które obecnie są odpowiedzialne za rozwiązywanie awarii. Przyznam szczerze, że kiedy jeszcze pracowałam w Polsce, to nie mieliśmy “oncall rotation”, nie wiem zatem, jak zwyczajowo nazywa się ta rola…
Oncall to zwyczajny programista bądź programistka z zespołu. Na co dzień klepią kod jak każda inna osoba. Tylko co jakiś czas przez kilka dni noszą za sobą piętno “oncall” i odpowiedzialność za działanie danego serwisu na swoich barkach. Nie wszystkie zespoły programistyczne praktykują “oncall rotation” – nie wszystkie zespoły mają taką potrzebę. Najczęściej będą to zespoły zajmujące się infrastrukturą (czyli wszelkimi narzędziami i bibliotekami niższego poziomu, które sprawiają, że serwis działa), chociaż spotkałam się też z tzw. “product engineer teams”, które również to praktykowały (i chwała im za to!).
W mojej karierze, jak do tej pory, wyglądało to podobnie: wszyscy członkowie zespołu należą do rotacji. Jedna zmiana trwa około tygodnia, 24/7. Częstotliwość zmian zależy od rozmiaru zespołu. W trakcie zmiany oncall zobowiązuje się do noszenia służbowego komputera wszędzie (do pracy, do domu, a nawet do kina, czy restauracji), albowiem oczekiwany czas reakcji na powiadomienie to mniej niż 10 minut. I może się zdarzyć, że trzeba wstawać w środku nocy…
Zwykle staram się nie planować zbyt wiele w trakcie moich zmian. W jednym okresie normą było dostawanie 50 krytycznych powiadomień dziennie (choć od “weteranów” słyszałam, że to i tak pikuś)! Jestem jednak daleka od totalnego odcinania się od życia na cały tydzień i siedzenia w domu w strachu, że zaraz dostanę powiadomienie i będę zmuszona rzucić wszystko i lecieć do gaszenia pożarów. Wręcz przeciwnie – zdażyło mi się naprawiać system siedząc na podłodze przed salą w trakcie konferencji; czy też w Burger Kingu, po środku niczego, 200 mil od domu, wracając z weekendowej wycieczki motocyklowej.
Naprawiamy system – czyli “restoration phase”
Niestety, sam fakt uczestniczenia w rotacji i bycie odpowiedzialną za działanie systemu wiosny nie czyni. Powiadomienia, które dostaje oncall mogą być bardzo klarowne, a mogą być też super niejasne. Mnie wielokrotnie zdarzało się panikować i czuć, że wszystko płonie, a ja nie wiedziałam już, w co ręce włożyć. Rolą oncall nie jest jednak znalezienie i naprawa błędu, ale przywrócenie systemu do działania. Jak wspomniałam na początku – powodów awarii systemu może być bardzo wiele, często faktycznym powodem (tzw. “root cause”) jest zmiana dokonana przez zupełnie inny zespół programistów. Na szczęście, nikt nie oczekuje (a przynajmniej – nie powinien oczekiwać), że oncall w 5 minut wdroży się w kod całego repozytorium i szybko znajdzie powód degradacji.
Co zatem należy robić?
Ja z reguły bardzo liczę na to, że autor danego powiadomienia zostawił gdzieś link do dokumentacji – playbooka, instrukcji obsługi, czy innej listy kroków, które należy wykonać, żeby naprawić dany problem. Z reguły jednak bardzo się przeliczam – bo nawet jeśli link jest, to prowadzi do przestarzałej dokumentacji, a problem, z którym się mierzę i tak nie jest opisany.
Jeśli powiadomionych zostało jeszcze kilka osób (np. z rotacji innych zespołów), to staram się synchronizować działania i wspólnie zbierać informacje o tym, co w ogóle się dzieje. Gdzie leży problem? Czym się objawia? Jak wielu użytkowników dotyka? – zadajemy sobie wspólnie te pytania, żeby oszacować skalę zniszczeń, a także zaplanować dalsze działania. Jeśli problem dotyczy wszystkich, a my nadal nie wiemy, co robić – należy eskalować, czyli powiadamiać innych programistów, osoby z większym doświadczeniem bądź odpowiedzialne bezpośrednio za konkretne komponenty systemu. Niestety, i to nie zawsze pomaga… (zwłaszcza jeśli samemu jest się osobą, do której problem był już eskalowany i wciąż nie wiadomo, o co chodzi ).
Jednym z podstawowych kroków, które warto podjąć, jest sprawdzenie, kiedy została wypuszczona nowsza wersja systemu i czy przypadkiem ta data nie jest skorelowana z raportami o błędach. W systemach, gdzie nowa wersja wypuszczana jest bez przerwy (może słyszałaś już o CI/CD?), zdarza się często, że jakaś zmiana dostała się na produkcję “niechcący”, przy okazji siejąc zamęt i zniszczenie wokół. Jeśli to możliwe – warto wtedy cofnąć wersję systemu do tej sprzed awarii. Z reguły to wystarczy, żeby zatamować krwawienie (z ang. “stop the bleeding”) i przywrócić naszą aplikację do działania. Z reguły – czyli nie zawsze.
W zależności od systemu i rodzaju błędu i awarii oncall może przeglądać i analizować metryki wysyłane przez serwis (przydaje się wtedy znajomość ze wspomnianą już Grafaną), czytać logi serwisu, czy też wykonywać konkretne polecenia na hoście w konsoli. Moimi przyjaciółmi niedoli na zawsze pozostaną polecenia: grep, awk, xargs, ps, netstat i ssh!
Jeśli rozwiązanie problemu jest czasochłonne, a skala awarii bardzo duża – w firmie tworzymy “incydent” (niektóre firmy z Doliny Krzemowej takie incydenty nazywają “SEV-ami”, sev – jako skrót od angielskiego “severe”). Incydent będzie wtedy odpowiednio otagowany, nazwany, a powiadomieni zostaną wszyscy w firmie (bądź organizacji). To taki moment, kiedy krzyczymy “wszystkie ręce na pokład!” i kto może, wpada pomagać. Jeśli kiedykolwiek słyszałaś plotki o tym, że w trakcie awarii Mark Zuckerberg zamyka swoich programistów w pokoju, rzuca im pizzę przez okno i nie pozwala wyjść, dopóki błąd nie zostanie naprawiony… – cóż, nie wygląda to aż tak dramatycznie na co dzień, ale jestem sobie w stanie wyobrazić takie działania w bardzo krytycznej sytuacji…
Największa awaria, z którą ja musiałam się zmierzyć, miała miejsce w czerwcu 2018 roku. Było to niedługo po tym, jak zaktualizowaliśmy nasze bazy danych do wersji 5.7 MySQL. Operacja została wykonana w piątek, a przez weekend wszystko wyglądało w porządku. Do poniedziałku. W poniedziałek system zaczął działać wolniej… i wolniej. Amazon RDS (serwis, w którym znajdowały się nasze bazy danych) oferował usługę “failover”, czyli możliwość wyłączenia aktywnej i przełączenia się na drugą, zapasową bazę danych. To jednak tylko pogorszyło sytuację. Przez pierwsze dwa dni nie mieliśmy pojęcia, co się dzieje, cofanie wersji naszego kodu nie pomagało, a cofnięcie aktualizacji MySQL okazało się niemożliwe. Trzeciego dnia byliśmy już w bezpośrednim kontakcie z programistami z AWS (Amazon Web Services), a z naszej strony w prace nad rozwiązaniem zaangażowanych było około 20 osób! Po tygodniu działań udało się zidentyfikować problematyczne ustawienia bazy danych, dowiedzieliśmy się też, że wraz ze zmianą wersji MySQL, Amazon zaserwował nam też zmianę bibliotek SSL, co było faktyczną przyczyną awarii. Cały ten tydzień nazwaliśmy później ‘SEVPOCALYPSE’ (jak “SEV” i apokalipsa) i zrobiliśmy sobie pamiątkowe naklejki na nasze służbowe laptopy. |
Lepiej zapobiegać, niż leczyć
Wiadomo. Lepiej zaszczepić się przeciw wszelkim choróbskom, jeśli to tylko możliwe; niż ryzykować wizytę w szpitalu i nieprzyjemny proces leczenia. Podobnie jest z oprogramowaniem. Żaden kod nie jest idealny, a programiści to tylko ludzie i błędy będą się zdarzały. Warto jednak zastanowić się nad tym, co można zrobić lepiej na przyszłość i jak ograniczyć skalę zniszczeń w przypadku podobnych awarii. Facebook niedziałający tylko dla 0.1% użytkowników nie jest aż tak wielką sprawą, jak kompletnie niedostępna strona dla wszystkich. Youtube usuwający lajki tylko przez 10 minut, wygląda znacznie lepiej, niż gdyby taki problem trwał godzinami. Robinhood mający problem z transakcjami akcji jednej konkretnej firmy, radzi sobie znacznie lepiej, niż gdyby transakcje nie działały dla nikogo.
Temu właśnie warto poświęcić czas po awarii. Jest to tzw. “prevention phase”. Na tym etapie oncall może uzupełnić braki w dokumentacji zalinkowanej w powiadomieniach; może dodać nowe powiadomienia czy dodatkowe metryki; a dodatkowo zarekomendować zmiany w procesie dostarczania oprogramowania na produkcję. Wszystko na podstawie analizy tej konkretnej sytuacji.
To, co jest ważne, to żeby nie szukać winnych. Ktokolwiek spowodował awarię (np. odpalając test na produkcji w piątek wieczorem), już pewnie jest wystarczająco zawstydzony i przygnębiony. Znęcanie się nad taką osobą poprzez podkreślanie, że to jej wina nikomu nie pomoże, a w przyszłości może odbić się czkawką, jeśli to nam powinie się noga. Dlatego też wiele firm stara się wprowadzić tzw. “blameless culture” i nakierowywać swoich pracowników na szukanie rozwiązań i zapobieganie awariom, zanim się wydarzą, zamiast szukania dziury w całym (np. jak zapobiegać nieautoryzowane testy na produkcji, czy ograniczyć ich skalę działania).
Kto może być oncall?
Tego typu szczegóły najlepiej ustalać wewnątrz własnego zespołu. Chciałam jednak zwrócić uwagę na to, że oncall to zadanie, które może (a nawet powinien) podjąć się każdy, przynajmniej raz w swojej karierze. Nie trzeba być SRE, DevOps, czy specem od Linuxa. Uczestniczenie w rotacji buduje wśród członków zespołu poczucie odpowiedzialności za serwis (w końcu, jeśli nie zastosują się do umówionych praktyk, to oni będą budzić się potem w środku nocy, by naprawiać błędy…); a także pozwala pogłębić swoją wiedzę o niektórych, wcześniej nam obcych, partiach systemu. Co więcej, jest to też dobry sprawdzian radzenia sobie ze stresem i umiejętności debugowania programów.
Moim zdaniem nie należy się tego bać. W końcu zawsze można prosić innych o pomoc lub eskalować!
Nie tylko serwisy działające online, w sieci, mają potrzebę tego typu procesu. Jeszcze w Warszawie pracowałam w niedużej firmie dostarczającej fizyczne urządzenia i oprogramowanie do nich. Choć nie mieliśmy systemu, który należało monitorować 24/7, to zdarzało mi się wskakiwać na motocykl i jechać przez pół miasta prosto do klienta, kiedy dostawaliśmy telefon, że większość urządzeń nie działa i nie jest w stanie synchronizować danych. Choć nie było tam oficjalnej rotacji, to jednak w pewien sposób byłam tam “oncall”. Ten przykład pokazuje, że każdemu według potrzeb i oczywiście w różnych firmach, produktach i usługach może to wyglądać inaczej (lub też nie wyglądać wcale). |
Na zakończenie, podrzucę jeszcze wpis autorstwa moich kolegów z pracy o tym, czego nauczyliśmy się, ogarniając awarie.
A jak wygląda to u Ciebie?
Byłaś już kiedyś w podobnej rotacji? Jak Twoja firma monitoruje systemy i wykrywa awarie? Podziel się w komentarzu – chętnie dowiem się, jak inni sobie z tym radzą!