【51CTO.com快译】“DevOps”的全称是“开发和运维”，但这个术语一点也不简明扼要。开发运维已变得如此臃肿、复杂和有争议，要是不先定义它，就没法讨论其投资回报率(ROI)。
正确理解DevOps
想要弄清楚Devops的ROI，可以先这样来理解DevDps：有武术，有柔术，还有柔道(这是柔术的分支，里约奥运会上出现过的项目)。而软件开发就好比是武术，敏捷方法是柔术，开发运维则是柔道。
开发运维有六大特征，它们带来了我们力求衡量的投资回报率：
1. 连续集成(CI)：开发人员和测试人员验证新代码的流程。
2. 持续交付(CD)：创建可发布工件的流程。
3. 动态云基础设施：优化计算资源的基础设施虚拟化。
4. 测试自动化：执行功能测试和接口测试的脚本。
5. 安全自动化：执行安全检查的脚本，越来越多地被称为开发安全运维(DevSecOps)。
6. 监控：不断衡量环境，积极主动地解决问题。
开发、运维和质量保证(QA)等团队协同工作，让开发运维成为可能。人们搞开发运维，并非因为它是潮流、或带有神秘色彩，而是为了满足业务目标。坦率地说，许多公司在开发上投入了大笔开支，期望能赚到大笔收入。
记牢五个评估指标
想在拥挤不堪的应用程序商店或企业市场中竞争，技术公司就要迅速交付新产品，不断更新产品，并严格确保质量。只有这样，公司才能获得旧的“瀑布模式”或基本的敏捷方法无法获得的投资回报率。那么，开发运维部门应如何衡量其ROI呢?我认为，可以参考以下五个指标：
1. 更短的上市时间
开发运维部门的一些敏捷团队每天多次发布软件，而其他团队发布软件则没有这么频繁。市场形势和经营战略决定了发布的步伐。但有时候，公司需要抢在竞争对手之前，尽快将创意变成产品。率先发布，其投资回报可能会高达数十亿美元。在这种情况下，我看好奉行开发运维理念的公司。
衡量上市时间很简单。比较一下瀑布模型下的周期时间和开发运维下的周期时间。在竞相进入市场的情况下，你的平均周期可以很好地表明你的团队能做什么。正如古希腊诗人阿基洛克斯所说：“我们无法上升到我们的期望水平，而是落到我们的训练水平。”
2. 更少的员工和更高的生产力
你可以从玻璃杯半空或玻璃杯半满的角度来看待开发运维和人才。悲观主义者可能会说，开发运维破坏了工作，因为它让公司能够用更少的人发布更多的软件。乐观主义者可能会说，开发运维让公司避免雇用不必要的员工。
这两种观点都有其道理;无论你削减人员还是从不添加人员，开发运维都能节省资金。可以从运维团队身上看到最显著的差异。借助开发运维，同样数量的人可以管理100台或1000台服务器。自动化使规模方面的差异显得不再重要。
3. 没有停机
有缺陷的代码和不堪重负的基础设施经常导致系统停机，因而每秒可能损失数千美元。当然，只有停机发生，它才是切实的成本。所以，大多数公司等到因停机而损失数百万美元后才投入于开发运维。我不会怪它们。你知道有多少人拥有备用发电机以防停电吗?除非你经历了没电的三个黑夜，否则不会备有发电机。
持续集成和持续交付(CI/CD)结合自动化测试和安全检查可生成异常稳定的代码，从而防止停机。此外，一种基于云的动态基础设施能够按需扩展，并自动顾及系统故障，它能减小流量波动的风险。通过自动化分配和重新分配服务器和容器，开发运维消除了原本导致系统崩溃的瓶颈。
同样重要的是，开发运维通过利用“微服务”来应对停机，微服务是这些年来系统架构领域最重要的技术之一，也是许多开发运维团队的一种关键工具。软件平台过去是一种单一整体式系统。如果登录服务停止工作或变得不堪重负，平台的其余部分就停止运行。现在，开发运维组织创建了几十个、甚至几百个微服务，它们都由API连接起来。如果一个微服务失效，其余微服务可以继续工作，只要平台设计正确。因而，微服务可以缩减停机时间，消除令人痛苦的停运。
4. 降低基础设施成本
微服务不仅更可靠，而且成本低得多。你可以构建应用程序，只在有需要的地方添加额外的计算能力。此外，使用容器，你可以榨取最后一滴效率，从而实现每个实例最大限度地提高资源利用率。结合动态云基础设施，你可以设置实例库和容器库，以便随着工作负载的增加或减少，资源库可以自动扩展或缩减。
一个完美的例子是亚马逊网站。节假日期间，它要处理庞大的流量，因此按需创建额外的服务器实例。它可能发现，Tickle Me Elmo成为人人都想要的热门玩具，于是它可以为其系统的这一个方面添加更多的计算能力。亚马逊只把钱花在有必要投入的基础设施上。
同样，为了衡量开发运维的投资回报率，要关注长期的变化。在早期(即瀑布开发年代)，你在虚拟机上花了什么?现在你又花了什么?还要考虑到用户群规模以及你所提供服务的范围。
5. 提高应用程序的质量和性能
质量和性能是很难衡量的特征。它们影响三种类型的衡量指标：服务单(service ticket)、使用模式和需求信号。你要以不同的方式来衡量这些，具体取决于贵公司。
假设你为内部客户开发企业应用程序。你在发布后的头48小时内生成多少服务单?最终用户如何与新功能进行交互?牢记一点：如果用户没有与新功能进行交互，不会生成任何服务单。多少现有用户下载最新版本、下载速度有多快?
反过来，如果你为外部客户开发企业应用程序，要关注客户服务活动、使用模式和销售活动。如果是面向消费者的应用程序，你可以查看应用程序商店上的评分、使用模式、下载次数和应用程序商店的转化率。
针对时间不够用的人
实施开发运维的投资回报率挺复杂。因为开发运维对运维成本和收入方面改善很多，以致于企业很难计算所有好的一面。不过，如果你是时间有限的CTO或CIO，好处很明确。成功标准就是更稳定、更安全、更频繁发布的代码。
无论IT达到何种水平，团队都会得益于开发运维方法带来的更快速度、更高质量和一致性。这方面根本不存在臃肿、复杂或有争议的东西。
原文标题：The ROI of DevOps: 5 Key Metrics，作者： Guest Author
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
