共计 3553 个字符，预计需要花费 9 分钟才能阅读完成。
谷歌提出的掂量 DevOps 品质的 DORA 指标让 MTTR（均匀复原工夫）名声大振。在本文中，你将理解到 MTTR 的作用、为什么它对行业钻研很有用、你可能被它误导的起因以及如何防止 MTTR 产生的弊病。
MTTR 到底是在测量什么？
MTTR 指均匀复原工夫，既是 Mean Time to Recovery，有时也是 Mean Time to Restore。它是指在产生故障后使零碎复原运行所需的工夫，它是 DORA 指标的一部分，目前曾经成为软件交付性能的规范。
当你的所有 DORA 指标都体现良好，那么就会领有疾速交付的高质量软件、更称心的员工，从而在所处的行业中获得竞争劣势。
如何计算 MTTR
收集 MTTR 须要收集每个故障从开始到完结的持续时间，而后将这些工夫相加，并用总数除以数量。一些团队会对所有事件进行排序，并抉择两头值来计算复原工夫的中位数。
软件交付过程会影响复原工夫，尤其是：
- 软件架构
- 文档
- 可观测性
- 部署流水线性能
当你能够疾速复原，事件的影响就会升高，客户也会更称心。因而，企业应该检查和调整流程以疾速复原并升高危险。
为什么 MTTR 对行业钻研很有用？
DevOps 钻研和评估（DORA）将考察作为钻研办法的一部分。须要各类数据和性能程度不同的企业对问题进行答复。DORA quick check 将 MTTR 问题表述为：
对于您开发的次要应用程序或服务，当产生影响用户的服务事件或故障（例如，计划外中断、服务受损）时，通常须要多长时间能力复原服务？
- 超过 6 个月
- 1- 6 个月之间
- 1 周到 1 个月之间
- 1 天到 1 周之间
- 小于 1 天
- 小于 1 个小时
大多数从事软件交付工作的人对故障持续时间都有大略的感觉，因而在考察中应用宽泛的选项能够让人们很容易抉择答案。钻研人员利用这些信息来寻找数据中的性能组，他们还寻找各种实际之间的关系以及对业务成绩的影响，并利用这些发现搭建 DevOps 构造方程模型。
为什么 MTTR 数据可能误导你的团队？
尽管 MTTR 在钻研中对性能组有帮忙，但这并不是你在团队中应用故障信息的形式。你应该利用这些信息从服务中断中学习，并改良今后的解决形式。最终目标并不是与其余团队或组织进行攀比。
如果要继续优化软件开发和交付流程，只关注平均数可能疏忽了一些重要信号。因而须要更细化的信息来理解故障解决的状况，并找到其起因。
Verica 事件数据库（VOID）蕴含了由近 600 个组织共享的超过 10000 个事件，他们在 VOID 报告中剖析了这些事件。在 2022 年的报告中对 MTTR 做出如下评论：
MTTR 不是掂量简单软件系统可靠性的可行指标，起因有很多，其中突出的起因是其存在潜在的差异性。
当数据量很大时，平均数所带来的差异性会变得平缓，但一般而言企业的故障频率不太可能会达到每月数千起（即在这个数量级才使平均数无效）。如果事件数量较少，平均数则成为一个不稳固的指标。甚至只管在事件治理方面有所改进，但平均数仍旧在减少。
VOID 数据库还发现， 大多数事件在 2 小时内失去解决，但存在一些长尾数据导致平均值被推高或推低 ，进而无奈代表客户对待系统可靠性的形式。
组织能够通过排除异样值来打消这种差异性，但那样就会暗藏一些有价值的信息。因而须要一个更好的办法应用这些数据来改善整个流程。
复原时长的用武之地
与其把事件复原工夫压缩成一个平均数，不如把每个持续时间绘制在图表上。应用散点图或箱线图（Box-and-whisker chart），在不失真实性的状况下将持续时间可视化。这能够显示趋势和异样值，这比平均数更有价值。
你当初能够清晰地理解修复时长的趋势，看看是否随着工夫的推移而改善。还能够辨认出异样值，并充沛探讨如何更好地解决它们，进而利用它们来改善事件治理和零碎稳定性。
如果事件须要代码修复，复原工夫取决于部署流水线的性能。可能疾速、平安地部署软件新版本也有助于进行事件治理。另外，引入监控和告警工具有助于帮忙企业在影响客户之前发现问题。
明确事件的定义
要获取大部分事件持续时间的数据，你须要对此有对立的定义：
- 什么是事件
- 什么是开始工夫
- 什么是完结工夫
对于事件，企业外部须要有一个清晰、统一的定义。它应该包含当零碎能够优雅地解决一个故障时，组织是否将其算作一个事件。例如，团队能够认为只有对客户产生影响的故障才是事件。
对于开始工夫和完结工夫也是一样的。是在导致事件产生的条件首次呈现时开始计时，还是在问题对客户可见时开始计时？依据定义，甚至可能呈现负的事件持续时间，即在故障影响到客户之前就解决了它。
就事件的定义和如何掂量其持续时间达成统一，使你的衡量标准更具可比性。当长期应用 DORA 指标时，它们可能不再能激发你进行下一步改良。你能够用 SPACE 框架设计一个新的掂量零碎。
应用 SPACE 框架来掂量事件响应
你能够通过 SPACE 框架来全面理解事件响应和治理，其将测量后果分为 5 个类别：
- 满意度和幸福感（Satisfaction and wellbeing）
- 体现（Performance）
- 活跃度（Activity）
- 沟通与合作（Communication and collaboration）
- 效率与流程（Efficiency and flow）
企业不用一次性采纳所有指标。SPACE 框架倡议至多在 3 个维度上进行测量，如果能涵盖集体、团队和零碎层面则更好。最终目标是倡议一套正当的测量方法来帮忙企业改良流程。
满意度和幸福感
定性考察在这里最无效，能够考察事件管理者，看他们对事件产生后复原的称心水平：
- 事件治理流程
- On-call 排期
- 在事件产生期间降级或拜访专家以提供帮忙的难易水平
还能够去查看相干数据以确定 On-call 排期的合理性：
- 当地工夫几点电话响起
体现
应用以下指标能够掂量事件治理体现：
- 零碎是否依照其可靠性指标执行
- 事变条件和察觉到事变产生之前的时长
- 解决事变所需的工夫
活跃度
事件活跃度并不仅仅是事件数量，其余指标也能够纳入参考。大部分数据其实曾经在你的现有零碎之中：
- 监控工具收回的告警数量
- 事件产生的数量
- 同时产生事件的数量
沟通与合作
信息通明对事件治理至关重要。你应该把这个维度纳入事件测量策略中。领有高质量的沟通将缩小解决故障所需的工夫，能够掂量以下指标：
- 每个事件所关涉的人员数量
- 每个事件波及多少个不同的团队
- 为解决一个事件建群的数量
- 查看事件报告的次数（或给予踊跃评估，或在其余事件中提到它）
效率及流程
当采纳效率和流程的指标时，就会发现零碎中的节约。如果重复“踢皮球”，那么处理事件的进度就会停滞不前，解决工夫更长。以下指标能够帮你发现瘟疫：
- 重新分配事件的频率
- 每个事件尝试缓解的次数
SPACE 框架总结
当须要取得各种洞察并改良零碎时，团队应该自在构建并依据理论状况调整指标。企业可能会发现从满意度、沟通和效率这 3 类指标开始是有帮忙的，因为通过测量这些指标并对相干状况进行优化会带来空谷传声的成果。
如果你曾经对客户进行考察，无妨问问他们如何为你的系统可靠性评分。
SPACE 框架提供了一种构建掂量体系的办法，它能够间接对事件治理产生影响。
不囿于数字，解决问题才是硬道理
掂量相干指标能够通过明确的数据来帮忙团队做出调整。如果没有数字，可能会把一个理论产生很频繁的事件当作一次性事件处理。
只管数字施展了作用，但它们只能通知你问题所在，而无奈解决它。因而，不要囿于数字，充分利用事件复盘和 review 来钻研如何优化企业中的事件治理。
数字并不能推动继续改良，但它能够打消探讨中的偏见和逻辑舛误，以帮忙团队解决好眼前的事实问题。
团队应该造成在事件产生后立即对其进行复盘，以避免回归到日常工作之后短少了上下文环境而无奈正确剖析出事件产生的起因。
对于根本原因的剖析要审慎，因为软件系统产生事变很少只有繁多的起因，它通常是几个因素独特促成的。根本原因剖析侧重于最靠近事件的人，而不是更宽泛的系统性问题。另外，须要进行事件后的 review，具体阐明产生的所有以及您为加重和解决它所做的工作。
事件复盘的成绩能够提供给解决将来事件的人应用，有助于缩短解决工夫。
平安是汲取事变教训的能力，而不是没有故障，事变复盘是最佳的学习机会。
—— Adrian Cockcroft
导致事变产生的起因从来不是单个员工，而是整个工作零碎。如果有人登录服务器，不小心抉择了“敞开”而不是“登出”导致服务器敞开，这实质上是零碎的故障——为什么不暗藏“敞开”选项？为什么他们须要间接拜访服务器？咱们能够用 runbook 来做这个吗？
定期 review 来复盘最近的事件，能够在沉着理智的状况下找到模式并思考改良形式。从事件中学习比围绕复原工夫制订指标更重要。
参考链接：
https://octopus.com/blog/how-to-measure-mean-time-to-resolve
