Zalecenia dotyczące projektowania strategii reagowania awaryjnego

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

W tym przewodniku opisano zalecenia dotyczące projektowania strategii reagowania awaryjnego. Niektóre problemy, które pojawiają się w trakcie cyklu życia obciążenia, są na tyle 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. Sytuacja kryzysowa naturalnie podnosi poziom stresu wszystkich i może 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 awaryjnego.

Kluczowe strategie projektowania

Strategia reagowania awaryjnego 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 rozwija twój zespół w kierunku szybkiego i bezpiecznego rozwiązywania problemu. Aby opracować strategię reagowania na zagrożenia, rozważ następujące omówienie:

• Wymagania wstępne
  • Opracowywanie platformy do obserwacji
  • Tworzenie planu reagowania na zdarzenia
• Fazy zdarzeń
  • Wykrywanie
  • Zawieranie
  • 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.

Wgląd w informacje

Aby zapewnić niezawodną strategię reagowania na zagrożenia, musisz mieć niezawodną platformę do obserwacji. Platforma do 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 klasyfikowania 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 ds. obciążeń. Unikaj alertów, które nie wymagają akcji ze strony 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 wglądu.

Plan reagowania na zdarzenia

Podstawą strategii reagowania na zagrożenia 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

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

Identyfikowanie lidera postmortemu. Ta osoba gwarantuje, że operacje pośmiertne są wykonywane wkrótce po rozwiązaniu zdarzenia. Tworzą one raport, który pomaga zastosować ustalenia, które pochodzą z incydentu.

Procesy i procedury

Zespół ds. obciążeń powinien definiować i rozumieć kryteria awaryjne. Gdy twój 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. Jednak nadal należy rozważyć problem w nagłych wypadkach, co wymaga zainicjowania planu reagowania awaryjnego. 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łaszany przez użytkowników zewnętrznych spełnia kryteria awaryjne, nawet jeśli nie ma wglądu w podstawowy problem.

Dokładnie zdefiniuj plany komunikacji i eskalacji. Na podstawie typu otrzymywanego powiadomienia o alercie 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 zawierania i klasyfikacji. Zespoły wykonują te procedury krok po kroku, gdy wykonują swoje funkcje zawierania i klasyfikacji. Podaj 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, inaczej znane jako konta awaryjne. Dołącz przewodnik krok po kroku opisujący sposób ich użycia.

Utwórz instrukcje dotyczące przechodzenia do szczegółów reagowania awaryjnego i zachowaj rekord czasu wykonywania ćwiczeń.

Udokumentowanie wszelkich niezbędnych środków prawnych lub regulacyjnych, na przykład w celu informowania o naruszeniach danych.

Wykrywanie zdarzeń

Jeśli masz dobrze zaprojektowaną platformę do obserwacji, która monitoruje anomalie i automatycznie na nich alerty, możesz szybko wykrywać problemy i określać ich ważność. Jeśli problem zostanie uznany za awaryjny, plan można zainicjować. 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ą, np. dyrektorami ds. kont lub dostawcami wirtualnymi. 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 reagowania może dodać stres i zamieszanie.

Zawieranie

Pierwszym krokiem w rozwiązaniu problemu jest rozwiązanie problemu w celu ochrony pozostałej części 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. Zawieranie powinno ograniczać promień wybuchu 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 do przeprowadzenia klasyfikacji, ważne jest, aby dostęp do pozostałej części obciążenia był zablokowany. Jak najwięcej, należy uzyskać dostęp tylko do składnika za pośrednictwem ścieżki oddzielonej od obciążenia i pozostałych systemów.

Triage (klasyfikacja)

Po pomyślnym wystąpieniu problemu można rozpocząć klasyfikację. Kroki wykonywane podczas klasyfikacji zależą od typu problemu. Zespół ds. obsługi obciążeń powinien utworzyć procedury dla 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 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.

Raportowanie 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 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 głównej przyczyny. Ta strategia zapewnia dokładną księgowość zdarzenia. 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.

Postmortemy zdarzeń

Bezstronna osoba powinna prowadzić bez winy postmortems. W sesjach postmortem każdy dzieli się swoimi ustaleniami z incydentu. Każdy zespół, który był 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 zakończyły się powodzeniem 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 opuścić sesję z jasną listą elementów akcji, które koncentrują się na ulepszeniach, takich jak:

• Ulepszenia planu odpowiedzi. W celu lepszego przechwytywania odpowiednich akcji może być konieczne ponowne oceny procesów lub procedur.

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

• Ulepszenia obciążenia. Zdarzenie może ujawnić lukę w zabezpieczeniach w obciążeniu, które należy rozwiązać jako trwałe korygowanie.

Zagadnienia do rozważenia

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

Podobnie agresywnie implementowanie automatycznego skalowania lub innych działań 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 automatycznych akcji, takich jak skalowanie. Wykonaj testy 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. Za pomocą usługi Log Analytics można uruchamiać zapytania względem zagregowanych dzienników i uzyskiwać szczegółowe informacje o obciążeniu.

Firma Microsoft oferuje szkolenia dotyczące gotowości do 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ń na platformie Azure i gotowość do zdarzeń).

Linki pokrewne

• 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 samozachowawczego

Lista kontrolna doskonałości operacyjnej

Zapoznaj się z pełnym zestawem zaleceń.