Change requests

Permabanned
Joined
28 Dec 2009
Posts
13,052
Location
london
I might be moving in to a new roll that will be more 3rd line based and they said that they are introducing a change control form and process that is going to be very strict. When i asked them about for an example windows updates. I said will i need to complete a change control form for applying windows updates and they said yes.

Do you have change control at work and if so does it include any changes to servers no matter how small and insignificant?

Do you think for a 100 user law firm that being so cautious that you have to use change control forms for basic things like applying updates is over the top?
 
Last place i worked had 5000 servers and change control was a nightmare, everything we did had to go through change control.
The good thing was that if anything broke you could say you had an approved change :)

Current place has 150 servers and no change control, everyone works away independly from one another with no communication or team meetings to communicate whats going on.
i frequently come in to find servers having mysteriously reboot, or the entire infrastructure fall over, no monitoring or alerting in place either.... oh the joys :)

Change control is a pain, but once you get used to it it's worthwhile.

Oh and i saw windows updates break a couple of servers and bring down a customer network last week... (Aint seen that in about 8 years!), so they need change controls as well :)
 
Any reputable organisation should have solid change control in place...

If you deploy an update and it screws up all 100 user's mail clients are you going to popular? Obviously you tested all updates for deployment

Ad hoc by cowboy admins are a nightmare.
 
ok thanks, I can see the purpose of change control and see how it can be usefull and beneficial for liability reasons. But i still have my reservations about it.

I have been working at a place for 6 months now with no change control and I have been applying updates, installing things and cleaning up servers and making changes to group policy when i need to (ad hoc). The only thing i don't do is anything that requires a server reboot. But some of the servers that just have prtg and hp sim installed, i update sql and reboot those during the day and never had any problems in six months.

If i have to do change control for things tweaking group policy or reboot and updatae prtg server that is going to be a waste of time imo.
 
Change control is needed as long as it doesn't take a long time to get a change approved or not if the case may be.

Users will get angry if it takes a while so I can see it from both sides. If an update breaks something theres hell on where I work. So change control is required.
 
Not really - 100 users may be on the small side of things but if you are planning to continue a career in IT and seek bigger environments to play getting change control into your head would be a good thing as most places should be doing it (in some form although it can be debatable :p).

If you can reboot SQL boxes in the middle of the day you must work in a very relaxed environment :D
 
When I did sysadmining I introduced change control as part of an overhaul we did for ISO27001. It is a pain to be honest but it does force you to stop and think about what you are doing and a second pair of eyes never hurt.

It actually proved quite useful once in fault finding as we went back through the change control log and looked at all the things that had been modified recently.

While I don't enjoy these things it is not going to disappear so we (as in IT administrators) might as well embrace it.
 
It's one of those things, everyone hates it but can be a necessary evil. Although for a 100 user company I'd expect it to be a pretty light touch process.

Won't go into our process but a relatively large company and it's a pretty big process to get a change raised which would be annoying I guess (I don't raise them, just assess and approve them from a certain aspect).
 
We use change controls at work, definitely worth it. As stated above it's ass coverage, and also good for auditing. I frequently go back through change controls i've raised to copy/paste the info so I don't need to remember every little command i've ever run.
 
Our change control for windows updates normally consists of the list of servers being done, and what level (MS Baseline) they are being updated to. Some organisations would want a list of the updates and their descs - boring stuff. We use Shavlik to install so it lowers the risk of bad patches as they are all pre-tested by someone else.

And yeah, any change, no matter how small gets logged. Its a pain, but you know, there's only so many hours in the day so if makes every job 3 times longer, the company lose out, we still get paid so bah.
 
When I was in a (admitted senior) support role I used to quite like the change control process. It made you consider exactly what you were doing and think about what your back-out would be if things went wrong. The account I was mainly on had twice weekly change board meetings where you had to present your change and be able to explain it, and answer questions, and they were really hot on making sure that things were not just being bodged through. It was always fun arguing about things and discussing points that may have been forgotten. There was, of course, a process for fast-tracking emergency changes.

Regarding the rolling out of Windows patches ... I worked on the Unix side but my understanding of the general procedure was a single change was normally raised to apply patches to a subset of test boxes to check for fatal issues and then if there were no problems a change would be raised to roll the patches out across the estate specifying what patches and when the different groups of servers would be patched. As it was a regular standard process an individual change wasn't required for each system.
 
We use change control at work, in an enterprise organisation I think it's difficult not too. How can you track who has done what and reasons for things going wrong or behaving differently.

Windows updates for us are a "standard change" meaning that it is almost pre-approved in some respects, but still needs a monthly review and approval when they come out - in case any patches get released that cause problems. But thats what pre-production systems are for and why we have a standard change to roll updates out to those before we do production.

I think there needs to be careful consideration by an organisation how they implement change control across systems. I think there is a fine line between too much beurocracy in approvals and getting the right measures in place to ensure things have been checked properly and given full consideration.
 
I was just asked to fill in a change control form to reboot a server that is having problems. A miss use of change control form?

Possibly/Probably.

As a Change Manager I would want to know if you were impacting other users by taking the server out. While one service might be broken, other services for other users might be working fine and if they are going to be impacted I would want a request filled in and approved.

As some have alluded to though, there are different types of requests. A simple reboot to restore service might be handled by a Standard Change that can be linked to the Incident and logged and approved by a duty manager for example. A change to deploy 20 patches to 5000 servers might need more planning and higher authority.

The real trick is to have a robust but flexible process that engages with all parties and doesnt leave anyone out. It takes a bit of work and a lot of persuasion, but Change Management is an essentially part of any moderately complex IT environment, big or small.
 
Back
Top Bottom