如今，除了每年进行几次恢复性训练外，他们大多都是站着不动。但想想看:这是大量闲置的能量，等待着一件可能每年只发生几个小时的事情。有办法利用虚拟化技术,存储区域网络和软件定义网络的热备用灾难恢复能力可以用作DevOps“工作区”测试和计划同时也剩下最初的目的——可以接受失败的工作负载?
答案是肯定的。管理程序和虚拟机可以在几秒钟内上下旋转，软件定义的网络可以通过脚本以自动化的方式重新路由和分流到不同的连接和端点。事实上，在大多数情况下，环境已经可以访问这些数据，因此常规的应用程序和操作测试实际上可以在不需要长时间复制的情况下使用真实的数据。您是否可以要求一个更好的现实世界性能测试环境，而不是在生产基础设施的副本中工作?在需要故障转移的情况下，您可以让监控系统启动这些脚本，更改存储端点并关闭虚拟机——然后您就可以恢复热备份。在“灾难”结束时，您可以通过还原那些自动化脚本所做的所有更改来手动恢复服务。PowerShell是在Windows、Hyper-V和VMware环境中实现这一点的好方法，而Bash脚本也适用于Xen和其他管理程序。当然，Puppet、Chef和Ravello也可以在这方面提供帮助。
这里的想法是，让一些未使用的容量做一些有用的事情，同时又不完全失去其存在的目的。开发人员需要访问这个大铁来进行实际测试，并在比他们的开发机器单独支持的更高的容量和负载下找出性能问题。让热备份基础架构除了热备份之外什么都不做可能是拥抱DevOps的对立面;通过重新设想这类应用程序，如果你愿意，你也可以鱼与熊掌兼得。
问题要问
当您开始更多地考虑持续灾难恢复时，以下几点是您的团队需要考虑的。
[相关:敏捷、DevOps和类似的认证值得吗?]
我们如何“桌面化”灾难恢复过程?谁拥有要遵循的程序清单?谁来执行脚本或者负责自动化?我们如何模拟单个应用程序、整个工作负载和基础设施本身的故障?哪些类型的场景会导致这些关键元素中的每一个失败?
关于灾难恢复，我可以强调哪些员工天生的优势?虽然DevOps倾向于混合开发人员和运维人员的角色，但自然会有一些具有更强的运维倾向和经验的员工，他们应该被授权处理故障转移所需的问责性。在开发方面，如果编码人员的代码导致故障转移事件，那么他们就应该负责，而那些倾向于成为优秀调试人员的编码人员可能希望在这里弥补一些漏洞。
如何更好地利用我已经支付了费用的灾难恢复站点和现有基础设施?这个环境是否设置为易于虚拟化的建立和拆除?如果不是，我需要做什么才能达到准备状态?
这个故事，“DevOps世界中的灾难恢复”最初是由首席信息官 ．