Sledování incidentů

7 min

Incidenty mají životní cyklus. Abyste mohli reagovat co nejúčelněji, musíte být schopni sledovat vývoj samotného incidentu a vývoj reakce na něj od samého začátku tohoto životního cyklu.

Vyhodnoťte, co víte

Dobrým způsobem, jak vyhodnotit postup sledování incidentů pomocí konkrétního incidentu, je položit si řadu otázek:

Kdy jste o problému poprvé dozvěděli? Pokud je vaším cílem zkrátit dobu potřebnou k zotavení z incidentů, budete muset začít zachytávat informace od okamžiku, kdy se o problémech dozvíte.
Jak jste se o problému dozvěděli? Upozornil vás na incident váš systém monitorování? Doslechli jste se o problému poprvé od vašich zákazníků, kteří si stěžovali přímo nebo na sociálních sítích?
Pokud se o problému teprve dozvíte, jste první, co potřebujete vědět? Pokud ano, koho je potřeba informovat? Pokud ne, kdo další o tomto problému ví?
Pokud o něm ví ostatní, co (pokud vůbec něco) s tím dělají? Předpokládají všichni, že se o problém stará někdo jiný, nebo se někdo pustil do akce a problém řeší?
Jak je to špatné? Možná nemáme žádnou představu o závažnosti nebo dopadu a neexistuje místo, kde bychom zjistili, jak je problém opravdu špatný a kdo je ovlivněný.

Pokud se nesledují žádné informace, může být obtížné na tyto otázky odpovědět.

Standardizace umístění, kde se budou informace o incidentu sledovat

Existuje mnoho možných umístění, kde můžete uchovávat a sdílet seznam incidentů (aktivních nebo jiných) a všechny aktuální informace o těchto incidentech. Může to být jednoduché jako sdílená oblast souborů s wordovými dokumenty a stejně složité jako vysoce specializovaný software a služby pro sledování incidentů. Mezi těmito dvěma extrémními hodnotami jsou systémy pro sledování lístků a sledování práce, které můžete pro tuto úlohu stisknout do služby. Který systém, který zvolíte, je ve skutečnosti méně důležitý než způsob jeho použití. Bez ohledu na to, jaký systém používáte, musí všichni, kdo mají vůbec jakékoli spojení s incidenty (technici, zákaznická podpora, správa, vztahy s veřejností, právní a tak dále), vědět, kam se má systém najít, jak vytvořit incident a jak získat přístup k datům, pokud je to vhodné. Sledování incidentů bude zcela jistě neúspěšné, když příslušní pracovníci neví, jak se k systému dostat („jaká byla ta adresa URL našeho systému?“), když ho potřebují.

V tomto modulu použijeme funkci pracovních položek Azure DevOps pro náš ukázkový sledovací systém.

Vytvoření mostu konverzace

Pokud chcete odpovědět na některé otázky v předchozí části Vyhodnocení toho, co znáte , a zahájit proces reakce na incidenty, musíte mít způsob, jak komunikovat s ostatními o incidentu. V ideálním případě to bude nějaký druh "týmové spolupráce" elektronické médium pro konverzaci, i když telefonní mosty fungují i. Konferenční hovory a telefonní mosty jsou méně upřednostňované, protože je obtížnější zpětně zkontrolovat komunikaci incidentu (proto je to role "Scribe", kterou jsme zmínili dříve).

Ať už zvolíte jakékoli médium, měli byste být jisti, že vyřezávejte jedinečný kanál, který je přísně omezený na diskuzi o tomto incidentu a nic jiného. Irelevantní diskuze je důležité udržovat mimo tento kanál, protože potřebujete být schopni vzít data a později je analyzovat při závěrečném vyhodnocení incidentu.

V tomto modulu použijeme Microsoft Teams jako metodu komunikace incidentů.

Automatizace spuštění sledování incidentů

Pojďme se podívat na to, co jsme si zatím řekli: Máme:

Seznam lidí na volání (a rotace definovaná pro ně).
Roli můžeme přiřadit lidem pracujícím na incidentu.
Konkrétní místo, kam budeme incident deklarovat, a sledovat ho.
Jedinečný kanál pro lidi pracující na daném incidentu, aby o něm mohli komunikovat.

