Co to są ciągłość działalności biznesowej, wysoka dostępność i odzyskiwanie po awarii?

W tym artykule zdefiniowano i opisano ciągłość działania oraz planowanie ciągłości działania w zakresie zarządzania ryzykiem dzięki wysokiej dostępności i projektowi odzyskiwania po awarii. Chociaż ten artykuł nie zawiera wyraźnych wskazówek dotyczących sposobu spełnienia własnych potrzeb związanych z ciągłością działalności biznesowej, ułatwia zrozumienie pojęć, które są używane w ramach wskazówek dotyczących niezawodności firmy Microsoft.

Ciągłość działania to stan, w którym firma może kontynuować operacje podczas usterek, przerw lub katastrof. Ciągłość działalności biznesowej wymaga proaktywnego planowania, przygotowania i implementacji odpornych systemów i procesów.

Planowanie ciągłości działania wymaga identyfikowania, zrozumienia, klasyfikowania i zarządzania ryzykiem. W oparciu o zrozumienie ryzyka i ich prawdopodobieństwa można zaprojektować plan dobrej ciągłości działania, aby osiągnąć strategię wysokiej dostępności i odzyskiwania po awarii (DR), która odpowiada potrzebom biznesowym.

Wysoka dostępność polega na projektowaniu rozwiązania, które ma być odporne na codzienne problemy i zaspokoić potrzeby biznesowe dotyczące dostępności.

Odzyskiwanie po katastrofie polega na planowaniu, jak radzić sobie z nietypowymi zagrożeniami i potencjalnymi katastrofalnymi awariami.

Ciągłość działalności biznesowej

Ogólnie rzecz biorąc, rozwiązania w chmurze są powiązane bezpośrednio z operacjami biznesowymi. Za każdym razem, gdy rozwiązanie w chmurze jest niedostępne lub występuje poważny problem, wpływ na operacje biznesowe może być poważny. Poważny wpływ może przerwać ciągłość działalności biznesowej.

Poważny wpływ na ciągłość działalności biznesowej może obejmować:

• Utrata dochodów z działalności gospodarczej.
• Niezdolność do zapewnienia użytkownikom ważnej usługi.
• Naruszenie zobowiązania, które zostało złożone klientowi lub innej osobie.

Ważne jest, aby zrozumieć i przekazać oczekiwania biznesowe oraz konsekwencje niepowodzeń ważnym uczestnikom projektu, w tym osobom, które projektują, implementują i obsługują obciążenie. Następnie osoby biorące udział w projekcie reagują, dzieląc koszty związane z osiągnięciem tej wizji. Zazwyczaj istnieje proces negocjacji i poprawek tej wizji w oparciu o budżet i inne ograniczenia.

Planowanie ciągłości działania

Aby kontrolować lub całkowicie uniknąć negatywnego wpływu na ciągłość działalności biznesowej, ważne jest, aby aktywnie tworzyć plan ciągłości działania. Plan ciągłości działania opiera się na ocenie ryzyka i opracowywaniu metod kontrolowania tych zagrożeń za pomocą różnych podejść. Konkretne zagrożenia i podejścia do ograniczania ryzyka różnią się w zależności od organizacji i obciążenia.

Plan ciągłości działania nie uwzględnia tylko funkcji odporności samej platformy w chmurze, ale także funkcji aplikacji. Niezawodny plan ciągłości działania obejmuje również wszystkie aspekty wsparcia w firmie, w tym osoby, procesy ręczne lub zautomatyzowane związane z biznesem oraz inne technologie.

Planowanie ciągłości działania powinno obejmować następujące kroki sekwencyjne:

1. Identyfikacja ryzyka. Identyfikowanie czynników ryzyka związanych z dostępnością lub funkcjonalnością obciążenia. Możliwe zagrożenia mogą być problemami z siecią, awariami sprzętu, błędami ludzkimi, awarią regionu itp. Zrozumienie wpływu każdego ryzyka.

2. Klasyfikacja ryzyka. Klasyfikuj każde ryzyko jako powszechne ryzyko, które powinno być uwzględnione w planach wysokiej dostępności, lub rzadkie ryzyko, które powinno być częścią planowania awaryjnego.

