Server Reboot - An RFC?

[UKVIKING]

Ed,

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

[scook2003]

Guys your all talking about servers!


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).

[Ed]

Hi scook2003

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.

Regards

Ed

[Mark-OLoughlin]

Hi,

"Remeber ITIL is about services". Correct and it also places big importance onthe CMDB which is made up of CI's - which are the very things that need to be rebooted.

Service may not be down but you still need to record the reboot - and use this as analysis to feed into problem management.Why are we continually getting the same problem?

Looking at the changes on this server we are having to reboot it twice a week. - and then the inestiagtion from Problem Management begins.
_________________
Mark O'Loughlin
ITSM / ITIL Consultant

[scook2003]

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.