作者介绍
哈啰技术风险负责人——孟闯
TakinTalks稳定性社区专家团成员。十年互联网行业研发经验，2015年加入哈啰出行，参与哈啰业务系统从0到1的建设，作为核心Owner主导多个重点稳定性保障项目，在高可用架构、技术风险等领域有丰富经验。目前主要牵头哈啰稳定性保障体系化建设，通过人员组织建设、工具/平台建设、关键项目落地等措施保障哈啰所有业务稳定性。
温馨提醒：本文约5000字，预计花费10分钟阅读。
背景
去年国庆假期前夕，本地出行及生活服务平台——哈啰举行了首届以节假日出行为主题的假日狂欢节（以下简称为“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 对架构设计的启发
防患于未然，是最好的预案。梳理预案的过程，也是重新对系统进行分析的过程。这个过程可以帮助我们认识到系统设计的不足，要优先通过自动容灾等策略来建设系统的自愈能力，如果系统无法自愈，再考虑做成需要人工介入的应急预案。（全文完）