3. Ograniczenie ryzyka. Zaprojektuj strategie ograniczania ryzyka dla wysokiej dostępności (HA) lub odtwarzania po awarii (DR), aby zminimalizować lub ograniczyć ryzyko, stosując takie metody jak nadmiarowość, replikacja, tryb failover i kopie zapasowe. Należy również rozważyć nietechniczne i oparte na procesie środki zaradcze i mechanizmy kontroli.

Planowanie ciągłości działania jest procesem, a nie jednorazowym zdarzeniem. Każdy utworzony plan ciągłości działania powinien być regularnie przeglądany i aktualizowany w celu zapewnienia, że będzie on odpowiedni i skuteczny oraz że obsługuje bieżące potrzeby biznesowe.

Identyfikacja ryzyka

Początkową fazą planowania ciągłości działania jest zidentyfikowanie ryzyka związanego z dostępnością lub funkcjonalnością obciążenia. Każde ryzyko należy przeanalizować, aby zrozumieć jego prawdopodobieństwo i jego ważność. Ważność musi obejmować wszelkie potencjalne przestoje lub utratę danych, a także to, czy jakiekolwiek aspekty pozostałej części projektu rozwiązania mogą zrekompensować negatywne skutki.

Poniższa tabela to niewyczerpująca lista zagrożeń uporządkowana przez zmniejszenie prawdopodobieństwa:

Planowanie ciągłości działania nie dotyczy tylko platformy chmury i infrastruktury. Ważne jest, aby wziąć pod uwagę ryzyko błędów ludzkich. Ponadto niektóre zagrożenia, które tradycyjnie mogą być uważane za zabezpieczenia, wydajność lub ryzyko operacyjne, należy również uznać za ryzyko związane z niezawodnością, ponieważ wpływają one na dostępność rozwiązania.

Oto kilka przykładów:

Analiza trybu awarii (FMA) to proces identyfikowania potencjalnych sposobów awarii obciążenia lub jego składników oraz sposobu działania rozwiązania w tych sytuacjach. Aby dowiedzieć się więcej, zobacz Zalecenia dotyczące przeprowadzania analizy trybu awarii.

Klasyfikacja ryzyka

Plany ciągłości działania muszą dotyczyć zarówno typowych, jak i nietypowych zagrożeń.

• Typowe zagrożenia są planowane i oczekiwane. Na przykład w środowisku chmury często występują przejściowe awarie , w tym krótkie awarie sieci, ponowne uruchomienia sprzętu z powodu poprawek, przekroczenia limitu czasu, gdy usługa jest zajęta itd. Ponieważ te zdarzenia zdarzają się regularnie, obciążenia muszą być na nie odporne.

  Strategia wysokiej dostępności musi uwzględniać i kontrolować każde ryzyko tego typu.

• Nietypowe zagrożenia są zazwyczaj wynikiem nieprzewidzianego zdarzenia, takiego jak klęska żywiołowa lub poważny atak sieciowy, które mogą prowadzić do katastrofalnego przestoju.

  Procesy odzyskiwania po awarii zajmują się tymi rzadkimi zagrożeniami.

Wysoka dostępność i odzyskiwanie po awarii są ze sobą powiązane, dlatego ważne jest, aby zaplanować strategie obu.

Ważne jest, aby zrozumieć, że klasyfikacja zagrożeń zależy od architektury obciążenia i wymagań biznesowych, a niektóre zagrożenia mogą być klasyfikowane jako wysoka dostępność dla jednego obciążenia i odporność na awarie dla innego obciążenia. Na przykład, pełna awaria regionu Azure byłaby ogólnie uznawana za ryzyko DR dla obciążeń w tym regionie. Jednak w przypadku obciążeń korzystających z wielu regionów platformy Azure w konfiguracji aktywny-aktywny z pełną replikacją, redundancją i automatycznym przełączeniem awaryjnym regionu, awaria regionu w takim przypadku jest klasyfikowana jako ryzyko wysokiej dostępności.

Ograniczenie ryzyka

Ograniczenie ryzyka polega na opracowywaniu strategii WD lub OPW w celu zminimalizowania lub ograniczenia ryzyka związanego z ciągłością biznesu. Ograniczenie ryzyka może być oparte na technologii lub na podstawie człowieka.

Ograniczenie ryzyka opartego na technologii

Ograniczenie ryzyka oparte na technologii wykorzystuje mechanizmy kontroli ryzyka oparte na sposobie wdrażania i konfigurowania obciążenia, takich jak:

