关于系统:稳定性关于缩短MTTR的探索-京东物流技术团队

一、什么是 MTTR ?

当零碎呈现系统故障时，咱们须要通过一些指标来掂量故障的重大水平和影响范畴。其中 MTTR(Mean Time To Repair 名为_均匀修复工夫_)是一个十分重要的指标，它能够帮忙咱们理解修复零碎所需的均匀工夫。破费太长时间来修复零碎是不可取的，尤其对于京东这样的企业来说更是如此。如果 MTTR 过长，可能会导致用户结算卡单、影响公司支出损失等严重后果。因而，为了确保零碎的稳定性和可靠性，咱们须要尽可能地缩短 MTTR。

要计算 MTTR，就是将总保护工夫除以给定时间段内保护操作的总数，MTTR 计算公式：

二、如何缩短 MTTR

理解 MTTR 对于任何组织来说都是一个十分重要的工具，因为它能够帮忙咱们更好地响应和修复生产中的问题。在大多数状况下，组织都心愿通过外部保护团队来升高 MTTR, 这须要必要的资源、工具以及软件反对。

那么，您能够采取哪些步骤来缩短组织的 MTTR 呢？最好的终点是理解 MTTR 的每个阶段并采取措施缩小每个阶段的工夫。具体来说，咱们能够思考以下几个方面：

1、问题发现工夫：监控报警辨认故障

对于产生故障后技术人员辨认问题的时间段，咱们能够通过建设报警零碎来缩短 MTTR 辨认工夫。通过实时监测零碎的运行状况，及时发现并触发报警机制，能够帮忙咱们在最短的工夫内定位问题，并采取相应的措施进行修复。

咱们能够通过设置正当的阈值和规定，过滤掉那些不必要的告警信息，从而防止告警乐音对开发运维团队的烦扰，让他们更加专一于真正的问题。

1.1、UMP 监控

• 通过 UMP 实现 3 个黄金监控指标（可用率、调用量、TP99）。

在配置报警机制时，咱们能够综合思考可用率、TP99 以及调用量等因素来进行评估。通过这些指标的综合评估，能够帮忙咱们更全面地理解零碎运行状况，从而及时发现潜在的问题并采取相应的措施。

倡议在进行报警配置时，可先采取较为严格的策略，即先紧后松，逐渐调整到最佳状态。这样能够确保在最开始阶段就可能及时发现问题，避免出现重大故障。但随着零碎的逐步稳固，咱们也能够依据理论状况适当放宽报警阈值，以进步零碎的可用性和效率。

须要留神的是，在进行报警配置时，咱们须要联合具体的业务场景和零碎特点来进行调整和优化。不同的零碎可能存在不同的危险点和瓶颈，因而咱们须要依据理论状况来制订相应的报警策略，以保证系统的稳定性和可靠性。

critical 告警形式：咚咚、邮件、即时消息(京 ME)、语音
可用率：（分钟级）可用率 < 99.9% 间断 3 次超过阈值则报警，且在 3 分钟内报一次警。性能：（分钟级）TP99 >= 200.0ms 间断 3 次超过阈值则报警，且在 3 分钟内只报一次警。调用次数：当办法调用次数在 1 分钟的总和，间断 3 次大于 5000000 则报警，且在 3 分钟内只报一次警

warning 告警形式：咚咚、邮件、即时消息
可用率：（分钟级）可用率 < 99.95% 间断 3 次超过阈值则报警，且在 30 分钟内报一次警。性能：（分钟级）TP99 >= 100.ms 间断 3 次超过阈值则报警，且在 30 分钟内只报一次警。调用次数：当办法调用次数在 1 分钟的总和，间断 3 次大于 2000000 则报警，且在 3 分钟内只报一次警

• 如果 UMP 是定时工作，最重要的一点就是确定好监控时段。只有正确地配置了监控时段，能力确保 UMP 在预计时间段内失常执行，这样一旦 UMP 未能在预计时间段内执行，就会主动触发报警机制，及时发现并解决问题。

1.2、报警要 快、准、少

在解决报警信息时，咱们的 要害不在于数量的多少，而在于信息的准确性和完整性。咱们的小组每天都会接管到几百个报警信息，你是否有足够的精力和工夫去查看每一个呢？你能确保每一个都失去了关注吗？

因而，咱们须要对业务影响进行评估，并依据状况设定适当的报警频率。特地是对于那些被视为 ” 要害语音 ” 的报警信息，咱们更应该第一工夫发现并进行解决。只有这样，咱们能力保障在面对紧急情况时，可能迅速、精确地作出反应，最大水平地缩小可能的影响。

1.3、细节决定成败

