ITIL incident managent

[Droned]

Ik weet niet of dit het juiste topic is maar ik weet niet waar anders te plaatsen. Het gaat over itil.

De volgende zaken zijn mij niet echt duidelijk :

• Je hebt problem management en incident management. Bij problem management ben ik zeker dat er van dat wanneer het probleem zich voordoet er gezocht wordt naar de oplossing en dan een request for change wordt ingediend en via change management deze request wordt afgehandeld. Het probleem is dan opgelost en de eventuele wijzigen zitten dan ook in de CMDB.
  
  Nu als er een incident voorvalt, wat de normale werking van het systeem onderbreekt zonder herkende oorzaak, moet er als er een oplossing gevonden wordt ook een request for change worden uitgevoerd of mag dit onmiddellijk gebeuren, want het incident moet volgens mij toch zo snel mogelijk worden opgelost.
• Nog andere onduidelijkheid zit mij in het verschil van continuity management en availability management, wat is hier juist het verschil tussen?

[TRON]

Incident Management draagt simpel gezegd zorg voor het zo snel mogelijk herstellen van de verstoorde dienstverlening. Bij het herstellen van een verstoring is het niet noodzakelijk om een change in te dienen. Ga je echter zaken wijzigen in de infrastructuur, applicatielandschap (bijvoorbeeld een patch), dan dien je gebruik te maken van Change Management. Hiervoor kan je dan de welbekende Urgent Change voor gebruiken.

Continuity Management zorgt ervoor dat je je bedrijfsprocessen zo snel mogelijk weer kan gebruiken (op de juiste prioritering) na bijvoorbeeld een calamiteit. Availability Management draagt zorg voor wanneer welke functionaliteit / dienst beschikbaar moet zijn (bijv. maandag t/m vrijdag van 8:00 tot 17:00).

[NMe]

ITIL is een verzamelnaam voor bedrijfsprocessen, geen programmeerprocessen. Ik denk dat je vraag in Werk en Inkomen meer tot zijn recht komt.

SEA>>WI

[PHiXioN]

Incident Management is een proces ingericht om incidenten te detecteren en binnen de afgesproken termijn op te lossen.

Als je je incidenten juist registreert (classificatie, prioriteit, moment van oplossen) en/of monitort op belangrijke indicatoren is Problem Management mogelijk. Dat is een proces waarbij informatie met betrekking tot incidenten analyseert om zo de oorzaak van de incidenten (het onderliggende probleem) op te kunnen lossen. Helemaal mooi is proactief Problem Management, waarbij problemen worden gedetecteerd voordat er een incident heeft plaatsgevonden.

Wat ik in de praktijk vooral merk is dat Incident en Problem Management zich bij alles behalve de grootste bedrijven vooral beperkt tot het dweilen met de kraan open.

[NMe]

PHiXioN schreef op dinsdag 26 januari 2010 @ 11:09:
Wat ik in de praktijk vooral merk is dat Incident en Problem Management zich bij alles behalve de grootste bedrijven vooral beperkt tot het dweilen met de kraan open.

Oh, je bedoelt van die bedrijven waarmee je dit soort gesprekken kan voeren?

Wij doen aan ITIL!
- Oh, leuk. Welke onderdelen hebben jullie in je bedrijf geimplementeerd?
Uhm....?
- ITIL is een verzamelnaam, voor kleinere bedrijven is het alleen maar handig om al die processen in te voeren.
...

[Wijnands]

Wat je in de praktijk vaak ziet is dat een problem opgestart wordt als er uit een (of meestal meerdere) incidenten blijkt dat er fundamenteel iets mis is. Een change kan zowel uit een problem voortkomen als uit een incident. Bij een dringend, productie verstorend, incident kan het goed voorkomen dat het eerst opgelost wordt en dat pas later een change aangemaakt wordt en meteen weer afgesloten.

[riddles]

Binnen de organisatie moet er inderdaad afgesproken worden voor welke acties er een change nodig is. Soms is bijvoorbeeld voor de herstart van een proces of een server wel een change nodig (dit kan immers leiden tot onbeschikbaarheid), maar soms ook niet. Voor echte wijzigingen (configuratie / software aanpassingen) is natuurlijk altijd een change nodig.

Ook of voor een directe actie om een incident op te lossen eerst een urgent change ingevoerd moet worden en daarvoor ook goedkeuring gezocht dient te worden, of dat eerst de actie uitgevoerd mag worden en de urgent change achteraf ingevoerd kan worden, is een afspraak die per organisatie kan verschillen.

In het verleden heb ik wel eens een volledige internetbankieren omgeving (van een niet nader te noemen bank) onderuit geholpen door de tijd op een enkele server goed te zetten (die liep een uur achter, wat tot problemen in de logfiles leidde). En inderdaad, die change had ik niet ingevoerd

[PHiXioN]

riddles schreef op dinsdag 26 januari 2010 @ 14:58:
In het verleden heb ik wel eens een volledige internetbankieren omgeving (van een niet nader te noemen bank) onderuit geholpen door de tijd op een enkele server goed te zetten (die liep een uur achter, wat tot problemen in de logfiles leidde). En inderdaad, die change had ik niet ingevoerd

Hebben ze je gepakt? ;-)


Wat je ziet is dat veel organisaties changes wel registreren, maar het puur als workflowtool zien. Zeg maar een soort van to-do-list om te zien wat er open staat. Degelijk change management gaat een stap verder.

Eerst moet je gewoon in kaart hebben wie changes mag aanvragen. Als elke Jan Doedel de helpdesk kan bellen met de vraag een bepaalde update query te runnen, of parameter aan te passen, weet je nog niet of deze change wel gewenst is. Dan moet voor elke change worden beoordeeld wat de impact is en de prioriteit. Op basis van deze beoordeling moet worden bepaald of en hoe deze getest moet worden. Stel iemand verantwoordelijk die mag bepalen of changes in productie mogen worden doorgevoerd. Idealiter wordt alles eerst in een separate omgeving getest, tenzij is beschreven dat bepaalde acties geen kwaad kunnen. Dit is helaas niet altijd mogelijk.

Als laatste, leg al bovenstaande stappen vast!! Een informele changeprocedure kan niet worden getoetst, dus weet je nog niet of je wijzigingen werkelijk op een gecontroleerde wijze doorvoert. Daar hoef je geen dure tool voor te kopen, een goed ontworpen excel spreadsheet voldoet ook als je een kleine organisatie hebt.

Aangezien mijn werk soms van mij vraagt dit soort processen te beoordelen erger ik mij kapot aan situaties waarbij je niet de indruk hebt dat er maar wat wordt aangeklooid, maar dat je niet kan vaststellen dat men de boel beheerst. Als hoofd van een IT-afdeling zou ik ook liever in control zijn op basis van feiten dan goed vertrouwen.

[Wijnands]

Nadeel van bovenstaande is dat het enorm veel tijd kost om goed in te regelen en de nodige discipline om het goed te houden. Wat je dus in de praktijk vrij vaak tegenkomt is dat men het halfslachtig doet vanwege kosten.