Zalecenia dotyczące przeprowadzania analizy trybu awarii

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

RE:03	Użyj analizy trybu awarii (FMA), aby zidentyfikować i ustalić priorytety potencjalnych awarii w składnikach rozwiązania. Wykonaj fmA, aby pomóc ocenić ryzyko i wpływ każdego trybu awarii. Określ sposób reagowania i odzyskiwania obciążenia.

W tym przewodniku opisano najlepsze rozwiązania dotyczące przeprowadzania analizy trybu awarii (FMA) dla obciążenia. FMA to praktyka identyfikowania potencjalnych punktów awarii w obciążeniu oraz powiązanych przepływów i odpowiednio planowania działań zaradczych. Na każdym etapie przepływu można zidentyfikować promień wybuchu wielu typów awarii, co pomaga zaprojektować nowe obciążenie lub refaktoryzować istniejące obciążenie, aby zminimalizować powszechny wpływ awarii.

Kluczowym zestawem FMA jest to, że awarie zdarzają się bez względu na to, ile warstw odporności stosujesz. Bardziej złożone środowiska są narażone na więcej typów awarii. Biorąc pod uwagę tę rzeczywistość, FMA umożliwia zaprojektowanie obciążenia tak, aby wytrzymać większość typów awarii i bezpiecznie odzyskać w razie awarii.

Jeśli całkowicie pominąsz fmA lub wykonasz niekompletną analizę, obciążenie jest narażone na nieprzewidywalne zachowanie i potencjalne awarie spowodowane nieoptymalnym projektem.

Definicje

Okres	Definicja
Tryb awarii	Typ problemu, który może spowodować, że co najmniej jeden składnik obciążenia zostanie obniżony lub poważnie dotknięty punktem niedostępności.
Ograniczanie ryzyka	Zidentyfikowane działania umożliwiające proaktywne lub reaktywne rozwiązywanie problemów.
Wykrywanie	Infrastruktura, dane i procesy i procedury monitorowania aplikacji oraz zgłaszania alertów.

Kluczowe strategie projektowania

Wymagania wstępne

Przejrzyj i zaimplementuj zalecenia dotyczące identyfikowania przepływów. Przyjęto założenie, że zidentyfikowano i określiliśmy priorytety przepływów użytkowników i systemów na podstawie krytycznej wersji.

Zebrane dane i artefakty utworzone w ramach pracy zawierają konkretny opis ścieżek danych związanych z przepływami. Aby zapewnić sukces w pracy FMA, dokładność i dokładność w artefaktach ma kluczowe znaczenie.

Podejście FMA

Po określeniu przepływów krytycznych można zaplanować ich wymagane składniki. Następnie postępuj zgodnie z poszczególnymi krokami przepływu, aby zidentyfikować zależności, w tym usługi innych firm i potencjalne punkty awarii, i zaplanować strategie ograniczania ryzyka.

Dekompozycja obciążenia

W miarę przechodzenia od ide do projektu należy zidentyfikować typy składników wymagane do obsługi obciążenia. Obciążenie określa niezbędne składniki, które należy zaplanować. Zazwyczaj należy zaplanować sterowanie ruchem przychodzącym, siecią, obliczeniami, danymi, magazynem, usługami pomocniczymi (takimi jak uwierzytelnianie, obsługa komunikatów i zarządzanie wpisami tajnymi lub kluczami) oraz kontrola ruchu wychodzącego. Na tym etapie pracy projektowej możesz nie znać konkretnych technologii, które zostaną wdrożone, więc projekt może wyglądać podobnie do poniższego przykładu.

Po utworzeniu projektu początkowej architektury możesz nałożyć przepływy, aby zidentyfikować odrębne składniki używane w tych przepływach i utworzyć listy lub diagramy przepływu pracy opisujące przepływy i ich składniki. Aby zrozumieć krytyczność składników, użyj definicji krytycznych, które zostały przypisane do przepływów. Rozważ wpływ awarii składnika na przepływy.

Identyfikowanie zależności

