A typical disaster could be: grid sector power outage (where all supply lines into a data centre go down), a communications failure (internet access on all lines goes down), an internal site wide issue (such as small fire in one part of the building turns on the sprinklers in the machine room) or an A/C failure (it's amazing how many people have redundant everything apart from A/C).
To recover successfully, all data and applications have to be present at a remote location where they can be started to begin exporting the service. What areas should a disaster recovery plan cover and of these areas, which are often overlooked and/or given little priority - even though their business impact could be substantial?
A plan should cover: Data Recovery ... how does your data get from the local site to the DR site? From simple tape backup transported once a day, to real time replication. Applications ... all the applications need to be present, installed, configured and licensed at the DR site so they can be started easily. Service Export… since the DR site may not have the same IP address, plans must be laid for service transition (i.e. known service name in DNS changed etc.). Trigger Point… how do you know a disaster actually happened? You need a process in place for confirming this before activating the disaster plan. This should always be manual, since automation never seems to get this entirely right. What 3 tips would you give a contact center manager looking to implement a disaster recovery plan? The most critical piece is the data - if you don't have it you can't recover. So know how the data gets between the two sites, and since most methods involve some time lag, make sure this accords with the amount of data you can handle the loss of, should you have a disaster situation.
Location of the DR site. You need a rough idea of what type of natural disasters you're planning for (fire, flood, earthquake etc.) and what sort of geographic scope they have. Make sure the location of the DR site is outside of this scope.
Trigger point. Since this is crucial to actually activating the DR site, and it always contains a human element, your trigger plan needs to be well thought out with adequate backup. There is no point having a disaster and then finding the person who does the activation is on holiday for a week.
Who should participate in the development of a disaster recovery plan and how involved should these people be?
This really depends on the scope. If you already have a remote location, or your DR plan is basically shipping data out on backup tape and finding somewhere in the event of a disaster then really only CIO and IT staff. If your plan involves provisioning a remote site, then you need to involve financial and budget people. In all of this, it might also be advisable to consult the consumers of the service to see what service levels make the most sense in the event of a disaster. What impact will evolving technology have on the development and success of future recovery plans and how will this process contrast to activities completed five years ago?
The basic impacts are: Cheapening of commodity and co-location services, making a backup which consists of a rack in a co-located remote ISP is far cheaper than it was 5 years ago.
The emergence of replication technologies and the cheapening of IP connections making real time replication viable for many more companies than it was five years ago.
Novel business models, like Application Service Provider (ASP), now called Service Oriented Architecture (SOA), which allow the effective outsourcing of DR risk.
In your opinion, how often should a disaster recovery plan be tested and updated and who should be responsible for managing the plan?
DR plans need to be tested once before they're deployed (it's amazing how many people don't do this) and then again about annually to make sure all the infrastructure is working. Since DR is basically infrastructure and application protection, responsibility falls to the most senior IT person (usually the CIO). What tools and techniques can a contact center employ to monitor the 'health' of their center and prevent disasters occurring in the first place?
The basic lesson is to pay attention to the details: Components manufactured in the same batch tend to fail at about the same time. If you spend the money on redundancy (like RAID or server equipment) make sure you monitor it. Once one disk blows in a RAID array, the next failure will take your data out.
Do you know the temperature in your data center? If not, you should; when it rises unacceptably, it can fry all your equipment and data.
A wide variety of management consoles exist to bring all these machine parameters to the attention of the system administrator on duty (with alerts if they go over the acceptable norms).
About James Bottomley:
James Bottomley is Chief Technology Officer for SteelEye Technology, responsible for future products and research programs solving issues around disaster recovery and high availability of applications. James is also a committed member of the Open Source community, currently holding the Linux Kernel SCSI Maintainership. About SteelEye Technology, Inc:
SteelEye Technology provides data and application availability management solutions for business continuity and disaster recovery. The SteelEye LifeKeeper family of application-focused data replication, high availability clustering and disaster recovery solutions enable enterprises of all sizes to ensure continuous availability of business-critical applications, servers and data. | 
