Traditional disaster recovery planning usually involves a hot site with duplicates of all your IT and network infrastructure -- and there's the direct and indirect costs of staff relocation, logistics and more. When your business continuity plan calls to run as usual when disaster strikes the primary data center, a hot site is mandatory. But such planning brings challenges in terms of complexity and cost. And executing your plan involves a complete set of processes with all components being tested regularly. have you considered the cost of unplanned downtime? If downtime occurs, how much it will cost? How long will a recovery will take?
My advice: use what works, and borrow best practices from agile software development/ Come up with a prototype and put the plan in action, learn from it, and go back to to re-work the next iteration.
Spending a year studying what to do is foolhardy; attack the problem with a series of end-to-end sprints that allow your plan to evolve. You will know you've reach reached close to the end-state and built a better solution with each new iteration, which will require planning and execution. Like a software development sprint, deliver something every three months and involve all the stakeholders.
Your planning should cover moving the data you need to your recovery cloud, to ensure you have it available when you need it. Since we are talking technology here, make effective use of automation tools. Amazon's cloud provisioning, workload automation and process automation are good examples of the facilities you can tap today, so your organization can recover quickly, using tested and proven processes, with a clear audit trail and avoiding human error.
No comments:
Post a Comment