IT Schizma

Podíváme-li se na obrázek 1, vidíme, že podle analytiků IT trhu podobně reagovali i ostatní ředitelé firem. Daleko zajímavější je ale jiná interpretace obou křivek. Pokud do grafu vneseme náklady na pořízení IT infrastruktury v jednotlivých letech, dostaneme podobnou křivku té dolní. Pokud přidáme náklady na provoz této infrastruktury, dostaneme křivku horní. Analytici tvrdí, že jeden dolar investovaný do infrastruktury znamená v současné době potřebu investovat deset dolarů do jejího provozu. Je to nejen kvůli větší komplexnosti infrastruktury a složitosti aplikací, ale také kvůli potřebě zajistit fungování IT služby bez výpadků. Nedávno jsem hovořil s vedením největší banky v jedné ze sousedních zemí a tam přišla minuta na zhruba deset tisíc dolarů a výpadek trval několik hodin.
Od IT se očekává větší pružnost, kvalita a spolehlivost dodávaných služeb, a to pokud možno za minimální náklady. Každý, kdo v IT pracuje nebo pracoval, mi dá jistě za pravdu, že splnit takové požadavky není jednoduché.
 

Obr. 1

Lidský faktor

Podnikové IT se snaží zlepšit dodávané služby zavedením ITIL a zlepšováním procesů pomocí CMMI. Používá se množství programů umožňujících přesnější pohled na provoz částí infrastruktury a aplikací. Ve většině případů tyto programy neumožňují vidět dodávanou službu od uživatele přes její komponenty, a tak identifikace příčiny výpadku a zapojení správných složek podpory trvá dlouho.
Mezi nejčastější příčiny výpadku služby patří implementace změn. V průměru více než šedesát procent změn je neúspěšných. Mezi nejčastější příčiny patří nejen nedostatečně testovaná aplikace před jejím zavedením do provozu, ale zhruba stejným procentem se podílejí změny, kde CAB (change advisory board) schválil změnu na základě špatných podkladů, nebo změna nebyla schválena, ale přesto provedena. Velké procento neúspěšných změn jde na vrub neaktuálních informací v CMDB (konfigurační databázi). Ve firmách, které používají ITIL řadu let, je situace překvapivě velmi podobná. Důvodem je lidský faktor a řada nepropojených programů v procesu změny. A tak je snadné některý krok procesu ignorovat nebo informace z jednoho kroku nepřenést do druhého, případně z jednoho programu do druhého, nebo je neuložit v CMDB.
Lidský faktor, zejména na helpdesku a v NOC (network operation center), je dalším bolavým místem v IT provozu. Je zde velká fluktuace, lidé odcházejí z důvodu směnného provozu nebo kvůli tomu, že jim po čase práce připadá rutinní a nezajímavá. Přitom nezaškolený nebo unavený pracovník na NOC, pokud používá papírové workbooky, nejlépe pro několik aplikací najednou, může způsobit výpadek s důsledky výbuchu malé bomby. Pokud při měsíční uzávěrce pustí aplikace ve špatném pořadí, uvedení dat do původního stavu před novým spuštěním je otázka mnoha hodin. Vzpomínám na případ, kdy kvůli takovému uklepnutí byla prezentována špatná závěrka a v důsledku toho firemní akcie ztratily na burze dvanáct procent.
Jak je patrné, vyloučení nebo omezení lidského faktoru z klíčových procesů IT a automatizace těchto procesů v souladu s ITIL může být správným krokem.

Automatizace a ITIL enforcement

Na obrázku 2 je znázorněn jeden z možných přístupů. Aplikace ve čtyřech sloupcích uprostřed obrázku slouží k automatizované správě jednotlivých složek infrastruktury, a to zejména k instalaci aplikací, ke změnám aplikací, k nastavení a změně konfigurace jednotlivých koncových zařízení a ke kontrole nastavení zařízení vůči standardům firmy atd. Veškeré informace o akcích provedených na infrastruktuře jsou ukládány do federativní databáze UCMDB.
 

Obr. 2

Service Automation Visualizer umožňuje přehled o stavu infrastruktury v celém rozsahu. Je možné vidět stav všech prvků realizujících poskytovanou obchodní službu a okamžitě identifikovat místo a příčinu chyby a odstranit ji automaticky podle vygenerovaného workflow. Samozřejmě všechny údaje jsou automaticky přeneseny do UCMDB.
Service Automation Reporter produkuje z dat v UCMDB reporty vyžádané uživatelem ve stanovené frekvenci. Nejužitečnější jsou zprávy ohledně shody se standardy, dále pak plnění SLA, ale je možné získat i detailní analýzu příčin pro neplnění SLA přes všechny skupiny podpory, které se podílejí na podpoře jedné obchodní služby.
Operation Orchestration dovoluje vytvořit workflow pro kritické procesy podle požadavků ITIL. Do něj je možné zahrnout nejen aplikace pro automatizaci, ale všechny aplikace, které firma používá pro daný proces.
Uveďme si pro názornost ukázku možného scénáře – instalace záplaty v SAP: Operation Orchestration (OO) otevře tiket pro změnu v příslušném tiketovacím programu. Přenese do něj údaje o stavu infrastruktury, kterou SAP používá a informace o možných kolizích s jinými aplikacemi, pokud využívají společné části infrastruktury. Tyto informace získá OO z aplikací pro automatizaci. Pokud firma používá aplikaci pro virtuální CAB, OO ji spustí a předá do ní potřebné informace. Každý z členů CAB má i možnost vlastní kontroly údajů přes Service Automation Visualizer. Jakmile CAB schválí Operation Orchestration, opět provede aktualizaci tiketu a spustí příslušné automatizační programy pro provedení změny. Před aktualizací tiketu a dat v UCMDB ještě vyvolá program pro monitoring k otestování úspěšnosti změny. Jelikož UCMDB je federativní databáze, jsou změny dat průběžně aktualizovány v databázích jednotlivých spouštěných aplikací.
Zní to jako pohádka, ale je to realita. Podobné scénáře je možné vytvořit i pro další kritické procesy, jako incident management, service provisioning apod. Na obrázku 3 je pro ilustraci ukázána část automatizovaného workflow pro provisioning.


Obr. 3

Vyplatí se? Vyplatí!

Závěrem se podívejme na konkrétní příklady z praxe. Distribuční řetězec automatizoval proces instalace aplikací na 2 600 serverech a zkrátil tak potřebnou dobu ze dvou týdnů na dvacet minut.
Velká IT firma zavedla automatizaci dohledu nad infrastrukturou a snížila počet incidentů z více než osmdesáti týdně na jeden. Letecká společnost zavedla automatizaci procesu pro disaster recovery. Čas se snížil ze 45 na 8 minut, automatizací procesu pro incident management snížila tato firma střední dobu vyřešení incidentu o šedesát procent. Finanční instituce zavedením automatizace workbooku pro NOC zvýšila produktivitu o šedesát procent, automatizací dalších workflow umožnila zvýšit tzv. first call resolution o padesát procent.
Z výše uvedeného tedy vyplývá, že zavedení automatizace IT procesů skutečně přináší to, co business očekává. V řadě případů je možné vzdálenost mezi oběma křivkami na obrázku 1 zredukovat o čtyřicet až osmdesát procent, a to ve finančním vyjádření i v kvalitě.

Karel Višňák
Autor působí jako business development manager
ve společnosti HP Software CEE