Zidentyfikuj zależności obciążeń w celu przeprowadzenia analizy pojedynczego punktu awarii. Rozdzielenie obciążenia i nakładanie przepływów zapewnia wgląd w zależności, które są wewnętrzne i zewnętrzne dla obciążenia.

Zależności wewnętrzne są składnikami w zakresie obciążenia, które są wymagane do działania obciążenia. Typowe zależności wewnętrzne obejmują interfejsy API lub rozwiązania do zarządzania wpisami tajnymi/kluczami, takie jak azure Key Vault. W przypadku tych zależności przechwyć dane dotyczące niezawodności, takie jak umowy SLA dotyczące dostępności i limity skalowania. Zależności zewnętrzne są wymaganymi składnikami poza zakresem obciążenia, takimi jak inna aplikacja lub usługa innej firmy. Typowe zależności zewnętrzne obejmują rozwiązania uwierzytelniania, takie jak Tożsamość Microsoft Entra i rozwiązania łączności w chmurze, takie jak Usługa Azure ExpressRoute.

Zidentyfikuj i udokumentuj zależności w obciążeniu i uwzględnij je w artefaktach dokumentacji przepływu.

Punkty awarii

W krytycznych przepływach obciążenia rozważ każdy składnik i określ, jak ten składnik i jego zależności mogą mieć wpływ na tryb awarii. Należy pamiętać, że istnieje wiele trybów awarii, które należy wziąć pod uwagę podczas planowania odporności i odzyskiwania. Na dowolny składnik może mieć wpływ więcej niż jeden tryb awarii w danym momencie. Te tryby awarii obejmują:

• Awaria regionalna. Cały region świadczenia usługi Azure jest niedostępny.

• Awaria strefy dostępności. Strefa dostępności platformy Azure jest niedostępna.

• Awaria usługi. Co najmniej jedna usługa platformy Azure jest niedostępna.

• Rozproszona odmowa usługi (DDoS) lub inny złośliwy atak.

• Błędna konfiguracja aplikacji lub składników.

• Błąd operatora.

• Planowana awaria konserwacji.

• Przeciążenie składnika.

Analiza powinna zawsze znajdować się w kontekście przepływu, który próbujesz przeanalizować, dlatego pamiętaj, aby udokumentować wpływ na użytkownika i oczekiwany wynik tego przepływu. Jeśli na przykład masz aplikację do handlu elektronicznego i analizujesz przepływ klienta, wpływ określonego trybu awarii na co najmniej jeden składnik może być taki, że wszyscy klienci nie mogą ukończyć wyewidencjonowania.

Rozważ prawdopodobieństwo wystąpienia każdego typu trybu awarii. Niektóre z nich są bardzo mało prawdopodobne, takie jak awarie w wielu strefach lub wiele regionów, a dodanie planowania ograniczania ryzyka poza nadmiarowość nie jest dobrym użyciem zasobów i czasu.

Ograniczanie ryzyka

Strategie ograniczania ryzyka dzielą się na dwie szerokie kategorie: tworzenie większej odporności i projektowanie pod kątem obniżonej wydajności.

Tworzenie większej odporności obejmuje dodawanie nadmiarowości do składników, takich jak infrastruktura, dane i sieć, oraz zapewnienie, że projekt aplikacji jest zgodny z najlepszymi rozwiązaniami dotyczącymi trwałości, na przykład dzieląc aplikacje monolityczne na izolowane aplikacje i mikrousługi. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące nadmiarowości i Zalecenia dotyczące samodzielnego zachowywania.

Aby zaprojektować pod kątem obniżonej wydajności, zidentyfikuj potencjalne punkty awarii, które mogą wyłączyć jeden lub więcej składników przepływu, ale nie wyłączają w pełni tego przepływu. Aby zachować funkcjonalność kompleksowego przepływu, może być konieczne przekierowanie co najmniej jednego kroku do innych składników lub zaakceptowanie, że składnik, który zakończył się niepowodzeniem, uruchamia funkcję, więc funkcja nie jest już dostępna w środowisku użytkownika. Aby powrócić do przykładu aplikacji do handlu elektronicznego, składnik, który zakończył się niepowodzeniem, taki jak mikrousługa, może spowodować niedostępności aparatu rekomendacji, ale klienci nadal mogą wyszukiwać produkty i wykonywać transakcje.

