Monday, 3 October 2016

Change Management

When is a change not a change ? Yes, this is a trick question, you see the sun coming up in the morning and going down in the evening is a change of state, however, it's one we expect, this is sometimes overlooked by change manager when they want a change request for what is expected behaviour like a move of a virtual server from one server in the farm to another.

Let us look at types of change first of all and compare them to real world examples.

Retrospective
Emergency
Normal

The retrospective should be the least used and really should only be used when a change was done to resolve a critical incident, a good example of this might be a software patch or firewall change to block an attack that was taking place.

The emergency change is used more than it should in my opinion, and should always be reviewed why it took place, some examples of this could be a zero-day exploit that you want to patch quickly, another could be last minute request from a business unit like a code change for a sales promotion.
In most if not all you have to ask if this could not have been foreseen and better planned.

The normal change is the one where you had a chance to tick all the boxes and should be most comfortable approving.

The questions that should have been asked in both normal and emergency change are as follows.
  • Has the change been tested?
  • Does the change affect other things, aka disaster recovery and service overview documents?
  • Other applications connected with it.
  • Have stakeholders from those affected applications taken place.
Next on the list is rollback plan.
  • Is there a rollback plan, if not then why not.
  • When is the rollback to take place aka the defined set of things that have or have not happened to trigger the rollback, and the expected time for the rollback to take place?
All of the information above should be available before the change advisory board review the change.
On the other hand when a server fails and as a result service fails over to the secondary this is not a change... this is expected behaviour, I have seen change managers ask for a change request for failovers and I have, to be honest, I've laughed at them.
When the primary is restored and we want to failover back to it "yes" that is a change... if something breaks and we have to change a setting to fix it "retrospective change" because you already have an incident.
However, we have to be clear, incident, in this case, needs to be service interrupting otherwise it can wait of emergency change, perhaps good example of this would be an overnight job is running and it will not finish in time and you need to change the import parameter to make it run faster, this is not yet a service impact, however, does require some urgency hence emergency if, on the other hand, this was going to finish this time but the trend is that in few weeks it will not complete in time as the jobs are getting slower that would be a Normal change.
Hopefully, this helps to understand when change management is used and when it can be informed after during impacting incidents.

No comments: