Sdílet prostřednictvím

Doporučení pro návrh strategie reakce na tísňovou reakci

  • Článek

Platí pro toto doporučení kontrolního seznamu provozní efektivity architektury Azure Well-Architected Framework:

OE:08 Vytvořte efektivní postupy pro nouzový provoz. 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 k vygenerování výstrah s možností reakce na tísňové volání prostřednictvím řídicích panelůachchch Jasně definovat lidské odpovědnosti, jako jsou obměna na volání, řízení incidentů, přístup k prostředkům tísňového volání a spouštění posmrtných událostí.

Tato příručka popisuje doporučení pro návrh strategie reakce na tísňové volání. Některé problémy, ke kterým dochází v průběhu životního cyklu úlohy, jsou dostatečně důležité, aby bylo nutné je deklarovat jako nouzové situace. 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 zpracovává klidným a uspořádaným způsobem. Mimořádné situace přirozeně vyvolávají úrovně stresu všech uživatelů a mohou vést k chaotickému prostředí, pokud váš tým není dobře připravený. Pokud chcete minimalizovat stres a nejasnosti, navrhněte strategii reakce, sdílejte strategii reakce s vaší organizací a proveďte pravidelné školení k nouzové reakci.

Klíčové strategie návrhu

Strategie nouzové reakce by měla být uspořádaná, dobře definovaná sada procesů a postupů. Každý proces a postup by měly mít skripty, které zajistí, že každý krok postupuje ve vašem týmu k rychlému a bezpečnému řešení problému. Při vývoji strategie nouzové reakce zvažte následující přehled:

  • Předpoklady
    • Vývoj platformy pozorovatelnosti
    • Vytvoření plánu reakcí na incidenty
  • Fáze incidentů
    • Detection
    • Omezení
    • Posouzení
  • Fáze po incidentu
    • Analýza původní příčiny (RCA)
    • Dodatečná analýza
  • Probíhající aktivita
    • Postupy reakce na tísňové volání

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

Pokud chcete mít robustní strategii nouzové reakce, musíte mít zavedenou robustní platformu pozorovatelnosti. Vaše platforma pozorovatelnosti by měla mít následující charakteristiky:

  • Holistické monitorování: Zajistěte důkladné monitorování úloh z hlediska infrastruktury a aplikací.

  • Podrobné protokolování: Povolte podrobné protokolování pro komponenty, které vám pomůžou s vyšetřováním při třídění problému. Strukturujte protokoly tak, aby se snadno spravily. 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 rámci vaší organizace. Různé týmy zodpovídají za různé aspekty stavu úloh.

  • Upozornění s možností akce: Vytvořte upozornění, která jsou užitečná pro vaše týmy úloh. Vyhněte se upozorněním, která nevyžadují akci od týmů. Příliš mnoho upozornění tohoto typu může vést k ignorování nebo blokování oznámení výstrah.

  • 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šechna upozornění, zatímco vaši technici zabezpečení by měli dostávat výstrahy jenom pro události zabezpečení.

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

Vytvoření plánu reakcí na incidenty

Základem strategie nouzové reakce je plán reakce na incidenty. Stejně jako plán zotavení po havárii jasně a důkladně definujte role, zodpovědnosti a postupy pro plán reakce na incidenty. Plán by měl být dokument řízený verzí, na který se vztahují pravidelné kontroly, které zajišťují, že je aktuální.

Jasně definujte následující komponenty ve vašem plánu.

Role

Identifikace manažera reakce na incidenty Tato osoba vlastní incident od zahájení až po nápravu analýzy původní příčiny. Vedoucí reakce na incidenty zajistí, že se budou dodržovat procesy a příslušné strany budou informovány, když tým reakce provádí svou práci.

Identifikujte vedoucího postmortem. Tento jednotlivec zajistí, že se postmortemy provádějí brzy po vyřešení incidentu. Vytvoří sestavu, která vám pomůže použít zjištění, která z incidentu pocházejí.

Procesy a postupy

Váš tým úloh by měl definovat a porozumět kritériím tísňového volání. 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 nemusí problém splňovat kritéria havárie. Přesto byste ale měli zvážit problém, který vyžaduje zahájení plánu nouzové reakce. Mimořádné situace můžou být problémy, které jsou pro vaši úlohu interní nebo můžou být vý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 tísňového volání, i když nemají žádný přehled o základním problému.

Přesně definovat plány komunikace a eskalace. Na základě 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. V plánech komunikace a eskalace zahrnují seznam plánů na volání a zaměstnanců.

Do celkového plánu zahrňte skripty pro zahrnutí a třídění. Týmy postupují podle těchto podrobných postupů, když provádějí své funkce zahrnutí a třídění. Uveďte popis toho, co definuje uzavření incidentu.