Należy również zaplanować środki zaradcze dotyczące zależności. Silne zależności odgrywają kluczową rolę w funkcji i dostępności aplikacji. Jeśli są nieobecne lub występują awarie, może to mieć znaczący wpływ. Brak słabych zależności może mieć wpływ tylko na określone funkcje i nie wpływać na ogólną dostępność. To rozróżnienie odzwierciedla koszt utrzymania relacji wysokiej dostępności między usługą a jej zależnościami. Klasyfikuj zależności jako silne lub słabe, aby ułatwić określenie, które składniki są niezbędne dla aplikacji.

Jeśli aplikacja ma silne zależności, których nie może działać bez, cele dostępności i odzyskiwania tych zależności powinny być zgodne z miejscami docelowymi samej aplikacji. Minimalizuj zależności, aby zapewnić kontrolę nad niezawodnością aplikacji. Aby uzyskać więcej informacji, zobacz Minimalizuj koordynację między usługami aplikacji w celu osiągnięcia skalowalności.

Jeśli cykl życia aplikacji jest ściśle powiązany z cyklem życia jej zależności, elastyczność operacyjna aplikacji może być ograniczona, szczególnie w przypadku nowych wersji.

Wykrywanie

Wykrywanie błędów jest niezbędne, aby upewnić się, że prawidłowo zidentyfikowano punkty awarii w analizie i prawidłowo zaplanowaliśmy strategie ograniczania ryzyka. Wykrywanie w tym kontekście oznacza monitorowanie infrastruktury, danych i aplikacji oraz zgłaszanie alertów w przypadku wystąpienia problemów. Zautomatyzuj wykrywanie w jak największym stopniu i wbuduj nadmiarowość w procesach operacyjnych, aby zapewnić, że alerty są zawsze przechwytywane i reagują na wystarczająco szybko, aby spełnić wymagania biznesowe. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące monitorowania.

Wynik

Na potrzeby wyniku analizy utwórz zestaw dokumentów, które skutecznie komunikują twoje wyniki, decyzje podjęte względem składników przepływu i środki zaradcze oraz wpływ awarii na obciążenie.

W analizie określ priorytety trybów awarii i strategii ograniczania ryzyka zidentyfikowanych na podstawie ważności i prawdopodobieństwa. Użyj tej priorytetyzacji, aby skoncentrować dokumentację na tych trybach awarii, które są typowe i wystarczająco poważne, aby uzasadniać poświęcanie czasu, nakładu pracy i zasobów na projektowanie strategii ograniczania ryzyka. Na przykład mogą wystąpić pewne tryby awarii, które są bardzo rzadkie w wystąpieniu lub wykryciu. Projektowanie strategii ograniczania ryzyka wokół nich nie jest warte kosztu.

Zapoznaj się z poniższą przykładową tabelą, aby uzyskać punkt początkowy dokumentacji.

Podczas początkowego ćwiczenia FMA dokumenty, które utworzysz, będą głównie teoretycznym planowaniem. Dokumenty FMA należy regularnie przeglądać i aktualizować, aby zapewnić aktualność obciążenia. Testowanie chaosu i rzeczywiste środowiska pomogą Ci udoskonalić analizy w czasie.

Ułatwienia platformy Azure

Wykrywanie problemów w obciążeniu za pomocą usług Azure Monitor i Log Analytics . Aby uzyskać więcej informacji na temat problemów związanych z infrastrukturą, aplikacjami i bazami danych, użyj narzędzi, takich jak Application Insights, Container Insights, Network Insights, VM Insights i SQL Insights.

Azure Chaos Studio to zarządzana usługa, która używa inżynierii chaosu, która pomaga mierzyć, rozumieć i ulepszać aplikację w chmurze i odporność usług.

Aby uzyskać informacje na temat stosowania zasad FMA do typowych usług platformy Azure, zobacz Analiza trybu awarii dla aplikacji platformy Azure.

