🥇Przygotowujemy DRP — nie zapomnij uwzględnić meteorytu

Nawet w czasach kryzysu zawsze znajdzie się czas na filiżankę herbaty

DRP (plan odzyskiwania po awarii) to coś, co w idealnym świecie nigdy nie będzie potrzebne. Ale jeśli nagle bobry migracyjne przegryzą światłowód, albo junior admin skasuje bazę produkcyjną, to chcesz być pewny, że masz wcześniej przygotowany plan, co z tym wszystkim zrobić.

Podczas gdy klienci w panice dzwonią do działu wsparcia technicznego, junior szuka cyjanów, Ty z mądrym wyrazem twarzy otwierasz czerwoną kopertę i zaczynasz wszystko porządkować.

W tym poście chcę podzielić się zaleceniami, jak pisać DRP i co powinien zawierać. A także omówimy następujące kwestie:

Nauczymy się myśleć jak zły bohater.
Przeanalizujemy korzyści z filiżanki herbaty w czasie apokalipsy.
Zaplanujemy wygodną strukturę DRP
Zobaczymy, jak należy go testować

Dla jakich firm może to być przydatne

Bardzo trudno jest wyznaczyć granice, kiedy dział IT zaczyna potrzebować takich rzeczy. Powiedziałbym, że DRP jest na pewno potrzebny, jeśli:

Zatrzymanie serwera, aplikacji lub utrata jakiejkolwiek bazy danych spowoduje znaczne straty finansowe dla firmy.
Masz pełnoprawny dział IT. Mówię o dziale jako pełnoprawnej jedności firmy, z własnym budżetem, a nie tylko kilku zmęczonych pracowników zajmujących się siecią, usuwaniem wirusów i napełnianiem drukarek.
Masz rzeczywisty budżet, przynajmniej na częściowe zabezpieczenie w przypadku sytuacji kryzysowej.

Kiedy dział IT miesiącami prosi o przynajmniej kilka HDD do starego serwera na backupy, nie będziesz w stanie zorganizować pełnego przeniesienia upadłego serwisu na zapasowe zasoby. Choć i tu dokumentacja nie zaszkodzi.

Dokumentacja jest ważna

Zacznij od dokumentacji. Załóżmy, że Twój serwis działa na bazie skryptu w Perl, który został napisany trzy pokolenia adminów temu, a nikt nie wie, jak to działa. Narastający dług techniczny i brak dokumentacji nieuchronnie uderzy Cię nie tylko w kolano, ale i w inne kończyny, to raczej kwestia czasu.

Gdy masz już dobre opisy komponentów usługi, zbierz statystyki dotyczące awarii. Prawie na pewno będą one całkowicie typowe. Na przykład, dysk okresowo się zapełnia, co prowadzi do awarii węzła aż do jego ręcznego oczyszczenia. Lub usługa kliencka staje się niedostępna, ponieważ ktoś znów zapomniał przedłużyć certyfikat, a Let’s Encrypt nie został odpowiednio skonfigurowany lub nikt nie chciał się tym zająć.

Myśl jak dywersant

Najtrudniejsza część polega na prognozowaniu tych awarii, które jeszcze nigdy się nie zdarzyły, ale które potencjalnie mogą całkowicie unieruchomić usługę. Zazwyczaj z kolegami bawimy się w złoczyńców. Bierzcie dużo kawy i coś smacznego, a potem zamykacie się w sali konferencyjnej. Upewnijcie się, że w tej samej sali zamknęliście inżynierów, którzy sami uruchamiali docelową usługę lub regularnie z nią pracują. Następnie, na tablicy lub na papierze zaczynacie rysować wszystkie możliwe przerażające scenariusze, które mogą się zdarzyć z Waszą usługą. Nie trzeba szczegółowo omawiać szczególnego sprzątacza i odcinania kabli, wystarczy rozważyć scenariusz „Naruszenia integralności sieci lokalnej”.

Zwykle większość typowych sytuacji awaryjnych można podzielić na następujące rodzaje:

Awaria sieci
Awaria usług systemu operacyjnego
Awaria aplikacji
Awaria sprzętu
Awaria wirtualizacji