• Redundancja
• Replikacja danych
• Tryb przełączania awaryjnego
• Kopie zapasowe

Mechanizmy kontroli ryzyka oparte na technologii muszą być brane pod uwagę w kontekście planu ciągłości działania.

Na przykład:

• Wymagania dotyczące niskich przestojów. Niektóre plany ciągłości działania nie są w stanie tolerować żadnej formy ryzyka przestoju ze względu na rygorystyczne wymagania dotyczące wysokiej dostępności . Istnieją pewne mechanizmy kontroli oparte na technologii, które mogą wymagać czasu na powiadomienie człowieka, a następnie reagowanie. Mechanizmy kontroli ryzyka opartej na technologii, które obejmują powolne procesy ręczne, mogą nie być dopasowane do włączenia ich do strategii ograniczania ryzyka.

• Odporność na częściową awarię. Niektóre plany ciągłości działania są w stanie tolerować przepływ pracy uruchamiany w stanie obniżonej wydajności. Gdy rozwiązanie działa w stanie obniżonej wydajności, niektóre składniki mogą być wyłączone lub niefunkcjonalne, ale podstawowe operacje biznesowe mogą być nadal wykonywane. Aby dowiedzieć się więcej, zobacz Zalecenia dotyczące samonaprawiania i samozachowania.

Ograniczenie ryzyka opartego na człowieku

Ograniczenie ryzyka opartego na człowieku korzysta z mechanizmów kontroli ryzyka opartych na procesach biznesowych, takich jak:

• Uruchamianie procedury odpowiedzi.
• Powrót do operacji ręcznych.
• Szkolenia i zmiany kulturowe.

Ze względu na to, że mechanizmy kontroli ryzyka oparte na człowieku są często wolniejsze niż mechanizmy kontroli oparte na technologii i bardziej podatne na błędy ludzkie, dobry plan ciągłości działania powinien obejmować formalny proces kontroli zmian dla wszystkich elementów, które mogłyby zmienić stan działającego systemu. Rozważ na przykład zaimplementowanie następujących procesów:

• Rygorystycznie przetestuj obciążenia zgodnie z krytycznością obciążenia. Aby zapobiec problemom związanym ze zmianami, należy przetestować wszelkie zmiany wprowadzone w obciążeniu.
• Wprowadź strategiczne bramy jakości jako część bezpiecznych praktyk wdrażania obciążeń. Aby dowiedzieć się więcej, zobacz Zalecenia dotyczące bezpiecznych praktyk wdrażania.
• Sformalizuj procedury dostępu do produkcji ad hoc i manipulowania danymi. Te działania, niezależnie od tego, jak niewielkie, mogą stanowić wysokie ryzyko wystąpienia zdarzeń związanych z niezawodnością. Procedury mogą obejmować współpracę z innym inżynierem, używanie list kontrolnych i uzyskiwanie przeglądów od kolegów przed wykonaniem skryptów lub zastosowaniem zmian.

Wysoka dostępność

Wysoka dostępność to stan, w którym określone obciążenie może utrzymywać niezbędny poziom czasu pracy w ciągu dnia, nawet podczas przejściowych błędów i sporadycznych awarii. Ponieważ te zdarzenia są regularnie wykonywane, ważne jest, aby każde obciążenie zostało zaprojektowane i skonfigurowane pod kątem wysokiej dostępności zgodnie z wymaganiami określonych aplikacji i oczekiwań klientów. Wysoka dostępność każdego obciążenia przyczynia się do planu ciągłości działania.

Wysoka dostępność może się różnić w zależności od obciążenia, dlatego ważne jest, aby zrozumieć wymagania i oczekiwania klientów podczas określania wysokiej dostępności. Na przykład aplikacja używana przez organizację do zamawiania materiałów biurowych może wymagać stosunkowo niskiego poziomu czasu pracy, podczas gdy krytyczna aplikacja finansowa może wymagać znacznie wyższego czasu pracy. Nawet w ramach obciążenia różne przepływy mogą mieć różne wymagania. Na przykład w aplikacji handlu elektronicznego przepływy obsługujące przeglądanie i składanie zamówień mogą być ważniejsze niż przepływy przetwarzania zamówień i zaplecza. Aby dowiedzieć się więcej na temat przepływów, zobacz Zalecenia dotyczące identyfikowania i oceniania przepływów.

