Zalecenia dotyczące przeprowadzania analizy trybu awarii
Dotyczy tego zalecenia listy kontrolnej dotyczącej niezawodności platformy Azure Well-Architected Framework:
| RE:03 | Użyj analizy trybu awarii (FMA), aby zidentyfikować i określić 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. W każdym kroku przepływu można zidentyfikować promień wybuchu wielu typów awarii, który pomaga zaprojektować nowe obciążenie lub refaktoryzować istniejące obciążenie w celu zminimalizowania powszechnego wpływu awarii.
Kluczowym zestawem FMA jest to, że błędy występują 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 pozwala zaprojektować obciążenie tak, aby wytrzymać większość typów awarii i odzyskać bezpiecznie, gdy wystąpi awaria.
Jeśli całkowicie pominąsz funkcję FMA lub wykonasz niekompletną analizę, obciążenie jest zagrożone nieprzewidywalnym zachowaniem i potencjalnymi awariami spowodowanymi nieoptymalnym projektem.
Definicje
| Okres | Definicja |
|---|---|
| Tryb awarii | Typ problemu, który może spowodować, że co najmniej jeden składnik obciążenia jest obniżony lub poważnie dotknięty punktem niedostępności. |
| Czynności zapobiegawcze | Zidentyfikowane działania umożliwiające proaktywne lub reaktywne rozwiązywanie problemów. |
| Detection | Infrastruktura, dane i procesy i procedury monitorowania aplikacji oraz zgłaszania alertów. |
Kluczowe strategie projektowania
Przejrzyj i zaimplementuj zalecenia dotyczące identyfikowania przepływów. Przyjęto założenie, że zidentyfikowano i nadaliśmy priorytet przepływom użytkowników i systemu na podstawie krytycznych zagadnień.
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 jest krytyczna.
Po określeniu przepływów krytycznych można zaplanować ich wymagane składniki. Następnie wykonaj poszczególne kroki krok po kroku, aby zidentyfikować zależności, w tym usługi innych firm i potencjalne punkty awarii, i zaplanować strategie ograniczania ryzyka.
Dekompiluj obciążenie
W miarę przechodzenia z ide do projektowania 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ć kontrolę ruchu przychodzącego, sieć, obliczenia, dane, magazyn, usługi pomocnicze (takie jak uwierzytelnianie, obsługa komunikatów i zarządzanie wpisami tajnymi lub kluczami) oraz sterowanie ruchem wychodzącym. 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 początkowego projektu architektury można nakładać przepływy w celu zidentyfikowania odrębnych składników używanych w tych przepływach i tworzenia list lub diagramów przepływu pracy opisujących przepływy i ich składniki. Aby zrozumieć krytyczność składników, użyj definicji krytycznych przypisanych do przepływów. Weź pod uwagę 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 usługa 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 spoza zakresu obciążenia, takimi jak inna aplikacja lub usługa innej firmy. Typowe zależności zewnętrzne obejmują rozwiązania uwierzytelniania, takie jak Microsoft Entra ID i rozwiązania łączności w chmurze, takie jak Azure ExpressRoute.
Zidentyfikuj i udokumentuj zależności w obciążeniu i uwzględnij je w artefaktach dokumentacji przepływu.
Ocena punktów awarii
W krytycznych przepływach obciążenia rozważ poszczególne składniki i określ, jak ten składnik i jego zależności mogą mieć wpływ na tryb awarii. Należy pamiętać, że podczas planowania odporności i odzyskiwania należy wziąć pod uwagę wiele trybów awarii. Każdy składnik może mieć wpływ na 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ładnika.
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ć, więc 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 oznaczać, ż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 wielu regionach, a dodanie planowania ograniczania ryzyka poza nadmiarowością nie jest dobrym wykorzystaniem zasobów i czasu.
Czynności zapobiegawcze
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 rozbijania aplikacji monolitycznych w izolowanych aplikacjach i mikrousługach. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące nadmiarowości i zalecenia dotyczące samodzielnego zachowania.
Aby zaprojektować pod kątem obniżonej wydajności, zidentyfikuj potencjalne punkty awarii, które mogą wyłączyć co najmniej jeden składnik przepływu, ale nie w pełni wyłączają 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 zakończyć swoją transakcję.
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. Zminimalizuj zależności, aby zapewnić kontrolę nad niezawodnością aplikacji. Aby uzyskać więcej informacji, zobacz Minimalizuj koordynację między usługami aplikacji, aby osiągnąć skalowalność.
Jeśli cykl życia aplikacji jest ściśle powiązany z cyklem życia jego zależności, elastyczność operacyjna aplikacji może być ograniczona, szczególnie w przypadku nowych wersji.
Detection
Wykrywanie błędów jest niezbędne, aby zapewnić prawidłowe zidentyfikowanie punktów awarii w analizie i prawidłowe zaplanowanie strategii 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 jak najwięcej, a następnie twórz 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
W celu uzyskania wyniku analizy utwórz zestaw dokumentów, które skutecznie komunikują wyniki, decyzje podjęte względem składników przepływu i środki zaradcze oraz wpływ awarii obciążenia.
W analizie określ priorytety trybów awarii i strategii ograniczania ryzyka, które zostały zidentyfikowane 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 zagwarantować poświęcanie czasu, nakładu pracy i zasobów na projektowanie strategii ograniczania ryzyka wokół. Na przykład mogą występować pewne tryby awarii, które są bardzo rzadkie w przypadku wystąpienia lub wykrywania. Projektowanie strategii ograniczania ryzyka wokół nich nie jest warte kosztu.
Zapoznaj się z poniższą przykładową tabelą , aby zapoznać się z punktem początkowym dokumentacji.
Podczas początkowego ćwiczenia FMA dokumenty, które tworzysz, będą w większości teoretycznie planowane. 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 przy użyciu 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 w celu ułatwienia mierzenia, zrozumienia i poprawy odporności aplikacji i usług w chmurze.
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 witryny internetowej handlu elektronicznego hostowanej w wystąpieniach usługi aplikacja systemu Azure z bazami danych Azure SQL Database 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 | Awaria pełnego obciążenia. Zależne od firmy Microsoft do skorygowania. | Pełny |
| 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 do skorygowania. | Tylko zewnętrzne |
| Azure Front Door | Awaria regionalna | Bardzo małe | Minimalny efekt. Usługa Azure Front Door to usługa globalna, więc globalny routing ruchu kieruje ruchem przez nieodpowiedzone regiony platformy Azure. | Brak |
| Azure Front Door | Błąd konfiguracji | Śred. | Błędy konfiguracji powinny zostać przechwycone 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 zapora aplikacji internetowej platformy Azure blokuje większość zagrożeń. Potencjalne ryzyko efektu ataków L7. | Potencjalna awaria częściowa |
| Azure SQL | Awaria usługi | Niski | Awaria pełnego obciążenia. Zależne od firmy Microsoft do skorygowania. | Pełny |
| 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. | Potencjalna pełna |
| 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 usługi 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 | Awaria pełnego obciążenia. Zależne od firmy Microsoft do skorygowania. | Pełny |
| App Service | Awaria regionalna | Bardzo małe | Minimalny efekt. Opóźnienie dla użytkowników w regionach. Usługa Azure Front Door automatycznie kieruje ruch do regionów, które nie działają. | 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 strefowej istnieje możliwość zastosowania. | Brak |
| App Service | Atak DDoS | Śred. | Minimalny efekt. Ruch przychodzący jest chroniony przez usługę Azure Front Door i zaporę aplikacji internetowej platformy Azure. | Brak |
Pokrewne łącza
Lista kontrolna dotycząca niezawodności
Zapoznaj się z pełnym zestawem zaleceń.