第二十九篇：故障处理流程

前言

故障处理流程大致可分为预防、发现、定位、止损几个大阶段，其中发现、定位、止损这三个阶段是处理故障现场的重要阶段，决定了处理故障的处理效率，能否在最短的时间内止损，故障处理效率也和我们的架构设计及基础建设有着密不可分联系；架构设计决定了我们的系统是否面向失败设计，基础建设决定了我们处理故障的效率，是否能够通过基建的可观测性先于用户发现问题、定位故障的根因、做到及时止损。

故障处理流程包括分别是故障现场处理、故障定期复盘，故障现场处理是当故障产生后，怎么快速协调调到组织，缩短故障时长，标准化处理流程就变得非常重要，尽可能避免出现故障手忙脚乱，不知该如何处理；故障定期复盘是为了不时的往回看，结合历史发生的故障来对标当下，看是否存在同样或类似的问题，要能够做到举一反三，避免同类型故障发生。

故障现场处理

为了在故障发生时，我们的人员能够训练有素，及时止损，为故障恢复争取最宝贵的时间而设计一套标准化流程，要花足够的时间去设计各个环节，确保各个流程环节及人员到位，并对各个环节预演&查缺补漏，并能够让相应的人员参与其中充分锻炼，从而做到训练有素，不至于在故障发生时手忙脚乱。

结构化问题

采用结构化问题解决思路，能够清晰全面的定义问题，梳理问题影响因素，挖掘出根本原因，或者有可能挖掘出多个原因，这样才能正确的解决问题，而不是过了一段时间发现问题又产生了。对于问题解决有很多结构化解决方法，如8D的结构化解决问题思路，尤其是各种专业的咨询公司，这些流程值得我们借鉴和学习。结合软件系统的生产环境故障来描述的话，一个典型的结构化问题解决步骤，如下：

• 问题定义：清晰的描述问题现象、影响，其中影响要尽量量化。例如xx时xx分开始，xx时xx分结束，持续多久，xx服务异常，成功率从99%下跌到90%，影响用户数。
• 分析问题原因：结合已知因素，找到问题的最根本原因。
• 故障责任人：相关负责的同学。
• 故障等级：PN
• 故障影响范围：因该故障影响业务功能。
• 短期方案：基于预案的临时解决方案和实施结果，包括符合条件的预案执行，或者应用发布过程中出现的异常后立即回滚，或重启、紧急更新等。
• 长期方案：通过问题根本原因、发现同类问题并制定排查放哪，如API超时配置合理问题，中间件超时，RPC调用超时等等是否合理。
• 长期方案责任人：长期方案的具体负责人、实施人、DeadLine，问题放大，举一反三，避免同类的问题继续发生。
• 故障总结。

故障处理流程

故障感知

故障感知来源通常情况下有两个渠道分别是监控、运营反馈；监控是每个团队都必须要做的事情，只不过是粒度不同，例如：服务存活监控、API接口状态监控；在某些情况下，对线上的SLI指标监控不够完善，就无法通过监控反馈出来，只能通过运营侧伙伴反馈。对于监控指标不能停留在基本或者太过技术性SLI指标，要更结合业务来构建SLI，在某些情况下纯技术SLI无法是反馈不出来的，例如：服务存活、API状态等等，要能够结合用户行为、事件、业务特点和流程来构建监控模型，例如：在某些情况下，商品列表流量很大，但是详情页的流量很少等情况。

故障预判

监控告警接收人默认情况下是该服务或者业务模块的负责人，其次及稳定性负责人或者团队Leader等等，当收到告警首先对告警预判，初步判断故障的类型、故障严重程度、影响范围，其次判断是否可依据紧急预案手册进行操作恢复，如不能，则尽快向上汇报，调动更多的资源和专业参与进来。

故障跟踪

故障跟踪是指技术支持在故障处理的过程中，需要多方协调，和运营、客服等多个角色同步故障处理进度，在过程中并负责收集相关伙伴反馈、记录关键信息，并建立故障状态&进度同步渠道，一方面对外做好安抚，另外一方面对内收集反馈给到内部团队，及时将故障处理进度重要信息同步给各个伙伴。

故障处理

故障处理是接受到故障之后处理方式，首先通过事件监控，排查近期是否有线上事件变更，百分之八十事故都有由变更引起的，变更包括代码发布、配置变更、数据变更、文件变更等，如果有，则尽快回滚，否则根据可观测性、来快速定位问题原因，判断故障事故是否能够短时间内修复，如短时间内可修复，是指物理操作不改变代码的情况，如升级物理配置等等，如不能，则可否通过降级、熔断等策略，提供有损服务。

故障观测

故障观测是指故障处理完成之后，要观测一段时间，而不是故障处理完就觉得没事了，尽可能观测半个小时左右，另外故障处理完首先有内部的测试伙伴进验证无误之后，再由技术支持伙伴和业务方的伙伴同步，防止对业务二次伤害，另外也要第二天该故障时间内留意观测。

故障复盘

故障复盘是对故障处理全过程回滚、故障原因、故障影响时长、及故障短期和长期的解决方案形成模板化，按照结构化问题思路处理，系统性的分析整个流程、运维流程、故障处理及恢复过程中的不足，从管理、技术、业务、执行层面多个维度、深入优化、列出解决方案，对故障复盘要重视，只有故障复盘到位，同样或者同类的问题才有可能避免，并对该故障复盘做内部分析，做到内部全员学习，最大程度的避免故障的再次发生，从而提升团队能力和系统能力，值得注意的是故障原因一定是根本原因，而不是表现原因，要能够剖析出最根本的诱因，故障复盘一定是对事不对人，该复盘并且不是追究责任的，是能够剖析最根本的原因，做到根治，及后续故障预防。

故障定期复盘

故障定期复盘是为了不时的往回看，结合历史发生的故障来对标当下，看是否存在同样或类似的问题，要能够做到举一反三，避免同类型故障发生，定期对历史的故障案例进行剖析、学习、讨论并检查之前故障列举出的长期方案是否都如期实现，提倡故障定期复盘团队学习文化，寻找规律、以史为鉴，从而有效预防故障，提升团队整体素质和能力以及系统的稳定性。