Zalecenia dotyczące projektowania strategii reagowania kryzysowego

Dotyczy tego zalecenia z listy kontrolnej dotyczącej doskonałości operacyjnej platformy Azure Well-Architected Framework:

OE:08

Opracowanie efektywnej praktyki w zakresie operacji ratowniczych. Upewnij się, że obciążenie emituje znaczące sygnały kondycji w całej infrastrukturze i kodzie. Zbierz wynikowe dane i użyj ich do generowania alertów z możliwością działania, które uchwalają reagowanie awaryjne za pośrednictwem pulpitów nawigacyjnych i zapytań. Jasno zdefiniuj obowiązki człowieka, takie jak rotacje połączeń, zarządzanie zdarzeniami, dostęp do zasobów awaryjnych i uruchamianie zadań pośmiertnych.

W tym przewodniku opisano zalecenia dotyczące projektowania strategii reagowania kryzysowego. Niektóre problemy występujące w trakcie cyklu życia obciążenia są wystarczająco krytyczne, aby uzasadnić ich sytuacje awaryjne. Można zaimplementować ściśle kontrolowane i ukierunkowane procesy i procedury, które zespół może wykonać, aby upewnić się, że problem jest obsługiwany w spokojny, uporządkowany sposób. Sytuacje awaryjne naturalnie zwiększają poziom stresu wszystkich i mogą prowadzić do chaotycznego środowiska, jeśli twój zespół nie jest dobrze przygotowany. Aby zminimalizować stres i zamieszanie, zaprojektuj strategię reagowania, podziel się strategią reagowania z organizacją i wykonaj regularne szkolenia w zakresie reagowania kryzysowego.

Kluczowe strategie projektowania

Strategia reagowania kryzysowego powinna być uporządkowanym, dobrze zdefiniowanym zestawem procesów i procedur. Każdy proces i procedura powinny mieć skrypty, aby upewnić się, że każdy krok postępuje w kierunku szybkiego i bezpiecznego rozwiązywania problemu. Aby opracować strategię reagowania kryzysowego, rozważ następujące omówienie:

• Wymagania wstępne
  • Opracowywanie platformy do obserwacji
  • Tworzenie planu reagowania na zdarzenia
• Fazy zdarzeń
  • Detection
  • Zamknięcia
  • Triage (klasyfikacja)
• Fazy po zdarzeniu
  • Analiza głównej przyczyny
  • Postmortem
• Bieżące działania
  • Przechodzenie do szczegółów reagowania awaryjnego

W poniższych sekcjach przedstawiono zalecenia dotyczące każdej z tych faz.

Aby zapewnić niezawodną strategię reagowania kryzysowego, musisz mieć niezawodną platformę do obserwacji. Platforma obserwacji powinna mieć następujące cechy:

• Całościowe monitorowanie: upewnij się, że dokładnie monitorujesz obciążenie z perspektywy infrastruktury i aplikacji.

• Pełne rejestrowanie: włącz pełne rejestrowanie składników, aby ułatwić badanie podczas klasyfikacji problemu. Dzienniki struktury, dzięki czemu można je łatwo zarządzać. Automatycznie wysyłaj dzienniki do ujść danych, które mają być przygotowane do analizy.

• Przydatne pulpity nawigacyjne: tworzenie pulpitów nawigacyjnych opartych na modelu kondycji dostosowanych do poszczególnych zespołów w organizacji. Różne zespoły są odpowiedzialne za różne aspekty kondycji obciążenia.

• Alerty z możliwością działania: utwórz alerty przydatne dla zespołów obciążeń. Unikaj alertów, które nie wymagają akcji ze strony Twoich zespołów. Zbyt wiele alertów tego rodzaju może prowadzić do ignorowania lub blokowania powiadomień o alertach.

• Powiadomienia automatyczne: upewnij się, że odpowiednie zespoły automatycznie otrzymują alerty, które wymagają od nich akcji. Na przykład zespół pomocy technicznej warstwy 1 powinien otrzymywać powiadomienia dotyczące wszystkich alertów, podczas gdy inżynierowie zabezpieczeń powinni otrzymywać tylko alerty dotyczące zdarzeń zabezpieczeń.

Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące projektowania i tworzenia struktury obserwacji.

Tworzenie planu reagowania na zdarzenia

Podstawą strategii reagowania kryzysowego jest plan reagowania na zdarzenia. Podobnie jak plan odzyskiwania po awarii, jasno i dokładnie zdefiniuj role, obowiązki i procedury planu reagowania na zdarzenia. Plan powinien być dokumentem kontrolowanym pod kontrolą wersji, który podlega regularnym przeglądom, które zapewniają jego aktualność.

Jasno zdefiniuj następujące składniki w planie.

Role

Zidentyfikuj menedżera reagowania na zdarzenia. Ta osoba jest właścicielem zdarzenia od zainicjowania w celu skorygowania głównej analizy przyczyny. Menedżer reagowania na zdarzenia zapewnia, że procesy są przestrzegane, a odpowiednie strony są informowane, gdy zespół reagowania wykonuje swoją pracę.

