Joined: Sep 16, 2006 Posts: 3570 Location: London, UK
Posted: Tue Nov 20, 2007 10:01 pm Post subject:
I do see your point about scenario 1. And to be fair I agree with your not liking the answer to the scenarios
The change process like you said should not be a hinderance.
You also have to be practical when you are a change manager
The main reason the RFC was not created was that there was no change process at the time for standard changes like this piece of work. Instead, historically, they used the incident ticket.
All changes had to be approved. The work did not meet the requirement for an emergency change and the only other alternate was the full process which included a 3 day lead time.
The Emergency change request process was being highly abused 30-40%
So I either allowed the change as an Emergency change request or
allowed the standard change (non impacting of course) through the incident process - as there was not a change one at that particular time. _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Remeber ITIL is about services. Does the server reboot affect/have an impact on any services? If yes then change management unless its not actually working anyway then I guess incident management would pass to problem management who would re-boot if it was the right thing to do? I would see no need for change management as the service is affected anyway. After this problem management would have a known error but not the root cause which would take further investiugation, if a change is required to fix the root cause then a RFC would be required, urgency dependent on business impact.
If the service is running then the reboot could be carried out in the maint window defined within the SLA therefore no breach in SLA (via change management).
Joined: Feb 28, 2006 Posts: 411 Location: Coventry, England
Posted: Wed Dec 12, 2007 6:06 pm Post subject:
If you read our posts you will see that both John & I are talking about rebooting servers that form part of a service.
To pick up on part of your post - If a server forms part of a service (whether up or down), it is part of the live environment - therefore it comes under Change Management. It does not matter what state it is in, until it is retired and replaced it is still part of that service. I personally would disembowel anyone that attempted a Change of any kind on one of my live servers, even if that Change is a Change of state, without an RFC in place.
I see your point, I suppose it would go to change control (whatever) who do look after the final stages of error resolution including impact assesment.
Any high availability business critical servers should have redundancy (i.e. mirroring) so I guess the "high urgency" situation shouldnt occur and therefore standard change control should be ok.
If it has to go through emergency change control then the business should be informed and the SLA of that service discussed with the customer (and availabity management) to include higher availability.
All times are GMT + 10 Hours Goto page Previous1, 2
Page 2 of 2
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum