Příběh: běžný provoz a údržba podle ITIL (2. díl)

Nyní si povíme, jak stejný případ vypadal po několika měsících implementační snahy následovat určité ITIL principy. Opět se zde vyskytují stejní účastníci, jen průběh příběhu (řešení incidentu) je odlišný.

Pondělní ráno přichází Marie do práce a používá ke své práci program SkladAObjednávky v1.1. Po hodině práce program přestane odpovídat a zhroutí se a již nejde znovu spustit. Marie se přihlásí k  Service Desk nástroji, který je jediným kontaktním místem (SPOC – Single Point Of Contact) a vytvoří záznam o incidentu (icident je událost která omezuje či změnožňuje práci uživatele IT služby), kde popíše, co se stalo. Záznam je reportovaný na IT službu SkladAObjednávky. Incident manažer je notifikován o novém záznamu incidentu a přiřadí kategorii (aplikace) a prioritu (vysoká) incidentu a přiřadí incident k řešení Adamovi. Marie je o přiřazení incidentu řešiteli notifikována automaticky e-mailem stejně jako Adam. Adam přeruší aktuální práci z důvodu vysoké priority nového incidentu a začne jej řešit. Začne prozkoumávat incident s použitím znalostní báze (KB – Knowledge Base), konfigurační databáze CMDB a automatických nástrojů. Adam ví, na kterém serveru program běží a jaké jiné programy využívá díky katalogu IT služeb (viz následující tabulka).

Adam díky automatickému nástroji pro správu konfigurace zjistí, že disk serveru, na kterém aplikace běží, je plný. Zazálohuje tedy dočasné soubory a začne prozkoumávat pouze log pro Oracle databázi a aplikační server Tomcat, jelikož ví z katalogu IT služeb, že služba tyto aplikační součásti využívá a také díky nástrojům ví, že nejede pouze tato služba. Okamžitě si všimne velikého logu Oracle databáze. Zálohuje a vymaže tento log, restartuje pouze danou službu a vyzkouší její funkčnost. Okamžitě také připraví skript, který bude pravidelně zálohovat na jiném stroji a poté mazat původní Oracle log (tzv. workaround) a instaluje ho. Služba stále funguje dobře. Poté vytvoří v Service Desk aplikaci záznam o problému (přiřadí Oracle skupině, která řeší problémy s Oracle databázemi a připojí odkaz na zálohovaný log) – proto, aby se zkoumala a vyřešila kořenová příčina tohoto incidentu, jelikož ji sám neodhalil. Nakonec Adam aktualizuje záznam o incidentu a uzavře jej. Marie je o uzavření / vyřešení opět automaticky notifikována e-mailem, takže nyní ví, že může danou IT službu opět využívat.

Stále ještě v pondělí, ale již po obědě, vytvoří Adam záznam ve znalostní bázi (KB) s popisem incidentu, jeho symptomů a přiloží workaround, který daný incident řeší. Tento záznam má pomoci rychle vyřešit incident tohoto typu, pokud se náhodou někdy v budoucnu opět objeví.

Nástroj pro reportování incidentů, problémů, požadavků na změn

Využívali jsme funkci Service Desk a proces zvaný Incident Management. V této fázi je však vyřešen pouze incident. Mohli jsme si všimnout, že díky vhodně nastaveným pravidlům a nástrojům se během několika hodin/možná desítek minut, kdy se okamžitě incidentem začaly zabývat osoby k tomu určené, mohla Marie opět pracovat. Důležitá služba sloužící ke zpracování objednávek tedy není 3 dny nedostupná, zákazníci nemuseli vůbec nic poznat. Nyní je však třeba vyřešit ještě kořenovou příčinu (pojmy ITIL tzv. problém) tohoto incidentu, aby se v budoucnu neopakoval. Podívejme se dále, jak budeme řešit problém s pomocí procesu Problem Management a implementovat danou změnu pomocí procesu Change Management.

Je zformován tým Problem Managementu (PrM), jelikož v Service Desku vznikl požadavek na řešení problému. Rachel, specialistka na Oracle, je přiřazena k danému problému a začne zkoumat záznam o problému, přidružený incident a také log soubor Oracle databáze, jenž je odkazován v detailu záznamu. Vidí, že v logu se objevují programátorské výpisy. Připojí se přímo na webu společnosti Oracle k jejich nástroji na reportování chyb, ale nenajde zde žádnou podobnou chybu. Proto přímo zde ihned vytvoří záznam o chybě. Po několika dnech je notifikována e-mailem, že Oracle vydal opravnou záplatu, která řeší tento problém. Rachel tedy vytvoří požadavek na změnu (RfC – Request for Change), který požaduje a vysvětluje nutnost implementace této záplaty.

Nyní existuje řešení kořenové příčiny a je požadavek na implementaci tohoto řešení do provozního prostředí. Za schválení požadavku, otestování a nasazení záplaty jsou zodpovědné procesy Change a Release Managementu. Postup by mohl vypadat následovně (již sme nebyli svědky tohoto řešení v dané organizaci).

Změna je schválena Change Managerem, jelikož její implementace téměř nic nestojí, řeší kořenovou příčinu, tudíž odstraňuje dočasné řešení, tzv. workaround. Oracle záplata je otestována v testovacím prostředí, všechny testy proběhnou v pořádku, je tedy možné záplatu nainstalovat i do provozního prostředí. Záplata je instalována do provozního prostředí ve večerním okně určeném pro údržbu (od 2.00 do 3.00 v noci) tzv. maintenance window. Po úspěšné instalaci záplaty je odstraněno dočasné řešení – zálohovací a mazací skript. Poté Rachel doplní řešení problému a uzavře záznam. Nakonec aktualizuje záznam ve znalostní bázi vytvořený Adamem a přidá k němu odkaz na záplatu řešící tento problém.

Použití formálních, popsaných a automatizovaných procesů definovaných podle ITIL umožnilo provést všechny nutné aktivity mnohem efektivněji než ad hoc přístup v prvním případě.

Na závěr můžeme říct následujících několik bodů. Incident byl vyřešen mnohem dříve, než v prvním případě. Řešili ho lidé k tomu určení a jeho řešení neovlivnilo práci jiných lidí v IT oddělení (např. programátorů). Lidé, kteří se podíleli na řešení, věděli co a jak mají dělat. Navíc hned ten samý den proběhlo zkoumání a řešení kořenové příčiny, z důvodu zamezení opakujících se incidentů a z důvodu strukturálního řešení, ne jen dočasného workaroundu.

Automatizované nástroje usnadnili spoustu práce s diagnostikou a hledáním. O všem existují záznamy v nástroji Service Desk, je snadné vysledovat změny a kroky provedené pracovníky podpory. Znalostní báze (KB) může pomoci při příštím řešení podobných incidentů/problémů.

Příspěvek byl publikován v rubrice Články se štítky . Můžete si uložit jeho odkaz mezi své oblíbené záložky.

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *