Server Reboot - An RFC?

[Kerrie]

If a live server is required to be rebooted, with no changes being made, should an RFC be raised (either upfront or restrospectively) according to the ITIL process?

[Kyoanna]

Hmmm..... not an easy problem. I am not sure if there is ITIL definition of this kind of situations.
I suppose there is no need to raise an RFC, maybe it's better to register a planned Incident (or some planned Incidents - it depends on the server type), that there can be a problem with some services during or after the reboot.

[Mnsotapop]

I don't know if this is the "correct" way to do it, but we open a Service Call (we use HPservice desk) and then the manager for the server must ok the reboot

[Kerrie]

Thank you both for your replies, but in my opinion I do think an RFC should be raised. This will ensure that the correct Approval process is followed, plus everyone who should be notified will be.

But I would like to know whether this is inline with ITIL, or whether ITIL doesn't actually stipulate the process down to this level.

Can anyone else help?

Thanks.

[dboylan]

Per the ITIL definition, yes, a RFC should be submitted for a server reboot. An ITIL Change is defined as the change of status or attribute of a Configuration Item. Even if you don't have a formal CMDB, most people would agree that a server's status and attributes should be tracked.

Rebooting a server takes the status of the server from online to offline and then back to online.

I would hope that a mature Change Management process would handle this as a Standard (pre-approved) Change or a Minor (the Change Manager has the authority to approve) Change. Having every server reboot go to the CAB could needlessly weigh down the process.

[ARoll]

i agree with dboylan. if you are following the book word for word, yes a server reboot would have an RFC and is most likely situations a standard change. That being said, let's take a look at practical application. Given the level of maturity in which most organizations are currently at, going to this level is just not accomplished easily and there will be a fair amount of push back. In previous organization, a server reboot on its own was handled as a service call, if it were a reboot as apart of a formal change it would be a task associated to that change. It does just depend on what level of detail your organization is currently handling, if within your cmdb you are tracking the online/offline status then yes will want to pursue the rfc route.
_________________
Adam
Practitioner - Release and Control
Blue Badge

"Not every change is an improvement, but every improvement requires a change"

[Mark-OLoughlin]

Hi,

A reboot should be controlled under change control. You are changing the state of the server and any applications etc. on that server from an "up" state to a "down" state" during the reboot causing potential outage or service disruption or possible performance issues.

If the server is in a clustered environ,ment you have a reduced possibility of service disruption but still it should be a change request due to the change in state of the CI.

i live in the real world and know that support teams will fight this and arguee the fact. So declare reboots as emergency changes (unless they
can be planned withing your change lead times).
Have the support teams call the change manager for all reboots
Have the Change Manager enpowered to approve the reboots - after a quick analysis or not to aprove if the impact is so high.
Change Manager then informs the Service Desk of the reboot and they can prepare for any potential calls that may come in.

I also look at it from a communications point fo view to ensure that all people know about the reboot that should i.e the change manager, the service desk, the support teams and then can deal with any issues that come out of it together.

[Jane]

Yes, you should definitely do an RFC as you are making a change to a production server.

[JoePearson]

This needn't be a complex question in one organisation - you just set the policy and go with it (managing your risk along the way). But I don't believe there's one standard answer for all organisations.

Here's something to think about: rebooting a server is not a change to the infrastructure. Everything is configured and operating exactly the same way afterwards as it was intended to work before. (Assuming you do it properly and restart all system services and applications.)

So it's more a question of what level of control you require, and at what cost in bureaucracy. If you've got cowboy sys admins, yes, force them through change control. If you have a case where a critical production server has crashed and the emergency change manager is not responding to messages ... don't wait.

[dboylan]

[Mark-OLoughlin]

Hi,

the reason I would put server reboots under change management it becuase whatever is running on that server may become unavailable during the reboot (clustered environments can be considered an exception if the apps that the users use are still available during a reboot - though you have to consider the capacity capability).

