Nawet w czasie katastrofy zawsze jest czas na filiżankę herbaty
DRP (plan odzyskiwania po awarii) to rzecz, która w idealnym przypadku nigdy nie będzie potrzebna. Jeśli jednak nagle bobry migrujące w okresie godowym przegryzą szkielet światłowodu lub młodszy administrator straci bazę produkcyjną, na pewno chcesz mieć pewność, że będziesz mieć z góry opracowany plan, co zrobić z całą tą hańbą.
Podczas gdy klienci w panice zaczynają odcinać telefony do pomocy technicznej, junior szuka cyjanku, Ty mądrze otwierasz czerwoną kopertę i zaczynasz wszystko porządkować.
W tym poście chcę podzielić się rekomendacjami jak napisać DRP i co powinien zawierać. Przyjrzymy się również następującym rzeczom:
- Nauczmy się myśleć jak złoczyńca.
- Przyjrzyjmy się zaletom filiżanki herbaty podczas apokalipsy.
- Zastanówmy się nad wygodną strukturą DRP
- Zobaczmy, jak to przetestować
Dla jakich firm może to być przydatne?
Bardzo trudno jest wytyczyć granicę, kiedy dział IT zaczyna potrzebować takich rzeczy. Powiedziałbym, że zdecydowanie potrzebujesz DRP, jeśli:
- Zatrzymanie serwera, aplikacji lub utrata części bazy danych doprowadzi do znacznych strat dla całej firmy.
- Masz pełnoprawny dział IT. W sensie działu w postaci pełnoprawnej jednostki firmy, z własnym budżetem, a nie tylko kilku zmęczonych pracowników układających sieć, usuwających wirusy i uzupełniających drukarki.
- Masz realistyczny budżet na przynajmniej częściowe zwolnienie w sytuacji awaryjnej.
Kiedy dział IT od miesięcy błaga o utworzenie kopii zapasowych co najmniej kilku dysków twardych na starym serwerze, jest mało prawdopodobne, że uda się zorganizować pełne przeniesienie nieudanej usługi w celu zarezerwowania pojemności. Chociaż tutaj dokumentacja nie będzie zbędna.
Dokumentacja jest ważna
Zacznij od dokumentacji. Załóżmy, że Twoja usługa działa na skrypcie Perla, który został napisany trzy pokolenia temu przez administratorów, ale nikt nie wie, jak to działa. Nagromadzony dług techniczny i brak dokumentacji nieuchronnie postrzelą Cię nie tylko w kolano, ale także w inne kończyny, to raczej kwestia czasu.
Po dobrym opisie elementów usługi przejrzyj statystyki wypadków. Prawie na pewno będą one całkowicie typowe. Na przykład od czasu do czasu dysk się zapełnia, co powoduje awarię węzła do czasu ręcznego oczyszczenia. Lub usługa klienta staje się niedostępna ze względu na to, że ktoś ponownie zapomniał odnowić certyfikat, a Let's Encrypt nie mógł lub nie chciał skonfigurować.
Myśli jak sabotażysta
Najtrudniejszą częścią jest przewidzenie wypadków, które nigdy wcześniej nie miały miejsca, ale które mogą potencjalnie całkowicie spowodować awarię usługi. Tutaj ja i moi koledzy zazwyczaj gramy złoczyńców. Napij się dużo kawy i czegoś smacznego i zamknij się w sali konferencyjnej. Tylko pamiętaj, aby w tych samych negocjacjach włączyć tych inżynierów, którzy sami opracowali docelową usługę lub regularnie z nią pracują. Następnie na tablicy lub na papierze zaczynasz rysować wszystkie możliwe okropności, które mogą przydarzyć się twojej służbie. Nie trzeba wnikać w szczegóły do konkretnej sprzątaczki i ciągnięcia kabli, wystarczy rozważyć scenariusz „Naruszenia integralności sieci lokalnej”.
Zazwyczaj najbardziej typowe sytuacje awaryjne można podzielić na następujące typy:
- Awaria sieci
- Awaria usług systemu operacyjnego
- Błąd aplikacji
- Awaria żelaza
- Błąd wirtualizacji
Po prostu przejrzyj każdy typ i zobacz, co ma zastosowanie do Twojej usługi. Na przykład demon Nginx może upaść i nie powstać - oznacza to awarie ze strony systemu operacyjnego. Rzadką sytuacją, która powoduje awarię aplikacji internetowej, jest awaria oprogramowania. Podczas pracy na tym etapie ważne jest ustalenie diagnozy problemu. Jak na przykład odróżnić zamrożony interfejs na wirtualizacji od uszkodzonego dysku cis i awarii sieci. Ważne jest, aby szybko znaleźć winnych i zacząć ciągnąć ich za ogon do czasu usunięcia wypadku.
Po spisaniu typowych problemów nalewamy kolejną kawę i zaczynamy rozważać najdziwniejsze scenariusze, gdy niektóre parametry zaczynają odbiegać daleko od normy. Na przykład:
- Co się stanie, jeśli czas w aktywnym węźle cofnie się o minutę w stosunku do innych w klastrze?
- A co jeśli czas przesunie się do przodu, co jeśli o 10 lat?
- Co się stanie, jeśli węzeł klastra nagle utraci sieć podczas synchronizacji?
- Co się stanie, jeśli dwa węzły nie będą dzielić przywództwa z powodu tymczasowej izolacji siebie w sieci?
Na tym etapie bardzo pomocne jest podejście odwrotne. Bierzesz najbardziej upartego członka zespołu z chorą wyobraźnią i dajesz mu zadanie zorganizowania w jak najkrótszym czasie sabotażu, który doprowadzi do upadku usługi. Jeśli jest to trudne do zdiagnozowania, tym lepiej. Nie uwierzysz, na jakie dziwne i fajne pomysły wpadną inżynierowie, jeśli dasz im pomysł, jak coś zepsuć. A jeśli obiecasz im stanowisko testowe do tego, nie ma w tym nic złego.
Co to za twój DRP?!
Zdefiniowałeś więc swój model zagrożenia. Uwzględniono także lokalnych mieszkańców, którzy przecinają kable światłowodowe w poszukiwaniu miedzi, oraz radar wojskowy, który zrywa linię radiową wyłącznie w piątki o 16:46. Teraz musimy zrozumieć, co z tym wszystkim zrobić.
Twoim zadaniem jest napisanie tych bardzo czerwonych kopert, które zostaną otwarte w sytuacji awaryjnej. Od razu spodziewaj się, że gdy (nie jeśli!) wszystko się skończy, w pobliżu znajdzie się jedynie najbardziej niedoświadczony stażysta, któremu ręce będą się mocno trząść z przerażenia tym, co się dzieje. Zobacz jak w gabinetach lekarskich wdrażane są znaki alarmowe. Na przykład, co zrobić w przypadku wstrząsu anafilaktycznego. Personel medyczny zna na pamięć wszystkie protokoły, jednak gdy w pobliżu zaczyna umierać bliska osoba, bardzo często wszyscy bezradnie chwytają się wszystkiego, co jest w zasięgu ich wzroku. W tym celu na ścianie znajdują się jasne instrukcje zawierające takie informacje, jak „otwórz opakowanie takiego a takiego” i „podaj dożylnie odpowiednią liczbę jednostek leku”.
Trudno myśleć w sytuacji awaryjnej! Powinny istnieć proste instrukcje dotyczące analizy rdzenia kręgowego.
Dobry DRP składa się z kilku prostych bloków:
- Kogo powiadomić o początku wypadku. Jest to ważne, aby w jak największym stopniu zrównoleglić proces eliminacji.
- Jak poprawnie zdiagnozować - wykonaj śledzenie, sprawdź status nazwy usługi systemctl i tak dalej.
- Ile czasu możesz spędzić na każdym etapie? Jeśli nie masz czasu na ręczne naprawienie problemu w ramach umowy SLA, maszyna wirtualna zostanie zabita i przywrócona z wczorajszej kopii zapasowej.
- Jak mieć pewność, że wypadek się skończył.
Pamiętaj, że DRP rozpoczyna się, gdy usługa całkowicie zawiedzie, a kończy się, gdy usługa zostanie przywrócona, nawet przy zmniejszonej wydajności. Sama utrata rezerwacji nie powinna uruchamiać DRP. Możesz także wpisać filiżankę herbaty do DRP. Poważnie. Według statystyk wiele wypadków zamienia się z nieprzyjemnych w katastrofalne, ponieważ pracownicy w panice pędzą coś naprawić, jednocześnie zabijając jedyny żywy węzeł z danymi lub w końcu wykańczając klaster. Z reguły 5 minut przy filiżance herbaty pozwoli Ci się uspokoić i przeanalizować to, co się dzieje.
Nie myl DRP z paszportem systemowym! Nie przeciążaj go niepotrzebnymi danymi. Wystarczy umożliwić szybkie i wygodne korzystanie z hiperłączy, aby przejść do żądanej sekcji dokumentacji i przeczytać w rozszerzonym formacie o niezbędnych sekcjach architektury usługi. A w samym DRP znajdują się tylko bezpośrednie instrukcje, gdzie i jak się połączyć za pomocą określonych poleceń kopiuj-wklej.
Jak poprawnie przetestować
Upewnij się, że każdy odpowiedzialny pracownik jest w stanie ukończyć wszystkie pozycje. W najbardziej kluczowym momencie może się okazać, że inżynier nie ma uprawnień dostępu do wymaganego systemu, nie ma haseł do wymaganego konta lub nie ma pojęcia, co „Połącz się z konsolą zarządzania usługami przez proxy pod adresem siedziba główna” oznacza. Każdy punkt powinien być niezwykle prosty.
Źle — „Przejdź do wirtualizacji i zrestartuj martwy węzeł”
Prawidłowo - „Połącz się przez interfejs sieciowy z witryną virt.example.com, w sekcji węzłów uruchom ponownie węzeł powodujący błąd.”
Unikaj dwuznaczności. Pamiętaj o przestraszonym stażyście.
Koniecznie przetestuj DRP. To nie jest tylko plan na pokaz – to coś, co pozwoli Tobie i Twoim klientom szybko wyjść z krytycznej sytuacji. Najlepiej zrobić to kilka razy:
- Jeden ekspert i kilku stażystów pracuje na stanowisku testowym, które w jak największym stopniu symuluje rzeczywistą usługę. Ekspert przerywa usługę na różne sposoby i umożliwia kursantom jej przywrócenie zgodnie z DRP. Wszelkie problemy, niejasności i błędy w dokumentacji są rejestrowane. Po przeszkoleniu stażystów DRP jest rozszerzany i upraszczany w niejasnych obszarach.
- Testowanie na prawdziwym serwisie. Tak naprawdę nigdy nie da się stworzyć idealnej kopii prawdziwej usługi. Dlatego kilka razy w roku konieczne jest rutynowe wyłączenie części serwerów, zerwanie połączeń i spowodowanie innych katastrof z listy zagrożeń, aby ocenić procedurę odzyskiwania. Planowana awaria trwająca 10 minut w środku nocy jest lepsza niż nagła awaria trwająca kilka godzin w szczytowym obciążeniu, która wiąże się z utratą danych.
- Prawdziwe rozwiązywanie problemów. Tak, jest to również część testów. Jeżeli zdarzy się wypadek, którego nie było na liście zagrożeń, konieczne jest uzupełnienie i sfinalizowanie DRP w oparciu o wyniki jego badania.
Kluczowe punkty
- Jeśli coś może się wydarzyć, to nie tylko się stanie, ale stanie się to w najbardziej katastrofalnym możliwym scenariuszu.
- Upewnij się, że masz zasoby do awaryjnego przeniesienia obciążenia.
- Upewnij się, że masz kopie zapasowe, są one tworzone automatycznie i regularnie sprawdzane pod kątem spójności.
- Przemyśl typowe scenariusze zagrożeń.
- Daj inżynierom możliwość zaproponowania niestandardowych opcji świadczenia usługi.
- DRP powinno być prostą i dosadną instrukcją. Cała kompleksowa diagnostyka przeprowadzana jest dopiero po przywróceniu obsługi klientów. Nawet przy mocy rezerwowej.
- Podaj kluczowe numery telefonów i kontakty w DRP.
- Regularnie sprawdzaj zrozumienie DRP przez pracowników.
- Organizuj planowane wypadki w zakładach produkcyjnych. Stojaki nie zastąpią wszystkiego.
Źródło: www.habr.com