Vytvoření efektivního plánu řízení incidentů pro správu přerušení

Incident je neplánovaná událost, která ruší, degraduje nebo ohrožuje narušení normálního provozu systému. Incidenty často negativně ovlivňují zákazníky nebo firmu. Existují ve spektru, od přechodných nebo lokalizovaných přerušení až po rozsáhlé události nebo havárie. Mezi příklady incidentů zabezpečení patří porušení zabezpečení dat, porušení právních předpisů, malware nebo ohrožení identity. Mezi příčiny patří selhání hardwaru nebo infrastruktury, limity prostředků, lidské chyby, jako jsou neúspěšná nasazení nebo chybné konfigurace, nebo externí faktory, jako jsou útoky na zabezpečení.

Řízení incidentů (ICM) poskytuje systematický přístup k obnovení služby během přerušení. Koordinuje detekci, vyšetřování, zmírnění rizik a řešení při zachování jasné komunikace a dokumentování přehledů pro průběžné vylepšování. Reakce na incidenty se řídí stejným playbookem bez ohledu na typ incidentu.

Při vytváření plánu ICM se nezaměřte jenom na řídicí panely a runbooky. Jako architekt navrhujte operace, ve kterých lidé, procesy a nástroje spolupracují pod tlakem na obnovení systémů efektivně a bez zmatků. Vaše strategie ICM by se měla škálovat na základě závažnosti, od rychlého zmírnění malých incidentů až po koordinované úsilí napříč týmy o významné události. Odpověď se také může lišit v závislosti na příčině.

Tento článek se zaměřuje na fáze ICM, mezi které patří příprava, aktivní reakce na incidenty, závěrečné vyhodnocení incidentu a průběžné vylepšování. Tyto pokyny také obsahují příklad pro ilustraci postupů návrhu. Než začnete, projděte si klíčové strategie a vyberte ty, které mají smysl pro vaši firmu. Další informace najdete v tématu Strategie architektury OE:08 pro návrh procesu ICM.

Tento článek nepopisuje havárie, které vyžadují specializované úsilí o obnovení. Další informace o zpracování takových scénářů najdete v tématu Vývoj plánu zotavení po havárii pro nasazení ve více oblastech.

Terminologie

Než začnete s vývojem plánu správy incidentů, seznamte se s těmito klíčovými pojmy.

Term Definition
Poloměr výbuchu Rozsah dopadu nebo ovlivněné oblasti při výskytu incidentu, které se strategie omezení snaží omezit.
Účty se zalomeným sklem Přihlašovací údaje tísňového volání se zvýšenými oprávněními používanými během kritických incidentů, které jsou přísně řízeny jasnými pokyny k používání.
Tým mostu Tým pro třídění incidentů, který se shromažďuje k vyšetřování incidentu, označujeme také jako inženýrský most. Skládá se z relevantních technických odborníků a rozhodovacích odborníků.
Zadržování Prvním krokem při nápravě incidentu, který izoluje ovlivněné komponenty, aby se problém nerozšíroval do jiných částí úlohy.
Řízení incidentů (ICM) Strukturovaný proces zjišťování, třídění, zmírnění a řešení incidentů při koordinaci komunikace a zachycení získaných poznatků.
Poslední známá-dobrá Poslední zdravý stav pracovní zátěže před zahájením incidentu, používaný jako referenční bod pro operace vrácení zpět.
Omezení rizik Akce k omezení nebo odstranění dopadu incidentu, včetně vrácení, rezervního řešení, obejití nebo nouzových oprav.
Retrospektiva Proces závěrečného vyhodnocení incidentu bez obvinění se zaměřuje na identifikaci poznatků získaných a použitelných vylepšení, a ne na přiřazování obviňování.
Analýza původní příčiny (RCA) Systematický proces vyšetřování incidentu s cílem identifikovat základní faktory zodpovědné za problém a zabránit opakování.
Úroveň závažnosti Klasifikační systém, jako je kritický, vysoký, střední a nízký, určuje odpovídající úroveň odezvy na základě obchodního dopadu a ovlivněných uživatelů.
Třídění Proces analýzy a stanovení priority incidentů za účelem určení závažnosti, účinku a vhodných akcí reakce.

Příprava

