By ITIL® from Experience©
Note: to simplify reading, the term reboot also refers to restarting services or daemons.
- 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
- What is a change
- Is a bulk data load a change
- What are examples of standard changes
- How is a Standard Change Pre-Approved
- Does an emergency change need an incident
- What is a quick way to implement Change Management
- What are the skills of a change manager
- Who should log the RFC
From Around the Web:
Are Production Server Reboots Standard Changes?
Copyright 2012-2016 - ITIL® from Experience - D.Matte