Udostępnij za pośrednictwem

Rekomendacje dotyczące projektowania strategii odpowiedzi na sytuację awaryjną

  • Artykuł

Dotyczy tego Power Platform zalecenia dotyczącego listy kontrolnej doskonałości operacyjnej Well-Architected:

OE:07 Opracowuj efektywne operacje awaryjne. Upewnij się, że w obciążeniach są wysyłane istotne sygnały dotyczące stanu systemu. Zbierz wynikowe dane i użyj ich do wygenerowania alertów z możliwością działania, które wdrażają reakcje w sytuacjach awaryjnych za pośrednictwem pulpitów nawigacyjnych i zapytań. Jasno zdefiniuj obowiązki ludzi, takie jak rozmowy telefoniczne, zarządzanie zdarzeniami, dostęp do zasobów i uruchamianie analiz post mortem.

Teb przewodnik opisuje rekomendacje dotyczące projektowania strategii odpowiedzi na sytuację awaryjną. Niektóre obciążenia mogą mieć kluczowe znaczenie dla misji, a problemy, które pojawiają się w trakcie cyklu życia obciążenia, mogą być na tyle poważne, że uzasadniają ogłoszenie ich jako sytuacji awaryjnych. Użytkownik może wdrożyć ściśle kontrolowane i ukierunkowane procesy i procedury, które mogą być stosowane przez zespół w celu zapewnienia, że problem zostanie obsłużony w sposób uporządkowany. Sytuacje awaryjne naturalnie podnoszą poziom stresu wszystkich użytkowników, a jeśli zespół nie jest dobrze przygotowany, mogą przejść do chaotycznego środowiska. Aby zminimalizować obciążenie i nieporozumienia, należy zaprojektować strategię odpowiedzi, udostępnić strategię odpowiedzi organizacji i regularnie wykonywać szkolenia w zakresie odpowiedzi.

Kluczowe strategie projektowania

Strategie odpowiedzi na sytuacje awaryjne powinny być dobrze zdefiniowanym zestawem procesów i procedur. Każdy proces i procedura powinny mieć skrypty, które zapewnią, że każdy krok zespół w kierunku szybkiego i bezpiecznego rozwiązania problemu. Aby opracować strategię odpowiedzi na sytuacje awaryjne, rozważ następujące omówienie:

  • wymagania wstępne
    • Opracowywanie systemu monitorowania
    • Tworzenie planu odpowiedzi na zdarzenie
  • Fazy zdarzeń
    • Wykrywanie i ograniczanie rozprzestrzeniania się wirusa
    • Klasyfikacja
  • Fazy po zdarzeniu
    • Analiza głównej przyczyny (rcA)
    • Post mortem
  • Bieżące działanie
    • Procedury odpowiedź na awarię

W poniższych sekcjach przedstawiono zalecenia dla każdej z tych faz.

System monitorowania

Aby mieć solidną strategię odpowiedzi w sytuacjach awaryjnych, musisz mieć solidny system monitorowania lub platformę obserwacji. Platforma z możliwością wglądu powinna mieć następujące cechy:

  • Całościowe monitorowanie: Upewnij się, że dokładnie monitorujesz obciążenie z perspektywy konfiguracji i aplikacji oraz uwzględniasz monitorowanie infrastruktury, jeśli składniki obciążenia są hostowane w chmurze lub lokalne. Upewnij się, że wszystkie składniki obciążenia są objęte strategią monitorowania. Jeśli na przykład obciążenie współdziała z zasobami platformy Azure lub systemem lokalnym, uwzględnij te składniki w monitorowaniu.

  • Pełne rejestrowanie: włącz pełne rejestrowanie składników, aby pomóc w badaniu podczas klasyfikowania problemu. Dzienniki struktury ułatwiają zarządzanie nimi. Automatyczne wysyłanie dzienników do źródeł danych w celu przygotowania się do analizy.

  • Przydatne pulpity nawigacyjne: Twórz pulpity nawigacyjne na podstawie modelu kondycji, które są dostosowane do każdego zespołu w organizacji. Różne zespoły są związane z różnymi aspektami kondycji obciążenia.

  • Alerty z możliwością działania: twórz alerty, które są przydatne dla zespołów ds. obciążeń. Należy unikać alertów, które nie wymagają działania zespołów. Zbyt wiele alertów tego typu może powodować ignorowanie lub blokowanie powiadomień o alertach.

  • Powiadomienia automatyczne: Upewnij się, że odpowiednie zespoły automatycznie otrzymują alerty, które wymagają od nich działania. Na przykład zespół pomocy technicznej poziomu 1 powinien otrzymywać powiadomienia o wszystkich alertach, podczas gdy inżynierowie ds. zabezpieczeń powinni otrzymywać alerty tylko o zdarzeniach związanych z bezpieczeństwem.

