Aktuálně: Postihly zákazy tvou profesi? Poptávka po ajťácích prudce roste, využij slevové akce 30% výuky zdarma!
Swift týden

Lekce 1 - Proč a jak začít s Konfigurační databází (CMDB) - Online kurz

Trápí tě taky níže uvedené otázky?

  • Jaký typ podpory máme na jaký hardware?
  • Kdo má přístup lokálního administrátora na jednotlivé servery?
  • Jaké máme aplikace? Na jakých technologiích běží? Kdo je spravuje?
  • Kdy mají naše auta technickou prohlídku?
  • Jaké máme certifikáty a kdy mi vyprší?
  • Kde máme všechna naše zařízení? Nejsou některá v povodňovém pásmu?

Na všechny tyto otázky potřebujete odpovědi, odpovědi SPRÁVNÉ a hlavně IHNED. V dnešní době nemůžete čekat tři dny nebo déle než někdo zkontaktuje někoho jiného a k odpovědi se následně dobere. Zvláště, když si tuto informaci můžete najít sami a bez čekání.

Řešení

Řešením je ve firmě používat Konfigurační databázi (Configuration Management Database – CMDB). Nejdříve si ale rozeberme, proč vlastně zavádět Konfigurační databázi. Níže budeme pracovat s příkladem konfigurační databáze IT. Stejný přístup můžeme ale aplikovat i na další oblasti a místo aplikací a serverů evidovat např. výrobní zařízení nebo předměty naší servisní činnosti. Přínosy z pořádku v informacích a návazných procesů budou stejné.

Pokud jsme administrátor serverů, možná si vedeme evidenci serverů v Excelu. Umožňuje nám to rychle zjistit, k čemu jednotlivé servery máme – jakou roli plní, jaké IP adresy používají, na jakém hardware běží a kde se daný server nachází. Možná sledujeme i to, zda k hardware máme servisní smlouvu a jaké máme kontakty na dodavatele.

Tento výukový obsah pomáhají rozvíjet následující firmy, které dost možná hledají právě tebe!

Pokud jsme manažer, dost možná cítíme nedostatek informací o oblasti, za kterou jsme zodpovědní. Věříme svým podřízeným, kteří nás ujišťují o tom, že je o vše řádně postaráno, ale zároveň bychom přece jen měli raději přístup ke všem přehledně uspořádaným informacím, abychom si mohli odpověď na naše otázky najít sami. Tyto informace nás mohou inspirovat i k otázkám, na které bychom se na naší pozici měli ptát, ale bez těchto informací nás nenapadne si je položit:

  • Kolik serverů běží na operačních systémech, které jsou již mimo hlavní podporu nebo se jí blíží?
  • Kdy mi končí podpora serverů výrobcem?
  • Jak velký si mám připravit rozpočet na příští rok?
  • Kolik serverů je fyzických a kolik virtuálních?
  • Kdo je klíčovým uživatelem jednotlivých aplikací? Kdo je hlavním gestorem rozhodujících o změnách z pohledu business funkcionality?
  • Jak si aplikace vyměňují data?

Konfigurační databáze nám umožní získat konsolidovaný přehled z Excelů, které si evidují jednotlivé týmy. Získáme také informace, které nyní existují pouze v hlavách jednotlivých uživatelů. Vedle pravdivého popisu stavu našeho informačního systému získáme jádro, kolem něhož budeme schopni postavit robustní procesy, které nás spolehlivě provedou plánováním a prováděním změn, vyhodnocováním dopadů, evidencí problémů, incidentů a odpověďmi na ně. Umožní nám evidovat naše znalosti strukturovaným způsobem tak, že se budeme schopni rychle dobrat potřebných informací. CMDB modeluje naše služby, aplikace a infrastrukturu. Jde o systém podporující správné rozhodování v IT, ale má přesahy do dalších oblastí včetně auditu, compliance či zákaznického servisu.

Konfigurační databáze musí být pro celou firmu

Konfigurační databázi nebudeme používat sami jako jediný uživatel. Je třeba, aby různí lidé z různých týmů udržovali data aktuální a zároveň z nich data čerpali pro svou práci. Pro zavedení Konfigurační databáze a návazných procesů je tak důležitá podpora managementu a přesvědčení ostatních, že jde o krok správným směrem, který nás posune dopředu.