Często dostępność jest mierzona na podstawie liczby "dziewiątek" w procentach dostępności. Procent czasu pracy odnosi się do tego, jak dużo przestojów dopuszczasz w danym okresie czasu. Oto kilka przykładów:

• 99,9% wymaganie dostępności pozwala na około 43 minuty przestoju w miesiącu (trzy dziewiątki).
• 99,95% wymaganie czasu pracy (trzy i pół dziewiątki) pozwala na około 21 minut przestoju w miesiącu.

Im wyższe wymaganie dotyczące czasu pracy, tym mniejsza tolerancja dla przestojów, a im więcej pracy trzeba wykonać, aby osiągnąć ten poziom dostępności. Czas pracy nie jest mierzony przez czas pracy pojedynczego składnika, takiego jak węzeł, ale przez ogólną dostępność całego obciążenia.

Elementy projektu o wysokiej dostępności

Aby osiągnąć wymagania dotyczące wysokiej dostępności, obciążenie może zawierać wiele elementów projektowych. Niektóre typowe elementy są wymienione i opisane poniżej w tej sekcji.

Usługi i warstwy platformy Azure, które obsługują wysoką dostępność

Wiele usług platformy Azure jest przeznaczonych do wysokiej dostępności i może służyć do tworzenia obciążeń o wysokiej dostępności. Oto kilka przykładów:

• Zestawy skalowania maszyn wirtualnych platformy Azure zapewniają wysoką dostępność maszyn wirtualnych przez automatyczne tworzenie wystąpień maszyn wirtualnych i zarządzanie nimi oraz dystrybucję tych wystąpień maszyn wirtualnych w celu zmniejszenia wpływu awarii infrastruktury.
• Azure App Service zapewnia wysoką dostępność za pośrednictwem różnych metod, w tym automatycznego przenoszenia procesów roboczych z niefunkcjonalnego węzła do sprawnego węzła oraz oferując funkcje samonaprawy dla wielu typowych usterek.

Skorzystaj z każdego przewodnika niezawodności usługi, aby zrozumieć możliwości usługi, zdecydować, które poziomy mają być używane, i określić, które możliwości usługi uwzględnić w strategii wysokiej dostępności.

Zapoznaj się z umowami dotyczącymi poziomu usług (SLA) dla każdej usługi, aby zrozumieć oczekiwane poziomy dostępności i warunki, które należy spełnić. Może być konieczne wybranie lub uniknięcie określonych warstw usług w celu osiągnięcia określonych poziomów dostępności. Niektóre usługi firmy Microsoft są oferowane z założeniem, że nie jest podana umowa SLA, na przykład dla warstw deweloperskich lub podstawowych, lub że zasób może zostać odzyskany z uruchomionego systemu, jak w przypadku ofert opartych na modelu spot. Ponadto niektóre warstwy mają dodatkowe funkcje niezawodności, takie jak obsługa stref dostępności.

Odporność na uszkodzenia

Odporność na uszkodzenia to możliwość kontynuowania działania systemu w określonej pojemności w przypadku awarii. Na przykład aplikacja internetowa może być zaprojektowana tak, aby kontynuować działanie, nawet jeśli pojedynczy serwer internetowy ulegnie awarii. Odporność na uszkodzenia można osiągnąć za pomocą nadmiarowości, trybu failover, partycjonowania, łagodnego obniżenia wydajności i innych technik.

Odporność na uszkodzenia wymaga również, aby aplikacje obsługiwały błędy przejściowe. Podczas tworzenia własnego kodu może być konieczne samodzielne włączenie obsługi błędów przejściowych. Niektóre usługi platformy Azure zapewniają wbudowaną obsługę błędów przejściowych w niektórych sytuacjach. Na przykład, domyślnie Azure Logic Apps automatycznie ponawia nieudane żądania do innych usług. Aby dowiedzieć się więcej, zobacz Zalecenia dotyczące obsługi błędów przejściowych.

Redundancja

Nadmiarowość to praktyka duplikowania wystąpień lub danych w celu zwiększenia niezawodności obciążenia.

Zwiększenie niezawodności można osiągnąć poprzez dystrybucję replik lub instancji zapasowych w co najmniej jeden z następujących sposobów:

