Udostępnij za pośrednictwem

Rekomendacje dotyczące wykonywania analizy trybu awarii

  • Artykuł

Dotyczy tego Power Platform zalecenia dotyczącego listy kontrolnej niezawodności Well-Architected Reliability:

RE:03 Analiza trybu awarii (FMA) umożliwia identyfikowanie i ustalanie priorytetów potencjalnych awarii w składnikach rozwiązania. Wykonaj FMA w celu dokonania oceny ryzyka i efektu poszczególnych trybów niepowodzenia. Określ sposób odpowiedzi i odzyskiwania obciążenia.

W tym przewodniku opisano najlepsze metody postępowania przy wykonywaniu analizy trybu awarii (FMA) w obciążeniach. FMA to praktyka identyfikowania potencjalnych punkty niepowodzenia w obrębie obciążenia i skojarzonych z nimi przepływów, a także planowania odpowiednich akcji naprawczych. W każdym kroku przepływu użytkownik określa zasięg wielu typów awarii, co ułatwia projektowanie nowego obciążenia lub ponowne określenie istniejącego obciążenia w celu zminimalizowania efektu szerokiego zasięgu awarii.

Kluczowe znaczenie w FMA ma to, że awarie występują bez względu na to, ile warstw odporności zostanie zastosowanie w różnych warstwach. Bardziej złożone środowiska są narażone na działanie większej liczby typów awarii. Ze względu na to FMA umożliwia projektowanie obciążenia, które wytrzyma większość awarii i płynnie odzyska sprawność po awarii.

Po pominięciu FMA lub wykonaniy niekompletnej analizy przez użytkownika istnieje ryzyko, że jego działanie będzie nieoczekiwane i będą potencjalne awarie powodowanych przez nieoptymalny projekt.

Definicje

Termin Definicja
Tryb awarii Typ problemu, który może spowodować, że jeden lub więcej składników obciążenia zostanie błędnie rozwiązanych lub zostanie uszkodzony aż do momentu niedostępności.
Ograniczanie ryzyka Działania, które zidentyfikowano w celu rozwiązania problemów są albo aktywne, albo reaktywne.
Wykrywanie Monitorowanie danych i aplikacji oraz ich przetwarzanie w alertach i procedury.

Kluczowe strategie projektowania

W kontekście FMA zrozumienie wymagań wstępnych jest kluczowe. Rozpocznij od przejrzenia i wdrożenia zaleceń dotyczących identyfikowania przepływów i ustalania priorytetów w oparciu o krytyczne znaczenie. Artefakty danych pełnią niezwykle ważną rolę w opisie ścieżek danych w tych przepływach. W podejściu FMA należy skupić się na elementach planowania przepływów o znaczeniu krytycznym, identyfikowaniu zależności (zarówno wewnętrznych, jak i zewnętrznych) i opracowaniu strategii planowania.

Wymagania wstępne

Przejrzyj i implementuj rekomendacje dotyczące identyfikowania i przepływów klasyfikacji. Wynika to z identyfikowania i ustalania priorytetów przepływów użytkowników i systemów na podstawie krytycznych informacji.

Zebrane dane i artefakty utworzone w pracy zawierają opis ścieżki danych uwzględnianej w przepływach. Aby FMA działało prawidłowo, dokładność i staranność artefaktów mają krytyczne znaczenie.

Podejście FMA

Po określeniu przepływów krytycznych można zaplanować ich wymagane składniki. Następnie należy krok po kroku śledzić przepływ w celu zidentyfikowania zależności, w tym usług innych firm i potencjalnych punktów niepowodzenia, oraz zaplanować strategie ograniczania ryzyka.

Rozkładanie obciążenia na elementy

W przypadku przechodzenia od ideologii do projektowania należy zidentyfikować typy składników wymaganych do obsługi obciążenia. Obciążenie określa niezbędne składniki, które należy zaplanować.

