Patches and Change Management

[Debbie]

We have implemented Change Management recently and are struggling with patches. How do most people handle changes around patches. We currently consider patches as a high risk change that requires testing and approval from several different application groups--goes through the entire CM process. The infrastructure teams have issues because the turn around time can sometimes be 3 months before they get approval from all the applications. Do most people consider these standard changes? How are they handled effectively and efficiently without bogging things down?

[MrDon]

In my place, things like MS security patches are tested and then deployed about a week later by raising a change. The change is considered BAU but always discussed in the CAB. For example, our client would like to know what kind of outages are related to patch installations etc.

Its only because we do these every month they are considered BAU as the change and procedures related are tried and tested.

[Debbie]

Hi MrDon,
What is a BAU?

[fighter]

BAU -- > Business As Usual. some Standard and non impact changes can be delcared as BAU.

A common test environment is to be created for testing the patch.

The patch is tested by various application team after the patch is installed. ( Exisiting environment + Patch --> Testing). Once the test is given a go then the patch is installed in the production environment. Make sure to test the back out and store the results for use in the future.

Make sure you do not update the patch in all the production servers at one go. Set a deadline for the patch to be installed in the organisation then approach 1 application at a time. This will help you to keep the resource allocation as well as reduce the risk.

To achieve this DSL should be maintained so that the required software can be produced on demand basis.

Hope this helps.

Vimzie