概述

线上故障通常是指大规模的影响线上服务可用性的问题或者事件，通俗点讲就是：掉‘坑’里了，这个‘坑’就是线上故障！线上故障的处理过程可以形象地表达为：‘踩坑’、‘跳坑’、‘填坑’、‘避坑’。

线上故障的处理不仅是一项技术活，更是对技术人员/技术团队反应能力、决策能力、判定能力、组织能力的考验。面对突发的生产故障，需要快速定位问题，找到解决方案，快速实施解决方案并不是一件容易的事情。本文主要包括如下内容：线上故障处理的目标、思路、步骤、基础设施。

本文是依据平时经历的生产故障排查和处理，总结一些肤浅的方法论，以求共同探讨，共同提高，欢迎探讨。

线上故障处理的目标

任何动物一旦掉进坑里，明智的做法一定是：跳坑-->填坑-->避坑，线上故障处理的过程也一样，优先级从高到低，线上故障处理的目标如下：

跳坑

‘跳坑’——快速恢复线上服务，或者将对线上服务的影响降到最低。

线上服务的可用性决定着服务者的客户利益，影响着公司的收益。一旦线上环境不可用，无法服务用户，给公司/团队带来经济利益损失的同时，更为严重的会给公司/团队带来恶劣的名声。所以一般公司都会对线上环境提出稳定性和可靠性的要求，这也是团队乃至部门的kpi。为此，遇到生产故障后的第一要务是：恢复生产服务，即使不能完全恢复线上服务，也要想尽办法将对线上服务的影响降到最低。

填坑

‘填坑’——找到问题原因，根本上解决问题。

在恢复线上服务，尽最大限度减掉对用户/公司/团队带来的影响后，我们需要彻查问题，搞清楚故障发生的根本原因，从根本上解决问题。通常情况下，‘填坑’和‘跳坑’是同步在做的，完成‘填坑’也就意味中‘跳坑’成功，但是也有一些紧急情况下的特别‘跳坑’方法，比如重启服务，或者服务降级/熔断等等，实际并未在当时完成‘填坑’，而是先采取非常规手段‘跳坑’，之后再慢慢‘填坑’。

避坑

‘避坑’——举一反三，消灭隐患。

找到了根本原因，解决了问题之后，我们需要举一反三，以此及彼，想想在这个故障排查和处理过程中，那些环节存在弱点？那些流程/规范/制度需要优化？这类问题是否在其他系统或者团队中也存在？通过这样的反思和自我批评，形成一份线上事故报告，不断完善流程，避免再次踩坑，也在团队中交流经验，共同提高。

线上故障处理的思路

依据线上故障处理的目标及目标的优先级，线上排障的第一目标是恢复线上服务或者降低对线上服务的影响，关键点在于快速二字，在‘跳坑’-‘填坑’之后，再行回溯总结，以便‘避坑’。因此，可以将线上故障处理的步骤分为：

其中前三步是‘跳坑’行为，后面一步包含了‘填坑’和‘避坑’。

上述步骤并不是说要从上到下顺序进行，建议在不乱阵脚的情况下，并行去做，因为通常线上故障后会紧急启动故障处理程序，运维、开发、测试、产品各个角色都会参与进来，这时候分工下去，并行去做，不断汇总消息，做出判断，以求快速排障，恢复服务。这个思路类似于操作系统的fork/join设计思想，目的在于提高效率。

在无法快速找到故障原因的时候，需要果断跳过故障定位环节，直接进行故障排除，比如采用服务降级、服务器扩容等手段，确保对线上服务降到最低且可控。等到线上服务'撑'过去之后，我们再慢慢定位故障原因，根本上解决问题。

下面我们会对这四个步骤进行详细说明。

故障发现

线上故障一般可以通过如下几种途径传递到开发/运维人员手中，按照从上到下的顺序，故障的严重程度依次变高。

上述途径传递过来的信息仅仅只是线上故障苗头，并非一定就发生了大规模的线上故障，所以首先需要确认的是这是不是一次线上故障？还是只是个例生产问题？是否和本系统有关系？一般来讲：‘系统监控告警’和‘业务监控告警’的情况下，大部分都和本系统有关，且可能是线上故障；而‘主动发现’和‘生产事件上报’则需要做甄别，可以根据上报事件个数或者问题复现的方式来评估是否是大规模线上故障，或者跟踪日志信息或者特定用户问题追溯来确定。至于‘关联系统故障追溯’的情况，首先不要慌，先从宏观上确定本系统服务正常，一般可以检查是否有服务器监控报警，是否有业务监控报警等来确定，如果上游或者下游提供了日志，可以通过日志进行追踪，从而确定本系统是否存在故障。

因此在得到一些线上故障苗头之后，可以通过以下途径确定是否是线上故障：业务监控告警、上报事件个数、问题重现、服务器监控等。这些途径可以并行进行，灵活组合，有时候一个手段就能确定，有时候需要组合多个手段予以判定。

故障定位

一旦确定是线上故障后，我们需要快速定位故障点，找到问题原因，以便对症下药，快速排除故障。

故障定位是一个不断‘收集信息--假设--验证--尝试’的循环过程，基本思路：拿到线上信息，产生怀疑点，拿到更详细的信息，进行推理验证，必要时刻，找到可行的验证措施，进行可控的尝试，或者在测试环境进行业务测试重现，性能测试重现。

可能存在的怀疑点有：

为此，可以通过如下几方面收集信息，以便支撑你的怀疑点：

 很多故障并不是由于单一原因造成的，而是多个条件同时满足时才出现的，所以，需要多收集信息，综合得到的信息，产生怀疑点，快速推理和验证，最后找到问题点，定位到故障。这个过程中可以集合大家的力量，并行去check各个点，并快速反馈信息。

由于组合情况众多，这里只将明显的故障定位场景列出，更多的需要总结归纳：

不一而足，需要逐步积累。下图是对上面描述的总结。