问题和事件管理
容量管理
变更和发布管理
绝对清楚，这些功能曾经属于运营组织，现在由Agile / DevOps组织拥有。存在导致不良行为的现有KPI：
根源原因分析时间已完成：
驱动不完整的RCA只是为了使它们进入
测试执行时间：
禁用长期运行的测试，无论其业务价值如何。
云服务的平均利用率：
鼓励过度使用计算资源，从而导致响应时间变慢
在DevOps计划中，哪些关键绩效指标可用于鼓励良好行为？
#1 楼
我认为没有任何“通用” DevOps KPI。例如，速度不是很好，除非它不是您业务的关键驱动力。亚马逊非常关注速度，因为它们拥有庞大的零售业务。对于拥有100个用户的小型应用而言，这没那么重要。这引出了一个问题：您如何选择与业务相关的最佳KPI？这是一个涉及整个企业的研究和发现过程。
您关心的是什么？
质量
可靠性
可维护性
速度
流程改进
服务水平
是什么让您的业务干系人晚上忙？什么因素决定您本季度是否能赚钱？上面的列表可能包括其中的某些内容，也可能没有。列出您的清单，然后弄清楚如何调整各个部门的激励措施以实现这些激励措施。
激励行为，因此就SMART目标进行协作决策。从脑力激荡的清单中选择两个或三个项目，然后为每个项目开始一个度量/修复反馈周期。不要一次选择太多-专注于两到三件事，您更有可能获得成功。
#2 楼
DevOps没有任何KPI。这就像问什么是爱的关键绩效指标。但是您提到的某些事情（问题和事件管理，容量管理，变更和发布管理）确实具有良好的KPI，其中有些是基于DevOps背后的理论的。一般来说，对于任何在业务流程中，您可以创建一个价值链图，描述价值从客户到企业再到客户的流向。整个循环始终必须以客户为起点和终点，但是有时候，对于服务组织而言，客户可以是内部的。通过这样的链条获得的价值吞吐量可能是以防篡改方式设计KPI的好方法。只要在价值链的任何单独环节中衡量任何KPI才有意义，只要该特定环节是流程的瓶颈，而您试图利用或提升该瓶颈。
KPI的常见问题是当它开始通过链的一半时。例如，更改和发布过程通常从开发人员开始，到部署结束。此过程不包括：
客户遇到问题
支持团队确定问题
产品团队为积压问题定义问题
解决方案团队针对客户
客户从解决方案中实现价值
问题在于，仅测量周期时间可能会导致两个主要问题：
瓶颈属于上述任何排除的部分，您的客户没有意识到价值，您也没有实现与周期时间成正比的收入。因此，尽管您的工程技术水平很高，但您的业务却受到损失。
与客户的脱节将使您的发布周期空无一物-尽管做出了更改，但仍未产生任何价值-甚至无法满足客户和工作的需求完成可能会带来负面的商业价值。
KPI的另一个问题是，在与客户开始和结束时，它可能实际上无法衡量对客户的价值。一个很好的例子是问题和事件响应流程以及将MTTR（平均修复时间）作为KPI。这个问题甚至影响到任何人吗？对客户来说有什么价值？在100次事件中，您可能具有3个小时的出色MTTR。但是，如果其中大多数事件是内部事件，对客户的影响没有或影响很小，并且在几分钟之内解决了，而一次具有巨大客户影响的大事件需要3天的时间来处理，则业务价值要比1天的MTTR要低，因为忽略大多数内部事件，但是您在1小时内对巨大的客户影响事件做出了响应。
注意：对于内部客户，在支持团队业务流程的情况下，得出的价值不是工作对内部客户的价值，但企业在解除内部客户自身业务流程的封锁中所获得的价值。与解除非瓶颈团队或个人相比，解除对自身流程中瓶颈的团队的价值更高。这样的支持团队的所有KPI都需要在计算中包括业务价值。
#3 楼
部署频率
部署速度
部署成功率
部署失败后如何快速恢复服务
最后，
DevOps Culture，实际上无法测量
评论
5.DevOpsCulture，实际上无法衡量=>为参与其中的每个人做一个匿名问卷调查，甚至询问他们对这一切的感觉如何。这肯定会告诉您您是否有一个过程是您的员工执行的，或者实际上是否有很多人不在门外……
– AnoE
17年11月23日14:02
评论
您已经发现所有KPI都存在固有的问题。人们将努力使绩效指标最大化，而不是使实际绩效最大化。度量标准可以使人们获得更高的分数，即使以做好工作为代价，他们也会做到。@Adrian我同意，但是某些KPI（例如周期时间）本来就很难玩。
真正。但是，即使是那些难于使用的KPI也会导致针对KPI进行优化，这通常可能不是最佳选择，或者只是偏向于可以进行游戏的KPI。我发现很少有方法可以通过指标自动测量DevOps性能。它主要是主观的，需要个人观察和参与。
那不是DevOps，而是ITIL哈哈