Než dojde k incidentu, nastavte základ efektivní reakce tím, že navrhnete pozorovatelnost, definujete jasné role a procesy a připravíte nástroje a prostředky, které vaše týmy potřebují. Zdokumentujte plán reakce na incidenty a pravidelně ho aktualizujte a kontrolujte.

  1. Udržujte přesné a aktuální diagramy architektury, které zobrazují všechny komponenty a jejich interakce, aby týmy mohly rychle identifikovat úzká místa nebo jednotlivé body selhání. Tento přístup umožňuje rychlejší řešení potíží v situacích s vysokým tlakem.

  2. Definujte data incidentu, která vaše monitorovací sada musí poskytovat pro celkovou zátěž:

    • Shromážděte kompletní telemetrii, včetně infrastruktury a aplikací.

    • Povolení strukturovaného protokolování pro všechny komponenty pro podporu třídění a vyšetřování a odesílání protokolů do datových jímek pro účely analýzy. V případě potřeby také odeslat protokoly do centrálně spravovaných úložišť. Ujistěte se, že členové týmu mají během incidentů časově omezený přístup s nejnižšími oprávněními.

    • Vytváření řídicích panelů na základě modelu stavu úloh Řídicí panely zobrazují metriky a signály, které váš tým monitoruje.

    • Nakonfigurujte upozornění s možností reakce, která aktivují oznámení pouze v případě překročení prahových hodnot a zjištění potenciálního incidentu. Vylaďte upozornění, abyste se vyhnuli příliš velkému počtu upozornění (šumu) nebo příliš málo upozornění. Například u incidentů živých stránek by upozornění měla monitorovat kritické metriky, jako jsou centrální procesorová jednotka (CPU), paměť, doby odezvy a výkon databáze, aby bylo možné detekovat řešitelné problémy, které odpovídají cílům výkonu.

      Automaticky směrujte upozornění na správné týmy. Například podpora vrstvy 1 získá všechna upozornění, zatímco technici zabezpečení obdrží pouze výstrahy související se zabezpečením.

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

  3. Definujte klíčové role pro zajištění odpovědnosti, rozhodování a efektivního následného sledování během incidentů a po incidentech. Vytvořte vhodné schvalovací procesy a rozlište je v jasném rozhodovacím stromu. Definujte úrovně autorizace pro různé typy závažnosti, rozhodnutí o zmírnění rizik, cesty eskalace a další oblasti.

    Jako výchozí bod použijte následující příklady a přizpůsobte je tak, aby vyhovovaly struktuře týmu.

    Role Zodpovědnosti
    Správce reakcí na incidenty Zodpovídá za incident od detekce po jeho vyřešení a analýzu příčiny problému. Zajišťuje, aby byly dodrženy procesy, byla učiněna rozhodnutí a správné osoby byly informovány.
    Retrospektivní lídr Řídí po-incidentní hodnocení, zachycuje získané zkušenosti, vytváří akční zprávy a zajišťuje, že jsou závěry uplatňovány.
    Pohotovostní inženýr Aktivně zmírní a vyřeší incidenty. Dodržuje odpovědnost za různé typy incidentů a podle potřeby spolupracuje se specializovanými týmy, aby se zajistilo včasné řešení incidentu.

  4. Definování postupů pro šetření:

    • Definujte kategorie pro typy incidentů, jako jsou provozní, zabezpečení, výkon a incidenty nasazení, a úrovně závažnosti, jako jsou kritické, vysoké, střední a nízké), které platí pro vaši úlohu.

    • Zdokumentujte, jak vyhodnotit závažnost, dopad a naléhavost incidentu. Zvažte dopad uživatelů, ovlivněné systémy a důležité obchodní funkce. Na základě úrovně závažnosti tým aktivuje plán zotavení po havárii pro případy, které splňují prahové hodnoty na úrovni havárie. Nebo se řídí standardním plánem reakce na méně závažné incidenty.

    • Definujte strategie, které izolují nebo odeberou ovlivněnou komponentu z cest toku úloh, jako je vypnutí prostředku nebo přesměrování provozu. Určete, které role mají oprávnění k provedení akce omezující šíření.

      Nastavte monitorovací systémy tak, aby automaticky iniciovaly uzavření definovaných incidentů. Tento přístup zajišťuje lidskou účast při kritických rozhodnutích. Správci systému, technici a vedoucí vývojáři by měli spolupracovat na omezení poloměru výbuchu při zachování degradované funkčnosti. Pokud musí komponenta zůstat k dispozici pro třídění, přísně izolujte jeho přístup od zbytku úlohy.

    • Vytvořte pokyny pro výběr strategií zmírnění rizik na základě závažnosti incidentu, jako je izolace, vrácení zpět, změny konfigurace a alternativní řešení.

    • Určete, které týmy nebo jednotlivci zpracovávají incident na základě typu a závažnosti. Zahrňte cesty eskalace pro situace, kdy počáteční respondenti nemůžou problém vyřešit.

    • Přehled, která data se mají shromažďovat během počáteční analýzy, jako jsou protokoly, metriky, zprávy uživatelů a výstrahy, za účelem podpory vyšetřování a rozhodování. Uveďte také, kdo by měl mít k datům přístup.

    Důležité

    Chraňte své nouzové přihlašovací údaje nebo účty pro případ nouze stanovením jasných pravidel. Určete, kdo je může používat, kdy a přesně jak. Spárujte tato pravidla s nouzovými postupy a sledujte každé spuštění. Definujte, jak často má tým provádět postupy. Během incidentu není čas ho v tuto chvíli zjistit. Cvičení poskytují odpovídající praxi a možnosti vylepšení.

  5. Nastavte infrastrukturu pro podporu řešení:

    • Parametrizovat datové toky. Povolte kanály nasazení a obnovení tak, aby přijímaly konkrétní verze pro rychlé vrácení zpět nebo opravu nasazení.

    • Zajistěte konzistenci roviny dat. Uchovávejte klíče, tajné kódy, konfigurace a stavová data zarovnaná během operací obnovení.

    • Automatizace škálování infrastruktury Upravte prostředky automaticky tak, aby zvládly posuny provozu nebo zvýšily zatížení.

    • Implementujte samoopravení. Bezpečně automatizujte reakce na běžné vzory incidentů, ale zahrňte správné monitorování a možnosti ručního zásahu.

  6. Definujte komunikační procesy. Zdokumentujte jasné plány komunikace a eskalace, aby podpora vrstvy 1 rychle dosáhla správných týmů. Zadejte vhodné komunikační kanály pro interní a externí účastníky a uveďte plány hovorů a kontaktní údaje.

  7. Definujte použití nástroje ICM a standardních provozních postupů, které by měl zachytit v jednoduchém pracovním postupu. Pracovní postup zahrnuje čtyři kroky: vytvoření, potvrzení, zmírnění a vyřešení. Nástroj poskytuje týmům přehled, sleduje průběh, udržuje odpovědnost a zajišťuje konzistentní zpracování incidentů za všech okolností. Centralizuje všechny aktivity pro podporu správy živého webu a pohotovostních služeb.

  8. Definujte kritéria, která oficiálně označí incident jako uzavřený:

    • Uveďte jasné faktory rozlišení. Řešení obvykle znamená, že systém a služby fungují v rámci smluv o úrovni služeb (SLA), výkonu a spolehlivosti se vrátí k přijatelným úrovním a akce okamžitého zmírnění rizik se úspěšně dokončí.

    • Zahrňte ověřovací kontroly pro potvrzení úplného řešení. Pomocí monitorovacích nástrojů zkontrolujte, že incident už nemá vliv na systém a postižení uživatelé již nepociťují přerušení.

    • Při uzavření incidentu zahrňte požadavky na komunikaci. Upozorněte relevantní zúčastněné strany, včetně interních týmů, pracovníků podpory a ovlivněných uživatelů, a poskytněte souhrn provedených akcí spolu s probíhající prací.

    • Při uzavření incidentu zajistěte důkladnou dokumentaci. Zaznamenejte všechny podrobnosti v systému ICM. Zahrňte spouštěcí událost, kroky k omezení, rozhodnutí o třídění a konečné řešení. Zacházejte s touto dokumentací jako s předáním analýzy základních příčin (RCA) a retrospektivy pro zachycení získaných poznatků.

    Důležité

    Navrhněte své operace tak, aby incident mohl zavřít jenom určený orgán, jako je správce reakce na incidenty. Vynucení striktních kontrolních seznamů k blokování předčasného uzavření Přeskočení kroků může zanechat skryté problémy nevyřešené, což může převést uzavřený incident na opakovanou havárii.