Zidentyfikuj lidera pośmiertnego. Ta osoba gwarantuje, że operacje pośmiertne są wykonywane wkrótce po rozwiązaniu zdarzenia. Tworzą one raport, który ułatwia zastosowanie ustaleń, które pochodzą z incydentu.

Procesy i procedury

Zespół ds. obciążeń powinien zdefiniować i zrozumieć kryteria awaryjne. Gdy zespół ustali, że przypadek jest poważny, możesz zadeklarować awarię i zainicjować plan odzyskiwania po awarii. W mniej poważnych przypadkach problem może nie spełniać kryteriów awarii. Należy jednak rozważyć problem awaryjny, który wymaga zainicjowania planu reagowania kryzysowego. Sytuacje awaryjne mogą być problemami wewnętrznymi obciążenia lub mogą być wynikiem problemu z zależnością obciążenia. Zespół pomocy technicznej musi mieć możliwość określenia, czy problem zgłoszony przez użytkowników zewnętrznych spełnia kryteria awaryjne, nawet jeśli nie ma wglądu w problem źródłowy.

Dokładnie zdefiniuj plany komunikacji i eskalacji. Na podstawie typu otrzymywanego powiadomienia o alertach upewnij się, że pomoc techniczna w warstwie 1 może łatwo skontaktować się z odpowiednimi zespołami w celu eskalacji problemów. Upewnij się, że wiedzą, jakiego typu komunikacja jest odpowiednia dla stron wewnętrznych i zewnętrznych. W planach komunikacji i eskalacji dołącz listę harmonogramów rozmów i pracowników.

W ogólnym planie uwzględnij skrypty zawierające i klasyfikacji. Zespoły wykonują te procedury krok po kroku, gdy wykonują swoje funkcje zawierania i klasyfikacji. Dołącz opis tego, co definiuje zamknięcie zdarzenia.

Inne elementy do uwzględnienia

Udokumentować wszystkie standardowe narzędzia, które będą używane podczas zdarzeń do komunikacji wewnętrznej, takiej jak Microsoft Teams, oraz do śledzenia działań w trakcie zdarzenia, takich jak narzędzia do tworzenia biletów lub narzędzia do planowania listy prac.

Udokumentuj poświadczenia awaryjne, nazywane inaczej kontami ze szkła awaryjnego. Dołącz przewodnik krok po kroku, który opisuje sposób ich użycia.

Utwórz instrukcje przechodzenia do szczegółów reagowania awaryjnego i zachowaj rekord podczas wykonywania ćwiczeń.

Udokumentowanie wszelkich niezbędnych środków prawnych lub regulacyjnych, na przykład komunikowania naruszeń danych.

Wykonywanie działań na temat wyzwalaczy obserwacji

Jeśli masz dobrze zaprojektowaną platformę do obserwacji, która monitoruje anomalie i automatycznie powiadamia o nich, możesz szybko wykrywać problemy i określać 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 platformy do obserwacji. Klienci mogą zgłaszać problemy do pomocy technicznej przy użyciu możliwości komunikacji zespołu pomocy technicznej. Mogą też skontaktować się z osobami, z którymi regularnie pracują, takimi jak kierownictwo ds. kont lub adresy wirtualne. Niezależnie od tego, jak zespół pomocy technicznej jest powiadamiany, zawsze powinni wykonać te same kroki, aby zweryfikować problem i określić ważność. Odchylenie od planu odpowiedzi może dodać stres i zamieszanie.

Definiowanie procedur zawierania

Pierwszym krokiem w rozwiązaniu problemu jest powstrzymanie problemu w celu ochrony reszty obciążenia. Strategia zawierania zależy od typu problemu, ale zwykle obejmuje usunięcie składnika, którego dotyczy problem, ze ścieżek przepływu obciążenia. Możesz na przykład zamknąć zasób lub usunąć go ze ścieżek routingu sieciowego. Administratorzy systemu, inżynierowie i starsi deweloperzy powinni współpracować ze sobą w celu projektowania strategii zawierania. Ograniczenie powinno ograniczać promień problemów i utrzymywać funkcjonalność obciążenia w stanie obniżonej wydajności do momentu rozwiązania problemu. Jeśli składnik, którego dotyczy problem, musi być dostępny w celu przeprowadzenia klasyfikacji, konieczne jest zablokowanie dostępu do pozostałej części obciążenia. Jak najwięcej, należy uzyskać dostęp tylko do składnika za pośrednictwem ścieżki oddzielonej od obciążenia i reszty systemów.

Definiowanie procedur klasyfikacji

Po pomyślnym usunięciu problemu można rozpocząć klasyfikację. Kroki wykonywane podczas klasyfikacji zależą od typu problemu. Zespół pomocy technicznej dla określonego obszaru obciążeń powinien tworzyć procedury dotyczące zdarzeń związanych z ich zespołem. Na przykład zespoły ds. zabezpieczeń powinny klasyfikować problemy z zabezpieczeniami i powinny postępować zgodnie ze skryptami, które opracowują. Ważne jest, aby zespoły przestrzegały dobrze zdefiniowanych skryptów podczas pracy nad klasyfikacją. Te skrypty powinny być procesami krok po kroku, które obejmują procesy wycofywania w celu cofnięcia zmian, które są nieskuteczne lub mogą powodować inne problemy. Użyj gotowych narzędzi do agregacji i analizy dzienników, aby efektywnie badać problemy wymagające głębokiej analizy. Po rozwiązaniu problemu postępuj zgodnie z dobrze zdefiniowanymi procesami, aby bezpiecznie przenieść składnik, którego dotyczy problem, z powrotem do ścieżek przepływu obciążenia.