Przykład

W poniższej tabeli przedstawiono przykład fmA dla witryny internetowej handlu elektronicznego hostowanej w wystąpieniach Azure App Service z bazami danych Azure SQL i jest fronted przez usługę Azure Front Door.

Przepływ użytkownika: logowanie użytkownika, wyszukiwanie produktów i interakcja koszyka

Składnik	Ryzyko	Prawdopodobieństwo	Efekt/Środki zaradcze/Uwaga	Awaria
Microsoft Entra ID	Awaria usługi	Niski	Pełna awaria obciążenia. Zależne od firmy Microsoft w celu skorygowania.	Pełne
Microsoft Entra ID	Błąd konfiguracji	Śred.	Użytkownicy nie mogą się zalogować. Brak efektu podrzędnego. Dział pomocy technicznej zgłasza problem z konfiguracją zespołowi tożsamości.	Brak
Azure Front Door	Awaria usługi	Niski	Pełna awaria dla użytkowników zewnętrznych. Zależne od firmy Microsoft w celu skorygowania.	Tylko zewnętrzne
Azure Front Door	Awaria regionalna	Bardzo małe	Minimalny efekt. Usługa Azure Front Door jest usługą globalną, więc globalny routing ruchu kieruje ruch przez nieodpowiedzone regiony platformy Azure.	Brak
Azure Front Door	Błąd konfiguracji	Śred.	Błędy konfiguracji należy przechwycić podczas wdrażania. Jeśli wystąpią one podczas aktualizacji konfiguracji, administratorzy muszą wycofać zmiany. Aktualizacja konfiguracji powoduje krótką awarię zewnętrzną.	Tylko zewnętrzne
Azure Front Door	Atak DDoS	Śred.	Potencjalne zakłócenia. Firma Microsoft zarządza ochroną przed atakami DDoS (L3 i L4), a usługa Azure Web Application Firewall blokuje większość zagrożeń. Potencjalne ryzyko efektu z ataków L7.	Potencjalna awaria częściowa
Azure SQL	Awaria usługi	Niski	Pełna awaria obciążenia. Zależne od firmy Microsoft w celu skorygowania.	Pełne
Azure SQL	Awaria regionalna	Bardzo małe	Grupa automatycznego trybu failover przełączy się w tryb failover do regionu pomocniczego. Potencjalna awaria podczas pracy w trybie failover. Cele czasu odzyskiwania (RTO) i cele punktu odzyskiwania (RPO) do określenia podczas testowania niezawodności.	Potencjalny pełny
Azure SQL	Awaria strefy dostępności	Niski	Brak wpływu	Brak
Azure SQL	Złośliwy atak (wstrzyknięcie)	Śred.	Minimalne ryzyko. Wszystkie wystąpienia Azure SQL są powiązane z siecią wirtualną za pośrednictwem prywatnych punktów końcowych, a sieciowe grupy zabezpieczeń dodają dodatkową ochronę wewnątrz sieci wirtualnej.	Potencjalne niskie ryzyko
App Service	Awaria usługi	Niski	Pełna awaria obciążenia. Zależne od firmy Microsoft w celu skorygowania.	Pełne
App Service	Awaria regionalna	Bardzo małe	Minimalny efekt. Opóźnienie dla użytkowników w obowiązujech regionach. Usługa Azure Front Door automatycznie kieruje ruch do regionów bez wpływu.	Brak
App Service	Awaria strefy dostępności	Niski	Brak wpływu. Usługi App Services zostały wdrożone jako strefowo nadmiarowe. Bez nadmiarowości strefy istnieje możliwość zastosowania.	Brak
App Service	Atak DDoS	Śred.	Minimalny efekt. Ruch przychodzący jest chroniony przez usługę Azure Front Door i usługę Azure Web Application Firewall.	Brak

Linki pokrewne

• Analiza trybu awarii dla aplikacji platformy Azure
• Odporność i zależności

Lista kontrolna dotycząca niezawodności

Zapoznaj się z pełnym zestawem zaleceń.

Lista kontrolna dotycząca niezawodności