Po utworzeniu początkowego projektu architektury można zweryfikować przepływy w celu zidentyfikowania składników dyskretnych używanych w tych przepływach oraz utworzenia list lub diagramów przepływu pracy opisujących przepływy i ich składniki. Aby zrozumieć krytyczne znaczenie składników, należy użyć definicji krytyczności przypisanych do przepływów. Należy uwzględnić wpływ, jak na przepływy składników wpływa działanie na przepływy.

Identyfikowanie zależności

Zidentyfikuj zależności prac w celu wykonania analizy jednego punktu niepowodzenia. Dekomponowanie obciążenia i powiązanych przepływów zapewniają wgląd w zależności wewnętrzne i zewnętrzne od obciążenia.

Zależności wewnętrzne to składniki w zakresie obciążenia, które są wymagane do działania obciążenia. Typowe zależności wewnętrzne to interfejsy API lub rozwiązania do zarządzania kluczami, takie jak usługa Azure Key Vault. W przypadku tych zależności należy przechwytywać dane niezawodności, takie jak umowy dotyczące poziomu usług (SLA) dotyczące dostępności czy ograniczenia skalowania. Zależności zewnętrzne są składnikami wymaganymi poza zakresem obciążenia, takim jak inna aplikacja lub usługa innych firm. Typowe zależności zewnętrzne to rozwiązania uwierzytelniania, takie jak Microsoft Entra ID i infrastruktura Power Platform.

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

Punkty niepowodzenia

Podczas przepływów krytycznych w obciążeniach należy rozważyć każdy składnik i określić sposób, w jaki tryb awarii może mieć wpływ na ten składnik i jego zależności. Należy pamiętać, że podczas planowania uwzględniającego odporności i odzyskiwania danych należy rozważyć wiele trybów awarii. W danym momencie na dowolny składnik może mieć wpływ więcej niż jeden tryb awarii. Tryby niepowodzenia to:

  • Awaria regionalna: Cała Power Platform lub region Azure jest niedostępny
  • Awaria usługi: Co najmniej jedna usługa Power Platform lub Azure nie jest dostępna
  • Rozproszony atak typu „odmowa usługi” (DDoS) lub inny złośliwy atak
  • Nieprawidłowa konfiguracja aplikacji lub składnika
  • Błąd operatora
  • Awaria planowanej konserwacji
  • Przeciążenie składnika

Należy wziąć pod uwagę prawdopodobieństwo wystąpienia poszczególnych typów niepowodzenia. Niektóre z nich są bardzo mało prawdopodobne, na przykład w przypadku wielu stref lub spoza regionu, a dodanie planowania poza zakresem zasobów i czasu nie jest dobrym rozwiązaniem.

Ograniczanie ryzyka

Strategie migracji są podzielone na dwie szerokie kategorie: tworzenie bardziej ryzykownych zmian i projektowanie wydajności.

Tworzenie większej odporności oznacza zapewnienie, że aplikacja jest projektowana zgodnie z najlepszymi praktykami w zakresie skalowalności. Przykłady: podział aplikacji monolitycznej na pojedyncze aplikacje i mikrousługi i używanie konfiguracji zainstalowanych na platformie, na przykład zasad ponowień. Aby uzyskać więcej informacji, zobacz Rekomendacje dotyczące nadmiarowości i Rekomendacje dotyczące funkcji samozachowawczych.

Aby zaprojektować tę obniżoną wydajność, należy zidentyfikować punkty potencjalnych awarii, które mogą wyłączyć co najmniej jeden składnik przepływu, ale nie całkowicie wyłączyć tego przepływu. Aby zachować funkcjonalność przepływu kompleksowego, może być konieczne ponowne kierowanie jeden lub więcej kroków do innych składników lub zaakceptowanie, że składnik, który zakończył się niepowodzeniem, uruchamia funkcję, więc ta funkcja nie jest już dostępna w interfejsie użytkownika. Aby powrócić do przykładu aplikacji e-commerce, składnik, taki jak mikrousługa, może spowodować, że aparat rekomendacji będzie niedostępny, ale klienci mogą nadal wyszukiwać produkty i zawierać transakcje.

