评估开发运维ROI的五个关键指标!

译文
新闻
如果密切关注上市时间和降低基础设施成本等因素,就可以评估开发运维(DevOps)的投资回报率。

【51CTO.com快译】“DevOps”的全称是“开发和运维”,但这个术语一点也不简明扼要。开发运维已变得如此臃肿、复杂和有争议,要是不先定义它,就没法讨论其投资回报率(ROI)。 

正确理解DevOps

想要弄清楚Devops的ROI,可以先这样来理解DevDps:有武术,有柔术,还有柔道(这是柔术的分支,里约奥运会上出现过的项目)。而软件开发就好比是武术,敏捷方法是柔术,开发运维则是柔道。

开发运维有六大特征,它们带来了我们力求衡量的投资回报率:

1. 连续集成(CI):开发人员和测试人员验证新代码的流程。

2. 持续交付(CD):创建可发布工件的流程。

3. 动态云基础设施:优化计算资源的基础设施虚拟化。

4. 测试自动化:执行功能测试和接口测试的脚本。

5. 安全自动化:执行安全检查的脚本,越来越多地被称为开发安全运维(DevSecOps)。

6. 监控:不断衡量环境,积极主动地解决问题。

开发、运维和质量保证(QA)等团队协同工作,让开发运维成为可能。人们搞开发运维,并非因为它是潮流、或带有神秘色彩,而是为了满足业务目标。坦率地说,许多公司在开发上投入了大笔开支,期望能赚到大笔收入。

[[173416]] 

记牢五个评估指标

想在拥挤不堪的应用程序商店或企业市场中竞争,技术公司就要迅速交付新产品,不断更新产品,并严格确保质量。只有这样,公司才能获得旧的“瀑布模式”或基本的敏捷方法无法获得的投资回报率。那么,开发运维部门应如何衡量其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】

责任编辑:wangxuze 来源: 51CTO.com
相关推荐

2021-04-26 23:03:48

运维并发Linux

2021-08-10 08:44:13

系统性能优化

2023-01-10 10:06:18

数据备份

2023-03-22 11:52:52

AI算法

2020-04-07 11:00:30

大数据大数据是软件即服务SaaS

2020-10-16 12:00:47

勒索软件驻留时间攻击

2022-09-06 12:40:42

安全运营网络安全

2020-07-06 09:41:47

开发运维软件开发开发运维工具

2023-12-28 10:44:20

DevOps开发运维

2013-09-09 13:48:28

移动应用指标运营

2023-12-21 11:59:29

2014-01-22 10:09:09

2022-01-14 12:48:07

数据分析关键指标产品

2022-01-09 16:45:36

前端性能优化编程

2016-10-18 14:22:58

开发运维

2016-10-18 11:26:54

开发运维开源

2023-05-25 13:56:58

2024-02-27 10:15:48

混合云数据科学数据管理

2023-11-27 08:00:00

数据可观察性ROI

2023-10-27 09:34:34

携程应用
点赞
收藏

51CTO技术栈公众号