For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone
Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
Posted: Mon Mar 31, 2008 10:23 pm Post subject: Change Request approval outside office hours
Hi,
I decided to control Service Reboots via an Emergency Change Request. All "emergency Requests" need to be approved by the Change Mgr in our company. This works fine - at least in business hours when the CHG Mgr is available. I wonder how other companies address this issue outside the office hours, when the Change Mgr is not in.
Joined: Oct 07, 2007 Posts: 441 Location: Jakarta, INA
Posted: Mon Mar 31, 2008 10:40 pm Post subject:
In my understanding, Emergency Changes must be justified by the CAB/EC.
Why not classifying reboots as standard/pre-approved change?
All you need to do is call the Change Mgr by phone and get an oral approval.
Action could be taken immediately but of course you will have to complete the documentation following the action
"Why not classifying reboots as standard/pre-approved change? " the question is about ot of hours - you can't assume that the CM is on duty 24*7 365.
Generally most organisations will have an on duty manager or a senior manager that will take a call out of hours for emergencies. A reboot out of hours that i snot planned shoul dbe for an emergency affecting a service that should be available at that time.
Another approach is to talk with the CM and senior manager and see if you can get a roster going for approval of emergency changes outside of normal operational hours and how to deal with the issue of remuneration is necessary - some roles this is added as a requirement to do some out of hours cover - some roles it is not and is not easy to get past i.e. in public sector. _________________ Mark O'Loughlin
ITSM / ITIL Consultant
Joined: Oct 07, 2007 Posts: 441 Location: Jakarta, INA
Posted: Mon Mar 31, 2008 10:50 pm Post subject:
Hi,
I guess I didn't speak clear enough.
Quote:
In my understanding, Emergency Changes must be justified by the CAB/EC.
Of course gathering the CAB/EC outside office hours would be out of question. Unless you define that Emergency Changes don't need the CAB/EC
Quote:
All you need to do is call the Change Mgr by phone and get an oral approval.
Action could be taken immediately but of course you will have to complete the documentation following the action
Joined: Mar 04, 2008 Posts: 1884 Location: Newcastle-under-Lyme
Posted: Tue Apr 01, 2008 8:43 am Post subject:
Hi,
Sorry to be naive, but why is a reboot a change? I consider it an operational procedure. All the risks and impacts should be well enough understood and documented to be controlled operationally. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Joined: Oct 07, 2007 Posts: 441 Location: Jakarta, INA
Posted: Tue Apr 01, 2008 10:29 am Post subject:
Hi,
The topic of whether reboots are classified as change or not has been a discussion for a long time.
People can have different valid understandings.
What is important is consistency. If you set reboots as changes, then treat them as changes. If you set them as SOPs, then treat them as operations items.
Just a discourse:
For me, reboots are more "bringing the service back as soon as possible" with the assumption that the reboot is required because of an application hangup, deadlocks.
Reboots due to patches, upgrade, network changes are part of the RFC to install the patches, upgrade, etc.
Joined: Mar 04, 2008 Posts: 1884 Location: Newcastle-under-Lyme
Posted: Tue Apr 01, 2008 6:59 pm Post subject:
Hi,
asrilrm wrote:
Reboots due to patches, upgrade, network changes are part of the RFC to install the patches, upgrade, etc.
I rather assumed that these were not in the question because they are, as asrilrm rightly points out, just a step in another activity which is a change.
But when reboot is simply recovery from crash or hang or whatever (power outage?), it is not conceivably a change, unless you have updated the CMDB with the status of the machine. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Im not saying what is right or wrong but have a comment regards the following
"But when reboot is simply recovery from crash or hang or whatever (power outage?), it is not conceivably a change, unless you have updated the CMDB with the status of the machine"
I don't fully agree. WHat if your recovery from the crach or hang or whatever causes additional problems and incidents. is that ok. E.g. to recover from a hung application you decide to reboot a server and not go through emergency change control. you reboot the server. However there are 4 other business critical application on the same server and rebooting it now causes all these applications to stop working the period of the reboot. - is this a good or a bad situation.
Emergency change can be used to prevent this and control the manner in which you recover protecting the other operational services. Also I don't buy the reason given that the CI has not chnaged, Sure you have not changes a value of an attribute but the state of the CI has changed from being available, or hung etc to being hard down when you reboot.
Just some thoughts. _________________ Mark O'Loughlin
ITSM / ITIL Consultant
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
