Strategie architektury pro návrh procesu správy incidentů (ICM)

Platí pro toto doporučení z kontrolního seznamu Azure Well-Architected Framework: Operational Excellence:

OE:08 Vytvořte jasný a strukturovaný proces správy incidentů s definovanými rolemi, zdokumentovanými postupy a architekturou navrženou pro rychlou detekci, diagnostiku a zotavení.

Když dojde k incidentům, měl by být tým úloh připravený s jasnými strukturovanými postupy.

Reakce na incidenty má dva klíčové aspekty. První je architektura, která se zaměřuje na navrhování systémů, které podporují efektivní postupy reakce a brání selhání kaskádově napříč komponentami. Druhou je procedurální, která zahrnuje detekci, zamezení a třídění pro rychlé řízení problémů, následovanou analýzou hlavní příčiny a postmortemními analýzami, aby se zabránilo opakování. Pravidelné postupy pomáhají udržovat připravenost a zajistit efektivní provádění plánu.

Tento článek popisuje osvědčené strategie návrhu architektury, která pomáhá reagovat a plán, který udržuje tým klidný, koordinovaný a kontrolující. Podrobné pokyny k implementaci, včetně krokových procesů a playbooků, najdete v doprovodné části: Vytvoření efektivního plánu řízení incidentů pro správu přerušení.

Definice

Term Definition
Chaosové inženýrství Záměrně vkládání selhání nebo nepříznivých podmínek do systému za účelem testování jeho odolnosti a postupů obnovení.
Omezení Omezení dopadu incidentu, aby se zabránilo ovlivnění jiných součástí nebo systémů.
Detekce Zjištění, že došlo k incidentu nebo že probíhá.
Zpětná analýza Strukturovaná, bezobvižná kontrola incidentu zahrnujícího všechny relevantní týmy, zachycení poznatků získaných a definování akčních vylepšení procesů, nástrojů a systémů.
Analýza RCA (analýza původní příčiny) Vyšetřování a identifikace základních příčin incidentu, včetně přispívajících faktorů, aby se zabránilo opakování.
cíl bodu obnovení (RPO) Maximální přijatelné množství ztráty dat měřené v čase.
RTO (cíl doby obnovení) Maximální přijatelná doba, po které může být systém nebo služba po incidentu mimo provoz, než způsobí nepřijatelný dopad.
Posouzení Posouzení a stanovení priorit incidentů za účelem určení odpovídající reakce

Zdokumentujte plán reakce na incidenty.

Incident může souviset s problémy s nasazením, zabezpečením nebo výkonem. Bez ohledu na to vytvořte základní plán reakce na incidenty, který pokrývá celý proces. Definujte doplňkové postupy pro každý typ incidentu, které popisují různé metody detekce, kroky pro omezení a obnovení, zúčastněné strany specifické pro daný typ incidentu. Plán incidentů zabezpečení může mít například procesy související s zapojením služby Security Operations Center (SOC), které se nevztahují na incident nasazení.

Plán reakce na incidenty by měl definovat klíčové role , které se týkají správy incidentu, a odpovědností každého z nich. Vyjasnění vlastnictví snižuje nejasnosti a zajišťuje, aby akce byly koordinované od detekce až po řešení. Identifikujte role, jako je manažer incidentů, technický vedoucí a komunikační vedoucí, aby se nastavila odpovědnost a podporovala konzistentní rozhodování.

Plán musí obsahovat komunikační a eskalační strukturu , která popisuje, jak se hlásí incidenty, kdo je upozorněn, a prostřednictvím jakých kanálů. Tím zajistíte, že se informace rychle přesunou na správné lidi a zabrání mezerám nebo duplikaci během kritických okamžiků.

Plán musí zahrnovat také základní postupy , které tým bude dodržovat během detekce, třídění, blokování a obnovení. Tyto kroky poskytují předvídatelný rámec pro reakci a pomáhají udržovat provozní stabilitu. Pravidelné kontroly těchto postupů udržují plán v souladu se změnami systému a poznatky získané z předchozích incidentů.

Kompromis. Příliš agresivní strategie reakce může aktivovat falešné alarmy nebo zbytečné eskalace.

Podobně automatické akce, jako je škálování nebo samoopravení aktivované porušeními prahových hodnot, můžou mít další náklady a provozní režii. Vzhledem k tomu, že optimální prahové hodnoty nemusí být zřejmé, ověřte je testováním v nižších prostředích a pečlivě monitorovanými produkčními pokusy za účelem sladění akcí se skutečnými požadavky.

