一分钟精华速览

应急预案，是指在系统出现故障时，为了保障核心业务能够持续可用，而提前准备的指导手册。这个手册可以用来告诉我们：在遇到什么样的问题后，做什么样的操作能最大化地降低对业务的影响，将被动响应变为主动防御。哈啰结合“930 大促”活动，从多角度分享了其在日常梳理、预案保鲜、预案执行等方面的实践经验。

作者介绍

哈啰技术风险负责人——孟闯

TakinTalks 稳定性社区专家团成员。十年互联网行业研发经验，2015 年加入哈啰出行，参与哈啰业务系统从 0 到 1 的建设，作为核心 Owner 主导多个重点稳定性保障项目，在高可用架构、技术风险等领域有丰富经验。目前主要牵头哈啰稳定性保障体系化建设，通过人员组织建设、工具/平台建设、关键项目落地等措施保障哈啰所有业务稳定性。

温馨提醒：本文约 5000 字，预计花费 10 分钟阅读。后台回复 “交流” 进入读者交流群；回复“0302”获取课件资料；

背景

去年国庆假期前夕，本地出行及生活服务平台——哈啰举行了首届以节假日出行为主题的假日狂欢节（以下简称为“930 大促”），包含共享单车、共享助力车、电动车、打车、顺风车、小哈换电、租车、酒店以及火车票等在内的多项平台服务，几乎都达到年度峰值，第三季度活跃用户规模也跃升至出行行业首位，哈啰 APP DAU 也首次突破 1500 万大关。

（图片来源：极光大数据）

一方面是用户规模不断增长，一方面是业务系统日渐复杂，在此背景下出现故障可以说是必然的事，那么故障发生后，如何尽可能降低故障对业务和营收的影响？哈啰通过技术风险团队来保障业务的连续性，一方面提高故障的发现能力，快速知道哪里出了问题；另一方面提高快速解决问题的能力，即应急处置能力。

而应急预案体系作为应急处置能力中非常重要的一环，能最大程度降低故障对业务的影响，本文将重点围绕预案展开，探讨预案在提升应急效率中的应用。

一、应急预案为什么这么难？

1.1 常见困难与挑战

在预案设计时，怎么保证预案对正常业务的低误伤率？预案的精确性，也就是怎么保证预案的执行就是针对特定异常场景？如何更加全面地梳理出异常场景？预案有效性如何验证？是否被有效执行的检验方法？这些问题是很多人在设计预案或者执行预案时，常常会存疑的问题。很多人会觉得想做好预案比较难，结合哈啰的业务及我以往的经验，我认为预案的难点有三个。

场景多：以哈啰为例，内部业务线较多，如两轮、四轮、电商等等，各业务线又包含各类复杂的场景，比如用户找车、扫码开锁、骑行卡购买等等。

保鲜难：由于预案梳理本身工作量是较大的，各团队预案梳理完后会存在更新频率低的问题。

预案杂：预案梳理中需要考虑各种技术组件、内部应用系统、中间件、底层存储、基础设施等等，涉及的预案种类较多。

1.2 整体解决思路

整个稳定性保障需要以保障核心业务可用性为大目标，所以——

第一步，先对业务做分级，从核心业务场景围绕核心链路开始梳理。不要想一开始就对整体的系统做非常全的覆盖，这是不现实的，而且很容易因为刚开始梳理就发现困难，而导致梳理进行不下去。

第二步，生产高频演练，保证预案有效性。有很多预案我们不知道是否有用，关键时刻不敢执行，所以预案一定是要经过验证的。对于无损的预案，可以在生产环境进行高频演练；对于业务有损的预案，可在线下做模拟验证，定期在生产环境业务低峰期演练。以哈啰为例，两轮车业务有典型的早晚高峰的场景，我们就可以在晚上凌晨两点做演练，尽可能降低对业务的影响。

第三步，对常见的故障画像进行建模分析，抽象出常用的止损手段。看起来预案的方法比较多，但是关键时候还是不知道怎么用，所以还需要梳理常见的故障，比如了解应用层一般有哪些故障，对故障画像进行建模分析，抽象出常用的止损手段，比如切换开关、熔断降级、自定义操作等。

二、如何从 0-1 建立应急预案体系？

2.1 应急预案的 5 个要素

触发条件：即在什么情况下需要执行这条预案，哪个资源出了什么问题，这个条件应是可评估或可量化的，比如需要注明某业务指标下跌超过某个比例，或者某技术指标超过某个比例。如果不量化，会出现不知道何时操作、能不能操作的问题。

执行动作：即预案具体要做什么事情，步骤要清晰，可观测和可回滚。要写清楚对哪个资源、做什么动作，而且还要标明通过哪些指标去判断操作是否生效。随着故障处理过程的变化，可能还是需要做回滚，要想清楚预案如何做到可撤销或者可回滚。

