However, in the real world, improbability has a habit of giving us a wake-up call and disasters do happen, ranging from natural events (fires, floods, influenza epidemics, lightning strikes...) to man-made happenings (wars, terrorist acts, police blockades...). Man-made need not be malicious - somebody could accidentally press a series of buttons in the wrong order and......

We're sure the chimpanzee is actually very intelligent - in truth, we couldn't find anybody willing to have a picture of themselves initiating a disaster placed here...)

We're discussing Disaster Management, and, in particular Recovery here because something completely unpredicted (or the cost to protect against was prohibitive) has occurred.

What is required is a way to regain control of processes, arrest the degradation in service availability and begin the route to restoring normal service in line with business needs. It is also useful if, during the recovery process, information about the cause and a catalogue of key events can be constructed or deduced to help determine if preventative measures need be introduced to guard against a repetition of the effects.

A “disaster” need not be a catastrophic event outside your organisation either. Something as simple as running a mission-critical server off an unprotected power supply can turn a short, local, power outage into a multi-million pound damage limitation exercise - we've seen this type of event happen all too often, and the root cause after investigation was surprisingly simple - in the case of the example quoted, a technician (not one of ours, we hasten to point out), under pressure to complete an installation, mislabeled a (spare) normal AC power socket as “protected” - indicating that in the event of a local power failure, that particular socket would remain live for a pre-determined time.

The same pressure then caused the final User Acceptance Tests to be less than thorough (We're sure you've encountered such a situation where, for instance, previous management decisions make it impossible to push back a service launch date). Over the next 18 or so months, the technician was redeployed and the business naturally evolved; IT expanded and the power socket was duly assigned to a server.

All was fine until one day the local power failed and something that should not have happened did happen and....

Disaster Management can generally be considered as 4 related Spheres of Activity:

If you wish to discuss Disaster Management issues and find out how Pro-Tess can assist in reviewing your current plans & processes and make recommendations to address any areas needing attention, please don't hesitate to contact us.