Po prostu przechodzicie przez każdy rodzaj i patrzycie, co można zastosować do waszej usługi. Na przykład, może upaść i nie uruchomić się demon Nginx — to dotyczy awarii ze strony systemu operacyjnego. Rzadką sytuacją, która powoduje, że Twoja aplikacja internetowa przestaje działać, jest błąd oprogramowania. Na etapie opracowywania tego punktu ważne jest, aby przeanalizować diagnostykę problemu. Jak odróżnić zawieszony interfejs na wirtualizacji od upadku serwera Cisco i awarii w sieci, na przykład. Jest to ważne, aby szybko znaleźć odpowiedzialnych i zacząć ich ciągnąć za ogon, dopóki awaria nie zostanie usunięta.

Po zapisaniu typowych problemów, nalewamy jeszcze kawy i zaczynamy rozważać najbardziej dziwaczne scenariusze, w których niektóre parametry zaczynają znacznie odbiegać od normy. Na przykład:

Co się stanie, jeśli czas na aktywnym węźle przesunie się o minutę wstecz w stosunku do innych w klastrze?
A co jeśli czas przesunie się do przodu, a jeśli o 10 lat?
Co się stanie, jeśli podczas synchronizacji węzeł klastra nagle straci połączenie z siecią?
Co się stanie, jeśli dwa węzły nie podzielą się przywództwem z powodu czasowej izolacji sieciowej?

Na tym etapie bardzo pomocne jest podejście od końca. Bierzemy najbardziej zdeterminowanego członka zespołu z bujną wyobraźnią i dajemy mu zadanie, aby w jak najkrótszym czasie zorganizował dywersję, która sparaliżuje usługę. Im trudniej ją zdiagnozować, tym lepiej. Nie uwierzysz, jakie dziwne i fajne pomysły wysuwają inżynierowie, gdy dadzą im pomysł na coś, co można zepsuć. A jeśli obiecamy im w tym celu stanowisko testowe — to już zupełnie świetnie.

Czym jest ten wasz DRP?!

Zidentyfikowałeś model zagrożeń. Ujęliście lokalnych mieszkańców, którzy tną światłowody w poszukiwaniu miedzi, oraz wojskowy radar, który zrzuca linię radiową w każdy piątek o 16:46. Teraz musisz zrozumieć, co z tym wszystkim zrobić.

Twoim zadaniem jest napisanie tych czerwonych kopert, które będą otwierane w sytuacji awaryjnej. Od razu zakładaj, że kiedy (nie jeśli!) wszystko się załamie, w pobliżu znajdzie się tylko najbardziej niedoświadczony stażysta, który będzie miał drżące ręce z powodu przerażenia. Zobacz, jak są zrobione tablice awaryjne w gabinetach medycznych. Na przykład, co robić w przypadku wstrząsu anafilaktycznego. Personel medyczny zna wszystkie protokoły na pamięć, ale kiedy obok osoba zaczyna umierać, często wszyscy bezradnie sięgają po wszystko. Dlatego na ścianie wisi jasna instrukcja z punktami typu „otworzyć opakowanie tego” i „wprowadzić dożylnie tyle i tyle jednostek leku”.

W sytuacji awaryjnej trudno jest myśleć! Muszą być proste instrukcje do przetwarzania na poziomie rdzenia.

Dobry DRP składa się z kilku prostych bloków:

Kogo powiadomić o rozpoczęciu awarii. To ważne, aby jak najbardziej rozdzielić proces eliminacji.
Jak prawidłowo zdiagnozować — dokonujemy trasy, sprawdzamy status systemu servicename i tak dalej.
Ile czasu można poświęcić na każdy etap. Jeśli nie zdążycie naprawić ręcznie w czasie SLA — maszyna wirtualna jest niszczona i przywracana z wczorajszego backupu.
Jak upewnić się, że awaria została zakończona.

