根据一项IT革命出版社与Puppet实验室联合进行的2015年调查在美国，使用DevOps的组织部署代码的速度比其他组织快30倍，每天进行多次部署。此外，与非DevOps组织相比，DevOps的更改失败减少了一半，服务恢复的速度高达168倍。
DevOps:更快地失败，更快地恢复
让我们来关注一下最后两点。有一件事是肯定的:拥抱DevOps也回报从灾难恢复的角度来看,因为您使用的工具和程序,将应用程序从开发到测试到生产和重新开发也可以应用到故障转移,从灾害中恢复和服务中断。自动化整个DevOps生命周期的工具也可以帮助您最大限度地利用已有的资源进行恢复。
确实有很多开源工具可以帮助实现这种自动化，比如Chef和Puppet，它们以一种自动化的方式创建、启动和部署新的虚拟机实例，并适当地配置它们。它们甚至可以跨越安全边界，部署在您的私人笔记本电脑上，部署在您自己的数据中心中，甚至部署在公共云上——Amazon Web Services和Microsoft Azure是支持雷竞技电脑网站Chef和Puppet的两个主要公共云提供商。通过使用这些工具，您不仅可以自动化开发人员使用开发机器环境和配置的副本编写的新代码的部署;您还可以在几分钟内组织和启动云中的备份环境。如果你把木偶和厨师像Oracle这样的工具Ravello(如果你的公共云是Amazon Web服务或谷歌)的VMware和KVM虚拟部署,您可以嵌套虚拟机监控程序,这样您就可以运行您的虚拟环境在公共云——网络、寻址和更多无需任何更改，以自动化方式部署。从DevOps和灾难恢复的角度来看，这些都是非常强大的工具。使用这些工具，您可以快速构建、测试、部署软件，减少bug并提供健壮的故障转移和恢复解决方案。持续部署变成了持续的灾难恢复和故障转移。
[相关:DevOps对安全性是好还是坏?］
DevOps的主要原则是，开发人员应该在运行代码的生产环境副本中编写代码并测试应用程序。使用虚拟机和容器解决方案(如运行在个人笔记本电脑或台式机上的Docker)，这通常几乎可以实现。当然，这比在Xcode或Visual Studio中盲目地编写代码，然后将包发送给系统管理员进行部署要好得多，但我说过近因为即使是这种类型的虚拟化也不能完全模拟真实生产环境的容量限制。例如，在一个运行在苹果MacBook Air上的容器化微服务上测试实际负载是很困难的，但是负载测试可以在一个完整的Azure Stack服务部署上以一种更现实、更可操作的方式进行。
灾难恢复环境作为潜在的DevOps工作区
一些公司发现，随着他们在更深层次上进一步接受DevOps，他们的开发人员将不断要求访问热备灾难恢复环境，以减轻“单台笔记本或台式机”的限制。一般来说,中型和大型组织有显著的备份的基础设施投资,几乎完全副本关键生产工作负载和运行的环境,这些工作负载需要导入到备用,以防在发生服务中断或灾难。