ITIL v praxi: Incident vs. Problem Management

Pokud jste někdy hledali práci na Service Desku (nebo v celém ITSM odvětví), z 90 % se v inzerátu objevila zkratka ITIL.

ITIL (Information Technology Infrastructure Library) je (ve zjednodušené zkratce) soubor doporučení, postupů a “best practices”, jak doručovat IT služby tak, aby z nich firma měla užitek, a ne bolehlav. A ačkoliv se ITIL skládá z velkého počtu modulů, rozeberme ty nejznámnější dva a navzájem si o sobě konkurující: Incident a Problem management.

Příklad ze Service Desku

S čím se denně setkáváte, to je Incident Management. Uživatel “Karel” vám oznámí, že nefunguje Wi-Fi ve třetím patře budovy A.

Jaký je váš absolutní primární cíl v ten moment? Obnovit uživateli jeho práci. Jak? Někdy elegantně restartováním konkrétního switche, někdy poměrně “humpolácky” tím, že mu dáte dlouhý kabel, natáhnete ho k nejbližší síťové zásuvce, vytvoříte tím z něj drátového uživatele, a uzavřete Incident - oprava hotova, práce je možná.

graph TD
    A[Uživatel Karel volá, Wifi nejde] --> B(Zapsání do Tiketu - Incident)
    
    B --> C{Jde mu dát dočasný kabel?}
    C -- Ne --> E[Zkusit restart switche - Obnovila se Wifi - Uzavírám Incident jako OK]
    C -- Ano --> D[Uživatel je online kabelem - Obnovila se práce - Uzavírám Incident]
    
    E -. "Výpadek se opakuje znovu druhý den u Jany" .-> A
    D -. "Další tucet lidí z patra volá o výpadku wifi" .-> A

Dali jsme mu dočasný kabel a odbyli ho. Jenže pět dalších kolegů ho nemá s čím ho propojit a switch padá každý den kolem poledne. Máte velký a opakovaný incident, takzvaný Problem.

Problem Management: Jak najít skutečnou příčinu

Tady nastupuje detektiv (Problem Manager). Už ho nezajímá uživatel (ten dostal od Service Desku kabel). Problem Management se nesnaží hned teď obnovit funkčnost, snaží se nalézt Root Cause (RCA - Root Cause Analysis). Proč ten switch padá? Je moc starý? Ztrácí napájení? Nebylo provedeno nastavení po poslední aktualizaci firmwaru?

Když ho Problem manager identifikuje, zadá příkaz k vytvoření Change Request (Žádosti o změnu) (výměna za lepší a dražší hardware), vyzkouší se a po okně údržby se implementuje do produkce.

Závěrem: L1 a Service Desk (Incident Management) hasí oheň na stole. L2/L3 a Problem Manager zkoumá a opravujeme sporák s rozbitým detektorem plynů, aby oheň už v budoucnu nemusel nikdy vzniknout. Obě dvě oddělení se však potřebují stejnou měrou.