Generowanie raportów zdarzeń analizy głównej przyczyny

Umowy dotyczące poziomu usług (SLA) dla klientów mogą dyktować, że musisz wydać raporty głównej przyczyny w określonym czasie po rozwiązaniu zdarzenia. Właściciel zdarzenia powinien utworzyć raporty analizy głównej przyczyny. Jeśli to nie jest możliwe, inna osoba, która ściśle współpracowała z właścicielem zdarzenia, może utworzyć raporty analizy głównej przyczyny. Ta strategia zapewnia dokładną księgowość incydentu. Zazwyczaj organizacje mają zdefiniowany szablon analizy głównej przyczyny z wytycznymi dotyczącymi sposobu prezentowania informacji i rodzaju informacji, które mogą lub nie mogą być udostępniane. Jeśli musisz utworzyć własny szablon i wytyczne, upewnij się, że są one przeglądane i zatwierdzane przez uczestników projektu.

Wstrzymanie pośmiertnych zdarzeń

Bezstronna osoba powinna prowadzić bez winy pośmiertnie. W sesjach pośmiertnych wszyscy dzielą się swoimi wynikami z incydentu. Każdy zespół zaangażowany w reagowanie na zdarzenia powinien być reprezentowany przez osoby, które pracowały nad incydentem. Osoby te powinny przyjść na sesję przygotowaną z przykładami obszarów, które odniosły sukces i które można poprawić. Sesja nie jest forum do przypisywania winy za zdarzenie lub problemy, które mogły pojawić się podczas odpowiedzi. Lider postmortem powinien pozostawić sesję z czystą listą elementów akcji, które koncentrują się na ulepszaniu, takich jak:

• Ulepszenia planu odpowiedzi. Procesy lub procedury mogą wymagać ponownego oceny i ponownego zapisania w celu lepszego przechwytywania odpowiednich akcji.

• Ulepszenia platformy do obserwacji. W celu wcześniejszego przechwycenia określonego typu zdarzenia może być konieczne ponowne oszacowanie progów lub konieczne może być zaimplementowanie nowego monitorowania w celu przechwycenia zachowania, które nie zostało uwzględnione.

• Ulepszenia obciążenia. Zdarzenie może ujawnić lukę w zabezpieczeniach obciążenia, która musi zostać usunięta jako trwałe korygowanie.

Kwestie wymagające rozważenia

Zbyt agresywna strategia reagowania może prowadzić do fałszywych alarmów lub niepotrzebnych eskalacji.

Podobnie agresywne wdrażanie automatycznego skalowania lub innych akcji samonaprawiania w celu reagowania na naruszenia progów może prowadzić do niepotrzebnych wydatków i obciążeń związanych z zarządzaniem. Możesz nie znać dokładnych progów ustawionych dla alertów i akcji automatycznych, takich jak skalowanie. Przeprowadź testowanie w niższych środowiskach i w środowisku produkcyjnym, aby ułatwić określenie odpowiednich progów wymagań.

Ułatwienia platformy Azure

Usługa Azure Monitor to kompleksowe rozwiązanie do zbierania, analizowania i reagowania na dane monitorowania ze środowisk w chmurze i środowiskach lokalnych. Zawiera niezawodną platformę alertów, którą można skonfigurować pod kątem automatycznych powiadomień i innych akcji, takich jak automatyczne skalowanie i inne mechanizmy samonaprawiania.

Użyj monitora, aby zintegrować uczenie maszynowe. Automatyzowanie i optymalizowanie klasyfikacji zdarzeń oraz proaktywnych miar. Aby uzyskać więcej informacji, zobacz AIOps i uczenie maszynowe w monitorze.

Log Analytics to niezawodne narzędzie analityczne wbudowane w monitor. Usługa Log Analytics umożliwia uruchamianie zapytań względem zagregowanych dzienników i uzyskiwanie szczegółowych informacji o obciążeniu.

Firma Microsoft oferuje szkolenia dotyczące gotowości zdarzeń związanych z platformą Azure. Aby uzyskać więcej informacji, zobacz Introduction to Azure incident readiness and Incident readiness (Wprowadzenie do gotowości zdarzeń i gotowość incydentów na platformie Azure).

Pokrewne łącza

• Zalecenia dotyczące projektowania i tworzenia struktury obserwacji
• Zalecenia dotyczące projektowania niezawodnej strategii monitorowania i zgłaszania alertów
• Zalecenia dotyczące samonaprawiania i samonaprawiania

Lista kontrolna doskonałości operacyjnej

Zapoznaj się z pełnym zestawem zaleceń.

Lista kontrolna doskonałości operacyjnej