问题描述
想要了解如何捕获数据以开始测量”修复时间平均值（MTTR）”指标，并且需要理清”回滚”如何对MTTR产生正面或负面影响。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
回滚与MTTR的关系
“回滚”是一种恢复机制，它的目标是快速恢复系统稳定性，但这可能会导致计划内的更改被暂停。在某些情况下，回滚可能会对MTTR产生积极的影响，尤其是在以下情况下：
1. 紧急性事件： 假设部署的代码引发了迅速被发现的事故（低MTTI，平均检测时间），此时可以选择回滚以迅速恢复稳定性。
2. 降低风险： 回滚可以减少业务风险，确保系统稳定。这使得问题得到解决之前，不会出现新的业务中断。
在这些情况下，回滚有助于降低MTTR，因为它能够迅速恢复系统稳定性。然而，需要权衡回滚对预期功能发布的影响，因为回滚后这些功能将无法在生产环境中使用。
向前与MTTR的关系
“向前”是一种冒险，它在修复问题的同时，还保持了计划内更改的进行。这可能导致MTTR延长，因为即使回滚，直到”修复后”的代码变得正常运行，MTTR的计时器仍在运行。
在这种情况下，MTTR似乎与业务结果的稳定性密切相关，而不仅仅是”嘿，事情变得稳定了”。
然而，向前也有风险。它可能会增加业务风险，因为这个修复可能会因稳定性问题而被迫匆忙推出，而没有足够的测试。向前是新代码的另一版本，之前可能没有经过充分的检查。
如何保持低MTTR
如果要保持低MTTR，建议立即回滚，无需讨论。这样可以消除业务风险，并在尝试部署修复之前检查修复是否实际有效。强烈建议将此作为策略，因为几乎总会有人要求修复而不是回滚，并召开会议来讨论/决定，而此时业务仍处于风险之中。
其他衡量指标
值得注意的是，如果你关心高变更失败率（Change Failure Rate），那么建议检查实际的回滚率，而不是从低MTTR中推导出来。也许你想在部署之前添加一个门控检查，针对最常见的失败情况。如果已经自动化了此检查 – 为什么不将其包括在CI验证中？如果还没有 – 也许现在是开始考虑的时候了？
这个问题可能涉及到开发人员和运维工程师之间的冲突，因为传统上，开发人员负责实施新功能，而运维工程师负责防止事情崩溃。这往往会导致部门之间的冲突，因为变更往往会导致故障。 DevOps背后的哲学之一是开发人员和运维工程师应该密切合作，以缓解这种紧张局势。
你可能还对Google的方法感兴趣，他们为开发团队制定了“错误预算”（error budgets）；一旦稳定性受到过多的惩罚，他们在本季度的其余时间必须只专注于稳定性。与此同时，网站可靠性工程师也有可用的目标，如果超出目标，他们会被鼓励让更多的变更通过；这里的想法是他们的目标不能简单地是将稳定性维持在尽可能高的水平，因为那样他们将在每种情况下都会被迫抵制变化。
综上所述，回滚和向前在MTTR中扮演着不同的角色。回滚可以帮助降低MTTR并恢复系统稳定性，而向前则可能延长MTTR，因为它要等到修复后的代码变得正常运行。维护低MTTR的关键是要根据业务需求和风险权衡回滚和向前的决策。同时，关注变更回滚率以及实施门控检查等措施，有助于更好地管理变更的质量和稳定性。最终，开发人员和运维工程师之间的紧密合作以及明确的错误预算等方法，也可以促进业务和稳定性之间的平衡。