Zarządzanie ciągłością działalności biznesowej na platformie Azure
Platforma Azure utrzymuje jeden z najbardziej dojrzałych i szanowanych programów zarządzania ciągłością działalności biznesowej w branży. Celem ciągłości działalności biznesowej na platformie Azure jest tworzenie i rozwijanie możliwości odzyskiwania i odporności dla wszystkich niezależnie odzyskiwalnych usług, niezależnie od tego, czy usługa jest dostępna dla klientów (część oferty platformy Azure), czy wewnętrzna usługa platformy pomocniczej.
W zrozumieniu ciągłości działalności biznesowej należy pamiętać, że wiele ofert składa się z wielu usług. Na platformie Azure każda usługa jest statycznie identyfikowana za pomocą narzędzi i jest jednostką miary używanej do ochrony prywatności, zabezpieczeń, spisu, zarządzania ciągłością biznesową ryzyka i innymi funkcjami. Aby prawidłowo zmierzyć możliwości usługi, trzy elementy osób, procesów i technologii są uwzględniane dla każdej usługi, niezależnie od typu usługi.
Przykład:
- Jeśli istnieje proces biznesowy oparty na osobach, takich jak dział pomocy technicznej lub zespół, dostarczanie usług jest tym, co robią. Osoby używają procesów i technologii do wykonywania usługi.
- Jeśli istnieje technologia jako usługa, taka jak usługa Azure Virtual Machines, dostarczanie usługi jest technologią wraz z osobami i procesami, które obsługują jej działanie.
Model wspólnej odpowiedzialności
Wiele ofert oferowanych przez platformę Azure wymaga od klientów skonfigurowania odzyskiwania po awarii w wielu regionach i nie ponosi odpowiedzialności firmy Microsoft. Nie wszystkie usługi platformy Azure automatycznie replikują dane lub automatycznie wracają z regionu, który zakończył się niepowodzeniem, aby przeprowadzić replikację krzyżową do innego włączonego regionu. W takich przypadkach klient musi skonfigurować odzyskiwanie i replikację.
Firma Microsoft zapewnia dostępność podstawowej infrastruktury i usług platformy. Jednak w niektórych scenariuszach użycie wymaga od klienta zduplikowania wdrożeń i magazynu w pojemności obejmującej wiele regionów, jeśli zdecyduje się na to. Te przykłady ilustrują model wspólnej odpowiedzialności. Jest to podstawowy filar strategii ciągłości działania i odzyskiwania po awarii.
Podział odpowiedzialności
W dowolnym lokalnym centrum danych jesteś właścicielem całego stosu. Podczas przenoszenia zasobów do chmury niektóre obowiązki są przenoszone do firmy Microsoft. Na poniższym diagramie przedstawiono obszary i podział odpowiedzialności między Użytkownika a firmą Microsoft zgodnie z typem wdrożenia.
Dobrym przykładem modelu wspólnej odpowiedzialności jest wdrożenie maszyn wirtualnych. Jeśli klient chce skonfigurować replikację między regionami w celu zapewnienia odporności w przypadku awarii regionu, musi wdrożyć zduplikowany zestaw maszyn wirtualnych w alternatywnym regionie włączonym. Platforma Azure nie replikuje automatycznie tych usług, jeśli wystąpi awaria. Klient jest odpowiedzialny za wdrożenie niezbędnych zasobów. Klient musi mieć proces ręcznej zmiany regionów podstawowych lub musi użyć usługi Traffic Manager do wykrywania i automatycznego przełączania w tryb failover.
Wszystkie usługi odzyskiwania po awarii z obsługą klienta mają publiczną dokumentację, aby cię poprowadzić. Aby zapoznać się z przykładem publicznej dokumentacji dotyczącej odzyskiwania po awarii z obsługą klienta, zobacz Azure Data Lake Analytics.
Aby uzyskać więcej informacji na temat modelu wspólnej odpowiedzialności, zobacz Centrum zaufania firmy Microsoft.
Zgodność z ciągłością działania: Odpowiedzialność na poziomie usługi
Każda usługa jest wymagana do ukończenia rekordów odzyskiwania po awarii ciągłości działania w narzędziu Azure Business Continuity Manager. Właściciele usług mogą używać narzędzia do pracy w modelu federacyjnym w celu spełnienia i uwzględnienia wymagań, które obejmują:
Właściwości usługi: definiuje usługę oraz sposób osiągnięcia odzyskiwania po awarii i odporności oraz identyfikowania strony odpowiedzialnej za odzyskiwanie po awarii (dla technologii). Aby uzyskać szczegółowe informacje na temat własności odzyskiwania, zobacz dyskusję na temat modelu wspólnej odpowiedzialności w poprzedniej sekcji i diagramie.
Analiza wpływu na działalność biznesową: Ta analiza pomaga właścicielowi usługi zdefiniować cel czasu odzyskiwania (RTO) i cel punktu odzyskiwania (RPO) na podstawie krytycznego znaczenia usługi w tabeli wpływu. Działania, prawne, prawne, prawne, wizerunki marki i wpływy finansowe są używane jako cele docelowe do odzyskania.
Uwaga
Firma Microsoft nie publikuje obiektów RTO ani RPO dla usług, ponieważ te dane są przeznaczone tylko dla miar wewnętrznych. Wszystkie obietnice i miary klientów są oparte na umowie SLA, ponieważ obejmuje szerszy zakres w porównaniu z celami czasu odzyskiwania lub celu punktu odzyskiwania, który ma zastosowanie tylko w przypadku katastrofatycznej utraty.
Zależności: każda usługa mapuje zależności (inne usługi), których wymaga, niezależnie od tego, jak krytyczne i jest mapowane na środowisko uruchomieniowe, wymagane tylko do odzyskiwania lub oba te elementy. Jeśli istnieją zależności magazynu, inne dane są mapowane, które definiują, co jest przechowywane, i jeśli na przykład wymagają migawek do punktu w czasie.
Pracownicy: Jak wspomniano w definicji usługi, ważne jest, aby poznać lokalizację i ilość pracowników, którzy mogą wspierać usługę, zapewniając brak pojedynczych punktów awarii, a jeśli pracownicy o krytycznym znaczeniu są rozproszeni, aby uniknąć awarii przez współużytność w jednej lokalizacji.
Zewnętrzni dostawcy: firma Microsoft utrzymuje kompleksową listę dostawców zewnętrznych, a dostawcy uznani za krytyczne są mierzone pod kątem możliwości. W przypadku zidentyfikowania przez usługę jako zależność możliwości dostawcy są porównywane z potrzebami usługi w celu zapewnienia awarii innych firm nie zakłóca działania usług platformy Azure.
Ocena odzyskiwania: ta ocena jest unikatowa dla programu Azure Business Continuity Management. Ta ocena mierzy kilka kluczowych elementów w celu utworzenia oceny odporności:
- Gotowość do przełączenia w tryb failover: chociaż może istnieć proces, może nie być to pierwszy wybór w przypadku krótkoterminowych przestojów.
- Automatyzacja trybu failover.
- Automatyzacja decyzji o przejściu w tryb failover.
Najbardziej niezawodnym i najkrótszym czasem pracy w trybie failover jest usługa, która jest zautomatyzowana i nie wymaga decyzji człowieka. Usługa zautomatyzowana używa monitorowania pulsu lub transakcji syntetycznych w celu określenia, czy usługa nie działa i uruchamia natychmiastowe korygowanie.
Plan odzyskiwania i testowanie: platforma Azure wymaga, aby każda usługa miała szczegółowy plan odzyskiwania i przetestowała ten plan tak, jakby usługa uległa awarii z powodu katastrofy. Plany odzyskiwania są wymagane do napisania, aby osoba z podobnymi umiejętnościami i dostępem mogła wykonać zadania. Napisany plan pozwala uniknąć dostępności ekspertów w danej dziedzinie.
Testowanie odbywa się na kilka sposobów, w tym samodzielne testowanie w środowisku produkcyjnym lub niemal produkcyjnym, a także w ramach przechodzenia do szczegółów w pełnym regionie platformy Azure w zestawach regionów kanarskich. Te regiony włączone są identyczne z regionami produkcyjnymi, ale można je wyłączyć bez wpływu na klientów. Testowanie jest uznawane za zintegrowane, ponieważ wszystkie usługi mają wpływ jednocześnie.
Włączanie klienta: gdy klient jest odpowiedzialny za konfigurowanie odzyskiwania po awarii, platforma Azure musi mieć wskazówki dotyczące dokumentacji dostępnej publicznie. W przypadku wszystkich takich usług linki są dostarczane do dokumentacji i szczegółowe informacje o procesie.
Weryfikowanie zgodności ciągłości działania
Po ukończeniu rekordu zarządzania ciągłością działania usługi należy przesłać ją do zatwierdzenia. Jest on przypisywany do zarządzania ciągłością biznesową doświadczonych praktyków, którzy przeglądają cały rekord pod kątem kompletności i jakości. Jeśli rekord spełnia wszystkie wymagania, zostanie zatwierdzony. Jeśli tak nie jest, zostanie odrzucony z prośbą o przerobienie. Ten proces zapewnia, że obie strony zgadzają się, że została spełniona zgodność z ciągłością działalności biznesowej i że praca jest zaświadczona tylko przez właściciela usługi. Wewnętrzne zespoły ds. inspekcji i zgodności platformy Azure wykonują również okresowe losowe próbkowanie, aby zapewnić, że najlepsze dane są przesyłane.
Testowanie usług
Firma Microsoft i Platforma Azure przeprowadzają rozbudowane testy pod kątem odzyskiwania po awarii i gotowości strefy dostępności. Usługi są testowane samodzielnie w środowisku produkcyjnym lub przedprodukcyjnym w celu zademonstrowania niezależnego odzyskiwania dla usług, które nie są zależne od głównych trybów failover platformy.
Aby zapewnić, że usługi mogą podobnie odzyskać w rzeczywistym scenariuszu w dół regionu, testowanie typu "pull-the-plug" odbywa się w środowiskach kanarowych, które są w pełni wdrożone regiony pasujące do środowiska produkcyjnego. Na przykład klastry, stojaki i jednostki zasilania są dosłownie wyłączone w celu symulowania całkowitej awarii regionu.
Podczas tych testów platforma Azure używa tego samego procesu produkcyjnego do wykrywania, powiadamiania, odpowiedzi i odzyskiwania. Żadna osoba nie oczekuje próbnego, a inżynierowie polegali na odzyskiwaniu, są normalnymi zasobami rotacji wywołań. Ten czas pozwala uniknąć w zależności od ekspertów w danej dziedzinie, którzy mogą nie być dostępne podczas rzeczywistego wydarzenia.
Te testy są usługami, w których klient jest odpowiedzialny za konfigurowanie odzyskiwania po awarii zgodnie z publiczną dokumentacją firmy Microsoft. Zespoły usług tworzą wystąpienia podobne do klientów, aby pokazać, że odzyskiwanie po awarii z obsługą klienta działa zgodnie z oczekiwaniami i że podane instrukcje są dokładne.
Aby uzyskać więcej informacji na temat certyfikatów, zobacz Centrum zaufania Microsoft i sekcję dotyczącą zgodności.