We have change control, but we also have an emergency change process for things like this where security is at stake. Essentially it overrules the standard process, so IT can create the change and implement without going through the full process. Things get tested as usual, but the whole approval part is missed out.

 

Do you have to write the change after the emergency change? We do :/

 

It is then in the system incase lets say a month down the line a system is behaving strange we can then look at that change and its config.

Do you have to write the change after the emergency change? We do :/

 

It is then in the system incase lets say a month down the line a system is behaving strange we can then look at that change and its config.

We have done in the past.

Change control....ahahahahahahahaha

 

 

hahahahaha

 

haha

ha

 

:'(

We have change control, but we also have an emergency change process for things like this where security is at stake. Essentially it overrules the standard process, so IT can create the change and implement without going through the full process. Things get tested as usual, but the whole approval part is missed out.

 

The same applies to us for any changes for our production systems - even say something as simple as bring a new SQL server DB online (network load, backups, performance for other DBs being hosted on the same hardware, etc).  Normal releases (new/upgrade) have to go through the approval process giving at least 7 days before the "release" date.  However in the event of a issue with a system with prevents work from being carried out as normal (and no short term work around), then we can make the necessary changes (after testing), and then raise a retrospective/emergency change, with all the necessary supporting documentation.  As they are reviewed in a weekly CCB, that means you won't get someone performing an update over the weekend, to then find that a VM customer has been taken offline, etc which then breaks something else....

 

However if someone raises more than a couple of these a year then their general testing/development/work ethic might be called into question and more testing of their code/peer reviews might take place to ensure our customers receive a certain level of quality.