Zalecenia dotyczące projektowania strategii odzyskiwania po awarii

  • Artykuł

Dotyczy tego zalecenia dotyczącego listy kontrolnej niezawodności platformy Azure Well-Architected Framework:

RE:09 Zaimplementuj plany strukturalne, przetestowane i udokumentowane plany ciągłości działania i odzyskiwania po awarii (BCDR), które są zgodne z celami odzyskiwania. Plany muszą obejmować wszystkie składniki i system jako całość.

W tym przewodniku opisano zalecenia dotyczące projektowania niezawodnej strategii odzyskiwania po awarii dla obciążenia. Aby spełnić wewnętrzne cele poziomu usług (SLO), a nawet umowę dotyczącą poziomu usług (SLA), która jest gwarantowana dla klientów, musisz mieć niezawodną i niezawodną strategię odzyskiwania po awarii. Błędy i inne poważne problemy są oczekiwane. Przygotowania do obsługi tych zdarzeń określają, ile klienci mogą ufać twojej firmie, aby niezawodnie je dostarczać. Strategia odzyskiwania po awarii to szkielet przygotowania do poważnych zdarzeń.

Definicje

Okres Definicja
Tryb failover Automatyczne i/lub ręczne przenoszenie ruchu obciążeń produkcyjnych z niedostępnego regionu do regionu geograficznego, którego dotyczy problem.
Powrót po awarii Automatyczne i/lub ręczne przenoszenie ruchu obciążeń produkcyjnych z regionu trybu failover z powrotem do regionu podstawowego.

Kluczowe strategie projektowania

W tym przewodniku założono, że w ramach planowania niezawodności wykonano już następujące zadania:

Niezawodna strategia odzyskiwania po awarii opiera się na podstawie niezawodnej architektury obciążenia. Przed rozpoczęciem projektowania strategii odzyskiwania po awarii przed rozpoczęciem projektowania strategii odzyskiwania po awarii należy sprostać niezawodności na każdym etapie tworzenia obciążenia. Ta podstawa zapewnia, że cele niezawodności obciążenia, takie jak cel czasu odzyskiwania (RTO) i cel punktu odzyskiwania (RPO), są realistyczne i osiągalne.

Obsługa planu odzyskiwania po awarii

Podstawą niezawodnej strategii odzyskiwania po awarii dla obciążenia jest plan odzyskiwania po awarii. Plan powinien być aktywnym dokumentem, który jest regularnie przeglądany i aktualizowany w miarę rozwoju środowiska. Przedstawianie planu odpowiednim zespołom (operacjom, liderom technologii i uczestnikom projektu biznesowego) regularnie (na przykład co sześć miesięcy). Przechowuj go w magazynie danych o wysokiej dostępności, takim jak OneDrive dla Firm.

