Jediné body selhání, o kterých nevíte

Služba má dva aplikační servery, databázi v clusteru a na architektonickém diagramu vypadá bezpečně. Pak jednoho dne vypadne jediný síťový prvek a služba je nedostupná celá. Při rozboru se ukáže, že oba aplikační servery běžely na stejném hypervizoru, nebo že obě databázové instance byly připojené ke stejnému diskovému poli. Redundance existovala jen v jedné vrstvě.

Takové objevy jsou nepříjemné pro všechny. Vlastník služby byl přesvědčen, že je chráněný. Provozní tým o slabém místě často tušil, ale neměl ho čím doložit. A lidé, kteří incident v noci řešili, se ptají, proč na to nikdo nepřišel dřív.

Proč jediné body selhání zůstávají skryté

Jediný bod selhání (SPOF) obvykle není chyba návrhu, ale výsledek postupného vývoje. Infrastruktura se mění, virtuální stroje se přesouvají, kapacity se přerozdělují. Co bylo při spuštění oddělené, se časem může potkat na stejném hardwaru.

• Redundance se posuzuje po vrstvách zvlášť. Tým aplikací vidí dva servery, tým virtualizace vidí volnou kapacitu, nikdo nevidí celý řetězec.
• Diagramy zachycují záměr, ne skutečnost. Popisují, jak to mělo být, ne kam se systémy mezitím přesunuly.
• Revize odolnosti jsou jednorázové. Proběhnou při návrhu nebo auditu, ale ne průběžně.
• Údržba odhalí slabiny pozdě. Pokud se patchují oba uzly redundantní dvojice zároveň, služba vypadne, přestože je formálně redundantní.

Jak k odolnosti přistupovat

Odolnost služby je vlastnost celého řetězce závislostí, nikoli jednotlivých komponent. Proto ji je potřeba posuzovat na úrovni služby, přes všechny vrstvy najednou. Doporučujeme:

1. Explicitně evidovat redundanci. Které položky se navzájem zastupují a tvoří redundantní skupinu.
2. Hledat SPOF průběžně, ne jednou ročně. S každou změnou v infrastruktuře se odpověď může změnit.
3. Ověřovat odolnost simulací. Ptát se, co se stane, když konkrétní komponenta vypadne.
4. Promítnout redundanci do údržby. Redundantní uzly patchovat postupně, aby služba zůstala v provozu.

Jak to řeší Eywo Stratum

Eywo Stratum pracuje s mapou závislostí po vrstvách – od business služeb přes aplikace, databáze a servery až po hypervizory, storage a síť. Na tomto základě umí:

• evidovat redundantní skupiny, tedy položky, které se vzájemně zastupují,
• identifikovat jediné body selhání – komponenty, jejichž výpadek zasáhne službu bez ohledu na redundanci jinde v řetězci,
• vyhodnotit odolnost služeb a ukázat, kde je služba chráněná a kde ne,
• simulovat výpadek vybrané komponenty a zobrazit zasažené služby a aplikace.

Znalost redundance se promítá i do údržby. Změny lze provádět postupně po položkách, takže se uzly redundantní skupiny nevypínají najednou. V edici Business pak dohoda o patchování s vlastníkem služby umožňuje postupné patchování redundantních uzlů – jeden uzel se aktualizuje, ověří a teprve potom přichází na řadu další. Služba tak zůstává dostupná i během pravidelné údržby.

Vlastník služby díky tomu nemusí věřit diagramu. Vidí aktuální stav odvozený z CMDB a ví, na čem jeho služba skutečně stojí.

Stejná znalost pomáhá i při plánování změn. Před odesláním změny Stratum vypočítá, které služby budou mimo provoz nebo degradované. Pokud zásah míří na jediný bod selhání, je to vidět dřív, než se změna dostane ke schválení, a tým může zvolit jiný postup nebo jiný termín.

Závěr

Jediné body selhání nevznikají ze dne na den a nezmizí jednorázovou revizí. Najít je lze jen tehdy, když se na službu díváme celou, přes všechny vrstvy, a když je tento pohled aktuální. Pak se z nepříjemných nočních objevů stávají běžné položky v plánu práce, které lze vyřešit v klidu a v pracovní době.

Redundantní skupiny, analýza jediných bodů selhání a simulace výpadku jsou součástí edice Standard; postupné patchování redundantních uzlů v rámci patch managementu přináší edice Business.