Když vypadne jeden switch, služba ještě nestojí

Ve dvě ráno vypadne jeden ze dvou přepínačů v racku. Servery jsou připojené do obou, takže služby běží dál. Monitoring přesto hlásí desítky alertů, mapa závislostí zčervená a ráno na poradě vlastníci služeb čtou, že jejich služba byla „degradovaná“. Nebyla. Jen na pár hodin přišla o zálohu.

Opačný případ je horší. Alertuje pět virtuálních serverů a hostitel, na kterém běží, mlčí, protože ho monitoring nevidí. Vzniká pět samostatných hlášení, pět lidí začne zkoumat svůj server a skutečná příčina zůstane bez povšimnutí.

Obojí má stejný kořen: nástroj ví, co je s čím propojené, ale neví, co by výpadek jedné části skutečně způsobil.

Dosah není dopad

Většina CMDB umí odpovědět na otázku, co na položce závisí. Poctivá odpověď ale potřebuje víc než seznam vazeb:

• Redundanci. Server připojený do dvou přepínačů výpadek jednoho přežije. Firewall ale nezastoupí přepínač a správcovské síťové rozhraní nezastoupí datové.
• Stav položek. Plánovaný druhý přepínač, který ještě není v provozu, nic nezálohuje. Prvek v údržbě je během změny fakticky mimo provoz.
• Druh vazby. Správa (konzole, která server řídí), replikace a záloha výpadek nešíří. Server nepřestane fungovat proto, že vypadla jeho replika.

Když to nástroj nerozliší, každá impact analýza je přehnaná. Lidé jí přestanou věřit a vrátí se k odhadům na poradách.

Tři stavy místo dvou

Stilla nově rozlišuje tři situace:

• Výpadek – položka nefunguje, protože vypadly všechny její opory.
• Degradace – položka funguje bez části funkcí nebo s horším výkonem.
• Ohroženo – vypadl jen jeden z redundantních prvků. Položka běží dál, jen bez zálohy.

Ohrožení se ukáže u nejbližší závislé položky a u služeb nad ní, které dostanou štítek „bez redundance“. Dál se nešíří. Výpadek jednoho přepínače z dvojice tak neoznačí stovky položek, ale jen to, co skutečně přišlo o zálohu. Výpadek obou přepínačů je pak správně výpadek.

Na stejném výpočtu stojí i další části produktu. Při plánování změny na redundantním prvku vlastník služby dostane informaci, že služba poběží bez zálohy, ale nemusí nic schvalovat a změnu lze provést mimo servisní okno. Kontrola jediných bodů selhání bere plánované položky jako chybějící, takže skrytá slabá místa vyplavou dřív, než se projeví.

Mapa, která ukazuje, co by se stalo

Mapa závislostí dostala tři změny:

• Správcovské vazby jsou samostatná vrstva, ve výchozím stavu vypnutá. Pohled „na čem služba závisí“ tak ukazuje jen skutečné závislosti, ne všechno, co ji spravuje.
• Pohled „co na položce závisí“ rovnou simuluje její výpadek. Barevné položky by výpadek zasáhl, šedé na ní závisí jen redundantně nebo přes správu.
• Cesta dopadu zvýrazní řetěz od příčiny ke každé zasažené službě, včetně portů, rozhraní a zón na cestě. Je vidět, kudy se výpadek ke službě dostane, a dá se to vysvětlit vedení i zákazníkovi.

Korelace událostí podle stejné logiky

Event management sloučí související alerty do jedné situace a označí pravděpodobnou příčinu. Nově to dělá simulací výpadku:

• Příčinou může být jen položka, jejíž výpadek alerty skutečně vysvětlí. Alert na jednom z dvojice přepínačů proto není příčinou výpadku serveru pod ním a operátor nejde řešit špatnou položku.
• Z více kandidátů vyhrává ten, který vysvětlí nejvíc alertů. Když alertuje virtuální server, jeho hostitel i datové úložiště, situace dostane hlubší příčinu, ne tu první v čase.
• Alerty vysvětlené příčinou jsou následky. V situaci jsou vidět, ale nebudí notifikace, nepočítají se do ukazatelů šumu a po vyřešení příčiny se vyřeší s ní.
• Odvozená příčina. Když alertuje několik položek a jejich společná opora sama mlčí, Stilla ji podle CMDB odvodí a založí jednu situaci s označením „odvozeno z topologie“. Operátor ví, kde začít, i když monitoring tu položku nevidí.

Priorita alertu i předvyplněného incidentu se řídí skutečným dopadem na službu. Alert na redundantním prvku proto nedostane prioritu kritické služby, kterou neohrožuje, a fronta operátora zůstane čistší.

Procesy, které na sebe navazují

Opravu obvykle provede změna. Jedna změna může řešit několik incidentů i problém a její výsledek se propíše do všech navázaných záznamů. Problém s popsanou příčinou po úspěšné změně přejde do stavu Vyřešený, neúspěšná změna ho vrátí do analýzy a ohlašovatelé incidentů dostanou zprávu. Když po dokončení změny přibudou alerty na jejích položkách, review po změně je povinné a incident se dá založit jedním tlačítkem.

Závěr

Impact analýza má cenu jen tehdy, když jí lidé věří. Proto musí rozlišit výpadek od ztráty zálohy a stejná čísla musí platit při plánování změny, při incidentu i ve chvíli, kdy monitoring hlásí desítky alertů. Pro provoz to znamená méně nočních telefonátů kvůli následkům, rychlejší cestu ke skutečné příčině a porady, na kterých se o dopadu nedohaduje.

Mapa závislostí, tři stavy dopadu, cesta dopadu a navázání změn na incidenty a problémy jsou součástí edice Standard. Korelace událostí podle simulace výpadku, následky a odvozená příčina patří do edice Business.