Dowiedz się więcej w temacie Zalecenia dotyczące projektowania i tworzenia struktury monitorowania.

Plan odpowiedzi na zdarzenie

Podstawą strategii odpowiedzi na zdarzenia jest plan odpowiedzi na zdarzenie. Podobnie jak w przypadku planu odzyskiwania po awarii, jasno i dokładnie zdefiniuj role, obowiązki i procedury reagowania na incydent. Plan powinien być dokumentem podlegającym regularnemu przeglądaniu, co zapewnia jego aktualność.

W planie należy dokładnie zdefiniować następujące składniki.

Role

Zidentyfikuj menedżera odpowiedzi na zdarzenie. Ta osoba jest właścicielem zdarzenia od inicjowania przez minimalizowanie do analizy głównej przyczyny. Menedżer ds. odpowiedzi na incydenty zapewnia, że procesy są przestrzegane, a odpowiednie strony są informowane podczas wykonywania swojej pracy przez zespół ds. odpowiedzi.

Zidentyfikuj lidera analizy post mortem. Ta osoba zapewnia, że czynności analizy post mortem zostaną wykonane wkrótce po rozwiązanym zdarzeniu. Utwórz raport, który pomoże w zastosowaniu ustaleń, które pochodzą z zdarzenia.

Procesy i procedury

Zespół obsługi obciążenia powinien definiować i zrozumieć kryteria wyboru. Jeśli zespół stwierdzi, że sprawa jest poważna, można zadeklarować awarię i zainicjować plan odzyskiwania danych. W mniej poważnych przypadkach problem może nie spełniać kryteriów klęski żywiołowej, ale mimo to należy go uznać za sytuację awaryjną, która wymaga zainicjowania planu odpowiedzi na wypadek sytuacji awaryjnej. Sytuacje awaryjne mogą mieć charakter wewnętrzny obciążenia, taki jak usterki w kodzie aplikacji, lub wynikać z problemu z zależnością obciążenia, takiego jak niedostępność interfejsu API lub bazy danych. Przyczyną może być również błąd dostawcy (np. problem z identyfikatorem lub Microsoft Entra ID lub Power Platform). Zespół pomocy technicznej musi być w stanie określić, czy problem spełnia kryteria awaryjne, nawet jeśli nie ma wglądu w podstawowy problem.

Dokładnie zdefiniuj plany komunikacji i eskalacji. W zależności od typu powiadomienia o alercie, które otrzymają, upewnij się, że członkowie zespołu pomocy technicznej poziomu 1 mogą łatwo kontaktować się z odpowiednimi zespołami w celu eskalacji problemów.

Inne elementy do dołączenia

Udokumentuj wszystkie standardowe narzędzia, które są używane podczas incydentów do komunikacji wewnętrznej, takie jak narzędzia do obsługi zgłoszeń lub narzędzia do planowania zaległości, takie jak Microsoft Teams narzędzia do obsługi zgłoszeń lub planowania zaległości.