Postępuj zgodnie z tymi zaleceniami, aby opracować plan odzyskiwania po awarii:

  • Jasno określ, co stanowi awarię, a zatem wymaga aktywacji planu odzyskiwania po awarii.

    • Awarie to problemy na dużą skalę. Mogą to być awarie regionalne, awarie usług, takich jak identyfikator Microsoft Entra lub Azure DNS, lub poważne złośliwe ataki, takie jak ataki oprogramowania wymuszającego okup lub ataki DDoS.

    • Zidentyfikuj tryby awarii, które nie są uważane za awarie, takie jak awaria pojedynczego zasobu, dzięki czemu operatorzy nie wywołują błędnie eskalacji odzyskiwania po awarii.

  • Skompiluj plan odzyskiwania po awarii w dokumentacji FMA. Upewnij się, że plan odzyskiwania po awarii przechwytuje tryby awarii i strategie ograniczania ryzyka awarii, które są zdefiniowane jako awarie. Zaktualizuj zarówno plan odzyskiwania po awarii, jak i dokumenty FMA równolegle, aby były dokładne, gdy środowisko się zmienia lub podczas testowania odkrywa nieoczekiwane zachowania.

    • Niezależnie od tego, czy tworzysz plany odzyskiwania po awarii dla środowisk nieprodukcyjnych, zależy od wymagań biznesowych i wpływu kosztów. Jeśli na przykład oferujesz klientom środowiska kontroli jakości (QA) na potrzeby testowania wersji wstępnej, warto uwzględnić te środowiska w planowaniu odzyskiwania po awarii.

  • Jasno zdefiniuj role i obowiązki w zespole ds. obciążeń i zapoznaj się z wszelkimi powiązanymi rolami zewnętrznymi w organizacji. Role powinny obejmować:

    • Strona odpowiedzialna za deklarowanie katastrofy.

    • Strona odpowiedzialna za deklarowanie zamknięcia incydentu.

    • Role operacji.

    • Role testowania i walidacji.

    • Role komunikacji wewnętrznej i zewnętrznej.

    • Role głównej analizy głównej przyczyny i retrospektywy.

  • Zdefiniuj ścieżki eskalacji, które zespół obciążenia musi wykonać, aby upewnić się, że stan odzyskiwania jest przekazywany uczestnikom projektu.

  • Przechwyć procedury odzyskiwania na poziomie składnika, odzyskiwanie na poziomie majątku danych i procesy odzyskiwania na poziomie obciążenia. Uwzględnij przepisywaną kolejność operacji, aby zapewnić, że składniki są odzyskiwane w najmniejszy wpływ. Na przykład odzyskaj i sprawdź bazy danych przed odzyskaniem aplikacji.

    • Szczegółowe informacje o każdej procedurze odzyskiwania na poziomie składnika jako przewodnik krok po kroku. Dołącz zrzuty ekranu, jeśli to możliwe.

    • Zdefiniuj obowiązki twojego zespołu w porównaniu z obowiązkami dostawcy hostingu w chmurze. Na przykład firma Microsoft jest odpowiedzialna za przywracanie usługi PaaS (platforma jako usługa), ale odpowiadasz za ponowne wypełnianie danych i stosowanie konfiguracji do usługi.

    • Uwzględnij wymagania wstępne dotyczące uruchamiania procedury. Można na przykład wyświetlić listę wymaganych skryptów lub poświadczeń, które należy zebrać.

    • Przechwyć główną przyczynę zdarzenia i przed rozpoczęciem odzyskiwania wykonaj środki zaradcze. Jeśli na przykład przyczyną zdarzenia jest problem z zabezpieczeniami, zniweluj ten problem przed odzyskaniem systemów, których dotyczy problem w środowisku trybu failover.

  • W zależności od projektu nadmiarowości obciążenia może być konieczne wykonanie znacznej pracy po przejściu w tryb failover przed ponownym udostępnieniem obciążenia klientom. Praca po przejściu w tryb failover może obejmować aktualizacje DNS, aktualizacje bazy danych parametry połączenia i zmiany routingu ruchu. Przechwyć wszystkie zadania po przejściu w tryb failover w procedurach odzyskiwania.

    Uwaga

    Projekt nadmiarowości może umożliwiać automatyczne odzyskiwanie po głównych zdarzeniach w pełni lub częściowo, dlatego upewnij się, że plan obejmuje procesy i procedury dotyczące tych scenariuszy. Jeśli na przykład masz w pełni aktywny-aktywny projekt obejmujący strefy dostępności lub regiony, możesz automatycznie przełączyć się w tryb failover po strefie dostępności lub regionalnej awarii i zminimalizować kroki planu odzyskiwania po awarii, które należy wykonać. Podobnie, jeśli obciążenie zostało zaprojektowane przy użyciu sygnatur wdrożenia, może wystąpić tylko częściowa awaria, jeśli sygnatury są wdrażane w sposób strefowy. W takim przypadku plan odzyskiwania po awarii powinien obejmować sposób odzyskiwania sygnatur w strefach lub regionach, których to dotyczy.

  • Jeśli musisz ponownie wdrożyć aplikację w środowisku trybu failover, użyj narzędzi, aby zautomatyzować proces wdrażania, jak najwięcej. Upewnij się, że potoki DevOps zostały wstępnie wdrożone i skonfigurowane w środowiskach trybu failover, aby umożliwić natychmiastowe rozpoczęcie wdrożeń aplikacji. Używaj zautomatyzowanych wdrożeń typu end-to-end z bramami zatwierdzania ręcznego w razie potrzeby, aby zapewnić spójny i wydajny proces wdrażania. Pełny czas trwania wdrożenia musi być zgodny z celami odzyskiwania.

    • Gdy etap procesu wdrażania wymaga ręcznej interwencji, należy udokumentować kroki ręczne. Jasno zdefiniuj role i obowiązki.

  • Zautomatyzuj jak najwięcej procedury. W skryptach użyj programowania deklaratywnego, ponieważ umożliwia idempotencję. Jeśli nie możesz używać programowania deklaratywnego, pamiętaj o tworzeniu i uruchamianiu niestandardowego kodu. Użyj logiki ponawiania prób i logiki wyłącznika, aby uniknąć marnowania czasu na skryptach, które utknęły w uszkodzonym zadaniu. Ponieważ uruchamiasz te skrypty tylko w sytuacjach awaryjnych, nie chcesz, aby nieprawidłowo opracowane skrypty powodowały większe szkody lub spowalniały proces odzyskiwania.

    Uwaga

    Automatyzacja stwarza ryzyko. Wytrenowani operatorzy muszą uważnie monitorować zautomatyzowane procesy i interweniować, jeśli wystąpią problemy. Aby zminimalizować ryzyko, że automatyzacja będzie reagować na wyniki fałszywie dodatnie, należy dokładnie przeprowadzić próbne odzyskiwanie po awarii. Przetestuj wszystkie fazy planu. Symulowanie wykrywania w celu wygenerowania alertów, a następnie przejście przez całą procedurę odzyskiwania.

    Pamiętaj, że próbne odzyskiwanie po awarii powinno weryfikować lub informować o aktualizacjach metryk docelowych odzyskiwania. Jeśli okaże się, że automatyzacja jest podatna na wyniki fałszywie dodatnie, może być konieczne zwiększenie progów trybu failover.

  • Oddziel plan powrotu po awarii od planu odzyskiwania po awarii, aby uniknąć potencjalnych pomyłek z procedurami odzyskiwania po awarii. Plan powrotu po awarii powinien być zgodny ze wszystkimi zaleceniami dotyczącymi opracowywania i konserwacji planu odzyskiwania po awarii i powinien być ustrukturyzowany w taki sam sposób. Wszelkie kroki ręczne, które były niezbędne do przejścia w tryb failover, powinny być dublowane w planie powrotu po awarii. Powrót po awarii może nastąpić szybko po przejściu w tryb failover lub może potrwać kilka dni lub tygodni. Rozważ powrót po awarii niezależnie od trybu failover.

    • Konieczność powrotu po awarii jest sytuacyjna. Jeśli kierujesz ruch między regionami ze względu na wydajność, powrót po awarii pierwotnie w regionie przełączonym w tryb failover jest ważny. W innych przypadkach obciążenie może być zaprojektowane tak, aby działało w pełni niezależnie od tego, w którym środowisku produkcyjnym znajduje się w dowolnym momencie.