影响范围：预案执行之后，预估对业务会造成什么样的影响，比如用户体验、数据一致性、资损等。大多数情况下，预案都会有一点损失，比如某个预案执行后，用户打开 App 时无法看到营销页面，或者没有弹窗提示等等，可能还会有一些影响比较大的情况，比如会导致短时间的数据不一致，所以在预案中要写清楚对用户的影响。预案是需要研发、产品、业务甚至运营共同讨论的，需要评估线上系统如果出故障，执行预案所带来的影响业务方是否能接受。

操作人：预案的实际执行人，日常维护负责人，避免人员单点，要有 Back up。之前我遇到过关键系统出现故障，但操作人电话无法接通，或者无法立即处理的情况，这就要求预案制定时需要有升级或者备份机制，能迅速找到对应处理人并确保预案执行。

同步机制：应急预案执行后，需要明确信息同步给哪些人，相应的沟通计划是什么样的，信息推送到哪些渠道等等，在应急指挥时避免信息不一致导致的时机延误。

2.2 预案梳理的 4 个流程

2.2.1 分析业务场景

在预案梳理时不要贪多，把核心与非核心业务分开，先保障核心业务，并找到几条关键链路来梳理。

以哈啰两轮业务为例，单车和租赁车业务里，会有诸如用户扫码开锁、查看附近车辆、购买次卡、骑红包车等等很多业务逻辑，我们会和业务沟通，哪些是核心业务场景，其中，“核心”的定义可以视各自公司情况而定，也可以参考通用的标准，比如影响用户的范围、用户 DAU/UV/PV、对业务收入即 GMV 的影响、是否会造成大规模客诉引发舆情问题等等。

2.2.2 识别关键资源

找到核心业务后，保障这个业务的连续性，需要识别它依赖哪些资源，网络入口、业务应用、中间件、存储、基础设施等等都要识别出来。依然是先看核心的强依赖，对关键资源做重保预案。对于弱依赖（组件挂掉后不影响核心业务），我们可以通过熔断、降级等自动化的预案 Cover。

2.2.3 列出故障模式

接着分析这些识别出来的核心资源可能发生哪些故障，比如负载变高影响内存 CPU，使用率延迟变大 RT 变高，错误率增多系统异常，或者其他个性化的故障，都要分析出来做成故障列表。

2.2.4 制定相应措施

一个故障可能会有多种预案，比如应用重启、限流、扩容等等，这些预案都要详细写下来。止损手段就像是给流血的伤口止血，之后要做信息同步。还有比较关键的是做数据的补偿和善后，因为业务恢复后，对研发来说工作其实没有结束，他们还要找到被故障影响的用户，通过数据分析后给用户做补偿和善后。

2.3 预案梳理的 4 个要点和踩坑经验

2.4 应急预案的日常治理

在预案梳理完后，还需要思考如何在日常的稳定性保障中让其运转，所以预案的日常治理也是非常关键的环节。

从整个预案的治理过程来看，首先是按照前面的方法产出预案清单；然后根据预案制定针对性的实战演练计划，需要确保预案在故障发生时能生效；接着开始预案执行，执行完后的系统表现也需要做好观测和记录，比如系统资源的变化、业务的恢复情况、资源水位、告警、日志……最后是效果验证，观察预案是否真的生效，并逐步完善预案。

所以预案梳理只是第一步，通过日常的治理并让其真正运转起来才是核心，否则线上出问题时，已有的预案大家也不敢使用，预案也就失去了存在的意义。

三、哈啰在实际工作中如何使用预案？

3.1 哈啰的预案是怎么梳理出来的

哈啰的预案来源主要有三个部分——主动梳理、线上故障、故障演练。

主动梳理：这里我们在第二部分已经详细讲过了，由业务系统 Owner 主动梳理，根据业务场景逐步往下做拆分，并与产品、业务方、运营方等等达成一致。

线上故障：在故障复盘时，我们会讨论几个比较关键的问题：应该做什么才能不出故障、应该怎么做才能快速恢复故障、整个故障过程中谁做了哪些操作……都列在时间线中拿出来讨论，这样引导大家思考和推演，针对特定场景多制定一些预案。

故障演练：在线上做突袭式的演练，以此发现流程中的不足，比如发现能力、定位能力、应急能力等等，发现问题然后促进优化完善应急预案。

3.2 哈啰应急预案实践案例

3.2.1 应急指挥体系

在分享实践案例之前，为了方便理解，这里先简单介绍哈啰的应急指挥体系，即在出现故障之后会有哪些角色参与，团队分别要去做哪些事情，以及大概的协同流程。

3.2.2 案例 1：数据库故障

故障情况说明：

某业务核心指标出现下跌，监控告警系统推送 High 级别告警至相关人员。

应急过程：

1）NOC 发起应急，on-call 的相关人员拉起，关键人员入群；

2）作战室排查定位，并进行初因分析，确认故障点为数据库宿主机异常，大量慢 SQL；

3）按照数据库应急预案，执行 HA 切换，备用实例切换至 Master；

4）观察上层应用的关键指标，确认业务恢复；

5）开始善后处置，研发开始拉取受影响用户范围，提交至运营，评估是否做出补偿策略；

要点：

