The ITIL change control and CAB process are quite useful when used properly and facilitated by the appropriate staff. That IT changes cause the majority of datacenter outages is not a debate, proper change control shows us this. However, CABs use is to get all changes in a room so impact and stacked changes can be weighted to ensure these "change outages" do not occur or at least minimize the risk.
Example: I need to push changes across a WAN but the network team has a router upgrade also planed. Someone is going to fail here. CAB resolves these conflicts.
Where CAB is supposed to back off is when we have ITIL-defined standard changes which dont require approval but are still notified so others can be aware systems WILL be rebooting. Our admins responsible for patching, have a pre-approved and scheduled patching cycle of systems, and CAB is the method we notify other departments of these updates. We have a stage and production environment for most applications anyway so we use these for patching also. Well know if an OS patch or package update breaks because it broke in stage, not production. And CAB is only there to pause patching IF theres an issue or other scheduled maintenance window more critical.
We have anywhere from 10 to 30 people in each weekly CAB and it takes 15 minutes (video conf/dial-in bridge). We then have another 15 minute meeting the day of our major maintenance windows. Since doing this weve reduced unplanned outages by 75% simply due to proper scheduling between departments. It takes 30 minutes a week. I spend maybe 30 to 45 minutes a week writing my change requests, so in the grand scheme, the benefit outweighs the administrative overhead.
However, this improvement assumes ITIL was facilitated and maintained by people with enough technical knowledge (through director-level) to make appropriate decisions based off changes presented. If your CAB is run by paper admins, youre in a world of hurt because theyre going to make uninformed approvals regardless of the amount of data presented. In your case, the CAB should not require a write up of every KB and you should not have to "prove" each update. Instead, if an update of a "test environment" goes fine, the CAB should only be there to make exceptions to your planned maintenance window.
I dont know the size of your contracts but my 30 minutes of CAB and pre-maintenance meetings allow us to maintain several hundred applications across multiple VM and physical server farms with additional AWS infrastructure. If ITIL is new to you and your CAB partners, it does take time to smooth out the workflow. It should take almost a year to get a nice flow because it is quite a shift to everyones workflow.
Or, if you have a bunch of chuckleheads running the show now, like others said, dust off the resume.
Slashdot Mirror
The ITIL change control and CAB process are quite useful when used properly and facilitated by the appropriate staff. That IT changes cause the majority of datacenter outages is not a debate, proper change control shows us this. However, CABs use is to get all changes in a room so impact and stacked changes can be weighted to ensure these "change outages" do not occur or at least minimize the risk.
Example: I need to push changes across a WAN but the network team has a router upgrade also planed. Someone is going to fail here. CAB resolves these conflicts.
Where CAB is supposed to back off is when we have ITIL-defined standard changes which dont require approval but are still notified so others can be aware systems WILL be rebooting. Our admins responsible for patching, have a pre-approved and scheduled patching cycle of systems, and CAB is the method we notify other departments of these updates. We have a stage and production environment for most applications anyway so we use these for patching also. Well know if an OS patch or package update breaks because it broke in stage, not production. And CAB is only there to pause patching IF theres an issue or other scheduled maintenance window more critical.
We have anywhere from 10 to 30 people in each weekly CAB and it takes 15 minutes (video conf/dial-in bridge). We then have another 15 minute meeting the day of our major maintenance windows. Since doing this weve reduced unplanned outages by 75% simply due to proper scheduling between departments. It takes 30 minutes a week. I spend maybe 30 to 45 minutes a week writing my change requests, so in the grand scheme, the benefit outweighs the administrative overhead.
However, this improvement assumes ITIL was facilitated and maintained by people with enough technical knowledge (through director-level) to make appropriate decisions based off changes presented. If your CAB is run by paper admins, youre in a world of hurt because theyre going to make uninformed approvals regardless of the amount of data presented. In your case, the CAB should not require a write up of every KB and you should not have to "prove" each update. Instead, if an update of a "test environment" goes fine, the CAB should only be there to make exceptions to your planned maintenance window.
I dont know the size of your contracts but my 30 minutes of CAB and pre-maintenance meetings allow us to maintain several hundred applications across multiple VM and physical server farms with additional AWS infrastructure. If ITIL is new to you and your CAB partners, it does take time to smooth out the workflow. It should take almost a year to get a nice flow because it is quite a shift to everyones workflow.
Or, if you have a bunch of chuckleheads running the show now, like others said, dust off the resume.