How do you do it

[tink43]

We are in the process of rewritting our policies and procedures for change management. I have 2 questions.

1.) Would you consider a standard reboot a RFC?

2.) Should you have timeframes associated with your classification of a change. For instance if you have a high impact change- should you require a 2 week lead time from when the RFC is entered? We currently do it that way and was just curious how other companys were doing it.

Thanks

[UKVIKING]

In answer to your question on a reboot

Why is the server being rebooted ?

If it is part of a solution to an incident no.... because it does not change the configuration and since the service may not be 100%, the reboot is part of the incident recovery plan

If the server is being rebooted and the service is 100% at the time .... first why is the server being rebooted ?

If it is part of a routine monthly maintenance or something like it; then the plan to do the work should go through the change management process

why ? you ask ... The reboot does not affect the configuration items.

The answer is the change management process is the best place to be the focal point for things like scheduled maintenance etc since the FSC and PSA are deliverable

FSC = Forward Schedule of Change
PSA = Projected Service Availability

Also, if there is a change which was approved, when it happens, the SD would say... ey this is the rgeular periodic reboot.


Also the same would apply if the reboot is not part of a regularly scheduled maintenance or an incident but a wild whim by an engineer.

This way you keep the wild whims under lock and key
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[tink43]

Thank you. That makes a lot of sense. I was thrown into Change management a couple of years ago and I haven't had any training except for the ITIL foundation and I really trying to make sure we get this right in the new policies and procedures.

[dsemeniuk]

I am not sure on the Rebooting of Server example.

I would think this would go through Change Management as you really need to understand the impact of rebooting a server. There could be other services running on that server that need consideration and should have proper review and approval before rebooting the server.

So I would like to see an RFC be submitted, depending on the urgency of course, after the fact RFC would suffice if it was an emergency, but still proper review and approval should be followed. I wouldn't want people just rebooting servers without proper authorization.

Does that make sense?

[UKVIKING]

dsemeniuk,

Look at the definition of Change Management - control the configuration items and the work which changes the configuration data of them.

A reboot does not change any configuration of a device it merely on/offs the device. Depending on the use of that device is whether the service & users notice it or not

If the service is already impacted by problems with the server, a reboot is a good incident recovery method - especially for Microsoft products

For ex:, a server has a Blue Screen of Death or just froze or the application running on it froze the system. A reboot would restore the server to an operational state.

It is kind hard to get diagnostics from a BSD'd machine -remotely.

So under a incident, a reboot is merely one of the steps to restore service. Since there was no configuration item attributes changes (Power on power off is not a attribute... it is a slogan for the Power Rangers !!!!), a change would not be necessary

Under the circumstances of rebooting the server every 8th day; this act is impacting the service (even Out of Hours) because the Service Desk monitoring team will notice it and if it takes longer than the alarm threshold, a incident ticket would usually be generated and then closed

However, in this case; the objective of pushing the regularly scheduled change is to assess and announce the risk, impact and justification for the silly (IMHO) task.
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[dsemeniuk]

I understand that in theory, we are not really changing anything on the server by doing a reboot but....what about its status?

You are really changing the status of that CI to Decomissioned, Down, or Under Maintenance, whatever you choose to use.

I know this one is very debatable and I am having a hard time not having control around somebody wanting to reboot a server.

If all of a sudden you get calls from other users saying what happened, I lost my connection, or I cannot access so and so, how are you going to know what "changed" to cause that incident?

[DanA]

If it is a planned reboot, we generally have them open a Change Request to track it and make it known to all. If it is part of incident restoration, then we just track it in the incident record.

[goitilcouk]

Our process:
Reboot - not a change unless the server was taken out of the farm/cluster as part of a problem, then an RFC is raised to re-introduce it

Regarding your second question, we operate a standard 8 day lead time for all changes (with the exception of standard = 3 days and emergency = immediate).

The part that changes based on the risk/impact is the process (ie approval cycle and wheter it goes to the CAB)

[jpgilles]

Back to my definition of a change, rebooting a server may be considered as a change

definition: "any action or operation modifying the nominal state of a component taking part in the provision or the delivery of a service"

If the normal status of a server is "up and running" then shutting it down is a change and needs to be evaluated in terms of impact, risk, ....

In addition, your server may be under supervision of some monitoring tools which may generate automated alerts when the server is shut down. That means that the requested operation is not only to reboot the server, but also, to turn off and on again some parameters within those tools (unless you do not care to bother people with an alert for a normal situation ...) : that is definitely a change... (basically 2 i a row).

best regards
_________________
JP Gilles

[CoolCat]

The way I see it - these need to be spereated into two scenario's (Categorised):

1 - A server freezes (BSOD) for whatever reason and needs to be rebooted to restore the service as quickly as possible (Incident Management). Users are down, there has been an impact.

2 - A planned reboot for maintenance etc... (Change Control) process to be followed. Users are working there is going to be an impact.

Thoughts...

[Ed]

Hi all

We actually treat this as a Standard Change. As a Change because taking the service away from the customer is a Change i.e. we are changing the status of a CI (the service) at this point from available to un-available and then back to available. As a Standard Change because it is a Change that is repeatable, and the risk/impact are known and understood.

Regards

Ed