• Wewnątrz centrum danych (nadmiarowość lokalna)
• Między strefami dostępności w regionie (redundancja strefy)
• Między regionami (nadmiarowość geograficzna).

Oto kilka przykładów sposobu, w jaki niektóre usługi platformy Azure zapewniają opcje nadmiarowości:

• Azure App Service umożliwia uruchamianie wielu wystąpień aplikacji, aby zapewnić, że aplikacja jest dostępna nawet w przypadku awarii jednego wystąpienia. Jeśli włączysz strefową nadmiarowość, te wystąpienia są rozłożone na wiele stref dostępności w używanym regionie Azure.
• Usługa Azure Storage zapewnia wysoką dostępność przez automatyczne replikowanie danych co najmniej trzy razy. Można dystrybuować te repliki w różnych strefach dostępności, poprzez włączenie magazynu strefowo nadmiarowego (ZRS). W wielu regionach można także replikować dane magazynu do innych regionów przy użyciu magazynu geograficznie nadmiarowego (GRS).
• Usługa Azure SQL Database ma wiele replik, aby upewnić się, że dane pozostają dostępne nawet w przypadku awarii jednej repliki.

Aby dowiedzieć się więcej o sposobie działania nadmiarowości, zobacz nadmiarowość, replikacja i tworzenie kopii zapasowych. Aby dowiedzieć się więcej o sposobie stosowania nadmiarowości w rozwiązaniu, zobacz Zalecenia dotyczące projektowania pod kątem nadmiarowości i zalecenia dotyczące używania stref dostępności i regionów.

Skalowalność i elastyczność

Skalowalność i elastyczność to możliwości systemu do obsługi zwiększonego obciążenia przez dodawanie i usuwanie zasobów (skalowalność) oraz szybkie zmienianie wymagań (elastyczność). Skalowalność i elastyczność mogą pomóc systemowi w utrzymaniu dostępności podczas szczytowych obciążeń.

Wiele usług platformy Azure obsługuje skalowalność. Oto kilka przykładów:

• Zestawy skalowania maszyn wirtualnych platformy Azure, usługa Azure API Management i kilka innych usług obsługują automatyczne skalowanie usługi Azure Monitor. Dzięki funkcji automatycznego skalowania w Azure Monitorze można ustawić zasady, takie jak "gdy mój procesor stale przekracza 80%, dodaj kolejne wystąpienie".
• Usługa Azure Functions może dynamicznie aprowizować wystąpienia w celu obsługi żądań.
• Usługa Azure Cosmos DB obsługuje autoskalowaną przepływność, dzięki czemu usługa może automatycznie zarządzać zasobami przypisanymi do baz danych na podstawie podanych zasad.

Skalowalność jest kluczowym czynnikiem, który należy wziąć pod uwagę podczas częściowej lub całkowitej awarii. Jeśli replika lub instancja obliczeniowa jest niedostępna, pozostałe elementy mogą być zmuszone przejąć większe obciążenie, aby obsłużyć obciążenie, które wcześniej było obsługiwane przez uszkodzony węzeł. Rozważ nadprowizjowanie, jeśli Twój system nie może się wystarczająco szybko skalować, aby obsłużyć oczekiwane zmiany obciążenia.

Aby uzyskać więcej informacji na temat projektowania skalowalnego i elastycznego systemu, zobacz Zalecenia dotyczące projektowania niezawodnej strategii skalowania.

Techniki wdrażania bez przestojów

Wdrożenia i inne zmiany systemowe powodują znaczne ryzyko przestoju. Ponieważ ryzyko przestoju jest wyzwaniem dla wymagań dotyczących wysokiej dostępności, ważne jest użycie praktyk wdrażania bez przestojów w celu wprowadzania aktualizacji i zmian konfiguracji bez konieczności przestoju.

Techniki wdrażania bez przestojów mogą obejmować:

• Aktualizowanie podzbioru zasobów jednocześnie.
• Kontrolowanie ilości ruchu, który dociera do nowego wdrożenia.
• Monitorowanie dowolnego wpływu na użytkowników lub system.
• Szybkie rozwiązanie problemu, na przykład przez przywrócenie poprzedniego sprawdzonego dobrego wdrożenia.

Aby dowiedzieć się więcej na temat technik wdrażania bez przestojów, zobacz Bezpieczne praktyki wdrażania.

