Posted: Tue Aug 08, 2006 12:55 pm Post subject: Is restarting a server or service considered a change?

We've had a debate here at work and people have decided that restarting a server or service is considered a change and requires an RFC. In fact, it's now been decided that even if a service is unavailable that we cannot restart its processes until we submit an RFC and obtain approval.

I see the point in documenting the reboot, but it seems to me that the above decisions will lead to delays in restoring service and this will negatively impact systems availability. Comments?

In my former job we also handled a reboot of a server in the change proces. For the small servers we had standard changes as Ed says. For restarting larger servers (up to the mainframe) we had an urgent change procedure.

We came to the conclusion that we do not want to 'stand in the way of Change', but to facilitate it, therefore pre-approving this kind of Change made perfect sense.

It's not without it's pitfalls - You have to make sure that the procedure behind the change is as solid as you can get it.

We ask for a Standard Change Release Notification from the Techies so that we know what they have done/are doing and can keep track of the changes as they make them (We post them in our Forward Schedule of Change as well).

In most organizations that we encounter, restarting a server is "not" a Change, as a "Change" implies the modification of a Configuration. Rebooting a machine does not change the machine's configuration and, therefore, changes nothing other than the state of the server, itself.

Restarting a server is typically treated as a basic "Service" that yields a Service Request when it is invoked by the requestor.

In most groups I've worked with, unless there is an alteration to the structure (i.e., not just a reboot), it isn't considered a change. Should it be documented... absolutely. That way we have evidence if we need to commit to a true change/alteration.

If the reboot is part of a solution to get a service back online, then just an incident should be required.

If however, the reboot is part of a measure to prevent a possible problem, then I would consider that an emergency change. This then allows for approval time and to get an outage message to any affected users.

in my organisation, it depends on the reason behind the restart. eg 1 - server is unavailable, all users impacted by loss of service, and service needs to be restored via restart, then there would be a Sev 1 or Sev 2 ticket active, therefore can be performed under that ticket.
eg 2- service/system is available to staff, but the restart is required in a pro-active manner, then an urgent change is raised (meaning for us that lead times don't need to be met given the justification for the work) and an outage notification is sent to users.
eg 3- server requires reboot as tasks running in the background have crashed (so incident ticket has been raised with high severity), statewide staff are not impacted by the crashed tasks, but will be by the reboot, so an Emergency change is raised to approve this loss of service, outage notification sent to affected staff.

A Change should be any work where the configuration of a device has been changed.

Therefore a reboot or a restart hich is merely being done either for a response to an existing incident or as part ofa weekly or monthly maintenence cycle (why?) is NOT a Change per ITIL.

However, if the reboot is part of a configuration change// install etc; then it is part of the implementation plan for a change and there should be indicated as such

Lastly ... what to do about the reboots//restarts where there is no configuration change / Easy 1- there should be a Incident (service Request) record, 2 - if the users are going to be affected - a notification of some kind should go out

You need to come up with a Maintenance work - non configuration work - ticket standards

Now I used RFCs because our RFC system also linked to the notification system_________________John Hardesty
ITSM Manager's Certificate (Red Badge)

Under a number of circumstances, because restarting a server changes its state, it involves a number of activities that are usually handled by the Change Management process: planning (as short as it may be), risk management, Projected Service Availability, back-out/contingency planning, etc...

I am a little skeptical here. What server? Do you turn off an AS/400 just like that, as a service request? How critical is this server? How long will it be down? Can it wait until the next service window? ... How about restarting services on that server? How about virtual machines in the server? Which services are going to be affected? How much does it mean in productivity loss?

For the sake of efficiency, and because we should have the server fully under control, we should have the answers to all those questions readily available in a documented procedure. Depending on the server, you may allow the Service Desk to perform the action following that procedure. But you cannot decide off the bat that restarting *any* server is "merely" a service request left up to whoever is performing Incident Management to decide and execute._________________BR,
Fabien Papleux

In ITIL a Change is defined as the process of moving from one defined state to another. Therefore, any request that: alters, removes or appends anything to a Configuration Item (CI), i.e. changing the baseline configuration of a CI, and/or has the potential to impact the Availability or Quality of Services within the production and supporting environments (test environment, Definitive Hardware Store (DHS), and Definitive Software Library (DSL)), is considered a Change and must follow the Change Management process.

It could be argued either way but I concur with Frank and John on this one in that the reboot does NOT change the baseline configuration of the server.

isn't it the great question of Change Management? What is a Change? What is a Service Request? Isn't any change different? How can you handle almost all changes with just one process? Won't the process just get to big in order to be able using it for almost all changes?

So there's just one conclusion... You need to define what are changes, what are service requests, what changes can be pre approved, what changes need to run through the whole process...

As there is no fit-for-all answer for this questions, as every change is different, as every company is different, you just have a continous process of rethinking and improving your own Change Process.

It's a shame, no easy going, no easy life, nothing is really a standard, always rethinking... Guess I could really think of worse jobs.

To your question... What is the benefit of generating a RFC for rebooting? What is the relation between benefit and effort? Are there different forms of rebooting? Is there a SOP for rebooting? Instructions, who is to be informed? Is it a nearly automized process? Change Management is much about defining things.

Since when did shutting down a server (to reboot it) not impact it's availability. Surely if a server is shut down , it is not available!

blamblam says

'In ITIL a Change is defined as the process of moving from one defined state to another. Therefore, any request that: alters, removes or appends anything to a Configuration Item (CI), i.e. changing the baseline configuration of a CI, and/or has the potential to impact the Availability or Quality of Services within the production and supporting environments (test environment, Definitive Hardware Store (DHS), and Definitive Software Library (DSL)), is considered a Change and must follow the Change Management process. '