Konfigurační databázi budeme nejspíše implementovat s nějakým existujícím modelem vztahů konfiguračních položek. Je dobré si uvědomit, že neexistuje jeden univerzální model, ale vše závisí na velikosti organizace, odvětví, ale i zkušenostech s danou problematikou. Tyto osobní pohledy také ovlivní úpravu modelu a je to v pořádku. Než se snažit sžít s evidencí, která nám bude připadat zbytečně složitá, implementujeme to, co nám v tuto chvíli dává smysl a na detailnější evidenci přejdeme, až o jejích přínosech budeme přesvědčeni. Na začátku ale zkonzultujeme náš model s dostupnými modely na internetu – např. dokumentace systémové nebo hardware vrstvy Konfigurační databáze ObjectGears. Pokud tě už nějak táhne konfigurační databáze, můžeš si projít tutoriál na ObjectGears.

Měli bychom zvolit systém, který umožňuje řídit vlastnosti konfiguračních položek pomocí dědičnosti. Vlastnosti mohou být společné všech konfiguračních položek (např. unikátní kód položky, který budeme generovat, popis funkce, konec životního cyklu nebo business vlastník položky, který schvaluje změny a technický vlastník, tedy administrátor, který ji podporuje a implementuje změny). Další vlastnosti mohou být specifické pro daný typ položky. Jiné vlastnosti budou mít hardware zařízení, jiné databázové servery, jiné aplikace a jiné třeba certifikáty:

Obrázek 1: Jednotlivé typy konfiguračních položek dědí společné vlastnosti ze společného předka Jednotlivé typy konfiguračních položek dědí společné vlastnosti ze společného předka

Data budeme automaticky importovat (tam kde je to možné – např. konfigurace serverů) a zadávat pomocí formulářů (např. automaticky nelze zjistit, kde máme jakou servisní smlouvu nebo proč si dvě aplikace vyměňují data). Systémy konfiguračních databází také nabízejí ruční importy z CSV souborů nebo Excelu, což nám také ulehčí práci. Ve výsledku budeme schopni zobrazit např. schéma naší infrastruktury relevantní pro určitou aplikaci:

Obrázek 2: Schéma ukazující aplikační komponenty, na jakých virtuálních serverech běží a jaká infrastruktura je použita pro virtualizaci. Vše s linky na detaily příslušných konfiguračních položek. Schéma ukazující aplikační komponenty, na jakých virtuálních serverech běží a jaká infrastruktura je použita pro virtualizaci. Vše s linky na detaily příslušných konfiguračních položek.

Budeme schopni se rychle dobrat k seznamu serverů, zobrazit jejich detailní informace a potřebné souvislosti:

Obrázek 3: Informace o hardware včetně prokliků na server, který na něm běží. Informace o hardware včetně prokliků na server, který na něm běží.

Stejně tak budeme schopni naplánovat dopad projektů nebo plánovaných změn výběrem dotčených konfiguračních položek v kartě projektu, releasu nebo změny:

Obrázek 4: Karta projektu popisující dopad do infrastruktury. Uvedené konfigurační položky pak zobrazují dopad ze všech projektů, což nám umožní identifikovat potenciální kolize. Karta projektu popisující dopad do infrastruktury. Uvedené konfigurační položky pak zobrazují dopad ze všech projektů, což nám umožní identifikovat potenciální kolize.

To vše nám umožní udržet přehled v tom, co děláme. Zajistit transparentnost a udržitelnost. Klíčové informace o naší infrastruktuře budou v Konfigurační databázi bezpečně uloženy a zároveň dostupné všem lidem a procesům, kteří s nimi mají pracovat.

V další lekci, Aktualizace CMDB z mnoha zdrojů dat, si ukážeme, jak přistupovat k aktualizaci dat CMDB a jak na emailové notifikace.


 

Všechny články v sekci
Konfigurační databáze (CMDB)
Článek pro vás napsal Pavel Carvan
Avatar
Jak se ti líbí článek?
Ještě nikdo nehodnotil, buď první!
Aktivity (3)

 

 

Komentáře

Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zatím nikdo nevložil komentář - buď první!