Náprava
Rozdělení životního cyklu reakce na incidenty na pět fází, jak jste viděli v tomto modulu, vám pomůže pochopit proces, ale fáze nejsou vždy tak odlišné, jak se zobrazují v diagramu. Konkrétně čára mezi fázemi odpovědi a nápravy se často rozostřuje. To platí zejména v případě, když mají akce zamýšlené pro zmírnění nebo zlepšení situace opačný účinek. V tomto případě se odpověď a náprava často překrývají nebo se mezi těmito dvěma fázemi průběžně přechází.
V této lekci se dozvíte více o nápravě a krocích, které tvoří tuto fázi, a také několik užitečných tipů a nástrojů. Jedna důležitá věc, kterou je třeba si uvědomit: Neměli byste přijmout opatření uvedená zde jako kontrolní seznam preskriptivních.
Pokud už máte skutečně připravený kontrolní seznam pro nápravu, často to znamená, že je čas začít používat automatizaci. Když přesně popíšete, co je potřeba udělat a v jakém pořadí se má problém napravit, je ideální čas naučit tyto kroky počítači, aby to systém mohl udělat za vás.
Kde začít
Dozvěděli jste se, jak je důležité snížit dobu potřebnou na vaši reakci na incident. Teď se podívejme na několik věcí, které vám pomůžou zrychlit proces nápravy nebo odstranit problém.
Různí členové týmu můžou mít různé duševní modely toho, jak věci fungují, a různé nápady ohledně toho, co by mělo být prvním krokem. Můžete se nejprve podívat na protokoly, zatímco jiný může nejprve spouštět dotazy a podívat se na metriky. K úspěchu nevede jedna správná cesta.
Dobré je ale poskytnout lidem kontext a pokyny týkající se toho, kam jít a na co se podívat.
Jak a komu eskalovat
Důležitou otázkou, na kterou je potřeba ve formulaci počátečního bodu nápravy odpovědět, je: komu mám zavolat a komu eskalovat problém, když se zaseknu? Měli byste se pokusit přenést více zodpovědností pohotovosti na tým obecně, nejen v oblasti provozu nebo řízení spolehlivosti lokality. Mít fungující a běžící systémy, tak aby byly splněny cíle spolehlivosti, by mělo být zodpovědností všech členů týmu.
Jaké prostředky jsou užitečné pro ty, kteří reagují jako první?
Dále je potřeba určit, co můžou osoby, které reagují jako první, použít k zahájení procesu. Můžou sem patřit relevantní metriky, protokoly, dotazy atd. Pokud je to možné, mělo by to vše být součástí pracovního sešitu nebo průvodce odstraňováním potíží. Promluvíme si o nich za chvilku.
Je také užitečné poskytnout jednoduché odkazy na prostředky (často v průvodci odstraňováním potíží). Pokud je vaším cílem reagovat na problém a napravit ho co nejrychleji, můžete celý proces zrychlit tím, že lidem pomůžete najít odpovědi na jejich otázky, aniž byste museli hledat správný dokument nebo adresu URL.
Poskytování aktuálních informací zúčastněným stranám
Můžete se tak zaměřit na řešení problému, na který byste mohli zapomenout, že existuje mnoho lidí, kteří nejsou přímo zapojeni do reakce na incident, ale chtějí a potřebují vědět, co se děje.
Je důležité komunikovat s ostatními interními týmy a udržovat je v přehledu o tom, co se děje, když dojde k incidentu. Pokud je neposkytujete s konzistentními aktualizacemi, pravděpodobně se zobrazí žádost o aktualizaci stavu. Mají všechna práva na tyto informace, ale potřebujete lepší způsob, jak jim dát vědět o problému a o čem se to dělá.
Potvrzení informací pro vaše interní týmy musí být jasné. Mějte jasno v prezentaci toho, co víte a co se dělá, a nastavte očekávání z hlediska toho, kdy se od vás ozve.
Vzorec komunikace se zúčastněnými stranami je jednoduchý:
- To je to, co víme.
- Tohle děláme.
- Vrátíme se k vám v X čase.
Tím zabráníte zúčastněným stranám, aby vám přišly a přerušily vás, když jste uprostřed pokusu o vyřešení problémů.
Jednou z možností, jak tyto informace distribuovat, je použití jednoduše upravitelné stavové webové stránky, jako je ta, o které jsme se zmínili v poslední lekci. V mnoha případech můžete chtít mít samostatnou, podrobnější stránku stavu pro interní účastníky a externí stránku pro vaše zákazníky. Předchozí vzorec funguje pro oba případy.
Použití Azure Monitor Workbooks a průvodců odstraňováním potíží
Azure má dvě úzce související funkce, které mohou být nesmírně užitečné pro tým ve fázi nápravy: Sešity azure Monitoru a průvodce odstraňováním potíží s aplikacemi Přehledy. Pro účely tohoto modulu jsou zaměnitelné, včetně stejného uživatelského rozhraní. Sešity Azure Monitoru najdete na webu Azure Portal v části Azure Monitor. Průvodci odstraňováním potíží s Azure Přehledy najdete na webu Azure Portal, když je vybraná instance Application Insight.
Sešity a průvodce odstraňováním potíží si můžete představit jako "živé dokumenty", které můžete vytvořit pomocí rozhraní pro vytváření stránek. Když vytvoříte nový dokument, můžete na stránku přidat:
- Libovolný text, například seznam položek s odrážkami, které mají dělat nebo jiné užitečné informace pro někoho, kdo se na stránce poradil
- Odkazy na jiné systémy, například odkazy na jiné řídicí panely nebo dokumentaci
- dotazy KQL (Kusto Query Language)
Je to poslední položka, díky které je dokument "živý". V předchozím modulu tohoto studijního programu jsme prozkoumali dotazovací jazyk KQL integrovaný do Log Analytics a dalších částí služby Azure Monitor. Pomocí tohoto jazyka můžeme napsat vlastní dotazy pro návrat a zobrazení diagnostických informací z naší aplikace a infrastruktury Azure. Když se dotaz KQL vloží do sešitu nebo průvodce odstraňováním potíží, aktuální výsledky tohoto dotazu se zobrazí živě čtenářům dokumentu. To znamená, že průvodce odstraňováním potíží nezobrazí pouze pokyn „Nezapomeňte zkontrolovat míru chyb na webovém serveru“, ale ukáže i aktuální graf dané míry chyb přímo vedle těchto pokynů. Může obsahovat odkaz jako třeba „tady najdete dokumentaci pro restartování webového serveru“. Tento odkaz přesměruje osobu, která reaguje jako první, přímo na požadovanou dokumentaci.
Azure dále nabízí některé existující šablony, které vám můžou pomoct začít vytvářet vlastní dokumenty. Tady je snímek obrazovky s některými předem připravenými šablonami, které vám můžou být nabídnuty:
K dispozici je funkce rozšířeného editoru pro sešity a průvodce odstraňováním potíží, která umožňuje přístup k dokumentu a vložení kódu JSON nebo šablony Azure Resource Manageru. To znamená, že je možné tyto dokumenty sledovat a distribuovat pomocí systému správy zdrojového kódu podle vašeho výběru. Umožňuje také automatizovat zřizování sešitů nebo průvodců odstraňováním potíží, což je užitečné při zřizování jiné infrastruktury. Vytvoření sady vlastních dokumentů pro řešení potíží pro přechod s novou službou v době, kdy je služba zřízena, se snadno použije tento osvědčený postup.
Další užitečné tipy a nástroje
V tomto modulu jste se seznámili s různými nástroji a zkratkami, které můžete použít ke zvýšení efektivity a zkrácení doby odezvy incidentu. Při zabalení této poslední lekce si ukážeme stručný přehled některých nástrojů a technik, které jsou užitečné při diagnostice problémů ve vašich systémech.
- Pomocí odkazu Řídicí panel aplikace v aplikaci Přehledy můžete automaticky vygenerovat řídicí panel, který obsahuje většinu klíčových položek, které budete potřebovat jako výchozí bod. Všimněte si, že nezahrnuje Azure Service Health. Tuto možnost byste si měli připnout na řídicí panel, abyste mohli zjistit, jestli se jedná o problém se systémy nebo se samotnou cloudovou službou.
- Pomocí mapy aplikace v aplikaci Přehledy můžete přejít k podrobnostem přesně o tom, co se děje, aby se problémy mohly způsobit. Příčinu chyby (např. chybně vytvořenou adresu URL) můžete najít pomocí popisu cesty.
- Log Analytics můžete použít k dotazování jakékoli části systému.
Všechny předchozí nástroje jsou neocenitelné při odstraňování problémů.