Należy również zaplanować ograniczenie ryzyka między zależnościami. Duże zależności odgrywają kluczową rolę w funkcji aplikacji i dostępności. Jeśli ich nie ma lub jest awaria, może to spowodować istotne efekty. Brak słabych zależności może mieć wpływ jedynie na określone funkcje i nie wpływa na ogólną dostępność. To rozróżnienie odzwierciedla koszt utrzymania wysokiej dostępności relacji między usługą a jej zależnościami. Zależności należy sklasyfikować jako mocne lub słabe w celu określenia, które składniki są niezbędne dla aplikacji.

Jeśli aplikacja ma duże zależności, bez których nie może działać, wartości docelowe dostępności i odzyskiwania tych zależności powinny być zgodne z celami samej aplikacji. Jeśli cykl życia aplikacji jest bardzo ograniczony i istnieje cykl życia jego zależności, dynamika działania aplikacji może być ograniczona, szczególnie w przypadku nowych wersji.

Wykrywanie

Wykrywanie awarii jest niezbędne, aby prawidłowo zidentyfikować punkty niepowodzenia w analizie oraz prawidłowo zaplanować strategię eliminowania błędów. Wykrywanie w tym kontekście oznacza monitorowanie infrastruktury, danych i aplikacji oraz powiadamianie w razie pojawiającego się problemu. Zautomatyzuj wykrywanie w miarę możliwości i buduj odporność w procesach operacyjnych, aby alerty zawsze były powtarzane i że odpowiadały na nie odpowiednio szybko, aby spełnić potrzeby biznesowe. Aby uzyskać więcej informacji, zobacz Rekomendacje dotyczące monitorowania.

Wynik

Aby uzyskać wynik analizy, należy utworzyć zestaw dokumentów, które w efektywny sposób informują o ustaleniach, decyzjach podjęte w odniesieniu do składników przepływu i ograniczenia ryzyka oraz wpływie niepowodzenia na obciążenie.

W analizie należy określić priorytet trybów niepowodzenia i strategii ograniczenia ryzyka, które zostały określone na podstawie ważności i prawdopodobieństwa wystąpienia awarii. Te priorytety należy wykorzystać do skupienia dokumentacji na trybach niepowodzenia, które są typowe i na tyle poważne, aby można było poświęcać czas, działania i zasoby na projektowanie strategii ograniczenia ryzyka. Na przykład mogą wystąpić tryby niepowodzenia, które są bardzo rzadkim zdarzeniem podczas wystąpienia lub wykrywania. Projektowanie strategii ograniczenia ryzyka i zarządzanie nimi nie jest warte swoich kosztów.

Zajrzyj do przykładowej tabeli, aby zapoznać się z punktem początkowym dokumentacji.

Podczas pierwszego ćwiczeń w ramach projektu FMA tworzone dokumenty będą najczęściej dotyczyć teoretycznego planowania. Dokumenty FMA należy przeglądać i regularnie aktualizować, aby zapewnić ich aktualne informacje na temat prac. Testowanie w warunkach chaosu i doświadczeń ze świata rzeczywistego ułatwiają dopracowanie w czasie.

Przykład

W poniższej tabeli przedstawiono przykład FMA dla aplikacji wydatków hostowanej jako aplikacja kanwy Power Apps z wewnętrzną bazą danych Microsoft Dataverse i interfejsami APIM hostowanymi w systemie innej firmy.

Przepływ użytkownika: logowanie użytkownika, składanie wniosku o zwrot kosztów i interakcja z raportem wydatków

