Publikováno: 18. 2. 2007
Je možné/přípustné Incident vyřešit Změnou (RFC), aniž by byl zalogován Problém. Příkladem budiž Incident – stížnost zákazníka na špatnou funkci aplikace a lze ji opravit pouze změnou kódu aplikace. Prosím případně o rozebrání rizik a výhod tohoto postupu.
ODPOVĚĎ
Odpověď Vladimíra Kufnera
Aniž bych si činil nárok na to stoprocentně vykládat ITIL, moje odpověď zní takto:
Obecně platí, že na jakýkoliv Incident, který vyžaduje provést nějakou změnu v infrastruktuře (typicky např. replacement komponenty, která mění sériové číslo) je možné a podle mne i žádoucí rovnou registrovat Změnu bez toho, aniž by se musel nutně předtím registrovat Problém. Takto to definuje a uvažuje i procesní model v knize SS. Podmínka pro takovýto postup je pouze jediná, musí být zřejmá “známá chyba”. Zjednodušenou alternativou, kterou jsme ve své praxi také viděl, je přímé provedení změny procesem Incident management bez nutnosti jít na ChM (podmínkou je, že se jedná o standardní/rutinní změnu, u které není nutné schvalování). Tomuhle se v ITIL říká delegování menších změn na ServiceDesk/Incident management – v publikacích ITIL to není, spíše v praxi firem jako je třeba Pink Elephant. Obecně bych takovýto postup doporučil v případě spíše infrastrukturních chyb a nikoliv chyb v SW.
U SW to podle mého názoru záleží na okolnostech. Pokud si např. stěžuje zákazník České spořitelny na opakovaně (tedy ne jednou, to by byl Incident management) nefunkční Internet Banking, může to být ve finále způsobeno celou řadou okolností (včetně koncového uživatele) , resp. celou řadou jak HW, tak i SW prvků. To pak vyžaduje monitoring, adekvátní analýzu atd. Tedy typický “abonent” na Problem management.
Stejně tak to může být v případě, že jde o evidentně zreprodukovanou chybu – tedy disfunkci SW v případě, kdy ale k chybě dochází pouze v určitém čase, v určité lokalitě, u určitého zákazníka nebo pokud není úplně jasné, v které části SW se chyba vyskytuje apod. I zde bych osobně doporučil řešit formou PrM, neboť zpravidla je nutné provést rozsáhlejší analýzu. Umím si nicméně představit, že pokud jde o chybu, která se vyskytuje naprosto pro všechny zákazníky jednotným způsobem a je elementárně jasné, kde se chyba/bug vyskytuje, je možné řešit pouze v rámci ChM. Chci v této souvislosti nicméně upozornit, že pokud se bavíme o SW, hraje zde roli ještě jeden proces a to Release management. Všechny tyto opravy SW by se měly provádět pokud možno v rámci pravidelných “releasů”, pokud to tedy tedy jejich urgence dovoluje (pokud nikoliv, řeší se jako Emegency changes, resp. emergency hot fixes, jak se praví v knize SS).
Chci ještě zůraznit, že tady se jedná o procesní přístup, který sice vypadá na složité rozdělování aktivit, ale ve finále může např. vypadat tak, že to ve skutečnosti řeší stejní lidé (vývojáři), kteří nejprve lokalizují známou chybu, určí pracnost (náklady) a závažnost a předpokládané časové provedení (PrM) a pak mohou předat ChManagerovi, resp. Release managerovi, kteří pak koordinují implementaci (kterou ve finále mohou dělat opět lidé, kteří to předtím řešili v rámci PrM).
Ve většině firem, které mají vlastní vývoj, se kterými jsem se ve své praxi potkal,se to takto nerozdělovalo, ale řešilo to rovnou a okamžitě. Ale to není vždy jednak možné (např. outsourcing vývojářů, kdy se musí poměrně komplikovaně specifikovat zadání i na úplnou drobnost či SW zajišťovaný třetí stranou) a jednak žádoucí (např. nejsme ochotni platit náklady za změnu, nemáme zdroje pro změny s nízkou prioritou, popř. se jedná o chybu v očích zákazníků, ale nikoliv třeba Release managera, který to naopak může považovat za “žádoucí” formu chování) a jednak může vést k enormnímu množství urgentních změn (neformuje se do Releasů).
Odpověď Jiřího Skály
V otázce je jako příklad uváděna situace, kdy si zákazník stěžuje na špatnou funkci aplikace, kterou lze odstranit pouze upgradem. Za určitých okolností takováto událost vůbec nemusí být kvalifikována jako incident, ale jako záruční, resp. pozáruční vada, a to v případě, kdy aplikace tuto požadovanou funkčnost neposkytovala nikdy, tzn. aplikace byla chybně vyvinuta, resp. testována –> v takovémto případě je nejlepší vystavit rovnou RfC, tedy stejně, jako kdyby zákazník požadoval novou funkcionalitu, a jediný rozdíl bude v tom, že za toto RfC nebude platit (pokud se jedná o záruční vadu). Záleží ale samozřejmě na konkrétních okolnostech a jejich posouzení.
Pro úplnost vysvětlení tohoto pohledu: definice incidentu je obecně známá, nebudu ji zde tedy opakovat, ale trochu ji přeformuluji: “incident je situace, kdy něco, co fungovalo, fungovat přestalo, anebo hrozí to, že to brzy fungovat přestane”. Z tohoto pohledu tedy není tento případ incidentem, tedy pokud je pravda to, že ta aplikace požadovanou funkčnost neposkytovala nikdy.
A ještě praktický pohled na věc: samozřejmě, že když se zákazník obrací na Service Desk s tím, že aplikace nefunguje, tak operátor rutinně zaloguje nový záznam (incident) a rozeběhne se klasický proces Incident Managementu, v němž se zjistí, že se jedná o záruční, resp. pozáruční vadu. V tom případě se záznam uzavírá s kódem uzavření “záruční, resp. pozáruční vada”, a vystavuje se nové RfC, které se posílá do procesu Change Management. Do reportu o dostupnosti, resp. spolehlivosti (tzn. počtu výpadků) služby, není tento záznam započítán, protože se v podstatě o incident nejednalo.
Štítky: Jiří Skála, Vladimír Kufner
Autor:: Kateřina Mrkvičková