|
|
|
Kód úlohy
Standardní kód úlohy v MBI.
:
|
Autor návrhu úlohy
Jméno a příjmení autora úlohy
:
|
Datum poslední úpravy
Datum poslední úpravy úlohy ve tvaru rrrr.mm.dd.
:
|
Předpokládaná pravděpodobnost užití v praxi
Předpokládaná pravděpodobnost užití úlohy v praxi, hodnoty 0 - 1. Např. 0,7 - úlohu lze využít v 7 z 10 podniků. Hodnoty jsou průběžně testovány a upřesňovány na základě anket a průzkumů.
:
|
|
|
Charakteristiky úlohy
1. “Řízení incidentů“ – cíl, účel
- Úloha řízení incidentů
se zabývá správou všech incidentů
, které nastanou v provozu IT v průběhu jejich celého životního cyklu.
-
Incidentem se rozumí jakékoliv neplánované přerušení, či snížení kvality
poskytované služby.
- Hlavním
cílem
úlohy je
obnovení úrovně poskytované služby
, v co nejkratším možném čase, aby byl omezen dopad incidentu na uživatele.
2. Obsah úlohy
- Obsahem úlohy je
definice a aktivní využívání postupu pro identifikaci, zaznamenávání, prioritizaci řešených incidentů
. Jako vstupu pro prioritizaci incidentu se využívá hledisek časové urgence a závažnosti dopadu na službu.
- V průběhu řešení incidentů technickými týmy
musí být koncoví uživatelé srozumitelně a v pravidelných intervalech informováni o postupu a předpokládaném časovém odhadu
do vyřešení incidentu.
- V případě nutnosti
může být incident eskalován
, na základě jasně stanovených pravidel pro funkční a hierarchickou eskalaci.
-
Pracovníci
odpovědní za řešení úlohy, by měli
využívat databázi známých chyb
a disponovat technickou dokumentací ke svěřeným systémům. V rámci úlohy může dojít
ke stanovení postupu k řešení závažného incidentu
.
-
Vstupním bodem pro informace o nastalých incidentech
, mohou být monitorovací nástroje a hlášení koncových uživatelů informujících pracovníky provozu některým z běžně využívaných informačních kanálů. (osobně, telefonicky, mailem, prostřednictvím portálu služeb).
5. Metriky, dimenze, aplikace využívané v úloze
- Celkový počet incidentů – ukazuje na celkové vytížení služby.
- Počet incidentů čekajících ve frontě – umožňuje identifikovat, jestli není proces přetížen, či zda nemá nějaká další úzká hrdla. (nejasné odpovědnosti, dlouhá doba potřebná k funkční eskalaci apod.).
- Počet incidentů s opakující se příčinou – vysoký počet opakujících se incidentů ukazuje na nefunkční či neefektivní správu problémů.
- Počet incidentů, u kterých byla nutná funkční eskalace – umožňuje posoudit, na kolik jsou pracovníci první úrovně podpory samostatně řešit nastalé incidenty.
- Počet znovuotevřených incidentů – ukazuje na kvalitu nalezených řešení.
- Podíl počtu incidentů založených na základě zprávy z monitorovacího systému v % – příliš nízký podíl může poukazovat na špatně nastavené monitorovací nástroje.
- Průměrná doba řešení incidentu podle priority – umožňuje zjistit, jak průměrně rychle jsou vyřešeny jednotlivé typy incidentů, a to například porovnat se smluvenými časy.
- Podíl jednotlivých skupin incidentů podle jejich přiřazené priority v % – výrazně nerovnoměrné rozdělení, může poukazovat na špatně prováděnou prioritizaci incidentů.
- Počet incidentů zapříčiněných implementovanou změnou – může být vstupem pro prověření kvality vývoje a správy změn.
- Spokojenost uživatelů – kvalitativní metrika, měřitelná například průzkumem spokojenosti za pomoci ankety.
6. Vztahy k IT úlohám
- Správa událostí – správně definovaná správa událostí je jednou z podmínek toho, aby byly včas řešeny nastalé incidenty, a tím tak omezuje jejich dopad na uživatele.
- Správa problémů – opakující se incidenty se stejnou, nebo podobnou příčinou by měly být řešeny v rámci správy problémů.
- Správa změn – pro vyřešení incidentu může být nezbytné implementovat změnový požadavek, pokud je zapotřebí měnit jakkoliv konfiguraci (v případě aplikací to může být třeba změna části programového kódu), na druhou stranu implementace špatně připravených změn může stát za incidenty.
- Správa IT infrastruktury – některé incidenty nelze vyřešit jinak, než prostřednictvím odstraněním jejich infrastrukturní příčiny.
7. Podmínky úspěšnosti úlohy
- Existence útvaru plnícího roli service desku,
- Jasně definované normální provozní stavy,
- Využívání nástrojů pro evidenci incidentů,
- Správně nastavený monitoring všech částí IT infrastruktury,
- Definovaný systém pro funkční a hierarchickou eskalaci incidentů,
- Dobře definované OLA,
- Jasná pravidla pro posouzení dopadu a urgence incidentů,
- Existence znalostní báze (databáze známých chyb, manuály),
- Stanovená pravidla pro obsah a formu komunikace s uživateli.
8. “ Řízení incidentů“ - klíčové aktivity
-
Identifikace a zaznamenání incidentu
– nově vyvstalá situace je vyhodnocena jako incident a zaznamenána v podobě tiketu do nástroje pro řízení incidentů.
-
Klasifikace a prioritizace incidentu
– dochází k určení, jaká a jak velká část IT infrastruktury byla zasažena a na kolik důležité je vyřešení incidentu v čase.
-
Vyšetřování a diagnóza
– přidělený pracovník, či tým zjišťuje příčinu incidentu, o průběhu vyšetřování je informován uživatel.
-
Eskalace incidentů
– v případě, že znalosti pracovníka první linie podpory nestačí, dochází k funkční eskalaci, incident je předán k řešení dalším specialistům, u některých obzvlášť závažných incidentů může dojít k hierarchické eskalaci incidentů, kdy jsou o situaci informování nadřízení manažeři.
-
Nalezení řešení
– podařilo se odstranit příčinu incidentu, nebo alespoň obnovit funkčnost služby za pomoci workaroundu.
-
Uzavření incidentu
– tiket incidentu je formálně uzavřen poté, co je ověřeno, že již dále nemá dopad na poskytovanou službu.
|
|
|
|