Detekce, prošetřování a reakce

Fáze 2 se zaměřuje na rychlé a efektivní zjišťování incidentů a reagování na ně. Tato fáze identifikuje problémy včas, posuzuje jejich dopad a implementuje správné strategie zmírnění rizik při současném narušení. Tato fáze také zajišťuje, že třídění, řešení a komunikace jsou koordinované, konzistentní a zodpovědné napříč všemi týmy.

Důležité

Jasná a konzistentní komunikace udržuje kontrolu a srozumitelnost v situacích s vysokým stresem. Definujte přesně to, kdo mluví, co se sdílí a jak často. Standardizujte frekvenci aktualizací, kanály a formáty zpráv tak, aby nikdo nemusel během krize horečně shánět informace. Ujistěte se, že každý účastník, od inženýrů po vedoucí pracovníky, ví, kdy mají očekávat aktualizace a kdy se vyžaduje eskalace.

  1. Reagujte okamžitě, když výstrahy nebo hlášení uživatelů indikují problém. Ke korelaci anomálií se změnami systému použijte nástroje pro pozorovatelnost a výkon. Příjemce incidentu vytvoří tým pro přemostění (bridge) se správnými členy a domluví komunikační metody, sledování postupu a přístup k prostředkům incidentu.

  2. Mobilizujte technický most k vyhodnocení dopadu a závažnosti. Vyhodnoťte dopad incidentu pomocí předdefinovaných klasifikací závažnosti. Data použijte k odůvodnění kritérií popsaných v plánu reakce na incidenty, jako je počet ovlivněných uživatelů, narušení obchodních funkcí, dopad na zabezpečení a dodržování předpisů a potenciální dopad na důvěru a reputaci zákazníků. Toto posouzení určuje odpovídající úroveň odpovědi a provede další kroky pro zmírnění rizik.

  3. Fáze vyšetřování začíná, když jsou zapojeny správné technické týmy a zahájí analýzu RCA. Tento proces zahrnuje hloubkovou technickou analýzu, která určuje příčinu a obsahuje dopad. Technici používají pozorovatelná data, řídicí panely telemetrie, systémové protokoly a historii změn k trasování anomálií a identifikaci bodů selhání. Zaměřují se na rychlou izolování problému, ověřování hypotéz pomocí dat v reálném čase a na vývoj přesného plánu zmírnění rizik, který obnoví stabilitu služeb bez zavedení nového rizika.

    Kompromis: Analýza RCA může nějakou dobu trvat. Pokud chcete korelovat problémy s výkonem, musíte shromažďovat a ukládat data. Požadovaný čas a infrastruktura mohou u provozních týmů způsobit dodatečnou práci a zvýšení nákladů na úlohy.

    Riziko: Pokud provádíte analýzu RCA bez správných bezpečnostních mantinelí, můžete při poskytování přístupu k protokolům a datům zveřejnit citlivé informace.

  4. Postupujte podle strategií uzavření a izolujte ovlivněné součásti a omezte poloměr výbuchu. Můžete provést následující akce:

    • Blokování přístupu k ovlivněným komponentám pomocí samostatných cest pro třídění. Můžete například vypnout prostředek, omezit provoz nebo zakázat neúspěšnou mikroslužbu.

    • Omezte dosah incidentu na konkrétní uživatele, oblasti nebo komponenty.

    • Pokud je to možné, udržujte funkčnost úloh v degradovaném stavu.

  5. Vyberte odpovídající strategii pro zmírnění rizik. Zvolte přístupy ke zmírnění rizik na základě aktuálního stavu úlohy, dostupných prostředků a okamžitých omezení.

    Vaše volba závisí na faktorech, jako je typ infrastruktury, dostupné mechanismy obejití, složitost opravy, požadavky na citlivost dat a dodržování předpisů, závislosti systému a plánovaná doba obnovení (RTO).

    • Vrácení zpět: Vraťte aktualizované systémy do stavu poslední známé dobré konfigurace. Tým pro zátěž by měl definovat, co znamená poslední známá dobrá konfigurace. Obvykle se odkazuje na poslední zdravý stav pracovní zátěže před zahájením nasazení, což nemusí být předcházející verze aplikace. Vrácení zpět může být složité, zejména pokud se týká schématu nebo změn dat. Chcete-li snížit riziko, provádějte aktualizace schématu přidáváním, nikoli nahrazováním záznamů. Stará a nová data můžou existovat společně, dokud nebudete moct bezpečně odebrat zastaralé záznamy. Vrácení zpět může vyžadovat pečlivé plánování a koordinaci napříč několika týmy.

    • Nouzový: Odeberte aktualizované systémy z produkčního směrování provozu a směrujte veškerý provoz na stabilní platformu. Tato strategie s nízkým rizikem řeší problémy s nasazením, aniž by to způsobilo další přerušení. Náhradní nasazení v kanárských nasazeních může být složité v závislosti na návrhu infrastruktury a aplikací. Před přepnutím provozu zpět zajistěte dostatečnou kapacitu na stabilní vrstvě. Náhradní řešení podporuje kontinuální provoz a izoluje problematické nasazení.

    • Obejsít problematickou funkci: K obcházení problematické funkce použijte feature flagy nebo vlastnosti konfigurace za běhu. Tento přístup umožňuje pokračovat v uvedení a izolovat problém. Vyhodnoťte kompromisy a komunikujte je se zúčastněnými stranami. Uveďte, jak dlouho můžete tolerovat degradovaný stav a odhadovanou dobu pro úplné vyřešení problému. Získejte schválení zainteresovaného pro plán.

    • Nouzové nasazení (rychlá oprava): Během zavádění nasaďte rychlou opravu, abyste problém rychle vyřešili. Dodržujte postupy bezpečného nasazení, včetně nasazování kódu prostřednictvím prostředí a kontrol brány kvality, ale urychlete harmonogramy. Zkraťte nebo upravte doby pečení a testy, aby se urychlilo nasazení. K zajištění spolehlivosti použijte automatizované testování. Horké opravy vyžadují koordinaci a pečlivé plánování minimalizace rizika a řešení problému okamžitě.

    Důležité

    Ujistěte se, že rozhodnutí o zmírnění rizik dodržují předdefinovaná autorizační pravidla. Správce incidentů by měl zpracovávat všechny akce pro zmírnění rizik. Vyžadovat autorizované pracovníky ke schválení kroků s vysokým dopadem a zdokumentování všech akcí. Při obnově systému udržujte řízené, bezpečné a zodpovědné akce.

    Když problém, který má dopad na uživatele, nastane přibližně ve stejnou dobu, kdy váš tým nasadil změnu, předpokládejte, že změna je pravděpodobnou příčinou, a okamžitě ji vraťte zpět, místo abyste nejprve trávili dlouhou dobu vyšetřováním. Doba, po kterou si vyberete strategii zmírnění rizik, se zohlední v střední době obnovení (MTTR). Využijte tento čas co nejlépe okamžitým přijetím nápravného opatření.

  6. Použijte rozlišení. Tento krok se zaměřuje na obnovení systému do úplného provozního stavu a zároveň brání opakování. Technické týmy používají ověřené opravy, které následují podle týmových skriptovaných postupů. K řízení vyšetřování používají nástroje pro analýzu protokolů a monitorování. Kroky vrácení zpět eliminují neefektivní změny, aby se zajistilo, že každá akce bude systém stabilně směřovat k úplnému zotavení.

  7. Vygenerujte sestavu analýzy příčiny (RCA). Po vyřešení incidentu vygenerujte zprávu o zjišťování příčin v časovém rámci SLA. Majitel incidentu, nebo úzce zapojený člen týmu, pokud není majitel k dispozici, by měl vytvořit zprávu, aby byla zajištěna přesnost. Postupujte podle definované šablony RCA, která obsahuje jasné pokyny k zahrnutí a sdílení informací nebo vytvoření a schválení nové šablony prostřednictvím kontroly účastníků.