Sama platforma Azure używa metod wdrażania bez przestojów dla naszych własnych usług. Podczas tworzenia własnych aplikacji można wdrażać wdrożenia bez przestojów za pomocą różnych metod, takich jak:

• Usługa Azure Container Apps udostępnia wiele poprawek aplikacji, których można użyć do osiągnięcia wdrożeń bez przestojów.
• Usługa Azure Kubernetes Service (AKS) obsługuje różne techniki wdrażania bez przestojów.

Chociaż wdrożenia bez przestojów są często skojarzone z wdrożeniami aplikacji, należy ich również używać do zmian konfiguracji. Poniżej przedstawiono kilka sposobów bezpiecznego stosowania zmian konfiguracji:

• Usługa Azure Storage umożliwia zmianę kluczy dostępu do konta magazynu na wielu etapach, co zapobiega przestojom podczas operacji rotacji kluczy.
• aplikacja systemu Azure Configuration udostępnia flagi funkcji, migawki i inne funkcje ułatwiające kontrolowanie sposobu stosowania zmian konfiguracji.

Jeśli zdecydujesz się nie implementować wdrożeń bez przestojów, upewnij się, że zdefiniujesz okna obsługi, aby można było wprowadzać zmiany systemu w czasie, gdy użytkownicy tego oczekują.

Testowanie automatyczne

Ważne jest, aby przetestować zdolność rozwiązania do wytrzymania awarii i usterek, które uznajesz za część Wysokiej Dostępności. Wiele z tych błędów można symulować w środowiskach testowych. Testowanie możliwości automatycznego tolerowania lub odzyskiwania po różnych typach błędów jest nazywane inżynierią chaosu. Inżynieria chaosu ma kluczowe znaczenie dla dojrzałych organizacji o rygorystycznych standardach dotyczących wysokiej dostępności. Azure Chaos Studio to narzędzie do inżynierii chaosu, które może symulować niektóre typowe typy błędów.

Aby dowiedzieć się więcej, zobacz Zalecenia dotyczące projektowania strategii testowania niezawodności.

Monitorowanie i zgłaszanie alertów

Monitorowanie informuje o kondycji systemu, nawet gdy mają miejsce zautomatyzowane środki zaradcze. Monitorowanie ma kluczowe znaczenie dla zrozumienia, jak działa twoje rozwiązanie, oraz do obserwowania wczesnych sygnałów awarii, takich jak zwiększone współczynniki błędów lub wysokie zużycie zasobów. Dzięki alertom możesz aktywnie otrzymywać ważne zmiany w środowisku.

Platforma Azure oferuje różne funkcje monitorowania i alertów, w tym następujące:

• Usługa Azure Monitor zbiera dzienniki i metryki z zasobów i aplikacji platformy Azure oraz może wysyłać alerty i wyświetlać dane na pulpitach nawigacyjnych.
• Usługa Azure Monitor Application Insights zapewnia szczegółowe monitorowanie aplikacji.
• Usługa Azure Service Health i usługa Azure Resource Health monitorują kondycję platformy Azure i zasobów.
• Zaplanowane zdarzenia doradzają, gdy konserwacja jest planowana dla maszyn wirtualnych.

Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące projektowania niezawodnej strategii monitorowania i zgłaszania alertów.

Odzyskiwanie po awarii

Katastrofa to odrębne, nietypowe, poważne zdarzenie, które ma większy i długotrwały wpływ, niż aplikacja jest w stanie zrównoważyć poprzez aspekt wysokiej dostępności w projekcie. Przykłady awarii to:

• Klęski żywiołowe, takie jak huragany, trzęsienia ziemi, powodzie lub pożary.
• Błędy ludzkie, które powodują poważny wpływ, na przykład przypadkowe usunięcie danych produkcyjnych lub nieprawidłowo skonfigurowaną zaporę, która uwidacznia poufne dane.
• Główne zdarzenia zabezpieczeń, takie jak ataki typu "odmowa usługi" lub ataki wymuszające okup, które prowadzą do uszkodzenia danych, utraty danych lub awarii usługi.

Odzyskiwanie po awarii polega na planowaniu sposobu reagowania na tego typu sytuacje.

Wymagania dotyczące odzyskiwania po awarii