Należy dokumentować poświadczenia sytuacji awaryjnej, znane również jako konta natychmiastowej reakcji. Należy dołączyć przewodnik krok po kroku opisujący sposób ich używania.

Twórz instrukcje dotyczące odpowiedzi w sytuacjach awaryjnych i rejestruj, kiedy ćwiczenia są wykonywane.

Udokumentuj wszelkie niezbędne środki prawne lub regulacyjne, takie jak informowanie o naruszeniach danych.

Wykrywanie i ograniczanie incydentów

W przypadku dobrze zaprojektowanego systemu monitorowania anomalii i automatycznego wykrywania alertów można szybko wykryć problemy i określić ich ważność. Jeśli problem zostanie uznany za awaryjny, można zainicjować plan. W niektórych przypadkach zespół pomocy technicznej nie jest powiadamiany za pośrednictwem systemu monitorowania. Użytkownicy mogą zgłaszać problemy związane z obsługą klienta, korzystając z aplikacji komunikacyjnych zespołu pomocy technicznej. Mogą też kontaktować się z osobami, z którymi regularnie współpracują lub o których wiedzą, że współpracują Power Platform, takimi jak Power Platform administratorzy usługi lub zespół Centrum doskonałości. Bez względu na to, w jaki sposób zespół pomocy technicznej został poinformowany, powinien zawsze wykonać te same kroki, aby sprawdzić poprawność problemu i określić przyczynę. Brak reakcji z planu odpowiedzi może dodawać nieporozumień.

Klasyfikacja

Pierwszym krokiem rozwiązywania problemu jest zidentyfikowanie składnika obciążenia, który powoduje problem. Czynności, które należy wykonać podczas klasyfikacji, zależą od typu problemu. Zespół zajmujący się określonym obszarem wsparcia obciążenia pracą powinien stworzyć procedury dla incydentów, które są związane z jego pracą. Na przykład zespoły ds. zabezpieczeń powinny rozwiązać problemy związane z zabezpieczeniami i powinny postępować zgodnie ze skryptami, które opracowują. Ważne jest, aby zespoły śledziły dobrze zdefiniowane skrypty podczas pracy nad ich działaniami klasyfikacji. Te skrypty powinny być instrukcjami krok po kroku, które obejmują procesy wycofywania w celu cofnięcia zmian, które są nieskuteczne lub mogą powodować inne problemy. Po rozwiązaniu problemu należy postępować zgodnie z dobrze zdefiniowanymi procesami, aby bezpiecznie przywrócić problematyczny składnik do ścieżki przepływu obciążenia.

Zgłaszanie analizy głównej przyczyny

Właściciel zdarzenia lub osoba, która ściśle z nim współpracowała, powinna utworzyć raporty z analizy przyczyn źródłowych (RCA). Ta strategia zapewnia dokładne rozliczanie zdarzenia. Zwykle organizacje mają zdefiniowany szablon RCA z wytycznymi dotyczącymi sposobu prezentowana informacji i rodzaju informacji, których można lub nie można udostępniać. Jeśli musisz utworzyć własny szablon i wytyczne, upewnij się, że interesariusze przejrzeli je i zatwierdzili.

Analizy post mortem zdarzenia

Osoba, która nie pełni roli w serwisie, powinna przeprowadzać analizy post mortem bez określania winy. W sesjach post mortem wszyscy mogą się dowiedzieć, co wynika z zdarzenia. Każdy zespół, który brał udział w odpowiedzi na incydent, powinien być reprezentowany przez osoby, które pracowały nad incydentem. Osoby te powinny przyjść na sesję przygotowane z przykładami działań, które zakończyły się sukcesem oraz obszarami, które można poprawić. Sesja nie jest forum do przypisywania winy za incydent lub problemów, które mogą pojawić się podczas odpowiedzi. Lider analiz post mortm powinien pozostawić w sesji jasną listę elementów akcji skupionych na poprawie, na przykład:

  • Udoskonalenia planu odpowiedzi. Procesy lub procedury mogą wymagać ponownego oceny i ponownego nadpisania, aby lepiej przechwytywać odpowiednie akcje.
  • Udoskonalenia systemu monitorowania. Progi mogą wymagać zmiany oceny w celu wcześniejszej kontroli nad określonym typem zdarzenia lub konieczne może być wdrożenie nowego monitorowania w celu wyłapania zachowania, które nie jest uwzględnione.
  • Udoskonalenia obciążenia. Zdarzenie może uwidocznić w obciążeniach lukę w zabezpieczeniach, która musi być rozwiązana jako trwałe zdarzenie.