Aktivity po incidentu

Po každém incidentu udělejte retrospektivu. Poskytují důležité příležitosti ke učení, zvýrazňují slabá místa v reakci, nasazení nebo infrastruktuře a informují o vylepšeních. Zdokumentujte položky akcí a sledujte je v backlogu pro iterativní implementaci.

Cílem není přiřadit příčinu, ale identifikovat užitečná vylepšení. Nestranný zprostředkovatel by měl vést tento proces. Jednotlivci, kteří pracovali na odpovědi, musí reprezentovat každý tým zapojený do incidentu. Musí být připraveni s poznatky o úspěších a oblastech pro zlepšení.

  • Vylepšení plánu odezvy: Aktualizujte procesy nebo postupy, abyste zajistili jasnější a efektivnější akce.

  • Vylepšení pozorovatelnosti: Upravte prahové hodnoty, přidejte monitorování nebo implementujte výstrahy, abyste dříve detekovali podobné incidenty.

  • Náprava úloh: Řešte zranitelnosti odhalené během incidentu, aby byly trvale opraveny.

Příklad: Reakce na selhání při nasazení

Následující příklad popisuje incident související s nasazením. I při pečlivém plánování a testování můžou nasazení někdy představovat problémy, které ovlivňují výkon systému nebo uživatelské prostředí.

