Toto je objekt systému MBI.

MBI (Management Byznys Informatiky) je portál obsahující zobecněná řešení v řízení provozu a rozvoje IT, resp. podnikové informatiky.

Pokud máte zájem získat více informací o tomto objektu (vazby na další objekty, přílohy, apod.), ale i získat mnoho dalších užitečných materiálů, můžete tak učinit ZDE / (registrace je bezplatná).

Úloha : Řízení incidentů
Řízení incidentů
Kód úlohy

Standardní kód úlohy v MBI.

:
U731A
Autor návrhu úlohy

Jméno a příjmení autora úlohy

:
Tenzer, A. (KIT, VŠE)
Datum poslední úpravy

Datum poslední úpravy úlohy ve tvaru rrrr.mm.dd.

:
2017-06-16
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ů.

:
0.7
Charakteristiky úlohy

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).
3. Vstupy úlohy:
  • Katalog IT služeb (D111A ),
  • Provozní dokumentace (D711A ),
  • Analýza IT dodavatelů (D121A ),
  • Aplikační architektura (D053A ),
  • Technologická architektura (D054A ),
  • Softwarová architektura (D056A ),
  • Analýza stavu technologické infrastruktury (D233A ),
  • Plán rozvoje technologické infrastruktury (D235A ).
4. Výstupy úlohy:
  • Evidence incidentů a problémů a jejich řešení (D721A ),
  • Technická dokumentace sítě (D712A),
  • Katalog IT služeb (D111A ), aktualizovaný.
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.