一分钟精髓速览
应急预案，是指在零碎呈现故障时，为了保障外围业务可能继续可用，而提前准备的领导手册。这个手册能够用来通知咱们：在遇到什么样的问题后，做什么样的操作能最大化地升高对业务的影响，将被动响应变为主动防御。
哈啰联合“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 读者交换群」
本文由博客一文多发平台 OpenWrite 公布！