Ze względu na rzadkość i surowość zdarzeń katastrofalnych, planowanie DR stawia różne oczekiwania względem twojej reakcji. Wiele organizacji akceptuje fakt, że w scenariuszu awarii pewien poziom przestoju lub utraty danych jest nieunikniony. Kompletny plan odzyskiwania po awarii musi określać następujące krytyczne wymagania biznesowe dla każdego przepływu:

• Cel punktu odzyskiwania (RPO) to maksymalny czas trwania akceptowalnej utraty danych w przypadku awarii. RPO jest mierzone w jednostkach czasu, takich jak "30 minut danych" lub "cztery godziny danych".

• Cel czasu odzyskiwania (RTO) to maksymalny czas trwania akceptowalnego przestoju w przypadku awarii, w którym "przestój" jest definiowany przez specyfikację. RTO (czas odzyskiwania) jest również mierzony w jednostkach czasu, takich jak "osiem godzin przestoju".

Każdy składnik lub przepływ w obciążeniu może mieć indywidualne wartości celu punktu odzyskiwania (RPO) i celu czasu odzyskiwania (RTO). Zapoznaj się z ryzykiem scenariusza awarii i potencjalnymi strategiami odzyskiwania podczas podejmowania decyzji o wymaganiach. Proces określania celu punktu odzyskiwania i celu czasowego odzyskiwania w efekcie tworzy wymagania odzyskiwania po awarii dla obciążenia w wyniku unikalnych wymagań biznesowych (kosztów, wpływu, utraty danych itp.).

Plany odzyskiwania po awarii

Niezależnie od przyczyny awarii ważne jest utworzenie dobrze zdefiniowanego i testowalnego planu odzyskiwania po awarii. Ten plan będzie wykorzystywany jako część projektowania infrastruktury i aplikacji, aby aktywnie je wspierać. Możesz utworzyć wiele planów awaryjnych dla różnych typów sytuacji. Plany odzyskiwania po awarii często polegają na kontrolach procesów i ręcznej interwencji.

DR nie jest funkcją automatyczną w Azure. Jednak wiele usług udostępnia funkcje i możliwości, których można użyć do wsparcia strategii odzyskiwania danych po awarii. Zapoznaj się z przewodnikami dotyczącymi niezawodności dla każdej usługi platformy Azure, aby zrozumieć, jak działa usługa i jej możliwości, a następnie zamapować te możliwości na plan odzyskiwania po awarii.

W poniższych sekcjach wymieniono niektóre typowe elementy planu odzyskiwania po awarii i opisano, jak platforma Azure może ci pomóc w ich osiągnięciu.

Przełączenie awaryjne i powrót po awarii

Niektóre plany odzyskiwania po awarii obejmują aprowizowanie wdrożenia pomocniczego w innej lokalizacji. Jeśli awaria wpłynie na podstawowe wdrożenie rozwiązania, ruch może zostać przekierowany do innej lokalizacji. Tryb failover wymaga starannego planowania i wdrożenia. Platforma Azure oferuje różne usługi ułatwiające przejście w tryb failover, takie jak:

• Usługa Azure Site Recovery zapewnia automatyczne przechodzenie w tryb failover dla środowisk lokalnych i rozwiązań hostowanych na maszynach wirtualnych na platformie Azure.
• Usługi Azure Front Door i Azure Traffic Manager obsługują automatyczne przełączanie ruchu przychodzącego w tryb failover między różnymi wdrożeniami rozwiązania, na przykład w różnych regionach.

Zwykle potrzeba trochę czasu, aby tryb failover wykrył, że wystąpienie podstawowe uległo awarii, i aby przełączyć się na wystąpienie pomocnicze. Upewnij się, że RTO obciążenia jest zgodne z czasem przełączenia awaryjnego.

Ważne jest również, aby rozważyć przywracanie po awarii, czyli proces, w którym przywracasz operacje w regionie podstawowym po jego odzyskaniu. Powrót po awarii może być złożony zarówno do zaplanowania, jak i wdrożenia. Na przykład dane w regionie podstawowym mogły zostać zapisane po rozpoczęciu przełączania awaryjnego. Musisz podjąć staranne decyzje biznesowe dotyczące sposobu obsługi tych danych.

Aby uzyskać więcej informacji, zobacz failover i failback.

Kopie zapasowe

