Zalecenia dotyczące przeprowadzania analizy trybu awarii
Dotyczy tego zalecenia listy kontrolnej niezawodności platformy Azure Well-Architected Framework:
| RE:03 | Użyj analizy trybu awarii (FMA), aby zidentyfikować potencjalne błędy w obciążeniu. Zidentyfikuj zależności i punkty awarii oraz opracuj strategie ograniczania ryzyka dla tych awarii. |
|---|
W tym przewodniku opisano najlepsze praktyki dotyczące przeprowadzania analizy trybu awarii (FMA) dla Twojego obciążenia. FMA to praktyka identyfikowania potencjalnych punktów awarii w obciążeniu roboczym oraz powiązanych przepływów, a także odpowiedniego planowania działań zapobiegawczych. Na każdym etapie procesu można zidentyfikować zakres wpływu wielu rodzajów awarii, co pomaga zaprojektować nowe obciążenie lub zrefaktoryzować istniejące obciążenie w celu zminimalizowania powszechnego wpływu awarii.
Kluczową zasadą FMA jest to, że błędy występują niezależnie od tego, ile warstw odporności się zastosuje. 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
| Termin | Definicja |
|---|---|
| Tryb awarii | Rodzaj problemu, który może spowodować, że co najmniej jeden składnik obciążenia zostanie pogorszony lub poważnie dotknięty do tego stopnia, że stanie się niedostępny. |
| Łagodzenia | 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
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 odnieść sukces w pracy FMA, dokładność i staranność w artefaktach są kluczowe.
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.
Rozłóż obciążenie
W miarę przechodzenia od kreacji do projektowania należy zidentyfikować typy komponentów wymaganych 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 obrębie obciążenia, które są niezbędne do jego funkcjonowania. Typowe zależności wewnętrzne obejmują interfejsy API lub rozwiązania do zarządzania tajemnicami/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 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 przerwa serwisowa.
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. Na przykład, jeśli masz aplikację e-commerce i analizujesz przepływ klientów, wpływ określonego trybu awarii na jeden lub więcej składników może oznaczać, że wszyscy klienci nie mogą ukończyć procesu zamówienia.
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.
Łagodzenia
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 komponentów obejmuje dodawanie nadmiarowości do składników, takich jak infrastruktura, dane i sieć, oraz zapewnienie, że projekt aplikacji jest zgodny z najlepszymi praktykami dotyczącymi trwałości, na przykład poprzez rozbijanie aplikacji monolitycznych na izolowane aplikacje i mikrousługi. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące nadmiarowości i Zalecenia dotyczące samozachowania.
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 uległ awarii, taki jak mikrousługa, może spowodować niedostępność silnika rekomendacji, ale klienci nadal mogą wyszukiwać produkty i zakończyć swoją transakcję.
Należy również zaplanować działania łagodzące związane z zależnościami. 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, bez których nie może działać, cele dostępności i odzyskiwania tych zależności powinny być zgodne z celami 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 w celu osiągnięcia skalowalności.
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.
Wykrywanie
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 w jak największym stopniu, a następnie twórz nadmiarowość w procesach operacyjnych, aby zapewnić, że alerty są zawsze przechwytywane i aby można było na nie szybko reagować, spełniając wymagania biznesowe. Aby uzyskać więcej informacji, zobacz zalecenia dotyczące monitorowania.
Wynik
W celu przedstawienia wyników analizy utwórz zestaw dokumentów, które skutecznie komunikują twoje ustalenia, decyzje podjęte w odniesieniu do składników przepływu i działań naprawczych, oraz wpływ awarii na twoje obciążenie pracą.
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 następującą przykładową tabelą jako punktem wyjścia do dokumentacji.
Podczas początkowego ćwiczenia FMA dokumenty, które tworzysz, będą w większości teoretycznymi planami. Dokumenty FMA powinny być regularnie przeglądane i aktualizowane, aby upewnić się, że pozostają up-to-date z obciążeniem. Testowanie chaosu i rzeczywiste doświadczenia pomogą Ci udoskonalić analizy z czasem.
Ułatwienia platformy Azure
Użyj usługi Azure Monitor i Log Analytics, aby wykrywać problemy w Twoim środowisku pracy. 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 Insightsi SQL Insights.
azure Chaos Studio to zarządzana usługa, która używa inżynierii chaosu w celu 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 dla witryny internetowej handlu elektronicznego hostowanej w wystąpieniach usługi Azure App Service z bazami danych Azure SQL i obsługiwaną 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/Złagodzenie/Uwaga | Awarii |
|---|---|---|---|---|
| Microsoft Entra ID | Awaria usługi | Niski | Całkowita awaria obciążenia. Zależne od firmy Microsoft na rozwiązanie problemu. | Pełny |
| Microsoft Entra ID | Nieprawidłowa konfiguracja | Średni | Użytkownicy nie mogą się zalogować. Brak efektu podrzędnego. Dział pomocy technicznej zgłasza problem z konfiguracją zespołowi tożsamości. | Żaden |
| Azure Front Door | Awaria usługi | Niski | Pełna awaria dla użytkowników zewnętrznych. Zależy od Microsoftu, aby naprawić. | Tylko zewnętrzne |
| Azure Front Door | Awaria regionalna | Bardzo niskie | Minimalny efekt. Usługa Azure Front Door to usługa globalna, więc globalny routing kieruje ruchem przez regiony platformy Azure nieobjęte zakłóceniami. | Żaden |
| Azure Front Door (usługa przyspieszania i zabezpieczania aplikacji webowych na platformie Azure) | Błędna konfiguracja | Średni | 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 | Średni | 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 | Pełne zatrzymanie pracy. Uzależnione od firmy Microsoft w celu naprawy. | Pełny |
| Azure SQL | Awaria regionalna | Bardzo niskie | Grupa automatycznego failover przełącza się do regionu zapasowego. Potencjalna awaria podczas pracy w trybie failover. Cele czasu odzyskiwania (RTO) i cele punktu odzyskiwania (RPO) do określenia podczas testowania niezawodności. | Pełny potencjał |
| Azure SQL | Awaria strefy dostępności | Niski | Brak efektu | Żaden |
| Azure SQL | Złośliwy atak (wstrzyknięcie) | Średni | 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. | Niskie ryzyko, potencjalna awaria częściowa |
| App Service | Awaria usługi | Niski | Awaria związana z pełnym obciążeniem. Zależność od firmy Microsoft w celu skorygowania. | Pełny |
| Usługa Aplikacji | Awaria regionalna | Bardzo niskie | Minimalny efekt. Opóźnienie dla użytkowników w dotkniętych regionach. Azure Front Door automatycznie kieruje ruch do regionów, które nie są dotknięte. | Żaden |
| App Service | Awaria strefy dostępności | Niski | Brak efektu. Usługi App Services zostały wdrożone jako strefowo nadmiarowe. Bez nadmiarowości strefowej istnieje ryzyko wystąpienia skutków. | Żaden |
| App Service | Atak DDoS | Średni | Minimalny efekt. Ruch przychodzący jest chroniony przez Azure Front Door i Azure Web Application Firewall. | Żaden |
Powiązane linki
- 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ń.