Můžete a měli byste automatizovat vytváření a správu všech těchto věcí v co největší možné míře. Když se vyskytne urgentní problém, nechcete opakovat všechny kroky nezbytné k tomu, aby byl incident oznámen, byli zainteresováni správní lidé a incident byl sledován. Chcete prostě zmáčknout tlačítko „start“, aby se okamžitě spustily práce na odstranění problému.

Použití Logic Apps pro automatizaci bez kódu

Jedním ze způsobů, jak automatizovat počáteční odpověď, je použití Logic Apps, které může zjednodušit úlohu plánování, automatizace a orchestrace úloh, obchodních procesů a pracovních postupů.

Logic Apps je cloudová služba Azure pro sestavování integračních řešení. K vytvoření automatizovaných pracovních postupů používá konektory. Triggery spustí aplikaci logiky , když dojde k určité události nebo když data splňují zadaná kritéria. Akce jsou operace, které se následně provedou v pracovním postupu aplikace logiky.

V našem příkladu použijeme následující Konektor aplikace logiky pro sledování incidentů:

Azure Boards (součást Azure DevOps), kterou můžete použít k vytváření a sledování problémů a incidentů.
Azure Storage, kde můžete ukládat a načítat informace o tom, kdo je na volání, abyste mohli přiřadit správné lidi, kteří na incident reagují. V našem příkladu budeme používat Azure Table Storage, protože nabízí velmi jednoduché úložiště klíč-hodnota, které usnadňuje ukládání seznamu techniků a jejich stavu při volání.
Microsoft Teams, který můžete použít k vytvoření nového jedinečného kanálu incidentu ke sledování konverzací technických týmů v reálném čase, když komunikují o konkrétních incidentech. To vám umožní zachovat interakce ve vztahu k časové ose událostí později při závěrečném vyhodnocení incidentu.

Teď to všechno spojíme pomocí aplikace logiky. Nejprve se podívejte na úplnou aplikaci, jak je znázorněno v Návrháři pro Logic Apps, a pak si ji projdeme krok za krokem.

Screenshot of a zoomed out view of a logic app as displayed in the Logic Apps Designer.

Prvním krokem je zpracování triggeru, o kterém jsme zmínili požadavek HTTP. Na naši logickou aplikaci je proveden požadavek HTTP POST, který obsahuje datovou část JSON s informacemi o incidentu, který chceme deklarovat. Tuto datovou část analyzujeme a pošleme zpět potvrzení, že jsme ji dostali:

Screenshot of the HTTP and Response block in Logic App Designer view of the Logic App.

Pomocí této informace vytvoříme novou pracovní položku v naší organizaci Azure DevOps představující tento incident.

Screenshot of the Create a work item block in Logic App Designer view of the Logic App.

Potom vytvoří nový kanál Teams pro incident:

Screenshot of the Create a channel block in Logic App Designer view of the Logic App.

Po vytvoření kanálu se pracovní položka, kterou jsme vytvořili před okamžikem, aktualizuje odkazem na nový kanál. Všechny informace se udržují ve stejném umístění (pracovní položce) a uživatelé se na ně můžou podívat později, aby zjistili, kde najít kanál, ke kterému se chtějí připojit.

Screenshot of the Update work item block in Logic App Designer view of the Logic App.

Teď je čas převést osobu na volání do obrázku. Ve službě Azure Table Storage provádíme vyhledávání pro e-mailovou adresu technika, který je uvedený jako on-call. Tím se vrátí odpověď JSON, kterou pak analyzujeme.

Screenshot of the Get entities block in Logic App Designer view of the Logic App.

Protože náš dotaz vrátí seznam, musíme jako další krok iterovat jednotlivé položky v seznamu. Pracovní položku přiřadíme každé osobě (nyní jsou to „vlastníci“ incidentu).

Screenshot of the Foreach block in Logic App Designer view of the Logic App.

Pak jako poslední krok pošleme do kanálu Teams zprávu s ukazatelem zpět na pracovní položku pro lidi, kteří se připojí k kanálu, a chceme vědět, kde jsou uložené autoritativní informace pro daný incident.

Screenshot of the Post a message as the Flow bot channel block in Logic App Designer view of the Logic App.

To je jen jeden příklad, jak můžeme automatizovat nastavení mechanismů pro sledování a komunikaci incidentů. V další lekci se budeme podrobněji věnovat aspektům komunikace ohledně incidentu.