应急预案只需要负责止血即可，根因定位和故障复盘不在应急范围。

3.2.3 案例 2：典型高危预案

故障情况说明：

几年前某业务系统故障，监控告警异常，用户进线增加，大量舆情反馈，on-call 拉起后，经过初步预判分析，故障短时间内暂无法恢复。

应急过程：

1）按照此前既定预案：指标 x 下跌超过 y 比例，且已经持续 m 分钟，预判 n 分钟内无法恢复，执行高级别应急预案，该业务系统切换至灾备系统。

2）判断用户影响：a.用户体验大幅受损，核心业务流程可以维持，即可以保证核心业务子集继续运转；b.数据可能出现短时间不一致，但是可以保证最终一致性，不会产生资损。

3）决策执行：研发 TL、业务 TL 通过线上/线下会议执行决策，同意按照应急预案切换，开始执行紧急操作。

4）信息同步 &善后：由于用户体验可能大幅受损，需告知关联部门尤其客服部门，预案执行后的业务情况，比如用户可能会看到什么样的界面，对用户是否产生影响等，沟通话术需同步给客服和运营，消除客户担忧。研发同步拉取受影响的用户范围，通过短信和消息通知等发放卡券补偿。

要点：

这是一个典型的高危预案处理案例，通过量化指标快速做决策，按照应急 SOP 沟通，如涉及到哪些部门、通知哪些信息、如何协同处理等等。

3.2.4 案例 3：哈啰 930 大促

以上两个故障的应急预案是日常的常态化应急，而大型活动期间的应急预案，是另一种比较特殊的场景。哈啰在 2022 年 9 月 30 日发起了以节假日出行为主题的促销活动，恰逢国庆节前夕四轮业务（打车、租车等）的高峰期，多种因素叠加，造成系统的稳定和应急挑战相对较大。

预案主要体现在上图的几个环节。每个业务线的稳定性 Owner，都要求负责梳理业务上的预案情况，且需要准备三类预案——前置预案、应急预案、事后预案。

（哈啰 930 大促的部分预案）

1）前置预案

大促的典型特征是时间短、流量大、玩法丰富，所以稳定性保障需要区分重点与非重点，比如在前置预案中把不必要的业务活动关掉，以及通过前置预案把缓存提前预热，提前把一些比较高频的行为降为低频，防止数据库被击穿等。

2）应急预案

在大促活动开始后，应急预案和日常常态化的预案差不多，通过降级等应急方案做保障。其中比较典型的场景，哈啰的业务中会有算法推荐，比如商品搜索结果的推荐排序，在业务系统故障时，底层的系统资源可能会出问题，此时我们会通过算法降级来处理，即把算法推荐切换成手动推荐，在保证大部分业务不受影响的前提下，牺牲部分推荐效果。

3）事后预案

这里主要是预案回滚的操作，比如打开之前关闭的低级别的活动，或者对提前扩容的部分进行缩容。

除了以上按照时间线划分，我们还从另外一个角度对预案做了区分，即技术预案和业务预案。在业务预案中，就需要多和业务沟通，有些技术问题可以通过业务逻辑的调整来规避，比如说临时关闭不重要的活动、降级非必要的业务逻辑等等，能帮助技术争取比较充分的时间、比较安全的环境来解决问题。

3.3 预案应用效果

预案的数量多与少，并不能绝对反映工作的好坏，还需要考虑核心场景覆盖率、演练成功率、故障类型覆盖率、故障处置有效率等等，这些综合构成预案的量化评价体系。以哈啰“930 大促”为例，我们的预案应用效果如下：

1）哈啰 930 大促 0 故障；

2）预案覆盖 10+业务线；

3）核心业务线预案覆盖率 80%以上；

4）月度周期进行常态化演练，定期检验应急预案。

四、总结 &规划

4.1 预案平台建设

在预案的工具化建设方面，业界也有很多比较好的实践。哈啰也在考虑自动化预案平台的建设，首先是先做预案的统一标准化管理，然后再与各个系统打通，提升预案执行效率，避免人工操作带来的一些问题。

如下图所示，预案平台在设计上包含四个关键能力——预案管理、能力对接、决策感知、应急协同。

预案的执行主要依赖两点：当前应该执行哪个预案，以及预案如何执行。

比如出现故障时，是靠人工判断来分析是否需要执行预案，这种判断依赖故障现象、数据和指标等，希望通过整合信息，由系统来判断当前可以使用哪些预案，推荐给故障处理人员，缩短决策时间。然后预案的执行一般是手动去某个平台修改一下配置，或者是执行某段命令等等。我们希望通过工具来做到一键执行。

4.2 对架构设计的启发

防患于未然，是最好的预案。梳理预案的过程，也是重新对系统进行分析的过程。这个过程可以帮助我们认识到系统设计的不足，要优先通过自动容灾等策略来建设系统的自愈能力，如果系统无法自愈，再考虑做成需要人工介入的应急预案。（全文完）

添加助理小姐姐，凭截图免费领取以上所有资料

并免费加入「TakinTalks 读者交流群」