随着业务越来越依赖于应用来产生的收入，所以非常有必要让应用的宕机和故障时间降至最低。IDC 和 AppDynamics 研究表明，在24小时服务环境里，基础架构的故障成本是每小时$100,000美元。虽然从现实的角度来看，完全的避免应用故障是不可能的，但是用来预计和修复故障的时间仍然是一个可以提高的因素。

尽管如此，在这个相同的报告里面，35%的业务估计 IT 故障花费了12个小时修复，17%的受访者说修复一些关键应用程序故障可以花费好几天时间。

当应用失败时，收入损失迅速增加，显然，改变这一情况就意味着要为大量业务上的方案做出改进。然而，不合标准的硬件和架构常常处理着业务，不仅要找出还要修复问题，这是引发问题的主要原因。

在内部，企业组织的开发和运营团队之间都有明确的界线，两个部门在工作关系上还需要做出许多。当应用出现问题，责任最初被划归到运营部门，他们常使用大量的监测和管理工具，探索具体的和竖井式（siloed）架构组件，诸如CPU，内存和网络，而在这之前常常发现开发团队也需要被保证。

开发团队常常使用他们自己的诊断工具，这导致了数据有多个来源，多种来源的信息与最终多源头的结论相关。结果就是发现导致问题的根本原因的时间变得更长，对客户在商业上的损失还有自身的收入上都不幸地造成了影响。此外，开发团队常常工作在不同的模式及不同的地点，在开发团队能证明挑战时才能挑选正确的人。

但是，这不是一条必由之路。在DevOps文化的支持下，它的目标是让一个在开发团队和运营团队之间形成协作关系，并已经在IT部门显示出灵活性的改进，同样这也能提高应用修复的速度。

采用DevOps, 应用性能的责任是由两个部门分担的，这就意味着开发团队从开始就更参与其中。不是简单地开发代码，然后把代码给运维团队来部署上线，整个过程会被更平等地分担，确保两个团队对应用的性能都可见的。

例如通过实施应用性能监控(APM)，并让所有的干系人了解，IT部门可以更快地解决问题。另外，通过使用记录代码变更的源码控制系统，允许两个团队的成员理解双方的工作方式以及代码变更的原因。

DevOps的方式同时也让在生产环境的bug更容易更快地被发现和修复。在传统的模式下，开发环境同生产环境隔离，因为环境的差异，当新的特新和bug修复发布到现实世界的时候，它们有时不能正确的工作。

结果一旦代码上线，这会增加了出故障的可能性，并会增加故障的平均解决时间(MTTR)。环境的差异同时也意味着在代码部署到生产环境之前，运维团队经常需要修改配置，这又增加了代码的部署时间。结果开发和生产环境的数据不一致延缓了代码部署和变更的过程，这不可避免地增加了业务成本。

然而，通过采用作为 DevOps 一部分的自动化，许多这样的问题就可以避免了。通过自动化代码测试和环境的提供，可以大大地缩短花在这两个任务上的时间，并且确保两个环境是基于相同的配置。

这意味着开发人员可以开发更短的代码并以更快地速度部署到开发环境，这极大地降低了部署新特性、变更和 bug 修复的时间。实际上，IDC 和 AppDynamics 报告显示业务预计 DevOps 将会提高15-20%的交付能力，这表明了这种模式可以带来的速度的改进。

然而，当 DevOps 加快新的应用和特性的交付速度，优化了员工的生产率和提高客户满意度，很重要的一点是在变更加快的同时，没有造成应用的宕机时间增加。

例如 Gartner 预测2015年80%的服务中断将是由人和流程引起的， 其中超过50%将会由变更配置和发布整合引起的。

通过让运维和开发团队了解整个的应用的生命周期，业务可以使用 APM 作为一种反馈和前馈相关的信息到软件开发周期(SDLC)。 这有助于确保新的发布和变更不会在运行或生产环境造成业务影响。

为了让 DevOps 起作用，CIO 们将需要克服不少的文化挑战，包括在业务的工作方式，和在招聘合适IT技术人员以支持 DevOps 的采用。

例如，组织现在需要理解或者有能力承担复杂的基础架构自动化任务的开发人员，以及具有所需软件基本的编程技能的运维人员。

就像之前说的，保持应用的平稳运行和作为结果可以实现的成本缩减的必要性意味着这些变化是为了满足客户需求和产生收益所必须的。

John Rakowski 是 AppDynamics 解决方案的讲师。

在从 ITProPortal.com 的许可证之下发布，网社区有限公司出版。保留所有权利。