Co se stane, když vypadne…? Dopad dřív než výpadek

Na poradě se probírá plánovaná výměna diskového pole. Někdo se zeptá: „Které služby to vlastně zasáhne?“ Nastane ticho. Správce storage ví, které servery jsou připojené. Správce virtualizace tuší, které virtuální stroje na nich běží. Kdo ale přesně ví, které aplikace a které business služby za tím stojí a koho je potřeba informovat? Odpověď se skládá z několika hlav a několika tabulek a často je neúplná.

Stejná otázka přichází i v horší chvíli. Monitoring hlásí výpadek hypervizoru a dispečink neví, zda jde o okrajový testovací systém, nebo o službu, kterou ráno používají tisíce lidí. Rozhodování o prioritě se zdržuje a lidé, kteří by mohli problém řešit, místo toho zjišťují, co vlastně spadlo.

Proč dopad obvykle neznáme včas

Informace o závislostech v organizacích existují, ale jsou roztříštěné. Každý tým vidí svou vrstvu a dobře jí rozumí. Chybí pohled, který by vrstvy spojil.

• Dokumentace architektury zastarává s každou změnou a málokdo ji aktualizuje.
• CMDB bez vztahů je pouhý seznam položek. Bez vazeb neodpoví na otázku, co na čem závisí.
• Monitoring vidí technické komponenty, ale nezná business služby, které na nich stojí.
• Analýza dopadu změny se dělá ručně a záleží na zkušenosti toho, kdo ji zrovna píše.

Výsledkem je, že dopad se zjišťuje až v okamžiku výpadku – tedy ve chvíli, kdy už je pozdě na plánování a komunikaci.

Jak přemýšlet o dopadu

Klíčem je modelovat závislosti jednou a používat je všude. Pokud CMDB zná vztahy mezi vrstvami – od business služby přes aplikaci, databázi a server až k hypervizoru, storage a síti – lze stejnou otázku položit v různých situacích:

• Před změnou: co bude během zásahu mimo provoz nebo degradované?
• Při incidentu: kterou službu porucha zasahuje a kdo je za ni odpovědný?
• Při zpracování událostí z monitoringu: které alerty spolu souvisejí a co je jejich pravděpodobná příčina?
• Při plánování: co se stane, když vypadne konkrétní komponenta, a vydrží to služba?

Jedna mapa závislostí tak slouží změnovému řízení, řešitelům incidentů i provozu monitoringu.

Jak to řeší Eywo Stratum

Eywo Stratum zobrazuje mapu závislostí po vrstvách: business služby, aplikace, databáze, servery, hypervizory, storage a síť. U každé položky je vidět, co na ní stojí a na čem stojí ona sama.

Nad mapou lze spustit simulaci výpadku. Vyberete komponentu a Stratum ukáže, které služby a aplikace by byly zasaženy a zda je některá z nich chráněná redundancí. Na stejném základě pracují další části produktu:

• Incidenty: při založení incidentu z položky CMDB Stratum navrhne zasaženou službu, dopad a řešitelský tým. Priorita se pak odvodí z dopadu a naléhavosti.
• Změny: ještě před odesláním změny se vypočítá dopad – které služby a aplikace budou mimo provoz nebo degradované. Vlastník zasažené služby pak schvaluje odstávku, o které ví, co znamená.
• Monitoring: v rámci event managementu se alerty seskupují do situací podle topologie CMDB, takže je vidět pravděpodobná příčina místo desítek samostatných hlášení.

Díky tomu se otázka „co se stane, když vypadne…?“ nezodpovídá na poradě odhadem, ale z dat, kterým tým rozumí.

Závěr

Dopad výpadku se dá znát předem. Vyžaduje to CMDB, která nezná jen položky, ale i jejich vztahy, a nástroj, který tuto znalost používá při změnách, incidentech i zpracování událostí. Pro provozní týmy to znamená méně dohadování v kritických chvílích a více jistoty při plánování.

Mapa závislostí, simulace výpadku a výpočet dopadu u incidentů a změn jsou součástí edice Standard; seskupování alertů podle topologie přináší edice Business.