Rekomendacje dotyczące projektowania strategii odzyskiwania po awarii
Dotyczy tego Power Platform zalecenia dotyczącego listy kontrolnej niezawodności Well-Architected Reliability:
| RE:07 | Zaimplementowanie strukturalnych, przetestowanych i udokumentowanych planów ciągłości biznesowej i odzyskiwania danych (BCDR) zgodne z celami odzyskiwania danych. W planach muszą zostać także dodane wszystkie składniki i system jako całość. |
|---|
W tym przewodniku opisano zalecenia dotyczące projektowania wiarygodnej strategii odzyskiwania po awarii w przypadku obciążenia. Aby spełnić wewnętrzne cele na poziomie usługi (SLO), a nawet umowy dotyczące poziomu usług (SLA), które gwarantuje klientom, należy posiadać niezawodną i wiarygodną strategie odzyskiwania po awarii. Oczekiwane są niepowodzenia i inne duże problemy. Przygotowania do zajścia tych zdarzeń określają, jak bardzo klienci mogą zaufać firmie pod kątem świadczenia ich w sposób wiarygodny. Strategia odzyskiwania po awarii stanowi podstawę przygotowania do istotnych zdarzeń.
Definicje
| Termin | Definicja |
|---|---|
| Tryb failover | Zautomatyzowane i/lub ręczne przeniesienie ruchu w obciążeniach produkcyjnych z niedostępnego regionu do regionu, który nie ma wpływu na dane. |
| Powrót po awarii | Zautomatyzowane i/lub ręczne przeniesienie ruchu w obciążeniach produkcyjnych z regionu trybu failover do regionu podstawowego. |
Kluczowe strategie projektowania
W tym podręczniku przyjęto, że w ramach planowania niezawodności zostały już wykonane następujące zadania:
Określenie przepływów krytycznych i niekrytycznych.
Wykonanie analizy trybu awarii (FAM) dla przepływów.
Zidentyfikowanie celów niezawodności.
Zaprojektowanie niezawodnej strategii testowania.
Wiarygodne architektury obciążenia stanowi podstawę wiarygodnej strategii odzyskiwania po awarii (DR). Przed rozpoczęciem planowania strategii odzyskiwania oprogramowania należy rozważyć niezawodność na każdym etapie tworzenia obciążenia, aby upewnić się, że są potrzebne składniki niezbędne do efektywnego odzyskiwania danych. Dzięki temu cele niezawodności w tym zakresie, takie jak cel naprawy (RTO) i cel punktu odzyskiwania (RPO), są praktyczne i możliwe do osiągnięcia.
Utrzymywanie planu odzyskiwania po awarii
Kluczem do wiarygodnej strategii DR dla obciążenia jest plan DR. Plan powinien być żywym dokumentem, który jest regularnie poprawiany i aktualizowany wraz ze zmianą środowiska. Regularnie udostępniaj plan odpowiednim zespołom (operacyjny, kierownictwo ds. technologii i interesariusze) (na przykład co sześć miesięcy). Należy zachować go w wysoko dostępnym, bezpiecznym magazynie danych, takim jak OneDrive.
Wykonaj następujące zalecenia w celu opracowania planu DR:
Należy dokładnie zdefiniować, co stanowi awarię i wymaga aktywacji planu DR.
Awarie to problemy na dużą skalę. Mogą to być regionalne przestoje, awarie usług, takich jak Microsoft Entra ID lub usługa Azure DNS, albo poważne złośliwe ataki, np. oprogramowanie wymuszające okup lub atak DDoS.
W planie DR należy uwzględnić przykłady trybów awarii, które nie są traktowane jako awaria, np. niedostępność jednego zasobu lub awaria pojedynczego zasobu, aby operatorzy przez pomyłkę nie wywoływali eskalacji DR.
Stwórz plan DR w oparciu o dokumentację FMA. Należy upewnić się, że plan DR rejestruje tryby failover i strategie ograniczenia ryzyka dla przestojów zdefiniowanych jako katastrofy. Jeśli wymagane są aktualizacje, należy zaktualizować jednocześnie plan DR i dokumenty FMA, aby były dokładne, gdy środowisko się zmieni lub podczas testowania odkrywa nieoczekiwane zachowanie.
Jasno zdefiniuj role i obowiązki zespołu obsługi obciążenia i zrozum wszystkie powiązane z nimi role zewnętrzne w organizacji. Jeśli awaria jest spowodowana przez awarię usługi zewnętrznej, takiej jak Microsoft Entra ID, upewnij się, że zdefiniowano rolę, która jest odpowiedzialna za komunikację ze stroną zewnętrzną, i można udostępnić aktualizacje zespołowi obciążenia. Role powinny obejmować:
- Strona odpowiedzialna za deklarowanie awarii
- Strona odpowiedzialna za deklarowanie zamknięcie zdarzenia
- Role operacji
- Role testowania i walidacji
- Wewnętrzne i zewnętrzne role w komunikacji
- Role liderów dla retrospektywy i analizy głównej przyczyny (RCA)
Zdefiniuj ścieżki eskalacji, które musi wykonać zespół obciążenia, aby zapewnić, że informacje o stanie odzyskiwania będą przekazywane interesariuszom.
Należy uwzględnić kolejność, w jakiej składniki obciążenia należy odzyskać, aby miało to najmniejszy wpływ. Na przykład przed odzyskiwaniem aplikacji należy odzyskać bazy danych i ponownie uruchomić przepływy w chmurze.
Szczegółowe informacje o procedurze odzyskiwania poszczególnych składników są opisane w przewodniku krok po kroku. W miarę możliwości dołącz zrzuty ekranów oraz wymagania wstępne procedury. Można na przykład wyświetlić listę wymaganych skryptów lub poświadczeń, które trzeba gromadzić.
Zdefiniuj obowiązki swojego zespołu w stosunku do obowiązków dostawcy hostingu w chmurze. Na przykład jest Microsoft odpowiedzialny za przywracanie PaaS (platformy jako usługi), ale jesteś odpowiedzialny za ponowne wypełnianie danych i stosowanie konfiguracji do usługi.
Przed rozpoczęciem odzyskiwania należy przechwycić główną przyczynę zdarzenia i wykonać ograniczanie ryzyka. Jeśli na przykład przyczyna zdarzenia stanowi problem z bezpieczeństwem, należy zawęzić ten problem przed odzyskiwania systemów, których dotyczył problem w środowisku trybu failover.
Jeśli trzeba ponownie wdrożyć aplikację w środowisku trybu failover, użyj narzędzi, aby zautomatyzować proces wdrażania w jak najwyższym możliwym terminie. Upewnij się, że usługa Azure Pipelines została wstępnie wdrożona i poprawnie skonfigurowana w środowiskach trybu failover, dzięki czemu można natychmiast rozpocząć wdrożenia. Zautomatyzowane kompleksowe wdrożenia z ręcznym zatwierdzaniem w razie potrzeby, aby zapewnić spójny i wydajny proces wdrażania. Jeśli na etapie procesu wdrażania jest wymagana interwencja ręczna, należy dokumentować kroki ręczne. Jasno zdefiniuj role i obowiązki.
Zautomatyzuj jak najwięcej procedur. Użycie logiki ponowień pozwala uniknąć marnowania czasu na skrypty, które zatrzymały się na zerwanym zadaniu. Ponieważ skrypty te są uruchamiane tylko w sytuacjach awaryjnej, nie należy nieprawidłowo tworzyć skryptów, które będą powodować większe błędy lub spowalniać proces odzyskiwania.
Uwaga
Automatyzacja powoduje ryzyko. Przeszkoleni operatorzy muszą uważnie monitorować zautomatyzowane procesy i interweniować w razie napotkania problemów z procesem. Aby zminimalizować ryzyko, że automatyzacja zareaguje na fałszywy alarm, należy dokładnie przejść do szczegółów DR. Przetestuj wszystkie etapy planu. Wykrywaj duplikaty w celu wygenerowania alertów i przejścia przez całą procedurę odzyskiwania.
Przeprowadzanie próbnego odzyskiwania danych
Dobrym planem dla DR jest przetestowanie metody testowania DR. Wiele branży ma struktury zgodności, które wymagają regularnego próbnego odzyskiwania po awarii. Niezależnie od branży częste próbne odzyskiwanie po awarii ma kluczowe znaczenie dla sukcesu.
Aby pomyślnie wykonać próbne DR, wykonaj następujące zalecenia:
Wykonaj co najmniej jedno produkcyjne próbne DR na rok. Wypróbuj uruchomienia próbne lub nieprodukcyjne pomagają zagwarantować, że strony zaznajomią się z rolami i obowiązkami. Te próbne operacje ułatwiają także operatorom tworzenie znajomości przez przechodzenie do procesów odzyskiwania. Jednak tylko próbne DR produkcyjne w pełni testują plany DR oraz metryki RTO i RPO. Użyj szczegółów produkcyjnych do procesów odzyskiwania czasu dla składników i przepływów, aby zapewnić, że wartości docelowe RTO i RPO zdefiniowane dla obciążenia są dostępne. W przypadku funkcji, które są poza kontrolą, takich jak Microsoft Entra ID, upewnij się, że wartości docelowe RTO i RPO dla przepływów, które obejmują te funkcje, obejmują też możliwe opóźnienia poza kontrolą.
Użyj próbnego uruchamiania w celu edukowania nowych operatorów o procesach i procedurach DR. Starsi operatorzy powinni zająć się wykonywaniem swoich ról przez nowych operatorów, a także obserwować szanse poprawy jakości. Jeśli nowy operator waha się lub nie rozumie kroku procedury, należy przejrzeć tę procedurę, aby upewnić się, że jest ona dobrze napisana.
Kwestie wymagające rozważenia
Wykonywanie próbnych DR w środowisku produkcyjnym może spowodować nieoczekiwane awarie. Podczas początkowych wdrożeń należy pamiętać o przetestowaniu procedur odzyskiwania w środowiskach nieprodukcyjnych.
Podczas próbnych uruchomień należy zapewnić zespołowi jak najwięcej czasu konserwacji. Podczas planowania czasu konserwacji należy wykorzystać metryki odzyskiwania zarejestrowane podczas testowania jako minimalny niezbędny czas.
W miarę dojrzewania praktyk próbnych DR poznajesz procedury, które można uruchomić równocześnie i które należy kolejno uruchomić. Na wczesnym etapie praktyk próbnego DR należy przyjąć, że każda procedura musi być uruchamiana kolejno i że w każdym kroku trzeba dodatkowy czas na rozwiązanie nieprzewidzianych problemów.
Możliwości trybu failover
Microsoft Aplikacje biznesowe zapewniają funkcje ciągłości działania i odzyskiwania po awarii (BCDR) we wszystkich środowiskach produkcyjnych w Dynamics 365 i Power Platform aplikacjach typu oprogramowanie jako usługa (SAAS). Dowiedz się, jak Microsoft zapewnić odporność danych produkcyjnych na regionalne przestoje.
Lista kontrolna niezawodności
Zapoznaj się z kompletną zestawem zaleceń.