V tomto příkladu tým úloh zavede funkci vylepšení vyhledávání, která zahrnuje více součástí:

  • Nový koncový bod rozhraní API pro vyhledávání s vylepšenými funkcemi filtrování
  • Aktualizované schéma databáze
  • Přepracovaný widget pro vyhledávání uživatelského rozhraní
  • Nová logika ukládání do mezipaměti

Tým provede následující kroky ke zjištění, zmírnění a vyřešení incidentu:

  1. Detekce: Tým si všimne problému, když se míra chyb zvýší v jedné z kanárských skupin zavádění. Tým okamžitě používá své pozorovatelné nástroje, jako je monitorování výkonu aplikací (APM), protokolování a telemetrie, které uživatele propojí s fázemi zavedení, k určení ovlivněné skupiny.

    Tým se připravil na tento scénář tím, že do procesu nasazení začlenil silnou pozorovatelnost. Spustili kouřové testy a kontroly kvality v každé fázi uvedení a vybavili svou aplikaci logováním, trasováním a metrikami výkonu. Telemetrie propojuje uživatele s konkrétními skupinami uvedení, aby mohli rychle zjistit, která verze ovlivnila uživatele. Také naplánovali nasazení během pracovní doby, kdy byla k dispozici úplná podpora, a zajistili, aby pracovníci podpory věděli, jak eskalovat problémy podle plánu nouzové reakce. Tato příprava jim umožňuje rychle detekovat špičku chybových sazeb a reagovat bez zpoždění.

  2. Zmírnění: Tým se rychle rozhodne o strategii pro zmírnění rizik. Zvažují, zda vrátit na poslední známou dobrou verzi, přesunout se zpět do stabilního prostředí, obejít problematickou funkci použitím funkčního příznaku, nebo nasadit opravu za provozu. Rozhodovací strom a proces schválení jsou již definovány.

    Jakmile tým zkontroluje všechny dostupné strategie, zužuje svoji volbu na vrácení zpět nebo náhradní a nakonec se rozhodne o náhradním řešení. Určí, že přesměrování provozu do stabilního stacku je rychlejší a méně rizikové než úplné vrácení zpět, které by mohlo vyžadovat složité operace s daty a schématy. Tým potvrzuje, že stabilní technologická zásoba má dostatečnou kapacitu pro zpracování plného produkčního zatížení a může izolovat aktualizované systémy od směrování produkčního provozu.

    Tým seskupil několik vzájemně závislých změn, včetně rozhraní API, schématu databáze, komponent uživatelského rozhraní a logiky ukládání do mezipaměti, takže identifikace konkrétní komponenty, která způsobila chyby, je náročnější a časově náročné, než kdyby nasadili každou změnu samostatně.

  3. Řešení: Tým implementuje záložní postup. Přesměrují provoz z aktualizovaného prostředí, aby izolovali problematické nasazení. Tým může vyřešit základní problém, aniž by to mělo vliv na většinu uživatelů.

    Záložní implementace odhalí provozní mezery. Zjistí zastaralé kontaktní informace pro dva klíčové členy týmu a jeden technik v eskalačním řetězci opustil společnost měsíce dříve. Tým ztratí čas na zjištění zodpovědného jednotlivce. Při pokusu o odebrání aktualizovaného nasazení z nástroje pro vyrovnávání zatížení odkazuje dokumentace na zastaralou konfiguraci nástroje pro vyrovnávání zatížení, která se změnila v nedávné aktualizaci Azure. Musí najít správný postup pod časovým tlakem.

    Komunikace je klíčovou součástí plánu pro zmírnění rizik. Tým informuje zúčastněné strany o rozhodnutí a jejích dopadech, včetně očekávané časové osy k vyřešení problému v izolovaném prostředí. Tým již standardizoval četnost poskytování aktualizací stavu během incidentů nasazení, takže účastníci vědí, kdy očekávat zprávy o průběhu a aktualizace. Tým také definoval typ a úroveň podrobností pro sdílení s uživateli a zajistil dodržování dalších požadavků na komunikaci incidentů nasazení. Tento strukturovaný přístup minimalizuje nejasnosti a pomáhá udržovat důvěru v proces reakce.

  4. Retrospektiva: Jakmile tým zmírní incident při nasazení, provedou retrospektivu, aby zachytili získané poznatky a zlepšili budoucí procesy. Tato relace zahrnuje všechny osoby zapojené do zavádění, od vývojářů a operátorů až po zástupce podpory a zúčastněných stran. Tým zkontroluje posloupnost událostí od detekce přes zmírnění rizik, aby porozuměl tomu, co proběhlo dobře a kde existovaly mezery.

    Klíčovou informací je, že sloučení změn rozhraní API vyhledávání, aktualizací schématu databáze, návrh uživatelského rozhraní a ukládání změn vrstvy do mezipaměti komplikuje řešení potíží i obnovení.

  5. Vylepšení po incidentu: Na základě retrospektivy tým implementuje několik provozních vylepšení, aby budoucí nasazení byla bezpečnější a zmírnění rizik spolehlivější:

    • Menší, časté změny: Tým se posune směrem k menším přírůstkovým nasazením, aby snížil rozdíl mezi po sobě jdoucími verzemi a usnadnil zmírnění rizik a snížil riziko.

      Pro posílení vyhledávání se tým konkrétně rozhodne nasadit každou komponentu nezávisle. Teď nasadí změny schématu databáze s zpětně kompatibilními změnami, pak aktualizacemi koncového bodu rozhraní API a dalšími změnami. Tento přístup umožňuje týmu ověřit každou vrstvu nezávisle předtím, než přidá další vrstvu, a snadněji izolovat problémy do konkrétní komponenty.

    • Pravidelné testování a cvičení: Tým zavádí postup častého testování pro strategii zmírnění dopadů selhání při úplném nasazení. Představují chaosové inženýrství a testy vkládání chyb, které simulují scénáře selhání a ověřují procesy zmírnění dopadů. Tato pravidelná cvičení by zachytila problémy, ke kterým došlo během incidentu, včetně zastaralých kontaktních informací a zastaralých postupů v runbooku.

