# Když vypadne jeden switch, služba ještě nestojí · Stilla > Impact analýza, která nezná redundanci, hlásí stovky „degradovaných“ položek a budí lidi kvůli alertům, které jen opakují jednu příčinu. URL: https://stilla.eywo.digital/blog/redundancy-aware-impact/ Language: cs Last updated: 2026-10-29 [← Zpět na blog](https://stilla.eywo.digital/blog/) Provoz29\. října 20264 min čteníTým Eywo # Když vypadne jeden switch, služba ještě nestojí Impact analýza, která nezná redundanci, hlásí stovky „degradovaných“ položek a budí lidi kvůli alertům, které jen opakují jednu příčinu. Stilla teď počítá dopad i korelaci událostí podle toho, co by se skutečně stalo. 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. **Stilla Business** Pro provoz, který chce propojit monitoring, bezpečnost a dodavatele. [Porovnat edice →](https://stilla.eywo.digital/edice/) ## Další články [Provoz·20\. srpna 2026 ### Závažný incident: koordinace místo chaosu Při závažném incidentu nerozhoduje jen technika, ale i to, kdo ví co a kdy. Popisujeme, jak z prvních minut udělat koordinovanou práci místo honu na informace. Business3 min čtení](https://stilla.eywo.digital/blog/major-incident-coordination/)[Provoz·6\. srpna 2026 ### SLA, které se měří správně Lhůta, která běží přes víkend a svátky, nebo nepočítá s čekáním na zákazníka, vytváří zbytečné spory. Jak měřit SLA tak, aby čísla odpovídala dohodě i realitě. Standard3 min čtení](https://stilla.eywo.digital/blog/sla-measured-right/)[Provoz·30\. července 2026 ### Šum z monitoringu: z tisíců alertů pár situací Když monitoring hlásí všechno, nehlásí vlastně nic. Jak z proudu událostí udělat několik srozumitelných situací s pravděpodobnou příčinou a jasným dopadem na služby. Business3 min čtení](https://stilla.eywo.digital/blog/monitoring-noise/)