Přidělení dostatečných prostředků pro infrastrukturu, procesy a pracovníky reakce na incidenty

Naplánujte dostatek prostředků, aby současně fungovaly aspoň dvě konfigurace úloh, pokud je potřeba náhradní řešení, aby nedocházelo k přerušení služeb. Týmy úloh by měly být v případě potřeby připravené na podporu obou konfigurací v produkčním prostředí. To může zahrnovat refaktoring úloh, jako je oddělení komponent nebo aktualizace datových modelů.

Z hlediska lidských prostředků musí tým vyvážit své pravidelné povinnosti s prací na reakci na incidenty. Může být potřeba zvýšit počet zaměstnanců nebo zapojit externí zdroje. Můžou to být podpora platforem od Azure, dodavatelů třetích stran nebo centrálních IT týmů, kteří se specializují na řízení incidentů a mají aktivní smlouvy o podpoře. Plán reakce na incidenty by měl jasně zdokumentovat, co každá strana pokrývá, vyloučení, postupy eskalace a očekávanou dobu odezvy.

Poznámka:

Ve spolupráci s vaší organizací připravte tyto smlouvy o podpoře předem, aby byly během incidentu snadno dostupné.

I s těmito externími závislostmi počítejte s tím, že někteří členové týmu budou pracovat přímo s dodavateli, zatímco jiní budou pokračovat v interním třídění a nápravě.

Udržujte kontaktní informace pro interní pracovníky a pracovníky dodavatelů aktuální. Vytvořte zabezpečené a jednoduché postupy pro ověřování a autorizaci přístupu externího nebo hosta s příslušnými oprávněními pro protokoly a produkční prostředí.

Příležitost AI: Před přechodem podpory na externí dodavatele může AI hrát roli jako tým dodavatelů pouze pomocí dokumentace, playbooků, modelů stavu a cest eskalace, které dodavatel poskytl. Testuje historické incidenty, aby odhalila mezery, jako jsou chybějící znalosti systémů nebo chybně nakonfigurované prahové hodnoty nebo závislost na znalostech kmene. To týmům umožňuje aktivně opravovat mezery a zajistit hladké předání.

Budování omezení a izolace v architektuře

Incidenty jsou nevyhnutelné, takže navrhněte architekturu tak, aby omezovala chyby a omezovala jejich poloměr výbuchu. Ujistěte se, že když komponenta selže, dopad je izolovaný a kaskádově se nespustí do jiných částí systému.

Toho dosáhnete prostřednictvím technik, jako je segmentace prostředků, oddělení komponent pomocí mikroslužeb a použití vzorů návrhu, jako jsou bulkheads nebo vydavatel/odběratel ve vašem návrhu. Zvažte také použití externích prostředků, pokud je to možné. Například místo pevně zakódování konfiguračních hodnot uvnitř aplikace použijte externí úložiště konfigurace ke správě nastavení mimo kód aplikace nebo balíček nasazení.

Vytváření možností monitorování pro rychlé zjišťování

Silný plán reakce na incidenty závisí na dobře navrženém monitorovacím zásobníku. Funkce, jako je strukturované protokolování, cílené řídicí panely a výstrahy s možností reakce , pomáhají týmům rychle reagovat, minimalizovat šum a vyhnout se únavě výstrah.

Riziko: Příliš agresivní strategie reakce nebo automatizace, jako je aktivace výstrah, eskalace nebo automatické škálování příliš často, může vést k falešně alarmům, zbytečným provozním přerušením, zvýšení nákladů kvůli špatně definovaným prahům.

Toto riziko můžete zmírnit provedením důkladného testování v nižších prostředích a kontrolovaných produkčních scénářích za účelem upřesnění prahových hodnot výstrah a škálování.

Efektivní monitorování má dvě klíčové dimenze. Nejprve by měl proces reakce dostávat včasná oznámení z Azure o důležitých indikátorech, jako je stav služby, stav závislosti, porušení zabezpečení a integrita dat. Za druhé , samotné řešení musí generovat bohatou, strukturovanou telemetrii, protokoly, metriky a trasování, které umožňují hloubkovou analýzu, třídění a identifikaci původní příčiny.

