哪些关键绩效指标（KPI）用于衡量DevOps？

我试图在DevOps转换计划中推动良好的行为，以支持这一点，我正在寻找围绕运营准则确定可行的指标：

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

绝对要清楚，这些功能曾经属于运营组织，现在由Agile / DevOps组织拥有。现有导致不良行为的KPI是：

• 根本原因分析时间已完成：
  • 驱动不完整的RCA只是为了使它们按时进入系统。
• 测试执行时间：
  • 禁用长期运行的测试，无论其业务价值如何。
• 云服务的平均利用率：
  • 鼓励过度使用计算资源，从而导致响应时间变慢

在DevOps计划中，哪些关键绩效指标可用于鼓励良好行为？

我认为没有任何“通用” DevOps KPI。例如，速度不是很好，除非它不是您业务的关键驱动力。亚马逊非常关注速度，因为它们拥有庞大的零售业务。对于拥有100个用户的小型应用而言，这并不重要。

这引出了一个问题：如何您选择相关的关键绩效指标最好的公司吗？这是一个涉及整个企业的研究和发现过程。

你在乎什么

• 质量
• 可靠性
• 可维护性
• 速度
• 流程改进
• 服务水平

是什么让您的业务干系人彻夜难眠？什么因素决定您本季度是否能赚钱？上面的列表可能包括其中一些内容，也可能没有。列出您的清单，然后弄清楚如何调整各个部门的激励措施以实现这些激励措施。

激励因素会驱动行为，因此就SMART目标进行协作决策。从脑力激荡的清单中选择两个或三个项目，然后为每个项目开始一个度量/修复反馈周期。不要一次选择太多-通过专注于两三件事，您更有可能获得成功。

DevOps没有任何KPI。这就像问爱情的关键绩效指标。但是您提到的某些内容（问题和事件管理，容量管理，变更和发布管理）确实具有良好的KPI，其中某些基于DevOps背后的理论。

通常，对于任何业务流程，您都可以创建一个价值链图，以描述价值如何从客户流到企业，再流回客户。整个循环始终必须以客户为起点和终点，但是有时候，对于服务组织而言，客户可以是内部的。该值吞吐量通过这样的链条可以设计你的KPI的防篡改方法的好方法。只要在价值链的任何单个链接中都测量该KPI，就有意义，只要该特定链接是流程的瓶颈，并且您试图利用或提升该瓶颈。

KPI的一个常见问题是它在链中途启动的时间。例如，更改和发布过程通常从开发人员开始，到部署结束。此过程不包括：

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

问题在于，仅测量周期时间可能会导致两个主要问题：

1. 瓶颈在上述任何被排除的部分中，您的客户没有实现价值，您没有实现与周期时间成正比的收入。因此，尽管您的工程技术出色，但您的业务却蒙受损失。

2. 与客户的断开连接将使您的发布周期变成空的-尽管进行了更改，但仍未产生任何价值-甚至抵消了客户的需求，并且所做的工作可能会带来负面的业务价值。

KPI的另一个问题是，在与客户开始和结束时，它实际上可能无法衡量对客户的价值。一个很好的例子是问题和事件响应流程以及MTTR（平均修复时间）作为KPI。这个问题甚至影响到任何人吗？对客户来说有什么价值？在100次事件中，您可能具有3个小时的出色MTTR。但是，如果其中大多数事件是内部事件，对客户的影响没有或影响很小，并且在几分钟之内解决了，而一次具有巨大客户影响的大事件需要3天的时间来处理，则业务价值要比您有1天的MTTR来得低，因为忽略大多数内部事件，但是您在1小时内就对巨大的客户影响事件做出了响应。

注意：对于内部客户，在支持团队业务流程的情况下，派生的价值不是对内部客户的工作价值，而是业务在解除内部客户自身业务流程的阻塞中所获得的价值。与解除非瓶颈团队或个人的封锁相比，解除对自身流程瓶颈的团队的价值更高。这样的支持团队的所有KPI都需要在计算中包括业务价值。

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