One recent thing we are struggling with is the idea of setting changes up on an "automatic" schedule. For example, setting a cron job on a production server to apply OS patches and reboot the server. While this may prevent the technologist from being up at 2am during the maintenance window, it does not get around needing to submit a normal change request.
There was a miss perception that setting up "automatic" jobs somehow got around the need to submit a change request. It's something we have to remind people of fairly frequently.
Our current software is custom built and does not yet support recurring change requests. Hopefully we can get the time to code that in so we can help make the daily work lives of our technologists better!
Friday, August 31, 2012
Thursday, August 30, 2012
Emergency Change - Rant of the Week
It is always fun to get emergency changes and sometimes they leave you shaking your head.
Emergency Change Reason: Classroom switches to be replaced that are currently not in use, but will be when school starts.
Background: To proactively replace old switches with the potential of dying and causing an unplanned outage.
I am not sure this rises to the level of an emergency, but lets consider it for a moment. The first thing is the "Emergency Reason" and while it is great that the switches are not in use, it does not really say why this is an emergency. That is alright, lets read further and see if the "Background" indicates what could be happening. No, not much in the "Background" section other than replacing old switches.
These types of change requests need more information for the CAB to make any sort of realistic decision. Of course, then the CAB is perceived as being nit-picky, but seriously.
I am not advocating lying to the CAB, but at least make it sound like an emergency. Perhaps the switches are throwing errors or maybe they are physically falling out of the racks. Who knows! The point is that the CAB needs to help educate people on what they need without being perceived as being nit-picky or overbearing. I find myself using up a lot of my banked "goodwill" with my peers over CAB issues. Looks like I should start investing in doughnuts and coffee to help replenish!
Emergency Change Reason: Classroom switches to be replaced that are currently not in use, but will be when school starts.
Background: To proactively replace old switches with the potential of dying and causing an unplanned outage.
I am not sure this rises to the level of an emergency, but lets consider it for a moment. The first thing is the "Emergency Reason" and while it is great that the switches are not in use, it does not really say why this is an emergency. That is alright, lets read further and see if the "Background" indicates what could be happening. No, not much in the "Background" section other than replacing old switches.
These types of change requests need more information for the CAB to make any sort of realistic decision. Of course, then the CAB is perceived as being nit-picky, but seriously.
I am not advocating lying to the CAB, but at least make it sound like an emergency. Perhaps the switches are throwing errors or maybe they are physically falling out of the racks. Who knows! The point is that the CAB needs to help educate people on what they need without being perceived as being nit-picky or overbearing. I find myself using up a lot of my banked "goodwill" with my peers over CAB issues. Looks like I should start investing in doughnuts and coffee to help replenish!
Tuesday, August 28, 2012
Basic Change Workflow
We used this graphic to walk our Interim-CIO through the basic change management process. We tried to present ITIL without a lot of technical jargon, but it was difficult since one benefit of using a service framework is to standardize on terminology.
Subscribe to:
Posts (Atom)