Server reboot

Discussion forum dedicated to configuration management and ITIL
Post Reply
User avatar
hamiltr
Itiler
Itiler
Posts: 22
Joined: Sun Sep 28, 2008 8:00 pm

Tue Mar 16, 2010 11:47 am

We have a CMDB that populates all our Configuration Items and we record Config changes when changes to Config are made eg adding memory or installing upgrade software to server.
Does a server reboot constitute a Config change? thanks


User avatar
Timo
ITIL Expert
ITIL Expert
Posts: 295
Joined: Thu Oct 25, 2007 8:00 pm
Location: Calgary, Canada

Tue Mar 16, 2010 12:12 pm

Is the physical status of your CI a configuration attribute? If yes - then yes... if not - then no. And if yes, why does it matter? YOu should probably be considering how to control server reboots from the CM process perspective, i.e. so that you don't mess up other CIs or unsuspecting users offline in the middle of an important conf call or something like that.
User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Tue Mar 16, 2010 2:53 pm

hamiltr,

there are least two major threads that discuss this topic ad nauseam. Plus there are side-swipes at it in various other threads. All within the last two years (there's older stuff as well, but it will not have had the benefit of my prejudiced opinion on the matter.

The bottom line is that I can find people here who will explain in great detail why it absolutely must be a change, and others who will explain that in very few circumstances should you even consider making it a change, and in the end anyone can tell you that you have to decide what is right for you anyway.
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
User avatar
hamiltr
Itiler
Itiler
Posts: 22
Joined: Sun Sep 28, 2008 8:00 pm

Wed Mar 17, 2010 5:57 am

We have a CI attribute of status which shows whether it is in stock, live or retired etc but nothing to show availability whether it's up or not. We are using the process to control this but our tool that we using is the evidence that the actuals satisfy the evidence from the process ie detail within change records.
I am interested to know whether reboots can be automatically calculated somewhere from the CMDB as I don't see any attribute that resembles this measure.
Would you suggest that we had to measure reboots manually through the process rather than measuring some relevant attribute pertaining to reboots within the CMDB?
thanks
User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Wed Mar 17, 2010 6:25 am

hamiltr,

in your first post you seemed to be asking about whether reboots were changes, which I interpreted to mean do you need to manage each reboot via your change management process. Now you seem to be talking about counting reboot records.
We are using the process to control this
Which process are you talking about?
What is "this" that you are controlling? - the reboot, the reboot data, the "change",...?

Somewhere you will keep a record of when a server goes down or is taken down and a record of when it is rebooted. ITIL doesn't really care if this is in your CMDB or your incident log or your event log or your server log or anywhere else. You care - that is why you are asking the question.

The answer is don't worry about ITIL, worry about practicalities. Keep the information somewhere it is easy to put it and easy to access it for whatever purposes of reporting or analysis you have and in a manner that allows you to control the quality of the information (its accuracy, reliability, completeness, timeliness, auditability)

If your CMDB tool does not lend itself to this kind of usage then you either replace the tool with one that meets your requirements or you record the information elsewhere. The choice is probably a no-brainer unless either the CMDB is useless for other things as well, or you have pots of money and spare time floating around.
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
User avatar
Tomahawk
Itiler
Itiler
Posts: 11
Joined: Sun Feb 11, 2007 7:00 pm
Location: Kent UK

Tue Apr 06, 2010 6:40 am

As Change Manager my rule of thumb is :

If a server reboot is required to change an attribute of the CI then an RFC is required and linked to the CI in the CMDB

If a reboot is required to correct a fault but no changes are being made then the reboot should be tracked against the recorded Incident and linked to the CI in the CMDB.

The important thing is to ensure users affected are informed in advance of the planned outage and the activity is recorded against the CI.
User avatar
paulfixter
Senior Itiler
Senior Itiler
Posts: 36
Joined: Sun Dec 21, 2008 7:00 pm
Location: Wakefield, West Yorkshire, UK

Thu Apr 29, 2010 9:42 am

Tomahawk wrote:As Change Manager my rule of thumb is :

If a server reboot is required to change an attribute of the CI then an RFC is required and linked to the CI in the CMDB

If a reboot is required to correct a fault but no changes are being made then the reboot should be tracked against the recorded Incident and linked to the CI in the CMDB.

The important thing is to ensure users affected are informed in advance of the planned outage and the activity is recorded against the CI.
I'd say that was spot on and exactly how I would do it 8)
User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Fri Apr 30, 2010 4:26 am

Tomahawk wrote:If a server reboot is required to change an attribute of the CI then an RFC is required and linked to the CI in the CMDB ...
If you are changing an attribute of a CI then you should already have a change request in process long before you get ready for the reboot which is just a step in the implementation of the change.

As I think you said, if you reboot to correct a fault then you should already have an incident or problem record open for that fault. The important thing now is to ensure that there are no other consequences of the reboot (perhaps from latent changes), and for this reason I advocate having a formal reboot procedure to follow.
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Post Reply