If the service or application on the server become unavailabe youare changingtheir state from a working state to a non working state and hence your change instate of a CI (Applications and services can be CI's)

The other reason (and the main real world reason) is for communication. Putting a server reboot under change control means that the Change Manager is aware and shouw advise (even by email) that a server reboot is about to take place. The service desk and IT management can be informed so that they can deal with any calls being reported or management queries. Also it allows for the service owners to advise their users of the situation.

However you can add a provision to your change management process to allow say the change manager to approve reboots on the spot (providing there is low impact) otherwise its an emergency change. This will make it less cumbersome but stil allow you maintain control and provide communication
_________________
Mark O'Loughlin
ITSM / ITIL Consultant

[Timo]

I agree with all the above posters that reboots should fall under change control. I think that RFC itself though is often mistaken for a complicated, time consuming document that requires time and effort to complete.

It could be the case, but it doesn't have to be. RFC's can take any form organization chooses them to be (not sure if ITIL prescribes anything specific).

Typically the need to reboot a server will arise either because of an incident (emergency change) or maintenance/support activity (normal/scheduled change). In case of a former, an RFC can be a phone call, email, or even in person communication with information about an incident to the change manager and/or ECAB.

In case of a latter, reboots would be reflected in FSC and have undergone regular CAB review and approval, unless it has been decided to pre-approve reboots, which I haven't seen anywhere yet.

So, to answer your question, yes, RFC is required. The difference is what form does the RFC take. Somebody please correct me if I am way off base here.

Thanks,

Michael

[thechosenone69]

Hi,

Very interesting topic. Well I disagree with some of you somehow. According to books I might be wrong but think of it this way. A customer calls saying that his server needs a hard reboot cause alot of users are having problem connecting to his server. How long its going to take you to approve this from the CM? Time is the enemy as they say. He can be losing alot of money-users untill you get the approvement for that reboot. I think the right way to do this is just logging it as a priority 1 incident. Call the customer to confirm the reboot. Then go ahead with it. Again this is just my point of view

Many Thanks,

Ali Makahleh

[UKVIKING]

My two cents.

First what is the purpose of the reboot ?

If the reboot is an action that is part of restoring service - ie part of an incident, then there is no real need to have a RFC for the work

If the reboot is not part of incident management, then the next questions applies is as follows

Why is the server being rebooted or restarted ?
Will the service availability be impacted ie will the customers & users see the reboot ?

I dont think that the power status - on or off - of any device should be a tracked Configuration Item attribute. The attribute - Power On or Power Off - really should not be tracked. There are better attributes to use - CI Lifecycle status for one - Installed, Delivery, Obsolete

Having said that, here are a couple of scenarios and how I would handle it
Scenario 1

There are 4 web servers in a web farm - the 4 web servers are a cluster of servers. The web sites are distributed via s/w and h/w over the 4 web servers. The 4 machines share the load. 1 server has to be rebooted. The web sites and services wont be affected or impacted as the 3 have sufficient availabilty and capacity to handle the load

first - who asked for the reboot ? If there is a service request to reboot the server that is created in the incident ticket system and the appropriate system group is assigned the work and does the work, then I would not have a RFC raised - what is the point ? That is providing that there are initial and closure codes that IDENTIFY The type of work

No RFC needed

Scenario 2

There is a requirement to reboot every WinTel server every 3 months. This is a maintenance requirement to ensure that the server is cleared of temporary files. The work is to be done out of normal service houring during the posted maintenance window

A RFC should be raised for the start of this process and should contain the 'original list of serves to be done'

If more are added or removed from the maintenance list, then a RFC should be raised to TRACK and IDENTIFY the fact that a server is on or off the list

Scenario 3

Joe Bloggs working in department A thinks the server he is using to do his work is slow. So he opens a request to have it rebooted during business hours. He contacts the Service Desk for the service request. He is merely a user.

A RFC is raised mainly to protect the IT environmen from idiots like him

The RFC process should reject the change.

The main points for raising RFCs for reboots are to identify whether the service is being impacted and to track the work being done and to have sanity checks (approval) for impacting work.
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[Ed]

My take on this is fairly simple

Our role as Change Managers is to ensure that the business can pursue it's daily tasks with as little hindrance as possible.

Anything that impacts the availability of a service, therefore needs to be tracked and an audit trail maintained.

I also like to be consistent in my approach, which is why I cannot agree with John on his scenario 1.

I think any reboot of a server must come under Change Management - we deal with it via Standard Change - with a procedure that is cast iron going with the RFC as part of the Release documentation.

Regards

Ed