Řízení incidentů z pohledu metodik

Zvolená skupina úloh spadá do oblastí řízení provozu podnikové informatiky. Tato oblast je rozdělena do dvou skupin úloh – řízení a správa zdrojů podnikové informatiky a řízení incidentů, problémů a požadavků v informatice. Skupina vybraných úloh, které jsou v tomto článku zmíněny, zajišťuje řešení chybových stavů a požadavků v technologické infrastruktuře, a také požadovanou úroveň konzultační i technické podpory uživatelů. Článek u každého z těchto procesů porovnává dostupné metodiky (např. ITIL, COBIT a další) a diskutuje nad vhodností jejich aplikace.

 

Vybrané úlohy jsou součástí operativního řízení provozu podnikové informatiky, konkrétně s řízení incidentů, problémů a požadavků v informatice, jehož součástí jsou mimo jiné i další úlohy jako řízení help-desku, řízení změn a řízení uvolnění a nasazení. Jak ukazuje obrázek, celý soubor úloh spolu velice úzce souvisí.
Jednotlivé normy a metodiky zabývající se těmito procesy, obohacují celý systém o svůj pohled na dané řešení a de facto se doplňují, což prospívá pochopení problematiky.

Například norma ISO 20000 velmi úzce souvisí s procesním rámcem ITIL, protože shrnuje jeho základní postupy do standardizovaných kritérií. Samotná norma ovšem obsahuje jen nejzákladnější informace o jednotlivých procesech. Detailnější informace jsou obsaženy právě v  ITILu, ačkoliv v něm scházejí části týkající se například řízení IT projektů.
Tyto chybějící části doplňuje CobiT, který představuje auditní a řídící rámec, pomocí kterého je možné propojit strategické řízení podnikové informatiky s požadavky businessu. CobiT je ale především určen k odhalení chyb v procesech, ale neříká nic o tom, jak je navrhovat a implementovat.

Posledním zdrojem, který se zabývá vybranými procesy, je norma ISO/IEC 27035, která se věnuje postupům detekce incidentů, jejich hlášení a vyhodnocení včetně následné reakce. Pomocí této normy je možné přijmout preventivní a nápravná opatření.

procesy

Řízení incidentů

Incident management, česky řízení incidentů, je součástí operativního řízení provozu informatiky a klade si za cíl efektivní a co možná nejrychlejší řešení incidentů, a zlepšoval tak dostupnost služby či systému. To s cílem, aby se uživatel systému, ať už interní či externí mohl věnovat své práci, v rámci které využívá danou službu či systém. U interních uživatelů jde především o efektivitu práce, která je snížena díky incidentu, a proto snaha o co možná nejrychlejší řešení incidentu. U  externích uživatelů pak je v sázce spokojenost uživatele potažmo pověst firmy a zisk firmy. Je tedy zřejmé, že zákazníkem procesu jsou uživatelé služby či systému. V rámci řízení incidentů se evidují incidentu, a to s cílem budovat znalostní bázi pro další řešení incidentů a problémů. Dalším cílem řízení incidentů je i reflexe poznatků získaných při řízení incidentů a vylepšení firemních metodik a postupů.

Definice řízení incidentů

Incident, tak jak ji definuje metodika ITIL, je neplánované přerušení nebo pokles kvality IT služby, nebo výpadek části systému, který nemám vliv na IT službu. Řízení incidentů je pak způsob zpracování jednotlivých incidentů, tedy nalezení řešení a evidence incidentu. S řízením incidentů je velice úzce spjato i řízení problémů, viz další kapitola. Zde je však nutné uvést, že incident je chápán jako projev nějakého problému a opačně problém může způsobovat více incidentů. Proto je třeba rozlišovat řešení incidentu a řešení problému. Řešení incidentu je náhradní řešení, tzv. workaround, tak by uživatel mohl provést požadovanou činnost. Zatímco řešením problému je odstranění příčiny problému.

 

Příklad: incident je, když je nefunguje tiskárna správně a problém potom může být nedostatek toneru. Řešením incidentu je pak například použití jiné tiskárny. Řešením problému je pak výměna toneru.