1. 如果报警信息的响应工夫较长，咱们须要检查一下团队的值班响应机制是否失常。咱们须要确保告警信息是否可能无效地传播给正确的人，以便及时解决问题。
2. 对于报警信息的日清日结，咱们应该建设相应的解决机制，确保每条报警信息都能失去妥善处理。如果无奈做到日清日结，咱们须要深入分析起因，并采取相应的措施加以改进。
3. 在解决报警信息时，咱们须要深入分析其根本原因。只有找到问题的本源，能力从根本上解决问题。
4. 如果报警频繁但始终未被解决，咱们须要认真思考这个报警是否有必要的存在。有时候，一些报警可能是因为误报或者无关紧要的问题引起的，这时候咱们须要对这些报警进行筛选和排除。
5. 如果呈现问题后发现对应的 UMP 或其余环节的报警信息未增加，咱们须要仔细检查是否还有其余外围环节也漏增加了。如果有漏增加的状况，咱们能够采纳工具扫描来发现。
6. 对于之前呈现的报警信息，咱们不能凭教训认为是某起因导致的。历史教训并不一定精确牢靠，只有通过考察和剖析相干日志能力得出真正的论断。
7. 在配置报警信息时，咱们须要认真思考其合理性。倡议先采取紧后松的形式逐渐调整到最佳状态。这样能够防止一开始就呈现过多或过少的报警信息，从而进步工作效率和准确性。

2、缓解零碎问题工夫：故障响应机制、疾速止血

为什么咱们须要缓解零碎问题工夫，而不是仅仅定位问题呢？这是因为在解决零碎问题时，仅仅定位问题只是解决问题的一部分。更重要的是，咱们须要尽快缓解零碎问题，以防止其对业务的影响进一步扩充。

为了进步问题解决效率，咱们须要从以下三个方面动手：

1. 欠缺指挥体系和角色分工：一个欠缺的指挥体系和明确的角色分工能够无效地进步故障解决的效率。在解决问题时，各个角色须要明确本人的职责和工作，并协同配合，独特解决问题。
2. 齐备的技术层面故障隔离伎俩：在技术层面上，咱们须要采取一些故障隔离伎俩，比方通过 DUCC 开关等形式来防止适度回滚代码。这样能够更加疾速止血（DUCC 开关秒级，如机器多回滚须要 5 -10 分钟）
3. 通过足够的演练的故障解决机制保障：最初，咱们须要建设一个通过足够演练的故障解决机制保障，包含 UAT 环境测试、捣鬼演练、应急预案 SOP 等。这样能够在真正呈现问题时，疾速响应并无效解决问题。

总之，为了进步问题解决效率，咱们须要采取一系列措施来缓解零碎问题工夫，而不仅仅是定位问题。只有这样，能力真正保障系统的稳定性和可靠性。

2.1、执行故障应急响应机制

无论一个组织规模有多大，其最重要的特色之一就是应答紧急事件的能力。在面对紧急情况时，须要有一套欠缺的应急预案和实战训练机制，以确保可能疾速、无效地应答各种突发状况。为了实现这一指标，咱们须要从以下几个方面动手：

1. 建设齐备的训练和演习流程：建设和保护一套齐备的训练和演习流程是十分重要的。这须要一批对业务相熟、专一投入的人来负责制订和执行相干打算。同时，还须要依据理论状况定期进行演习和模仿测试，以确保应急预案的有效性和可操作性。
2. 先把问题上报组内、施展团队的力量：在解决紧急事件时，应该先把问题上报组内，并充分发挥团队的力量。通过集思广益的形式，能够更加疾速地找到问题的本源，并采取相应的措施进行解决。
3. 正当断定问题重大水平：在判断问题的重大水平时，须要具备良好的工程师判断力，并放弃肯定的沉着。

总之，为了进步组织的应答紧急事件的能力，咱们须要 建设齐备的训练和演习流程，充分发挥团队的力量，并正当断定问题的重大水平。只有这样，能力真正保障组织的稳定性和可靠性。

要害角色分工

1. 故障指挥官。这个角色是整个指挥体系的外围，他最重要的职责是组织和协调，而不是执行，比方负责人、小组长、架构师。
2. 沟通疏导。负责对内和对外的信息收集及通报，然而要求沟通表达能力要比拟好，比方产品经理。
3. 执行者。参加到故障解决中的各类人员，真正的故障定位和业务复原都是他们来实现的，比方小组外围研发、运维共事等。

流程机制

1. 故障发现后，On-Call 共事或者小组长，有权招集相应的业务开发或其它必要资源，疾速组织会议。
2. 如果问题疑难，影响范畴很大，这时能够要求更高级别的染指，比方部门负责人等。

