Share via

Doporučení pro návrh strategie reakce na mimořádné události

  • Článek

Platí pro toto doporučení kontrolního seznamu efektivity provozu azure Well-Architected Framework:

OE:08 Vyvinout efektivní postupy nouzového provozu. Ujistěte se, že vaše úloha vysílá smysluplné signály stavu napříč infrastrukturou a kódem. Shromážděte výsledná data a použijte je ke generování výstrah s akcemi, které prostřednictvím řídicích panelů a dotazů reagují na tísňové situace. Jasně definujte lidské zodpovědnosti, jako jsou obměna hovorů, řízení incidentů, přístup k nouzovým prostředkům a spouštění posmrtných událostí.

Tato příručka popisuje doporučení pro návrh strategie reakce na mimořádné události. Některé problémy, ke kterým dochází v průběhu životního cyklu úlohy, jsou natolik kritické, že je nutné deklarovat jako nouzové. Můžete implementovat úzce řízené a zaměřené procesy a postupy, které váš tým může dodržovat, aby se zajistilo, že se problém vyřeší klidným a spořádaným způsobem. Mimořádné události přirozeně zvýší úroveň stresu každého a můžou vést k chaotickému prostředí, pokud váš tým není dobře připravený. Pokud chcete minimalizovat stres a zmatenost, navrhněte strategii reakce, sdílejte ji s vaší organizací a pravidelně provádějte školení pro reakce na mimořádné události.

Klíčové strategie návrhu

Strategie reakce na mimořádné události by měla být uspořádaná a dobře definovaná sada procesů a postupů. Každý proces a procedura by měly mít skripty, které zajistí, že každý krok posune váš tým k rychlému a bezpečnému řešení problému. Pokud chcete vyvinout strategii reakce na tísňové situace, zvažte následující přehled:

  • Požadavky
    • Vývoj platformy pozorovatelnosti
    • Vytvoření plánu reakcí na incidenty
  • Fáze incidentu
    • Detekce
    • Členství ve skupině
    • Třídění
  • Fáze po incidentu
    • Analýza původní příčiny (RCA)
    • Dodatečná analýza
  • Probíhající aktivita
    • Postupy reakce na mimořádné události

Následující části obsahují doporučení pro každou z těchto fází.

Pozorovatelnost

Pokud chcete mít robustní strategii reakce na mimořádné události, musíte mít zavedenou robustní pozorovatelnou platformu. Vaše platforma pozorovatelnosti by měla mít následující vlastnosti:

  • Holistické monitorování: Ujistěte se, že úlohy pečlivě monitorujete z hlediska infrastruktury a aplikací.

  • Podrobné protokolování: Povolte podrobné protokolování komponent, které vám pomůže při zkoumání problému podle priorit. Strukturujte protokoly tak, aby se snadno spravují. Automaticky odesílat protokoly do datových jímek, aby byly připravené k analýze.

  • Užitečné řídicí panely: Vytvářejte řídicí panely založené na modelu stavu, které jsou přizpůsobené jednotlivým týmům v organizaci. Různé týmy zodpovídají za různé aspekty stavu úloh.

  • Výstrahy s možností akce: Vytvářejte upozornění, která jsou užitečná pro týmy úloh. Vyhněte se upozorněním, která nevyžadují akci od vašich týmů. Příliš mnoho upozornění tohoto druhu může vést k tomu, že lidé oznámení upozornění ignorují nebo blokují.

  • Automatická oznámení: Zajistěte, aby příslušné týmy automaticky dostávaly výstrahy, které od nich vyžadují akci. Například tým podpory vrstvy 1 by měl dostávat oznámení pro všechny výstrahy, zatímco vaši bezpečnostní technici by měli dostávat upozornění jenom na události zabezpečení.

Další informace najdete v tématu Doporučení pro návrh a vytvoření architektury pozorovatelnosti.

Plán reakce na incidenty

Základem strategie reakce na mimořádné události je plán reakce na incidenty. Podobně jako plán zotavení po havárii jasně a důkladně definujte role, povinnosti a postupy pro plán reakce na incidenty. Plán by měl být dokument se správou verzí, který je pravidelně kontrolovaný, aby se zajistilo, že je aktuální.

V plánu jasně definujte následující komponenty.

Role

