We are receiving some questions about when an issue should be an Incident and when it should be a Change. Here are some examples:
Jim
Hi Jim,
This is a good question, and a common one. I will address your examples one at a time.
“Our Server Group needs to reboot a server because our monitoring tool states it has run out of memory.”
Running out of memory probably should be considered an incident. Rebooting would probably be considered more of a workaround. If running out of memory is chronic, then it’s a problem and the underlying cause may need to be diagnosed via Problem Management and corrected via the Change Management process.
“Our Database Group notices that a database appears to be quite fragmented and needs to execute a defrag on Saturday during our standard maintenance window.”
If database fragmentation is the result of normal operations (no known or suspected systemic error causing it) then it could be considered to be a “routine resolution” … similar to password resets, etc. As the process implementer it’s up to you to determine what is and isn’t an incident. Unless defragmenting the database causes something to actually change in the infrastructure or you’re required to document equipment status then it’s probably not worth considering it as a change. If you choose to make it a change, I’d suggest establishing standard change templates so this kind of activity doesn’t clog up the normal change process with minor and well understood maintenance activities like this.
“Our Information Security Group was notified of a security patch that should be rolled out immediately”
Unless there was a “security incident” then this would be a change. Similar to #2, I’d suggest establishing standard change models to streamline this kind of change.
Note: Activities that cycle production equipment status may classified as changes if the status change occurs during normal production hours as opposed to scheduled maintenance. This most often depends on policy or industry regulation issues.
Thanks again, and I hope this helps -- David Nichols