我试图了解捕获数据的最佳方法，以开始测量平均维修时间（MTTR）指标，我需要全神贯注于“回滚”如何对MTTR产生正面或负面影响。

方案1

假设已进行了可靠的监视，则部署了导致导致很快检测到事件的事件（MTTI较低）。在识别时，有两种主要的前进方式（是的，出于讨论目的，我将其简化了）：


回滚部署，快速返回稳定性，但没有预期的结果生产中的功能。
向前滚动，并进行了其他更改以解决事件并保留预期的功能。

在此场景中，MTTR相当低，因为可以恢复站点稳定性很快。就是说，变更的预期结果无法实现，因此代码/功能/变更仍然停留在过程中。如果目标的平均MTTR较低，则似乎可以将回滚作为一种恢复机制。

场景2

在这种情况下，严格按照MTTR需要多长时间来衡量预期的代码/功能/更改将在生产中正常运行。即使我回滚，直到我的“固定”代码更改进入产品，MTTR计时器仍在运行。在这种情况下，MTTR似乎与业务结果的稳定性有关，而不仅仅是纯粹的“嘿，事情很稳定”。

现在，答案可能很简单，因为MTTR并不是在真空中用作度量标准，而是与变更失败率结合使用-由频繁回滚导致的MTTR极低可能表明天高的变更失败率。也就是说，将MTTR度量值与业务结果相分离的想法对我来说似乎是不对的。

我可能对此有个过分的思考，但是我很好奇其他人如何衡量MTTR以及“恢复”的最终时间点是什么。您是将其简单地用作稳定性，还是其他因素决定了“恢复”的含义？

#1 楼

是的，MTTR始终/应该始终与业务成果联系在一起：如果事情不稳定，则业务将面临风险。

预期的代码/功能/变更仍在处理中方案1无关紧要：此功能不稳定，因此不会带来新业务，从当时的业务前景来看，回滚是您可以做的最好的事情。使业务处于风险中，等待潜在的修复，实际上，从统计上来说，成功的变化较小（由于不稳定，与最初造成不稳定的变化相比，它总是会被匆忙处理，甚至没有施加这样的压力）。前滚是之前未检查过的代码的另一个版本。

如果您想将MTTR保持在较低水平，请立即回滚，而无需争论。这样可以消除业务风险，并让您有机会在尝试部署此修补程序之前检查其是否确实有效。我强烈建议将其作为一项政策，因为是的，几乎总是会有人要求修复而不是回滚，并召集会议进行谈判/决定，而这一切都在企业处于危险之中。

侧面说明：如果您担心变更失败率较高，那么我建议您检查实际的回滚率，而不是从较低的MTRR中得出。也许您想在部署之前添加登机检查，以查找最常见的故障。
如果您已经自动进行了此类检查-为什么不将其包括在CI验证中？如果您没有，也许是时候开始考虑了？ :)

评论

总的来说，我认为我应该同意回滚应该是标准的立场，但这似乎是devops世界中讨论/辩论的重点。我看到很多东西说永不回滚，唯一的选择就是前滚。我可以看到双方的风险/回报逻辑。令我惊讶的是，您严格将MTTR视为一种稳定性措施，而回滚提供了最佳的稳定性选项。在“仅前滚”模型中，MTTR的稳定性包括变更的业务结果。这仅仅是回滚/前进辩论的哪一方面的问题？

–史蒂夫·克莱门特
17年5月24日在12:04
永不回滚？太疯狂了假设将更改部署到产品中，从而揭示了在测试期间未暴露的特定于环境的缺陷。整个服务中断，修复将需要几个小时。应该禁止任何人在开发修补程序的过程中投票让产品腐烂，而不仅仅是回退，因此必须禁止IT人员参与。

–阿德里安
17年5月24日在17:17

#2 楼

平均恢复时间有一个隐含的主题-平均恢复时间是什么？定义这是有效使用该指标的关键。

您是否恢复了生产网站的总体可用性？您是否正在恢复具有错误的特定功能的功能？一旦知道了您实际要测量的内容，就可以更轻松地进行测量！

您的问题的总体主旨似乎实际上是围绕运输功能和维护可靠性的竞争目标，即一场古老的战斗。传统上，开发人员的工作是实施新事物，系统管理员的工作是防止事物破损，这会导致部门冲突，因为变更往往会导致破损。与DevOps相关的一种理念是，开发人员和操作工程师应密切合作以缓解这种紧张关系。

您可能还对Google解决该问题的方法感兴趣，即有“错误预算”供开发团队使用；一旦他们过多地破坏了稳定性，他们就必须将剩下的四分之一时间都花在稳定性上。除此之外，站点可靠性工程师还有一些可用的目标，如果他们过头了，就会鼓励他们进行更多的更改。这里的想法是，他们的目标绝不能只是保持尽可能高的可靠性，否则他们会被激励去应对各种情况下的变化。