Pamiętaj, że DRP zaczyna się, gdy usługa całkowicie zawodzi, a kończy na przywróceniu jej funkcjonalności, nawet przy zmniejszonej wydajności. Prosta utrata rezerwy nie powinna aktywować DRP. Możesz również w DRP zasugerować filiżankę herbaty. Poważnie. Statystyki pokazują, że wiele awarii z nieprzyjemnych staje się katastrofalnymi, ponieważ personel w panice próbuje coś naprawić, jednocześnie niszcząc jedyną żywą węzeł z danymi lub całkowicie dobijając klaster. Zazwyczaj 5 minut na filiżankę herbaty daje ci trochę czasu na uspokojenie się i analizę sytuacji.

Nie myl DRP z paszportem systemu! Nie przeciążaj go nadmiernymi danymi. Po prostu pozwól szybko i wygodnie przejść do odpowiednich sekcji dokumentacji za pomocą hiperlinków i przeczytać w rozszerzonym formacie o potrzebnych częściach architektury usługi. A w samym DRP tylko bezpośrednie instrukcje, gdzie i jak się podłączyć z konkretnymi komendami do skopiowania.

Jak prawidłowo testować

Upewnij się, że każdy odpowiedzialny pracownik jest w stanie wykonać wszystkie punkty. W najważniejszym momencie może się okazać, że inżynier nie ma uprawnień do dostępu do potrzebnego systemu, brakuje haseł do potrzebnego konta lub nie ma pojęcia, co oznacza „Podłącz się do konsoli zarządzania usługą przez proxy w głównym biurze”. Każdy punkt powinien być maksymalnie prosty.

Niepoprawnie — „Wejdź w wirtualizację i zrestartuj martwy węzeł”
Poprawnie — „Podłącz się przez interfejs webowy do virt.example.com, w sekcji węzła wykonaj restart węzła, który powoduje błąd”.

Unikaj niejasności. Pamiętaj o przestraszonym stażyście.

Obowiązkowo testuj DRP. To nie jest tylko plan dla formalności — to coś, co pozwoli tobie i twoim klientom szybko wyjść z krytycznej sytuacji. Optymalnie, aby zrobić to kilka razy:

Jeden ekspert i kilku stażystów pracują na testowym stanowisku, które jak najlepiej imituje rzeczywistą usługę. Ekspert psuje usługę na różne sposoby i daje stażystom możliwość jej przywrócenia zgodnie z DRP. Wszystkie problemy, niejasności w dokumentacji i błędy są zapisywane. Po szkoleniu stażystów, DRP jest uzupełniane i upraszczane w niejasnych miejscach.
Testowanie na rzeczywistym serwisie. W rzeczywistości nigdy nie można stworzyć idealnej kopii prawdziwego serwisu. Dlatego kilka razy w roku konieczne jest planowe wyłączenie części serwerów, przerywanie połączeń i przeprowadzanie innych awarii z listy zagrożeń, aby ocenić porządek przywracania. Lepiej zaplanowana awaria na 10 minut w środku nocy niż nagła awaria trwająca kilka godzin w szczycie obciążenia z utratą danych.
Rzeczywiste usuwanie awarii. Tak, to też część testowania. Jeśli wystąpi awaria, której nie było na liście zagrożeń, konieczne jest uzupełnienie i poprawienie DRP w oparciu o wyniki jej dochodzenia.

Kluczowe punkty

Jeśli coś może pójść źle, to na pewno się zepsuje, a zrobi to w najbardziej katastroficzny sposób.
Upewnij się, że masz zasoby do awaryjnego rozkładu obciążenia.
Upewnij się, że masz kopie zapasowe, które są automatycznie tworzone i regularnie sprawdzane pod kątem spójności.
Przemyśl typowe scenariusze zagrożeń.
Daj inżynierom możliwość wymyślenia nietypowych sposobów na unieruchomienie serwisu.
DRP powinien być prostą i łatwą do zrozumienia instrukcją. Wszystkie skomplikowane diagnozy tylko po tym, jak klienci odzyskają serwis. Nawet na rezerwowych zasobach.
Podaj kluczowe numery telefonów i kontakty w DRP.
Regularnie testuj pracowników pod kątem zrozumienia DRP.
Organizuj planowe awarie w produkcji. Stoiska nie mogą zastąpić wszystkiego.

Źródło: habr.com