使用哪些关键绩效指标(KPI)来衡量DevOps？

Question

我试图在DevOps转换程序中驱动良好的行为，为了支持这一点，我将围绕操作规程来确定可操作的度量标准：

• 问题与事件管理
• 容量管理
• 变更和发布管理

非常清楚的是，这些功能过去属于运营组织，现在属于敏捷/DevOps组织。现有的KPI驱动不良行为的原因有：

• 完成根本原因分析的时间：
  • 驱动不完整的RCA只是为了让他们及时进入系统。

• 测试执行持续时间：
  • 禁用长时间运行的测试，而不考虑其业务价值。

• 云服务的平均利用率：
  • 鼓励计算资源的过度投入，导致响应时间较慢。

在DevOps项目中可以使用哪些关键绩效指标来鼓励良好行为？

Answer 1

我不认为有任何“通用”的DevOps KPI。例如，速度是很好的，除非它不是你的业务的关键驱动力。亚马逊非常关心速度，因为他们拥有庞大的零售业务。对于一个拥有100个用户的小型应用程序来说，这一点就不那么重要了。

这就引出了一个问题:您如何选择与您的业务相关的最佳KPI？这是一个涉及整个企业的研究和发现过程。

你在乎什么？

• 质量
• 可靠性
• 维修性
• 速度
• 工艺改进
• 服务水平

是什么让你的商业利益相关者夜不能寐？是什么决定了你这个季度是否赚钱？上面的列表可能包括其中的一些内容，也可能没有。列出你的清单，然后找出如何使每个部门的激励措施一致以实现这些目标。

激励驱动行为，因此合作决定聪明的目标。从你的头脑风暴清单中挑选两到三个项目，并为每个项目启动一个度量/修正反馈周期。不要一次选太多--你更有可能通过专注于两三件事情来成功。

Answer 2

DevOps没有任何KPI。这就像问什么是爱的KPI。但是您提到的一些东西(问题和事件管理、容量管理、变更和发布管理)确实有很好的KPI，其中有些是基于DevOps背后的理论。

通常，对于任何业务流程，您都可以创建一个价值链图，描述价值如何通过企业返回到客户。整个循环总是以Customer开始和结束，但有时，对于服务组织来说，客户可以是内部的。通过这样的链的价值吞吐量可以是一个很好的方式来设计您的KPI以防篡改的方式。在价值链的任何单个环节中测量任何KPI都是有意义的，只要该特定环节是流程的瓶颈，并且您试图利用或提升瓶颈。

KPI的一个常见问题是当它从半个链开始的时候。例如，更改和发布过程通常从开发人员开始，以部署结束。这一进程不包括：

• 有问题的顾客
• 支持小组发现问题
• 定义积压问题的产品团队
• 解决方案小组为客户自定义部署
• 客户从解决方案中实现价值

问题是，仅测量一个周期时间就可能导致两个主要问题：

1. 瓶颈是在上述任何一个被排除的部分，您的客户没有实现价值，您也没有意识到收入与您的周期时间的速度成正比。因此，虽然你的工程是优秀的，但你的业务受到影响。
2. 与客户的脱节会使你的发布周期变得空洞无物--尽管已经做了改变，却没有产生任何价值--或者甚至违背了客户的需求，而正在做的工作可能会产生负面的商业价值。

KPI的另一个问题是，在开始和结束于客户时，它可能实际上并不衡量对客户的价值。一个很好的例子是问题和事件响应过程，MTTR (平均修复时间)作为KPI。这个问题会影响到任何人吗？顾客的价值是什么？你可以拥有超过100起事故3小时的出色的MTTR。但是，如果大多数都是内部的，对客户没有或最小的影响并在几分钟内就解决了，而一个对客户产生巨大影响的大型事件需要3天才能处理，那么业务价值就会低于1天MTTR，因为你忽略了大多数内部事件，但你在1小时内就对巨大的客户影响事件做出了反应。

注意:对于内部客户，在支持团队业务流程的情况下，导出的价值不是工作对内部客户的价值，而是业务在自己的业务流程中释放内部客户所获得的价值。解锁一个团队，这是他们自己的流程中的一个瓶颈，它比解除一个非瓶颈的团队或个人具有更高的价值。这类支持团队的所有KPI都需要在计算中包含业务价值。

Answer 3

1. 部署频率
2. 部署速度
3. 部署成功率
4. 在失败的deployment之后恢复服务的速度，最后，
5. DevOps文化，实际上是无法衡量的