线上故障的正确打开方式

对技术同学来说，线上故障是一个绕不开的话题。

一方面，线上故障会极大的影响个人的绩效和心态；另一方面，处理线上故障也是很好的提升解决问题能力的机会。

因为线上故障的原因是多种多样的，会逼迫你去收集信息，从各种角度分析定位根因，然后想办法去优化解决。

处理线上故障的过程，是一个复杂的判断和筛选过程，而解决故障后沉淀的经验，对技术同学来说，是很宝贵的职场收获。

这篇文章，来聊聊应对线上故障比较通用的一些方法。

思维导图

先看下面的这张应对线上故障的流程图：

将这个故障处理的思维导图分为事前、事中、事后三个阶段，分别对应的是发现故障、处理故障、复盘故障。

这三个阶段涉及到多个角色参与，并且不同角色之间要做的事情都有上下游的依赖关系。

事前：发现故障

首先要明白的一点是：线上故障是无法避免的。

无论我们从技术上做各种提升优化，还是从流程机制方面进行保障，最大的作用是提升系统整体的稳定性，以及面对故障时能以更高的效率响应和解决，降低故障带来的风险和影响。

从软件工程角度来说，最终目标也不是完全不出问题，而是在整个研发交付过程中控制风险范围，降低风险带来的影响。

线上故障随时可能发生，且可能出现在任何环节，想要降低线上故障带来的影响，第一步就要尽可能快的发现故障，在出现故障苗头的时候就发现并解决。常见的发现故障的方法有如下几种：

• 监控告警：建立完善的监控告警平台，除了如CPU、内存等基础指标监控外，还有诸如链路追踪、业务监控等；
• 定时巡检：通过自动化手段定时开展基于业务场景的巡检，这也是线上稳定性保障最核心的一点：业务防资损；
• 异常治理：对于偶尔抛出来的异常也要提高重视，定期分析筛选，针对可能带来更大影响的风险进行专项处理；

当故障出现并且被观测到之后，需要及时通知到对应的值班研发和运维介入处理，同时将信息同步给测试以及产品同学。

有些故障是单纯的技术问题，可以很快修复。但有些故障的修复方案可能会影响到业务，因此需要让产品介入进行评估。

当然，如果遇到重大的问题，需要及时的信息上报，让更具经验和权责的领导进行决策指挥。

一般来说，中小型企业都是运维兼任监控观测的职责。但如果团队规模比较大，且业务和技术架构比较复杂的话，建议由专门的人员来负责监控观测盯盘，以及信息的汇总和分发。

这个NOC角色还需要在事后组织故障复盘，跟进复盘落地进度，并不仅仅是一个单纯的工具人。

事中：处理故障

在处理故障的过程中，下面是几点个人认为比较重要的经验之谈：

• 优先止血：即故障发生后，以恢复正常的业务运行为首要目标。
• 保留现场：比如服务集群挂了，踢出不健康的服务集群并重启时，建议保留至少一个故障服务实例。这样做的好处在于：一方面便于研发和运维同学更好的排查定位原因，另一方面也可以作为复盘时的证据，客观分析后沉淀案例库，便于后续的复盘改进。
• 单一决策：出现故障后最怕的就是病急乱投医，因为引起故障的原因可能有多个，不能只通过故障的表现就头疼医头脚疼医脚，而是需要尽可能收集相关的监控数据、日志，结合业务场景综合判断评估，才能比较合理的解决问题。这也是为什么上面提到的需要有专人来负责信息数据的汇总分发，以及上级领导决策的原因。
• 应急预案：面对线上故障，技术同学要做的更多是发现和预防应对，而不是四处救火。因为故障是无法避免的，也可能随时发生，四处救火只会疲于奔命。因此需要在前期做好风险评估，制定对应的线上故障应急预案并演练，这样在故障出现时可以更快的响应和解决，将故障带来的影响控制在可接受范围内。

事后：复盘故障

故障解决，线上业务恢复正常运行后，还需要进行复盘，持续改进。复盘时需要注意如下几点：

• 借助现场证据（故障应用/监控数据和日志），客观分析深层次的原因；
• 故障改进措施需要具备良好的可行性，且从改进方案中应沉淀出应急预案；
• 改进措施应该有明确的deadline和目标，且需要进行验证，确保改进的有效性；
• 故障复盘对事不对人，故障定级应该有合理且被大家接受的方式，否则很容易变成甩锅大会；

总的来说，复盘是重新梳理业务和技术实现的过程，可以找到更深层次的潜在风险。通过复盘可以发现以往工作中存在的流程机制方面的不足，并通过持续改进来不断提升团队的应急能力，最终提升线上业务和应用的稳定性。

当然，复盘并不仅仅限于故障复盘，故障定级也不是单一的事项。

应该从项目立项开始就介入，前期分析评估风险，设计阶段冗余，研发实现阶段做好异常处理，测试阶段多进行一些异常和边界的测试验证，交付阶段补齐监控和告警手段。

同时，制定合理的流程、故障应急机制、线上稳定性预案，这样才能更好的保证线上服务的稳定性，将故障带来的影响控制在合理区间。