Proces řízení incidentů

Životní cyklus řízení incidentů je dle jednotlivých metodik (ITIL, COBIT) velice podobný. Skládá ze z následujících aktivit:

  • Založení incidentu - Identifikace - Klasifikace - Prioritizace
  • Vyšetření incidentu - Eskalace
  • Uzavření incidentu - informování/akceptace uživatelem - Vytvoření reportu

Proces se u jednotlivých metodik liší drobnými nuancemi jako je pojmenováním aktivit, ale liší se také v zásadních věcech. Metodika ITIL na rozdíl od CobiTu nedefinuje poslední aktivitu vytvoření reportu pro management. Standard ISO/IEC 27035 definuje životní cyklus řízení incidentů v 5 fázích (Plánování a příprava, Detekce a reporting, Posouzení a rozhodnutí, Odpověď a poslední fáze Poučení). Tyto fáze jsou srovnatelné s aktivitami dle CobiTu. Dále poslední v poslední fázi dle CobiTu není exaktně řečeno, že se jedná o poučení z incidentu ale pouze vytvoření reportu.

Proces řízení incidentů začíná založením incidentu. Založení incidentu může být automatické či manuální. Automatické vytvoření incidentu je doménou automatických monitorovacích nástrojů (event management), které detekují změny stavů a předcházejí tak výpadkům IT systémů. Metodika ITIL se Event managementu věnuje obšírně, zatímco COBIT se tomuto tématu příliš nevěnuje. O manuální založení incidentu se pak stará operátor help-desku na základě hlášení incidentu od uživatele, nebo správce systému na základě reportů z provozu systémů (sítí, aplikací či databází). Založením incidentu je myšleno prvotní evidence, parametry, které mohou být evidovány, definuje metodika ITIL. Standard ISO/IEC 27035 definuje možné evidované parametry, tento výčet je však stručný a nedostatečný. Metodika COBIT nedefinuje žádné parametry.

Vstupem pro řízení incidentů jsou tedy protokoly ze správy systémů a protokoly o provozu help-desku. ITIL jako další vstup definuje výstupy z event managementu. Standard ISO/IEC 27035 se vstupy procesu nezabývá. Oproti tomu COBIT specifikuje vstupů vícero, dalšími vstupy jsou reporty z řízení problémů, tzv. Incident ticket SLA. Co se týče vstupů pro řízení incidentů je COBIT více komplexní, což je velice zřejmé na příkladu SLA jako vstupního dokumentu, protože incident management ze své definici zajišťuje právě obnovení služby do normálního stavu definovaným právě v SLA. Dalšími důležitými vstupy jsou aplikační architektura a technologická architektura, protože např. v případě poruchy na serveru je nutné znát jeho umístění, apod. Důležitým podprocesem založení incidentu je prioritizace, tedy přiřazení priority incidentu, tak aby byly upřednostňovány důležité incidenty. Za přidělení priority by měl být zodpovědný správce incidentů či podobná role, nikoli uživatel, protože pro uživatele je každý incident ten důležitý. Metodika ITIL definuje systém priorit podle stupně závažnosti incidentu a jeho dopadu na službu či systém, tento systém je znázorněn na Tabulka 1- Definice priority incidentu. Podle toho také určuje dobu řešení incidentu,viz Tabulka 2 - Čas na řešení incidentu podle závažnosti.

 

Vliv na službu či systém

 

 

Vysoký

Střední

Nízký

 

 

závažnost

Vysoká

1

2

3

Střední

2

3

4

Nízká

3

4

5

 

Kód priority

Popis

Čas na řešení

1

Kritický

1 hodina

2

Vysoký

8 hodin

3

Střední

24 hodin

4

Nízký

48 hodin

5

Plánovaný

plánováno