Kopie zapasowe obejmują pobranie kopii danych i bezpieczne przechowywanie ich przez określony czas. Dzięki kopiom zapasowym można odzyskać dane po awariach, gdy automatyczne przejście w tryb failover do innej repliki nie jest możliwe lub gdy wystąpiło uszkodzenie danych.

W przypadku korzystania z kopii zapasowych w ramach planu odzyskiwania po awarii należy wziąć pod uwagę następujące kwestie:

• Lokalizacja magazynu. W przypadku korzystania z kopii zapasowych w ramach planu odzyskiwania po awarii powinny one być przechowywane oddzielnie dla głównych danych. Zazwyczaj kopie zapasowe są przechowywane w innym regionie świadczenia usługi Azure.

• Utrata danych. Ponieważ kopie zapasowe są zwykle wykonywane rzadko, przywracanie kopii zapasowych zwykle wiąże się z utratą danych. Z tego powodu odzyskiwanie kopii zapasowej powinno być używane w ostateczności, a plan odzyskiwania po awarii powinien określać sekwencję kroków i prób odzyskiwania, które należy wykonać przed przywróceniem z kopii zapasowej. Ważne jest, aby dopilnować, że RPO obciążenia jest zgodne z interwałem tworzenia kopii zapasowej.

• Czas odzyskiwania. Przywracanie kopii zapasowej często zajmuje dużo czasu, dlatego ważne jest przetestowanie kopii zapasowych i procesów przywracania w celu zweryfikowania ich integralności i zrozumienia, jak długo trwa proces przywracania. Upewnij się, że czas przywrócenia kopii zapasowej jest uwzględniony w RTO obciążenia.

Wiele usług danych i magazynowania platformy Azure obsługuje kopie zapasowe, takie jak:

• Usługa Azure Backup udostępnia automatyczne kopie zapasowe dla dysków maszyn wirtualnych, kont magazynu, usługi AKS i różnych innych źródeł.
• Wiele usług baz danych platformy Azure, w tym usług Azure SQL Database i Azure Cosmos DB, ma funkcję automatycznego tworzenia kopii zapasowych baz danych.
• Usługa Azure Key Vault udostępnia funkcje umożliwiające tworzenie kopii zapasowych wpisów tajnych, certyfikatów i kluczy.

Wdrożenia automatyczne

Aby szybko wdrożyć i skonfigurować wymagane zasoby w przypadku awarii, użyj zasobów infrastruktury jako kodu (IaC), takich jak pliki Bicep, szablony usługi ARM lub plik konfiguracji narzędzia Terraform. Użycie IaC skraca czas odzyskiwania i potencjalne błędy w porównaniu z ręcznym wdrażaniem i konfigurowaniem zasobów.

Testowanie i ćwiczenia

Ważne jest, aby rutynowo weryfikować i testować plany odzyskiwania po awarii, a także szerszą strategię niezawodności. Uwzględnij wszystkie procesy ludzkie w ćwiczeniach i nie skupiaj się tylko na procesach technicznych.

Jeśli nie przetestowano procesów odzyskiwania w symulacji awarii, prawdopodobnie wystąpią poważne problemy podczas korzystania z nich w rzeczywistej awarii. Ponadto, testując plany odzyskiwania po awarii i wymagane procesy, można zweryfikować wykonalność celu odzyskiwania.

Aby dowiedzieć się więcej, zobacz Zalecenia dotyczące projektowania strategii testowania niezawodności.

Powiązana zawartość

• Skorzystaj z przewodników dotyczących niezawodności usług platformy Azure, aby dowiedzieć się, jak każda usługa platformy Azure obsługuje niezawodność w projekcie, oraz dowiedzieć się więcej o możliwościach, które można utworzyć w planach wysokiej dostępności i odzyskiwania po awarii.
• Skorzystaj z filaru Niezawodność Azure Well-Architected Framework, by dowiedzieć się więcej na temat projektowania niezawodnego obciążenia roboczego na platformie Azure.
• Skorzystaj z perspektywy dobrze zaprojektowanej struktury dla usług platformy Azure, aby dowiedzieć się więcej o sposobie konfigurowania każdej usługi platformy Azure w celu spełnienia wymagań dotyczących niezawodności i innych filarów dobrze zaprojektowanej struktury.
• Aby dowiedzieć się więcej na temat planowania odzyskiwania po awarii, zobacz Zalecenia dotyczące projektowania strategii odzyskiwania po awarii.