Składnik Ryzyko Prawdopodobieństwo Efekt/Ograniczenie ryzyka/Uwaga Awaria
Identyfikator usługi Microsoft Entra Przestój usługi Minimum Pełen przestój obciążenia. Zależne od Microsoft korygowania. Pełny
Identyfikator usługi Microsoft Entra Nieprawidłowa konfiguracja Średnia Użytkownicy nie mogą się zalogować. Brak efektu podrzędnego. Problem z konfiguracją raportów pomocy dla zespołu tożsamości. None
Power Apps Przestój usługi Minimum Pełen przestój dla użytkowników zewnętrznych. Zależne od Microsoft korygowania. Pełny
Power Apps Przestój regionalny Bardzo nisko Pełen przestój dla użytkowników zewnętrznych. Zależne od Microsoft korygowania. Pełny
Power Apps Atak DDoS Średnia Możliwość zakłóceń. Microsoft zarządza ochroną przed atakami DDoS (L3 i L4). Potencjalny częściowy przestój
Dataverse Przestój usługi Minimum Pełen przestój obciążenia. Zależne od Microsoft korygowania. Pełny
Dataverse Przestój regionalny Bardzo nisko Grupa automatycznego trybu failover jest przejmowana do regionu pomocniczego. Potencjalny przestój podczas trybu failover. Cele czasu odzyskiwania (RTO) i cele punktów odzyskiwania (RPO), które należy określić podczas testowania niezawodności. Potencjalne pełne
Dataverse Złośliwy atak (wstrzyknięcie) Średnia Minimalne ryzyko. Potencjalnie niskie ryzyko
API Management Przestój usługi Minimum Pełen przestój dla użytkowników zewnętrznych. Zależne od Microsoft korygowania. Pełny
API Management Przestój regionalny Bardzo nisko Pełen przestój dla użytkowników zewnętrznych. Zależne od Microsoft korygowania. Pełny
API Management Atak DDoS Średnia Możliwość zakłóceń. Microsoft zarządza ochroną przed atakami DDoS (L3 i L4). Potencjalny częściowy przestój
Twoje rozwiązanie Power Platform Nieprawidłowa konfiguracja Średnia Podczas wdrażania należy przechwytywać nieprawidłowe konfiguracje. Jeśli te zmiany nastąpią podczas aktualizacji konfiguracji, administratorzy muszą wycofać zmiany. Aktualizacja konfiguracji powoduje krótki zewnętrzny przestój. Potencjalny pełen przestój

Ułatwienia Power Platform

Power Platform integruje się z programem Application Insights, będącego częścią ekosystemu Azure Monitor. Za pomocą tej integracji możesz wykonać następujące czynności:

  • Subskrybuj te dane telemetryczne przechwytywane przez platformę Dataverse w Application Insights w ramach diagnostyki, wydajności i operacji wykonywanych przez aplikacje w bazie danych Dataverse i w aplikacjach opartych na modelu. Ta telemetria zawiera informacje, których można użyć do diagnozowania i rozwiązywania problemów związanych z błędami i wydajnością.

  • Połącz aplikacje kanwy z Application Insights, aby użyć tej analityki w celu diagnozowania problemów, zrozumienia, jak użytkownicy korzystają z Twoich aplikacji, podejmowania lepszych decyzji biznesowych i poprawiania jakości aplikacji.

  • Skonfiguruj telemetrię Power Automate do przepływu do Application Insights. Tej telemetrii można użyć do monitorowania wykonywania przepływu w chmurze i tworzenia alertów o niepowodzeniach uruchomienia przepływu w chmurze.

  • Przechwytywanie danych telemetrycznych z Microsoft Copilot Studio drugiego pilota do użycia na platformie Azure Application Insights. Za pomocą tej telemetrii można monitorować zarejestrowane komunikaty i zdarzenia wysyłane do i z drugiego pilota, tematy wyzwalane podczas konwersacji użytkowników oraz niestandardowe zdarzenia telemetrii, które mogą być wysyłane z tematów.

Power Platform zasoby rejestrują działania w Microsoft portal zgodności usługi Purview. Większość zdarzeń jest dostępnych w ciągu 24 godzin od działania. Nie należy używać tych informacji do monitorowania w czasie rzeczywistym. Aby uzyskać więcej informacji na temat rejestrowania działań w Power Platform, zobacz temat:

Lista kontrolna niezawodności

Zapoznaj się z kompletną zestawem zaleceń.

Lista kontrolna niezawodności