一分钟精华速览
应急预案,是指在系统出现故障时,为了保障核心业务能够持续可用,而提前准备的指导手册。这个手册可以用来告诉我们:在遇到什么样的问题后,做什么样的操作能最大化地降低对业务的影响,将被动响应变为主动防御。 哈啰结合“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 发布!