# Jediné body selhání, o kterých nevíte · Stilla > Služba je postavená redundantně – na papíře. Ve skutečnosti může celá stát na jednom přepínači, jednom poli nebo jednom hypervizoru. URL: https://stilla.eywo.digital/blog/single-points-of-failure/ Language: cs Last updated: 2026-10-25 [← Zpět na blog](https://stilla.eywo.digital/blog/) Odolnost18\. června 2026Aktualizováno 25\. října 20263 min čteníTým Eywo # Jediné body selhání, o kterých nevíte Služba je postavená redundantně – na papíře. Ve skutečnosti může celá stát na jednom přepínači, jednom poli nebo jednom hypervizoru. Jak takové body najít dřív, než se projeví. 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ší Stilla Stilla 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 Stilla 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. **Stilla Standard** Pro organizace, které chtějí spolehlivou CMDB a řízené ITSM procesy. [Porovnat edice →](https://stilla.eywo.digital/edice/) ## Další články [CMDB·25\. října 2026 ### Virtuální síť v CMDB: od port group po leaf přepínač Mezi virtuálním strojem a fyzickou sítí leží vrstva, kterou většina CMDB nevidí – virtuální switche, port groupy a uplinky hostitelů. Právě na ní se ale rozhoduje, kterých služeb se změna v síti dotkne. Standard3 min čtení](https://stilla.eywo.digital/blog/virtual-network-in-the-cmdb/)[Řízení·25\. října 2026 ### NIS2 a DORA: co musí provoz umět doložit Obě regulace se ptají na totéž – víte, které služby výpadek zasáhne, kdo za ně odpovídá a co se kdy změnilo? Bez spolehlivé mapy závislostí se odpovědi skládají ručně, často pod časovým tlakem. Standard2 min čtení](https://stilla.eywo.digital/blog/nis2-dora-evidence/)[Zavedení·15\. října 2026 ### Zavedení ITSM bez půlročního projektu Zavedení nového ITSM nástroje nemusí znamenat měsíce workshopů a konzultantů. Stačí začít na jedné oblasti, převzít data, která už máte v Excelu, a před spuštěním si ověřit, že nic podstatného nechybí. Standard3 min čtení](https://stilla.eywo.digital/blog/itsm-without-half-year-project/)