Przeprowadzanie próbnego odzyskiwania po awarii

Praktyka testowania odzyskiwania po awarii jest równie ważna, jak dobrze opracowany plan odzyskiwania po awarii. Wiele branż ma struktury zgodności, które wymagają regularnego wykonywania określonych prób odzyskiwania po awarii. Niezależnie od twojej branży regularne ćwiczenia odzyskiwania po awarii są najważniejsze dla Twojego sukcesu.

Postępuj zgodnie z następującymi zaleceniami dotyczącymi pomyślnego testowania odzyskiwania po awarii:

  • Wykonaj co najmniej jedno próbne odzyskiwanie po awarii w środowisku produkcyjnym rocznie. Ćwiczenia na tablecie (dry run) lub ćwiczenia nieprodukcyjne pomagają upewnić się, że zaangażowane strony znają swoje role i obowiązki. Te ćwiczenia pomagają również operatorom w budowaniu znajomości ("pamięci mięśniowej"), wykonując procesy odzyskiwania. Jednak tylko próbne środowiska produkcyjne naprawdę testuje ważność planu odzyskiwania po awarii oraz metryki celu odzyskiwania po awarii i celu punktu odzyskiwania. Użyj próbek produkcyjnych do procesów odzyskiwania czasu dla składników i przepływów, aby upewnić się, że cele celu czasu odzyskiwania i celu punktu odzyskiwania zdefiniowane dla obciążenia są osiągalne. W przypadku funkcji, które są poza kontrolą, takich jak propagacja DNS, upewnij się, że cele celu czasu odzyskiwania i celu punktu odzyskiwania dla przepływów, które obejmują te funkcje, z powodu możliwych opóźnień poza kontrolą.

  • Używaj ćwiczeń na tablecie nie tylko do budowania znajomości doświadczonych operatorów, ale także do edukacji nowych operatorów na temat procesów i procedur odzyskiwania po awarii. Starsi operatorzy powinni zająć trochę czasu, aby umożliwić nowym operatorom wykonywanie swojej roli i powinno watch w celu zwiększenia możliwości. Jeśli nowy operator jest niezdecydowany lub zdezorientowany krokem w procedurze, zapoznaj się z procedurą, aby upewnić się, że jest on wyraźnie napisany.

Zagadnienia do rozważenia

  • Wykonywanie próbnego odzyskiwania po awarii w środowisku produkcyjnym może spowodować nieoczekiwane awarie katastrofalne. Pamiętaj, aby przetestować procedury odzyskiwania w środowiskach nieprodukcyjnych podczas początkowych wdrożeń.

  • Zapewnij zespołowi jak najwięcej czasu konserwacji podczas ćwiczeń. Podczas planowania czasu konserwacji należy użyć metryk odzyskiwania, które są przechwytywane podczas testowania jako minimalny czas niezbędny przydziałów.

  • W miarę rozwoju praktyk testowania odzyskiwania po awarii dowiesz się, które procedury można uruchamiać równolegle i które należy uruchomić w sekwencji. Na początku praktyk przechodzenia do szczegółów załóżmy, że każda procedura musi być uruchamiana w sekwencji i że potrzebujesz dodatkowego czasu w każdym kroku, aby obsłużyć nieprzewidziane problemy.

Ułatwienia dla platformy Azure

Wiele produktów platformy Azure ma wbudowane możliwości trybu failover. Zapoznaj się z tymi możliwościami i uwzględnij je w procedurach odzyskiwania.

W przypadku systemów IaaS (infrastruktura jako usługa) użyj usługi Azure Site Recovery do automatyzacji pracy w trybie failover i odzyskiwania. Zapoznaj się z następującymi artykułami dotyczącymi typowych produktów PaaS:

Przykład

Zapoznaj się z serią odzyskiwania po awarii dla platformy danych Platformy danych Azure , aby uzyskać wskazówki dotyczące przygotowywania przedsiębiorstwa do odzyskiwania po awarii.

Lista kontrolna dotycząca niezawodności

Zapoznaj się z pełnym zestawem zaleceń.

Lista kontrolna dotycząca niezawodności