Publikováno: 29. 4. 2011
V knize Service Operation na str. 49 je uveden seznam atributů, které je vhodné při zakládání incidentu vyplnit. Kam však zapsat, která služba nefunguje? Je to Incident Category? Pokud ano, znamená to, že Category tree je nadmnožinou Katalogu služeb ? Pokud chci vědět, kolik incidentů bylo hlášeno k příslušné službě, není lepší mít rovnou atribut “Affected Service”, kde si vyberu službu ze seznamu poskytovaných služeb ? Jaká je praxe v tomto ohledu?
ODPOVĚĎ
Podíváme-li se do knihy Service Operation jen o pár stránek dál, můžeme si také přečíst:
„Configuration Management provides the data used to identify and progress incidents. One of the uses of the CMS is to identify faulty equipment and to assess the impact of an incident.”
A to je z hlediska teorie klíč k odpovědi na Váš dotaz. Vazba incidentu na ovlivněnou službu (Affected Service) nemusí být jednoznačná – incidentem může být ovlivněna jedna nebo více služeb, v důsledku jednoho incidentu může být jedna služba nedostupná a jiné služby degradované do různé míry, incident může ovlivňovat služby katalogové (řízené v rámci SLA), ale také infrastrukturní (řízené v rámci OLA), atd. Popsat tyto potenciálně komplexní vazby jedním atributem incidentu tedy není obecně možné.
Nejflexibilnější model popisu vazeb ovlivněných služeb na incident je prostřednictvím konfiguračních položek. V rámci konfigurační databáze by měly být jako konfigurační položky vedeny prvky podstatné pro poskytování služeb a jejich vazby. Logický model konfigurační databáze by měl s využitím klasifikace konfiguračních položek a vazeb umožňovat analyzovat dopad na služby různého typu. Tento způsob však nemusí být nejpraktičtější. Předně velmi málo organizací udržuje spolehlivou, aktualizovanou a dobře strukturovanou konfigurační databázi. Předpokladem je rovněž využití sofistikovaných softwarových nástrojů pro podporu Service Desku, CMDB a pro reporting.
Řada referenčních modelů, které vychází z nejlepší praxe podle ITIL a konkretizují příslušné implementační postupy (např. i ve vztahu ke konkrétním podpůrným nástrojům), proto podobně jako navrhujete Vy, zavádí buďto atribut, nebo raději relaci na seznam ovlivněných služeb. Tento přístup nevyžaduje složitou údržbu stromů služeb a na základě manuálního výběru ze seznamu služeb jsou k dispozici cenné informace pro řešení incidentu i pro další analýzy v rámci různých procesů.
Nakonec komentář ohledně kategorie incidentu (Incident Category). Praktickým účelem tohoto atributu incidentu je především zvolit odpovídající postup řešení, tj. vybrat správné workflow umožňující co nejrychlejší vyřešení incidentu – zahrnující především správné přidělení incidentu řešiteli nebo řešitelské skupině, získání specifických dodatečných informací, prosazení příslušných eskalační postupů, atd. Tento atribut je proto spíše než se strukturou služeb spojený se strukturou organizace práce v rámci poskytovatele. Některé postupy řešení incidentů jsou na straně poskytovatelů organizovány podle technologií, jiné podle dodavatelů, jiné podle služeb apod., a tuto nejednotnost nutně odráží typická kategorizace incidentů. Při zavádění samoobslužných systémů pro registraci incidentů však tato praxe, výhodná z hlediska efektivního řízení řešení incidentů, přináší zjevný problém obtížné pochopitelnosti a srozumitelnosti takové kategorizace incidentů ze strany podporovaných uživatelů. Tento rozpor je pak prakticky řešitelný mapováním zjednodušených, laicky srozumitelných kategorií (vycházejících např. i z katalogu služeb) nabízených podporovaným uživatelům na kategorie incidentů používané na straně poskytovatele.
Štítky: Jaromír Šlesinger
Autor:: Kateřina Mrkvičková