Identifikace správce reakce na incidenty Tato osoba vlastní incident od zahájení až po nápravu až po analýzu původní příčiny. Správce reakce na incidenty zajišťuje, že se dodržují procesy a že příslušné strany jsou informovány, když tým reakce provádí svoji práci.

Identifikace posmrtné vedoucí instance Tato osoba zajišťuje, aby se posmrtné akce prováděly krátce po vyřešení incidentu. Vytvoří sestavu, která vám pomůže použít zjištění, která pocházejí z incidentu.

Procesy a postupy

Váš tým úloh by měl definovat a rozumět nouzovým kritériím. Když váš tým zjistí, že případ je závažný, můžete deklarovat havárii a zahájit plán zotavení po havárii. V méně závažných případech problém nemusí splňovat kritéria havárie. Přesto byste ale měli tento problém považovat za nouzový stav, který vyžaduje zahájení plánu reakce na mimořádné události. Mimořádné události můžou být problémy, které jsou interní pro vaši úlohu, nebo můžou být důsledkem problému se závislostí vaší úlohy. Tým podpory musí být schopný určit, jestli problém nahlášený externími uživateli splňuje kritéria nouzové situace, i když nemají žádný přehled o základním problému.

Přesně definovat plány komunikace a eskalace. V závislosti na typu oznámení o upozornění, které obdrží, se ujistěte, že vaše podpora vrstvy 1 může snadno kontaktovat příslušné týmy a eskalovat problémy. Ujistěte se, že vědí, jaký typ komunikace je vhodný pro interní a externí strany. Do plánů komunikace a eskalace zahrňte seznam rozvrhu hovorů a zaměstnanců.

Do celkového plánu zahrňte skripty pro zahrnutí a třídění. Týmy při provádění funkcí uzavření a třídění používají tyto podrobné postupy. Uveďte popis toho, co definuje uzavření incidentu.

Další položky k zahrnutí

Zdokumentujte všechny standardní nástroje, které se budou během incidentů používat k interní komunikaci, jako je Microsoft Teams, a ke sledování aktivit v průběhu incidentu, jako jsou nástroje pro vytváření lístků nebo nástroje pro plánování backlogu.

Zdokumentujte své nouzové přihlašovací údaje, které se také označují jako účty s proskleným sklem. Připojte podrobného průvodce, který popisuje, jak se mají používat.

Vytvářejte podrobné pokyny pro reakce na tísňové události a udržujte si záznamy o tom, kdy byly postupy provedeny.

Zdokumentování všech nezbytných právních nebo regulačních opatření, například komunikace o úniku dat.

Detekce incidentů

Pokud máte dobře navrženou platformu pozorovatelnosti, která monitoruje anomálie a automaticky na ně upozorní, můžete rychle detekovat problémy a určit jejich závažnost. Pokud se problém považuje za nouzový, je možné plán zahájit. V některých případech není tým podpory upozorněn prostřednictvím platformy pozorovatelnosti. Zákazníci můžou hlásit problémy podpoře pomocí komunikačních cest týmu podpory. Nebo se můžou spojit s lidmi, se kterými pravidelně pracují, jako jsou vedoucí pracovníci účtů nebo virtuální počítače. Bez ohledu na to, jak tým podpory obdrží oznámení, měl by vždy postupovat stejným postupem, aby ověřil problém a určil závažnost. Odchylka od plánu reakce může přidat stres a zmatenost.

Členství ve skupině

Prvním krokem při nápravě problému je zahrnutí problému za účelem ochrany zbytku vaší úlohy. Strategie omezování závisí na typu problému, ale obvykle zahrnuje odebrání ovlivněné komponenty z cest toku úloh. Můžete například vypnout prostředek nebo ho odebrat z cest síťového směrování. Správci systémů, technici a vedoucí vývojáři by měli spolupracovat na návrhu strategií omezování. Uzavření by mělo omezit poloměr výbuchu problémů a zachovat funkčnost úloh ve sníženém stavu, dokud se problém nevyřeší. Pokud musí být ovlivněná komponenta přístupná, aby bylo možné provést posouzení, je důležité, aby byl její přístup ke zbytku úlohy zablokovaný. Pokud je to možné, měli byste ke komponentě přistupovat pouze prostřednictvím cesty, která je oddělená od úlohy a zbytku systémů.

Třídění

