Hypothetical:
A server is generating log files (it is not given as to why), but the amount of log files it is generating is going to cause a fault (hence a problem has been identified). The fault is when the log files fill up the hard disk, there will be no more space to store data (which will occur within 48 hours).
The identified fix is to restart the server.
To restart the server will impact 30,000 users, as it will take 30 minutes to fully restart.
Obviously we are not “changing the CI” we are just restarting it.
Is this a change or an incident?
In our company if it is an incident – you just go ahead and do it (providing you are not “changing” anything). Conversely, if it is a change you begin the “emergency change” process. However, because it is around christmas time, the company has an embargo in effect, and only the CIO can approve a change during the embargo (company policy). Approaching the CIO is not out of the question – but you don’t want to look like a goose asking for permission, when permission is not necessarily required.
I would have to say that it is both. It is common for Incidents to be resolved by the implementation of Changes. That would appear to be the case here. You have an Incident (An event which is not part of the standard operation of a service and which causes, or may cause, an interruption to, or a reduction in, the quality of that service) for which the resolution is a Change (A change in status or attribute of a CI).
You could decide to have the Problem Management process investigate and fix the root cause (why the server is creating so many log files) but that is entirely voluntary. You could continue your business with Incident Management opening Change requests to reboot the server every time the volume gets full.
Now as to the politics of the issue, I would say that you should approach the CIO and ask for permission to reboot the server. You say that it could affect 30,000 users. Who will look like a goose if it fails to reboot successfully?
Leave a Reply