反馈机制

反馈以后解决停顿以及下一步 Action，如果中途有须要马上执行什么操作，也要当时通报，并且要求通报的内容包含对业务和零碎的影响是什么，最初由故障指挥官决策后再执行，防止忙中出错。没有停顿也是停顿，也要及时反馈。对于技术以外的人员反馈，如 客服等等。肯定不是用技术术语，而是以尽量业务化的语言形容，并且要给到对方大抵的预期，比方咱们正在做什么，大抵多长时间会复原，如果不能复原，大概多长时间内会给一个反馈等等。

2.2、疾速止血应急预案

根本准则：在故障处理过程中采取的所有伎俩和口头，所有以复原业务为最高优先级，复原现场止血计划高于寻找故障起因。

1. 面对问题时，你的第一反馈可能是立刻开始故障排查过程，试图尽快找到问题本源，这是谬误的！不要这样做。正确的做法是：缓解零碎问题是第一要务，尽最大可能让零碎复原服务。
2. 疾速止血而不是本源排查。首先只须要粗定位问题大略即可，而后通过一些应急预案措施（DUCC 开关降级、限流、回滚等）来复原现场。
3. 线上问题首先思考，是不是上线、业务批改配置等变更导致，拉齐信息。
4. 公布期间开始报错，且公布前一切正常？什么都不必管，先回滚再说，恢复正常后再缓缓排查。
5. 利用曾经稳固运行很长一段时间，忽然开始呈现过程退出景象？很可能是内存泄露，默默上重启大法。
6. 如何确认是不是上线引入的问题呢？同比下上线前（比方昨天、上周）是否也存在一样问题。如果也存在阐明跟上线没关系。看看昨天的日志，日志是最靠谱的。可用率会坑骗大家（因为你可能明天治理了可用率，之前可用率是 100%，但不肯定是真的 100%）
7. 业务、产品、研发多路并行
8. 疾速定位问题时乃应该及时保留问题现场，比方先把 JSF 服务摘除，但机器保留 1 台（别重启），保留 JVM 堆栈信息以便后续进行问题本源剖析。

2.3、充分利用现有工具，智能剖析定位问题

2.2.1、针对 TP99 高，定位难：

调用关系简单，难以疾速定位性能瓶颈。可通过工具当时梳理分明服务间简单的依赖关系，聚焦瓶颈服务的外围问题，而不是呈现问题才去整顿链路。

• 如泰山 故障转移等：智能告知这个告警与哪个因素最相干，性能试用中。

• 全域看板，集成 UMP 采集点，可疾速定位是哪一个环节 TP99 高

• 长链路利用，配置泰山雷达图。

• Pfinder 分布式调用链路，作为剖析根底

2.2.2、针对调用量忽然高

可通过 JSF》流量防护》利用和接口》别名 & 办法名 定位上游哪个利用调用量状况，再采取对应措施，比方更上游沟通，限流策略等

2.2.3、线程剖析、JVM、火焰图 CPU 采样等

泰山平台》故障诊断》在线诊断

2.2.4、业务问题

依据 logbook 查找，这个没什么好讲的。

通过标准化程序来领导训练技术人员，能够缩小解决问题所需的工夫。在雷同的故障状况下，领有适当的文档和应急预案 SOP 能够让您疾速查看可能导致故障的所有因果因素。

三、总结

在线上问题修复后，编写 COE(Center of Excellence)复盘报告是十分重要的一步。在这个报告中，咱们能够回顾整个问题的处理过程，思考如果过后做了哪些能够更快缩短 MTTR(Mean Time To Repair)的办法。

具体来说，咱们能够从以下几个方面动手：

1. 剖析问题呈现的起因：首先须要对问题进行深刻的剖析，找出问题的根本原因。只有找到问题的本源，才可能采取有针对性的措施来解决问题，从而缩短 MTTR。
2. 总结经验教训：在剖析问题的过程中，咱们须要总结经验教训，并提出改良倡议。这些倡议能够包含优化流程、提高效率、增强培训等方面的内容，但不须要列一堆 Action，依据 2 / 8 法令抓重点即可。
3. 触类旁通，杜绝下次产生相似问题：咱们须要将本次问题的解决教训和教训利用到其余相似的问题中，防止相似问题的再次发生。

总之，通过深入分析问题、找出根本原因、总结经验教训以及触类旁通，咱们能够无效地缩短 MTTR, 保障系统的稳定性和可靠性。

参考：

SRE Google 运维解密

继续交付 2.0

作者：京东物流 冯志文

起源：京东云开发者社区 自猿其说 Tech 转载请注明起源