Is a server reboot a change

By ITIL® from Experience©

Note: to simplify reading, the term reboot also refers to restarting services or daemons.

Early in the design and implementation of the Change Management process Technicians may argue that a reboot is not a change (see What is a change). Common arguments include:

A reboot does not change the configuration of the service or the attributes of the configuration items thus, it is not a change
If a reboot is required, the service is pretty well inoperable and cannot be impacted any further. Therefore, approving a reboot and reviewing its impact is useless
If the reboot is performed to resolve an incident, it is done as part of the Incident Management process and not as part of the Change Management process thus, it is not a change (see Does an emergency change need an incident
When dealing with an incident, logging a Request For Change (RFC) and waiting for it to be authorized unnecessarily delays resolution
The reboot will be not be noticed by users because of our high-availability environment.

Although these arguments appear correct, they are most often used by technicians to avoid logging an RFC and be subject to the Change Management process and authority (see How to get people to log tickets).

Let us explain why a reboot is a change and why an RFC needs to be logged for it.

1. The reboot actually changes the status attribute of the Configuration Item. For example:

It is changed from “Live” to “offline” and then again to “Live”. Although the result is identical to the original state, the status did change even though it may not have been recorded in the CMDB.
Replacing a defective router or faulty drive in a storage array would have the same result if an identical model and configuration was used (albeit the serial number would be different if tracked in the CMDB). Most Technicians working on a networking incident would want to know that a router was changed. Recording the replacement of a router as work notes in the Incident record makes it difficult to easily and quickly identify “what changed.” Logging a reboot as a Request For Change (RFC) makes it visible and easily identifiable to the anyone working on an incident.

2. The ITIL® definition of a change states that it is “...anything that could have an effect on IT services.”1

Rebooting is somewhat of a severe impact to a service since for that moment in time the service is actually unavailable while the reboot is taking place (I.e. the service does not exist during this time). In addition, with shared hosting and virtualization, rebooting is often impacting more than one service, application or components thereof. Thus, rebooting without reviewing the potential impact can cause additional incidents.

3. The purpose of Change Management is to ensure “that standardized methods and procedures are used for the prompt handling of all changes.” 2

Part of these procedures is to communicate. Thus, service owners and application administrators can properly/gracefully shut down their application. They are also aware that they may need to restart them, manually restore interfaces, etc. Failure to review the impact of a reboot and to communicate can result in unnecessary down time and lost effort if a team is unaware of the reboot and is under the impression that they are dealing with an incident when the service goes offline.

For all these reasons, a reboot should be a change. Logging an RFC also provides a record of the work performed. These historical records can be invaluable to Problem Management to identify trends and perform root cause analysis if need be.

Now to address the argument that in the case of a service outage, taking the time to log an RFC and getting it authorized unnecessarily lengthens the incident's resolution time. A well designed Emergency Change Process should address the issue. A policy such as: "in case of an emergency, engage the Change Manager so that he/she can start the communication that a reboot will be taking place, and log the RFC after the reboot took place. Moreover, in high-availability environments a reboot can be a standard change (see How is a Standard Change Pre-Approved).

Last updated on: 2016-12-15
Published on: 2012-10-09

"There is nothing wrong with change, if it is in the right direction." Winston Churchill.

More Quotes

Category:
ITIL Process > Change Management

From Around the Web:
Are Production Server Reboots Standard Changes?

Plugin disabled

Plugin footnotearea cannot be executed.

Disclaimer

<HR>