Další položky, které se mají zahrnout

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

Zdokumentujte své přihlašovací údaje pro tísňové volání, jinak označované jako účty break-glass. Uveďte podrobný průvodce, který popisuje, jak se mají používat.

Vytvořte pokyny pro podrobnou analýzu tísňového volání a poznamenejte si, kdy byly provedeny postupy.

Zdokumentování jakýchkoli právních nebo regulačních opatření nezbytných například pro komunikaci porušení zabezpečení dat.

Reakce na triggery pozorovatelnosti

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é zahájit plán. V některých případech není tým podpory prostřednictvím platformy pozorovatelnosti upozorněn. Zákazníci můžou nahlásit problémy s podporou pomocí cest komunikace týmu podpory. Nebo se mohou 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 je tým podpory upozorněn, by měl vždy postupovat podle stejných kroků k ověření problému a určení závažnosti. Odchylka od plánu reakce může přidat stres a zmatenost.

Definování postupů zahrnutí

Prvním krokem při nápravě problému je uložení problému, který chrání zbytek vaší úlohy. Strategie zahrnutí 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 směrování sítě. Správci systému, technici a vedoucí vývojáři by měli spolupracovat na návrhu strategií zahrnutí. Uzavření by mělo omezit poloměr výbuchu problémů a udržovat funkčnost úloh v degradovaném stavu, dokud se problém nevyřeší. Pokud musí být ovlivněná komponenta přístupná k provádění třídění, je důležité, aby byl přístup ke zbytku úlohy zablokovaný. Co nejvíce byste měli ke komponentě přistupovat pouze prostřednictvím cesty, která je oddělená od úlohy a ostatních systémů.

Definování postupů třídění

Po úspěšném zahrnutí problému můžete zahájit třídění práce. Postup, který provedete během 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 řešit problémy se zabezpečením a měly by postupovat podle skriptů, které vyvíjejí. Je důležité, aby týmy sledovaly dobře definované skripty při práci na třídění. Tyto skripty by měly být podrobné procesy, které zahrnují procesy vrácení zpět za účelem vrácení změn zpět, které jsou neefektivní nebo můžou způsobit jiné problémy. Pomocí nástrojů pro agregaci a analýzu protokolů mimo plán 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ů a bezpečně přeneste ovlivněnou komponentu zpět do cest toku úloh.

Generování sestav incidentů RCA

Smlouvy o úrovni služeb (SLA) pro vaše zákazníky můžou diktovat, že po vyřešení incidentu budete muset vydávat sestavy RCA v určitém časovém období. 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é účtování incidentu. Organizace mají obvykle definovanou šablonu RCA s pokyny k zobrazení informací a o tom, jaké druhy informací se můžou 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.

Blokování incidentů pomortems

Nestranný člověk by měl vést bez viny postmortems. V postmortemových relacích sdílí všichni svá zjištění z incidentu. Každý tým, který byl zapojen do reakce na incident, by měl být reprezentován jednotlivci, kteří na incidentu pracovali. Tito jednotlivci by měli přijít na zasedání připravené s příklady oblastí, které byly úspěšné a oblasti, které lze zlepšit. Relace není fórum pro přiřazování viní z incidentu nebo problémů, které by mohly během reakce nastat. Vedoucí postmortem 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ůžou být potřeba znovu vyhodnotit a přepsat, aby bylo možné lépe zachytit vhodné akce.

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

  • Vylepšení úlohy Incident může vystavit chybu zabezpečení v úloze, která se musí řešit jako trvalá náprava.

Důležité informace

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

Podobně může agresivní implementace automatického škálování nebo jiných samoopravených akcí, které reagují na porušení prahových hodnot, vést k zbytečným výdajům a režijní zátěži. Možná neznáte přesné prahové hodnoty nastavené pro upozorňování a automatické akce, 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 monitorování dat z cloudových a místních prostředí. Zahrnuje robustní platformu pro upozorňování, kterou můžete nakonfigurovat pro automatická oznámení a další akce, jako je automatické škálování a další mechanismy samoopravení.

Použití nástroje Monitor k integraci strojového učení Automatizujte a optimalizujte třídění 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 integrovaný do monitorování. Pomocí Log Analytics můžete spouštět dotazy na agregované protokoly a získat přehled o vaší úloze.

Microsoft nabízí školení týkající se připravenosti na incidenty související s Azure. Další informace najdete v tématu Úvod do připravenosti na incidenty Azure a připravenosti incidentů.

Kontrolní seznam pro efektivitu provozu

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

Kontrolní seznam pro efektivitu provozu