Usnadnění na platformě Azure

  • Microsoft poskytuje š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ů.

  • Azure Monitor je ř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 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í.

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

    • Log Analytics je analytický nástroj ve službě Azure Monitor. Pomocí Log Analytics můžete spouštět dotazy na agregované protokoly a získat přehled o vaší úloze.

    • Application Insights je rozšíření Azure Monitor, které poskytuje funkce APM.

  • Microsoft Sentinel je řešení pro správu bezpečnostních informací a událostí (SIEM) a orchestrace zabezpečení, automatizace a reakce (SOAR). Jedná se o jediné řešení pro detekci výstrah, viditelnost hrozeb, proaktivní vyhledávání a reakci na hrozby.

  • Azure Pipelines poskytuje služby sestavení a vydávání, které podporují kontinuální integraci a průběžné doručování (CI/CD) vašich aplikací.

  • Azure Test Plans je řešení pro správu testů založené na prohlížeči. Toto řešení poskytuje možnosti potřebné pro plánované ruční testování, testování přijetí uživatelů a průzkumné testování. Azure Test Plans také nabízí způsob, jak shromáždit zpětnou vazbu od zúčastněných stran.

  • Azure Logic Apps je cloudová platforma pro spouštění automatizovaných pracovních postupů, které integrují aplikace, data, služby a systémy. Logic Apps můžete použít k vytvoření nové verze aplikace při aktualizaci. Azure udržuje historii verzí a může vrátit nebo zvýšit úroveň jakékoli předchozí verze.

  • Mnoho databázových služeb Azure poskytuje funkce obnovení k určitému bodu v čase (PITR), které vám mohou pomoci, když potřebujete provést vrácení změn:

  • Azure Chaos Studio je spravovaná služba, která využívá chaos engineering k tomu, aby vám pomohla měřit, porozumět a zlepšit odolnost vašich cloudových aplikací a služeb.

  • Last updated on