有哪些方法可以评估DevOps的ROI？

#1 楼

好问题！我们大多数人都知道，出于种种原因，对DevOps实践进行投资是非常值得的追求。但是，我们并不经常仅靠DevOps来证明对底线的影响。

注意：这是一个自以为是的问题，我的回答也是自以为是的。

Tensibai明智地建议我们找到正确的指标，并以上市时间为例。这是一种很棒的全局方法。

作为一种替代方法，我在bean计数器方面的经验是，他们不需要-或一定要-知道全局，他们只是想要财政责任的证据。他们希望看到正确方向的发展趋势。

以下只是一些财务上的优势：


计算通过利用自动扩展节省的服务器成本云，用于创收站点，推断出每分钟的停机时间成本，然后再次显示MTTI和MTTR的改善

，对于创收站点，估算成本通过利用基于过去事件的高可用性架构节省了三分钟的时间
，如果您在构建和部署管道方面进行了改进，则表明您已经减少了由于已跟踪的故障而导致的生产回归和错误
如果您已经改进了开发人员测试环境，甚至改进了开发人员笔记本电脑上的工具和配置，请查看提交历史记录，看看新工程师加入后是否能尽快做出自己的第一贡献？
在云和就像Gitlab最近所做的那样，在本地部署来证明您的基础架构支出合理（又名节省！）然而，如果您精打细算，并且赢得了一些明显的胜利，通常就足够了。我当然错过了一些明显的例子。请随时在下面添加评论。

#2 楼

DevOps管道的关键指标是周期时间（也称为提前期）。这是进行更改（或进行更改请求，一直跟踪到构思开始）所花费的时间。我所知道的这个概念的最好例证是《目标》一书，该书在制造环境中进行了讨论。我们希望在DevOps管道中进行频繁部署。没有神奇的“ 1天好，2天坏”的度量；

部署规模：无论您的开发人员衡量工作水平（用户故事，故事点，棚屋等），都要进行度量。同样，您希望看到一段时间内的趋势，而不是绝对值。

在频率和大小之间有一个故事可以讲。我们的发行版变得越来越少并且越来越大吗？为什么？他们变得越来越小，越来越频繁吗？同样，为什么？

解释频率/大小趋势是否良好，我们还需要“失败部署百分比”。了解这三个指标中的“为什么”将告诉您很多有关项目运行状况的信息。

我个人最喜欢的，虽然是虚荣的指标，但是琐碎部署的时间。如果您发现最小的事情值得在整个站点上进行重新部署……也许是CEO的名字打错了……您从紧急电话转到部署站点的速度有多快？我之所以说“虚荣”，是因为它确实不是上述其他指标所讨论的那样具有预测性，但是当我喜欢该价值时会让我感觉很好。

如果我们要进行监控，那么会有很多我们可以跟踪的不同事物……从诸如“正常运行时间”之类的无所不包的事物，到诸如在请求-响应周期上重新生成自定义HTML所花费的时间之类的非常底层的事物……但是这些并非专门用于建立DevOps文化。

这些并不直接与美元挂钩……这样做将需要比我在这样的论坛中提供的有关组织的更多知识；但它们是开始回答该问题的关键。一旦知道您能够将工作作为非事件定期发布到生产中，就可以开始查看您之前浪费了多少精力。正如《目标》一书中所讲的（关于制造管道-这是相关的），本地优化看起来像是在省钱，但最终，它只会创造与库存相关的价值（未部署的功能）。

除了这些建议，您还应该查看过去几年的《 DevOps状态报告》。这充满了您可以模拟的有关现实世界项目的度量。

#3 楼

明显是船长：通过减少产品上市时间和发布缺陷。

要扩展到这条底线，通常的陷阱是没有任何参考的组织变更。

参与文化或组织变革意味着在培训和向人们介绍这种新方法时会花费一些费用，这不仅会增加培训成本，而且还意味着生产力下降，因为参加培训的人们不会生产任何东西。这是文化变革的投资部分。

要衡量投资回报率，您首先必须找到一些需要改进的相关指标（了解成本高昂，昂贵或利润损失的原因）。这样可以缩短产品上市时间，减少每次发行后的补丁，从而提高产品中的客户参与度。相关指标将高度依赖于您的产品。

衡量ROI（您支付培训费用的速度）意味着您实际上可以提出这些指标的发展，因此在使用变化，您必须定义这些指标并以客观的方式对其进行衡量。
一旦有了真实的发展，就可以告诉您是否确实以涵盖培训费用并比利润更丰厚的方式进行了改进

通常的陷阱是在定义任何指标之前进行更改，从而根据感觉而不是事实数据评估ROI。

生产率可以是度量，但通常很难以客观的方式对其进行度量，因此不应将其作为此类研究的一流度量。

#4 楼

在这里比赛晚了，但是我认为我会喜欢。

您无法管理您不测量的内容，因此对于初学者来说，这是devop团队应该跟踪事件响应的关键指标：



正常运行时间百分比：总可用时间百分比= [总时间-停机时间] / [总时间]

MTTR：平均时间解决方案= [停机时间] / [事件数]

MTTA：平均确认时间= [确认总时间] / [事件数]

MTBF：两次之间的平均时间故障= [总时间-停机时间] / [事件数量]

这些指标为您提供了运行状况的高级状态检查，并帮助您确定需要进一步挖掘的地方。

请看这里的白板动画，以更深入地了解该主题。

一旦了解了指标，就可以将它们与停机时间的成本进行比较。您可以从那里开始建立团队的ROI，并设置一些定量指标以进行持续改进。