So Bob, how did the disaster recovery test go on the weekend?

If you work in the IT industry, I am pretty confident that you have been asked this question before - but how do you answer it? Something like: "It was ok... there were a few problems but we are confident that all the issues we experienced will be resolved by the next test." Sound like an answer you would give? Not very convincing, is it?

The first question I need to pose here is: do you have a disaster recovery (DR) plan in place? If your answer is no, stop reading this article immediately and go and create one (come back once done).

For those who have a plan in place, there are a couple of follow-up questions to be answered, like:

* Is your DR plan properly documented with the required detail?
* How often is your DR plan tested?
* Is your DR plan followed to the letter? How do you know?
* Will your plan pass the `auditor`s test`?

The aim of this article is not to assist you with writing a DR plan (unfortunately you`re on your own with that one), but there are some easy ways that you can test and improve the effectiveness of your DR system, resulting in accurate compliance and governance that will make your boss, his boss, the auditor, and ultimately the CIO, extremely happy.

In the IT industry there is a relatively new area of focus called `IT process automation` or `runbook automation`. So what is it? In layman`s terms, it is effectively taking those dusty DR manuals and procedures and creating an `intellectual property (IP)` repository where these DR processes and procedures can be stored, managed, updated and re-used at will.

The runbook in the repository cannot be changed by the user so your critical business applications remain safe and uncompromised. Runbooks can be run on an ad hoc basis, as and when the need arises, or can be scheduled at regular intervals to perform these checks automatically. The bonus for the NOC supervisor is that his people can now be deployed elsewhere and time is not taken up by mundane repetitive tasks - crumbs, that`s what computers were invented for, so let`s leave them to do just that.

If we use our example of a DR situation, say a catastrophic failure on an e-mail system, your runbook could incorporate the following steps:

* Ensure that the DR event is declared and that a change request is logged and approved.
* Validate that all components of the DR site are in place and operational, namely networks, servers, applications and storage.
* Define and perform all the failover tasks.
* Once complete, determine if the e-mail system is available and then close the change and declare the DR event complete.

A good runbook solution should be able to provide an easy and intuitive build environment for you to design your flows, as well as a debug environment for testing and quality assurance. This system will also allow you to execute workflows quickly, efficiently and reliably and also provides click of a button documentation creation; a reporting mechanism which focuses on management information.

Boss: So Bob, how did the disaster recovery test go on the weekend?
Bob: The DR test was a complete success thanks to our runbook solution we implemented last month. Here`s the documentation, all completed and signed off ready for the auditor.

Too good to be true? Believe it... it`s possible.

(c) 2010 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.

The only warranties for HP products and services are set forth inn the express warranty statements accompanying such products and services. Nothing herein should be constructed as constructing an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.