K procesu vyšetřování incidentu patří i institut eskalace incidentů. Jedná se skrze praktickou metodu. A to za účelem optimalizace nákladů. Idea je taková že pokud pracovník přiřazený na vyřešení incidentu nemá například dostatečné technické znalosti, tak incident eskaluje na jiného pracovníka, který má hlubší technické znalosti. Pokud nestačí ani znalosti druhé úrovně je možné eskalovat incident dále a pak se do řešení incidentu může zapojit například i dodavatel SW či HW. Eskalace se pochopitelně řídí jasně danými pravidly a neznamená to, že by si mezi sebou pracovníci navzájem přehazovali. Jak již bylo uvedeno, cílem tohoto principu je optimalizace nákladů, jelikož čím hlubší znalosti jsou vyžadovány, tím dražší je práce pracovníka.

Proces samotného řešení incidentu ohlášeného uživatelem začíná právě u pracovníka help-desku. V případě, že je pracovník help-desku okamžitě nalezne řešení a ověřit s uživatelem jeho akceptaci, je incident rovnou uzavřen. V opačném případě je třeba přistoupit k eskalaci. Po nalezení řešení musí být toto řešení korektně zaevidovány k příslušnému incidentu.

Závěrečnou skupinou aktivit v procesu řízení incidentů je uzavření incidentu. Součástí procesu uzavírání incidentu je informování uživatele a předání řešení, dále pak ověření jak byl uživatel s řešením spokojen (akceptace) a samozřejmě formální uzavření incidentu. Metodiky ITIL a COBIT jsou v procesu uzavírání incidentu kompatibilní a definují výše popsané aktivity. Akceptace řešení uživatele, tedy ověření jak je uživatel spokojen v praxi probíhá buď telefonicky či emailovým dotazníkem. V praxi se také využívá automatického uzavření incidentu, a to v případě pokud uživatel po zaslání řešení nekontaktuje help-desk do určité doby například 2 pracovní dny. V tom případě pak musí být možnost znovu otevřít incident pro případ pozdějších problémů.

Výstupy z procesu řízení incidentů jsou evidence incidentů včetně řešení incidentu, tato evidence je základní vstupním elementem řízení problémů. Výstupem procesu je i založený nový problém, nebo přiřazení incidentu k již existujícímu problému.

Incident management je primárně kompetencí help-desku, podrobnější definici rolí však metodika ITIL nespecifikuje. Standard ISO/IEC 27035 také nespecifikuje jednotlivé role. COBIT definuje RACI společně pro jednotlivé procesy řízení incidentů, kde také specifikuje, jaké role do procesu řízení incidentů vstupují. Jinou definici rolí můžeme vidět v RACI matici pro řízení incidentů, tak jak ji definuje nástroj BSM od firmy HP.

Metriky a CSF 

Součástí řízení incidentů je i monitorování metrik pro posouzení efektivnosti celého procesu. Metodiky ITIL či nástroj BSM (HP, 2009) definují konkrétní metriky. Metodika COBIT pojímá metriky lépe, nejprve definuje cíle (procesu, IT) a k nim definuje metriky.

ITIL definuje jednotlivé faktory úspěchu - CFS pro řízení incidentů.

  • Správně fungující help-desk (service-desk)
  • Jasně definované normální provozní stavy služby či systému dle SLA
  • Integrace nástrojů pro podporu řízení incidentů (ticketovací a sledovací nástroje)
  • Dobře definované OLA

K uvedeným bychom mohli přidat:

  • Hromadění incidentů
  • Existence znalostní báze

Z dalšího srovnání metodiky vyplývá, že COBIT verze 4.1 jako jediný definuje, jak by měla vypadat zralost procesu dle modelu CMM (Capability Maturity Model), verze 5 již zralost procesu nedefinuje. Závěrem bychom ještě rádi zmínili normu ISO/IEC 20000, jenž se také zabývá řízením incidentů, resp. jej zmiňuje jako požadavek pro certifikaci dle této normy a velice lehce zmiňuje klíčové části procesu řízení incidentů.

Jak již bylo uvedeno výše s řízením incidentů je spjato i řízení problémů, o něm více v následujícím článku.

 

Share

Počítač ENIAC z roku 1946
IBM PC z roku 1981
Datacentrum - "skladiště" cloudových služeb