Po úspěšném vyřešení problému můžete zahájit práci na posouzení. Postup při třídění závisí na typu problému. Tým pro určitou oblast podpory úloh by měl vytvořit postupy pro incidenty, které souvisejí s jejich týmem. Týmy zabezpečení by například měly analyzovat problémy se zabezpečením a měly by postupovat podle skriptů, které vyvíjejí. Je důležité, aby týmy při práci s tříděním postupovaly podle dobře definovaných skriptů. Tyto skripty by měly být podrobné procesy, které zahrnují procesy vrácení zpět, aby bylo možné vrátit změny, které jsou neefektivní nebo můžou způsobit jiné problémy. Pomocí nástrojů pro agregaci a analýzu protokolů můžete efektivně zkoumat problémy, které vyžadují hloubkovou analýzu. Po vyřešení problému postupujte podle dobře definovaných procesů, abyste ovlivněnou komponentu bezpečně přenesli zpět do cest toku úloh.

Generování sestav RCA

Smlouvy o úrovni služeb (SLA) pro vaše zákazníky můžou diktovat, že během určitého časového období od vyřešení incidentu musíte vydat sestavy RCA. Vlastník incidentu by měl vytvořit sestavy RCA. Pokud to není možné, může sestavy RCA vytvořit jiná osoba, která úzce spolupracovala s vlastníkem incidentu. Tato strategie zajišťuje přesné zaúčtování incidentu. Organizace mají obvykle definovanou šablonu RCA s pokyny k tomu, jak se informace prezentují a jaké druhy informací se dají nebo nedají sdílet. Pokud potřebujete vytvořit vlastní šablonu a pokyny, ujistěte se, že jsou zkontrolovány a schváleny zúčastněnými stranami.

Následné incidenty

Nestranný jednotlivec by měl vést posmrtná bez obviňování. V následných relacích všichni sdílejí svá zjištění z incidentu. Každý tým, který byl zapojen do reakce na incident, by měl být reprezentován osobami, které na incidentu pracovaly. Tito jednotlivci by měli přijít na zasedání připravené s příklady oblastí, které byly úspěšné, a oblastí, které lze zlepšit. Relace není fórum pro přiřazování viníka incidentu nebo problémů, ke kterým mohlo dojít během reakce. Vedoucí po skončení schůzky by měl opustit relaci s jasným seznamem položek akcí, které se zaměřují na zlepšení, například:

  • Vylepšení plánu reakce. Procesy nebo postupy může být potřeba znovu vyhodnocovat a přepsat, aby se lépe zachytávaly příslušné akce.

  • Vylepšení platformy pozorovatelnosti Aby bylo možné zachytit konkrétní typ incidentu dříve, může být potřeba znovu vyhodnotit prahové hodnoty, nebo může být potřeba implementovat nové monitorování, aby se zachytilo chování, které nebylo zohledněno.

  • Vylepšení úloh. Incident může vystavit chybu zabezpečení v úloze, kterou je potřeba vyřešit jako trvalou nápravu.

Požadavky

Příliš agresivní strategie reakce může vést k falešným poplachům nebo zbytečným eskalacím.

Podobně agresivní implementace automatického škálování nebo jiných samoopravených akcí, které reagují na překročení prahových hodnot, může vést ke zbytečným výdajům a režijní zátěži. Možná neznáte přesné prahové hodnoty pro nastavení upozornění a automatických akcí, jako je škálování. Proveďte testování v nižších prostředích a v produkčním prostředí, abyste mohli určit správné prahové hodnoty pro vaše požadavky.

Usnadnění Azure

Azure Monitor je komplexní řešení pro shromažďování, analýzu a reagování na data monitorování z cloudových a místních prostředí. Zahrnuje robustní upozorňující platformu, kterou můžete nakonfigurovat pro automatická oznámení a další akce, jako je automatické škálování a další mechanismy samoopravení.

Využijte Monitorování k integraci strojového učení. Automatizujte a optimalizujte posouzení incidentů a proaktivní opatření. Další informace najdete v tématu AIOps a strojové učení ve službě Monitor.

Log Analytics je robustní analytický nástroj, který je součástí monitorování. Log Analytics můžete použít ke spouštění dotazů na agregované protokoly a získání přehledu o úlohách.

Microsoft nabízí školení připravenosti na incidenty související s Azure. Další informace najdete v tématech Úvod do připravenosti na incidenty Azure a Připravenost na incidenty.

Kontrolní seznam efektivity provozu

Projděte si kompletní sadu doporučení.

Kontrolní seznam efektivity provozu