CMDB, které nikdo nevěří

Je dvě hodiny ráno a padá aplikace pro klienty. Službu konající administrátor otevře CMDB, najde server a vidí u něj vlastníka, který odešel před rokem. Databáze, na které aplikace stojí, v záznamu chybí úplně. Následuje série telefonátů, hledání ve sdílených tabulkách a dohadování, kdo za co odpovídá. Incident se protáhne a ráno se znovu ozve známá věta: „Do CMDB se stejně nedá dívat.“

V praxi často vidíme, že konfigurační databáze existuje, je drahá na údržbu, a přesto jí nikdo nevěří. Lidé si proto vedou vlastní evidenci v Excelu, v hlavě nebo na wiki. Tím se kruh uzavírá: čím méně se CMDB používá, tím méně se aktualizuje, a tím méně se jí dá věřit. Za tím vším jsou unavení lidé, kteří při každém výpadku skládají obraz infrastruktury od nuly.

Proč běžné přístupy nefungují

Obvyklou reakcí je jednorázový úklid. Tým stráví několik týdnů revizí záznamů, data jsou na chvíli v pořádku a za půl roku je stav stejný jako předtím. Problém totiž není v jednom špatném importu, ale v tom, jak data vznikají a stárnou.

• Ruční zápis bez kontroly. Položky zakládá více lidí různými postupy a nikdo neověřuje, zda dávají smysl.
• Chybějící historie. Když je údaj špatně, nelze zjistit, kdo jej změnil, kdy a z jakého zdroje.
• Více pravd najednou. Organizace má primární CMDB v jednom nástroji a provozní data v jiném. Bez spolehlivého propojení se záznamy rozcházejí.
• Žádná zpětná vazba. Nekonzistence se objeví až ve chvíli, kdy je nejméně času je řešit – při incidentu.

Jak k důvěře v data přistupovat

Důvěra v CMDB nevzniká dokonalostí, ale průhledností. Lidé budou datům věřit, když uvidí, odkud pocházejí, kdy byla naposledy potvrzena a co s nimi není v pořádku. Doporučujeme stavět na čtyřech principech:

1. Plnit automaticky tam, kde to jde. Discovery a importy mají přednost před ručním opisováním.
2. Každá změna má autora a zdroj. Historie verzí je základ pro dohledání chyb i pro audit.
3. Kontrolovat kvalitu průběžně. Nekonzistence je lepší najít v úterý odpoledne než v noci při výpadku.
4. Mít jasný vztah k primární evidenci. Pokud existuje jiná hlavní CMDB, musí být jednoznačné, který záznam odpovídá kterému.

Jak to řeší Eywo Stratum

Eywo Stratum pracuje s 34 třídami položek – od business služeb a aplikací přes databáze, virtuální i fyzické servery, IBM Power, kontejnery a storage až po síť a OT zařízení. Data lze plnit několika způsoby a kombinovat je:

• přes discovery API, kam posílají data skenovací a inventarizační nástroje,
• importem z CSV nebo Excelu, typicky při zavádění nebo migraci,
• ručním založením pro položky, které jinak zachytit nelze,
• synchronizací s primární CMDB (například ServiceNow nebo SMAX) přes externí ID, takže je vždy jasné, který záznam odpovídá kterému.

Každá změna položky vytvoří novou verzi. V historii je vidět, kdo změnu provedl, kdy, co přesně se změnilo a odkud data přišla – zda z discovery, z importu, ze synchronizace, nebo ručně. Když se údaj ukáže jako chybný, dá se dohledat jeho původ během chvíle.

Na to navazuje kontrola kvality dat. Stratum upozorňuje na nekonzistence a neúplné záznamy, takže tým je může opravovat průběžně, a ne až pod tlakem incidentu. CMDB se tak postupně stává místem, kam se lidé dívají jako první, protože vědí, co v ní najdou.

Závěr

CMDB, které nikdo nevěří, není technický problém, ale problém důvěry. Tu nelze nařídit, dá se jen budovat: automatickým plněním, průhlednou historií, průběžnou kontrolou a jasnou vazbou na primární evidenci. Odměnou je provoz, ve kterém administrátor v noci najde odpověď v datech, a ne v telefonu kolegy.

Správa CMDB, historie verzí, importy a kontrola kvality dat jsou součástí edice Standard; synchronizace s primární CMDB přes externí ID je k dispozici v edici Enterprise.