Klíčové obchodní pracovní postupy by měly být vysledovatelné tak , aby bylo možné incidenty přesně rekonstruovat. Například v systému zpracování objednávek by týmy měly být schopny sledovat, kdy byla objednávka přijata, kdy došlo k pokusu o autorizaci platby a kde došlo k chybě. Navrhněte komponenty pro usnadnění ladění s konfigurovatelnou úrovní podrobností protokolu, výpisy paměti a zabezpečeným sdílením diagnostických dat mezi prostředími. Tyto funkce poskytují viditelnost a kontext potřebný k rychlé a efektivní reakci na incidenty.

Příležitost AI: Je běžné, že šetření se kvůli ručnímu shromažďování dat zpozdí. AI může zrychlit a usnadnit reakce na incidenty tím, že automaticky shromažďuje kontext, koreluje data a provádí počáteční třídění, jakmile se aktivuje výstraha. Místo toho, aby technici hned získali jasný přehled, jsou incidenty směrovány správným odborníkům a bezpečné a běžné opravy se dají navrhnout nebo automatizovat pomocí mantinely. Při dostatečném testování zvažte vytvoření řešení, které poskytuje automatizovanou počáteční odpověď se všemi korelovanými kontexty.

Usnadnění s diagnostickými daty a postupy

Navrhněte řešení, aby bylo diagnostikování a řešení problémů rychlejší a spolehlivější. Přístup spočívá ve vložení laditelnosti a sledovatelnosti do návrhu systému.

Začíná správným sběrem všech relevantních diagnostických dat, jako je pád systému a výpis paměti. Ujistěte se, že jsou potřebné nástroje k bezpečnému shromažďování, ukládání a sdílení těchto dat pro efektivní korelaci a analýzu. Nástroje, jako jsou trasovací nástroje sítě a servery symbolů, by měly být integrované, aby podporovaly hlubší možnosti ladění. Nakonec se ujistěte, že všechna diagnostická data jsou chráněná před manipulací prostřednictvím zabezpečeného úložiště, omezeného přístupu a správného řízení zásad správného řízení dat.

Systém by měl obsahovat také integrované háky a přepínače, které podporují správu incidentů. Tyto mechanismy jsou užitečné při zakazování nebo izolování vadných komponent v reálném čase bez opětovného nasazení. Kromě toho by se neúspěšné prostředky měly zachovat v karanténě pro forenzní analýzu, a ne okamžitě zahodit.

Vizualizace dat incidentů v jednotném přehledu

Vytvořte centralizovaný řídicí panel pro správu incidentů nebo portál pro aktualizace stavu v reálném čase, viditelnost a sdílení znalostí. Řídicí panel by měl fungovat jako sdílený zdroj pravdy, který udržuje všechny ve shodě ohledně priorit, aktuálních akcí a závislostí. Incidenty jsou stresující situace pro týmy a mít dostatek informací jim pomáhá udržet soustředění a podporuje včasné rozhodování. Posiluje také kulturu odpovědnosti a průběžného učení.

Klíčové komponenty by měly zahrnovat pozorovatelná data, časové osy, podrobnosti o vlastnictví a indikátory závažnosti. Viditelnost by měla být specifická pro konkrétní roli s příslušnými bezpečnostními prvky, jako je RBAC, a zajistit tak uživatelům přístup k potřebným informacím, aniž by museli vystavit citlivá data nebo zákaznická data. Uveďte odkazy na relevantní zdroje a jasné pokyny, které uživatelům pomůžou s dalšími kroky a jejich zodpovědnostmi. Volitelně můžete podporovat předplatná na vyžádání nebo upozornění, která budou účastníky informovat o změnách stavu incidentu.

Zachytávání a ukládání tras auditu

Navrhněte řešení s auditem jako základním požadavkem na podporu reakce na incidenty. I když se záznamy auditu často zobrazují hlavně jako bezpečnostní opatření, jsou stejně důležité pro provozní analýzu. Systém by měl zaznamenávat podrobné záznamy o změnách konfigurace, akcích správy a provozních postupech, jako jsou nasazení, zálohování a ladění aktivit.

Otestování plánu

Pravidelně testujte procesy reakce na incidenty pomocí simulovaných testů nebo cvičení chaos engineeringu. Simulujte reálné incidenty, abyste ověřili obnovitelnost, ověřili cíle RTO a RPO a zajistili, že komunikační a eskalační plány fungují pod tlakem.