Kwestie wymagające rozważenia

Strategia odpowiedzi na sytuację awaryjną powinna być blisko wyrównana z ogólną strategią pomocy technicznej Power Platform. Współpracuj z Power Platform administratorami i zespołem Centrum doskonałości w celu omówienia opcji i procesów pomocy technicznej i odpowiedzi w sytuacjach awaryjnych, które mogą być już zdefiniowane.

Podczas definiowania procesu pomocy technicznej i ścieżki eskalacji ważne jest, aby kategoryzować rozwiązania w oparciu o krytyczność. Ta praktyka pozwala na ustanowienie procesów, które zapewniają, że krytyczne aplikacje mają niezbędne bariery ochronne do ich obsługi, jednocześnie nie tłumiąc innowacji w scenariuszach produktywności ani nie przytłaczając zespołów odpowiedzi na incydenty. Podczas definiowania modeli pomocy technicznej pomyśl także o ścieżce stopniowania. Rozwiązanie może początkowo wymagać tylko pomocy technicznej na poziomie produktywności, ale może rozrastać się pod względem funkcjonalności lub bazy użytkowników, aby wymagać wyższego poziomu pomocy technicznej. Zdefiniuj sposób, w jaki twórcy mogą zażądać bardziej formalnej pomocy i przejścia do środowisk obsługiwanych.

Ułatwienia Power Platform

Power Platform integruje się z programem Application Insights, będącego częścią ekosystemu Azure Monitor. Używaj tej integracji do wykonywania następujących czynności:

  • Odbieranie telemetrii z diagnostyki i wydajności przechwyconej przez platformę Dataverse w Application Insights. Można subskrybować, aby otrzymywać dane telemetryczne dotyczące operacji wykonywanych przez aplikacje w bazie danych i Dataverse w aplikacjach opartych na modelach. 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. Tych analiz można użyć do diagnozowania problemów i zrozumienia, jak użytkownicy korzystają z aplikacji. Możesz zbierać informacje, które pomogą Ci podejmować lepsze decyzje biznesowe i poprawić jakość swoich aplikacji.

  • Skonfiguruj Power Automate telemetrię , do której ma przepływać Application Insights, na przykład w celu monitorowania wykonań przepływu w chmurze i tworzenia alertów dotyczących niepowodzeń uruchamiania 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.

Application Insights to kompleksowe rozwiązanie służące do zbierania, analizowania i odpowiadania na monitorowanie danych ze środowisk chmury i lokalnych. Obejmuje on niezawodny system alertów, na której można skonfigurować automatyczne powiadomienia i inne akcje.

Zestaw Power Platform Automation Kit to zestaw narzędzi, które przyspieszają korzystanie z aplikacji klasycznej Power Automate w projektach automatyzacji. Zestaw zawiera narzędzia pomocne przy zarządzaniu projektami automatyzacji i monitorowaniu ich w celu szacowania zaoszczędzanych środków i zwrotu z inwestycji (ROI). Częścią zestawu Automation Kit jest centrum sterowania, które uzupełnia istniejącą funkcję monitorowania przebiegów przepływu pulpitu. Głównym celem Centrum sterowania jest widok centrum pomocy technicznej dla analityków i organizacji, które w razie potrzeby mogą monitorować, podjąć działania i alerty.

Następne kroki

Lista kontrolna doskonałości operacyjnej