# Co se stane, když vypadne…? Dopad dřív než výpadek · Stilla > Otázku „co všechno na tom visí“ si týmy obvykle kladou až ve chvíli, kdy něco nefunguje. Mapa závislostí po vrstvách umožňuje znát odpověď předem. URL: https://stilla.eywo.digital/blog/impact-before-outage/ Language: cs Last updated: 2026-10-25 [← Zpět na blog](https://stilla.eywo.digital/blog/) CMDB11\. června 2026Aktualizováno 25\. října 20263 min čteníTým Eywo # Co se stane, když vypadne…? Dopad dřív než výpadek Otázku „co všechno na tom visí“ si týmy obvykle kladou až ve chvíli, kdy něco nefunguje. Mapa závislostí po vrstvách umožňuje znát odpověď předem. 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ší Stilla Stilla 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 Stilla 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 Stilla 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. **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/)[CMDB·1\. října 2026 ### Datové centrum v CMDB: od sálu po pozici v racku Když technik stojí v sále a hledá konkrétní server, nepomůže mu IP adresa. Potřebuje vědět, ve které uličce, v jakém racku a na jaké pozici, a také jestli je ten kus hardwaru ještě pod servisní smlouvou. Business3 min čtení](https://stilla.eywo.digital/blog/data-center-in-the-cmdb/)[CMDB·24\. září 2026 ### Konec podpory OS a hardwaru pod kontrolou Konec podpory operačního systému nebo serveru obvykle nepřijde jako překvapení, a přesto zaskočí. Ukazujeme, jak mít životní cyklus pod kontrolou a plánovat obnovu podle služeb, ne podle seznamu serverů. Standard3 min čtení](https://stilla.eywo.digital/blog/end-of-support-under-control/)