Bez těchto testů mohou malá selhání rychle eskalovat do dlouhotrvajících výpadků nebo velké ztráty dat, což zanechává týmy překotně reagovat a ohrožuje obchodní operace. Testování vám umožňuje identifikovat mezery před výskytem skutečného incidentu a zlepšit koordinaci.

Přeměna zjištění RCA na vylepšení systému

Po každém incidentu proveďte důkladnou analýzu RCA, abyste identifikovali základní příčiny a přispívající faktory. Postupujte podle toho s bezvýhradnou analýzou vedenou nestranným facilitátorem, kde každý tým sdílí pozorování, úspěchy a příležitosti ke zlepšení.

Průběžné podávání lekcí zpět do systému snižuje riziko opakovaných incidentů. Zachyťte a klasifikujte položky s možností reakce na akce ve třech oblastech: upřesnění plánu reakce na incidenty, vylepšení pozorovatelnosti při zjišťování podobných problémů dříve a vylepšení návrhu úloh.

Příležitost AI: Není neobvyklé, že správci incidentů ručně kontrolují protokoly, lístky a diskuze, aby pochopili výpadky, identifikovali původní příčiny a formulovali otázky pro retrospektivy. Tato opakující se práce může být časově náročná a odvádět pozornost od úsilí o obnovení.

AI může zvýšit efektivitu díky automatickému generování analytických otázek, shrnutí kontextu incidentů a odhalení vzorů napříč zdroji dat. Může také analyzovat retrospektivní poznámky a data minulých incidentů, aby navrhla prioritní položky backlogu, což snižuje ruční úsilí. Implementace této funkce vyžaduje integraci umělé inteligence s ICM a nástroji SDLC. Vyhodnoťte nástroje, jako je PowerAutomate a LogicApps, ke správě pracovních postupů.

Zajištění flexibility a konzistence prostřednictvím automatizace

Začleňte automatizaci v rámci pracovního postupu reakce na incidenty, abyste snížili ruční úsilí a urychlili reakci. Nástroje jako Azure Batch, Runbooky, Functions a Logic Apps můžete použít k automatizaci zjišťování, zachycování, upozorňování a komunikace, jak je to možné. Udržujte knihovnu skriptů a šablon IaC (infrastructure-as-code) pro obnovení, ověřování, řešení potíží a analýzu původní příčiny. Ujistěte se, že jsou tyto automatizace zdokumentované a přístupné, aby je týmy mohly spolehlivě spouštět během incidentů. Čím více automatizujete, bude vaše odpověď konzistentnější.

Azure agent SRE je provozní agent využívající AI, který urychluje diagnostiku incidentů a automatizuje rutinní reakce. Podporuje konfigurovatelné úrovně autonomií, od režimu poradenství až po automatizovanou reakci v rámci definovaných mantinely. Začněte s poradním režimem a postupně povolte automatizaci při sestavování důvěryhodnosti. Pro scénáře s vysokou závažností implementujte pracovní postupy schvalování a mantinely pro řízení automatizovaných akcí.

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í 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 nástroje Monitor. 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 Azure na incidenty a Připravenost na incidenty.

Pomocí monitoru připojení v Azure Network Watcher můžete průběžně sledovat síťovou konektivitu a výkon napříč prostředky Azure. Během nouzových incidentů poskytují vlastní sešity v nástroji pro sledování připojení přehled o stavu zdraví připojení v reálném čase, trendech v latenci a stavu upozornění. Pokud chcete provést efektivní analýzu příčin a dosáhnout rychlejšího řešení, použijte nástroj Connection Troubleshoot v rámci sady diagnostických nástrojů Network Watcher.

Analýza provozu umožňuje analyzovat protokoly toku virtuální sítě a zobrazit přehledy, jako jsou blokovaný provoz, škodlivé toky a vystavené porty. Vytváření sešitů v analýze provozu umožňuje týmům monitorovat chování živého provozu, přijímat výstrahy a používat zobrazení časové osy a topologie k rychlé identifikaci ovlivněných síťových segmentů a efektivní reakci.

Pomocí nástrojů AI a DevOps Microsoft můžou týmy automaticky převést retrospektivní přehledy na položky backlogu s možností akcí. Zvažte Microsoft Foundry pro operace modelu AI, Azure DevOps pro správu backlogu, Power Automate nebo Logic Apps pro automatizaci.

Kontrolní seznam pro efektivitu provozu

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

Kontrolní seznam provozní dokonalosti

  • Last updated on