我们是如何保障哈啰930大促的

业界有很多大促活动，像618、双11、双12等等。每一次大促不只是给业务带来了新高，对于技术同样也有很重要的意义，纵观一些优秀的技术团队，都是跟着业务一起成长的。在高并发大流量的背景下，如何支撑好业务运营，是一件很有挑战性的事情，它可以从多方面检验我们的技术能力，对我们的系统架构和应急保障都提出了很高的要求。

哈啰在去年9月30日开启了首届的假日狂欢节，我们也做了很多的稳定性保障工作，最终大促顺利渡过，业务体感非常顺滑，所以借此机会总结下我们在稳定性保障这方面的一些工作，分享给大家。

相比日常的稳定性保障来说，大促的主要特点是时间短、流量大、玩法丰富。大促的过程一般都只有几天甚至数小时，为了尽可能冲到新的业务目标，要充分调动用户的积极性，所以营销玩法一般都比较丰富。因此，我们在大促的稳定性保障中，重点从容量规划、压测演练、应急预案、变更管控这几个维度来做保障。

哈啰由于多业务形态共存，每条业务线有自己的发展特点，因此大促开始前，要充分分析业务特点，制定针对性的保障方案。例如两轮业务(共享单车和共享助力车等)，与典型的通勤场景是一致的，在早晚的上下班高峰期，后台的系统流量也会特别大。而四轮业务(打车、顺风车、送货等)，则是跟着节假日有较强的关联性，每到节假日前夕，系统可能会面临数倍于日常流量的峰值。

顺着大促的时间轴来看，一般会包含活动早期的方案制定、压测演练 ，活动中的应急预案和联动等，活动后的收尾工作等。下面按顺序介绍下其中的一些重点工作。

公司级大促，需要多个业务线共同协作，涉及多个部门众多人员，这个时候需要有一个类似大促保障组之类的组织来统筹协调，这个组织是大促保障的决策机构，它是大促保障的第一责任人，同时也赋予相应的权利:在涉及到资源冲突的时候，大促保障组有权拍板，能与业务运营沟通需求，特殊情况下，可以停掉一些非必要的迭代需求，保障大促的事项顺利推进。

同时，各个业务研发团队，也需要明确各自的大促负责人(也称大促技术PM)，大促技术PM是本业务研发团队大促保障的首要负责人，要根据业务特点制定详细的保障方案，配合本业务完成大促目标。

在分工上，大促保障组负责关键里程碑的设定，比如说大促项目需求上线时间、什么时候开始压测、什么时候进行封网、封网之后的变更审批(破网)流程，以及给出整体的保障方案框架，例如大促保障模版、技术目标拆解方式等等，可以供业务线的大促技术PM来作为参考依据。

在沟通机制上，大促保障组要能够从全局视角给出当前的整体工作进度和风险概况，及时汇报给管理层。同时各个业务线的大促技术PM也需要定期向大促保障组汇报工作进展，包括各业务线的大促需求研发进展、当前已知风险、资源瓶颈等等。

我们上面提到过，大促的核心在于对流量的把控，因此目标拆解的目的主要是从业务目标拆解为技术目标。

在业务目标设定的时候，一般会考虑用订单量/GMV/DAU/PV/UV等各类指标作为目标，但是在我们做保障方案的时候，需要明确地知道技术目标，一般是QPS、用户数等等。

所以这里需要有一个转化的过程，首先是与业务运营深入沟通，搞清楚这次大促的主要策略和玩法，核心点是弄明白这个问题: 相比日常的业务流程来说，这次的流量从哪里来，这个玩法是如何吸引用户的，用户的操作路径与以往会有哪些不一样。搞清楚这个，就明白了流量路径。比如以两轮骑行为例，会考虑通过一些骑行任务来提升用户的骑行意愿：骑行N单之后给X元奖励。那这里面就需要关注骑行流程、营销活动、任务奖励等这几个平台相关的各个系统。同时进一步深入分析，还发现在大促活动中需要保证供给侧有足够的车辆，线下运维可能会进行一些额外的调度工作等等，这里面就需要关注运维系统相关的流量变化。

总的来说，即技术目标 = 业务目标 -> 实现路径(策略、玩法) -> 找到依赖的系统 -> 明确系统的QPS。

技术目标设定好之后，就要进行压测了，然后根据压测的结果进行调整和优化。在设定技术目标的同时，我们还要根据业务线的具体业务玩法，设定对应的应急预案，这些预案也要经过演练来验证。

因为压测演练讲得比较多，这里就不做过多展开，感兴趣的同学可以翻阅以往的文章。

变更是导致线上故障的最大来源之一，因此大促期间，变更需要提前做好管控。根据大促的具体节奏，提前设定好相应的封网计划，包括应用发布、配置变更、运维变更等等，同时也准备好相应的应急流程，对于某些特殊情况需要变更的，做好记录，以便活动结束后进行复盘。

大促活动因为有时间窗口限制，所以在正式上线之后要做充分的测试，避免出现意外情况。在做好灰度发布的基础上，对于大促的活动业务逻辑，也要进行灰度验证，一般可以用内部、外灰逐步放量、扩全的方式进行。这次大促活动正式上线之前，我们采用了内灰的方案进行验证，先让公司内部同事加入到灰度白名单，去体验一下大促玩法等等。但是要注意数据的隔离，避免内灰测试中，消耗了真实的奖励等等。

大促开始前，要明确好信息同步机制，即大促值班纪律和规范，比如说系统核心owner必须到作战室进行值班，同时在IM中提前规范各个沟通群的名称和作用，把相应的研发、产品、业务、运营、客服都关联同学都拉到对应的沟通群。

比如说可以建一个全员沟通群，用于信息同步和相关通知。同时为了高效决策，还需要把一些有决策权的TL拉到会议室一起值班，出现问题之后快速决策，下发执行等等。

上面主要是大促过程中的几个关键环节，看完了这些，相信大家对大促保障已经有一个整体认识了，接下来我们重点聊一下保障方案具体怎么做，如果你是大促技术PM，你会如何制定保障方案？

大促保障方案是一个整体的框架，在实际的工作中，是由大促保障组产出了这个框架，然后各个大促技术PM根据业务特点，制定出具体的保障方案，接下来大家一起评审并进行相应的压测演练验证。

为了让大家理解一致，每个模块下都有了明确的产出物要求，即具体要做什么事情。

大促的关键点在于流量，想要治理好流量，就需要对流量路径做到了如指掌。比如说，本次大促有哪些关键入口，这些入口对应了哪些后端系统、涉及了哪些资源，目前这些系统和资源的水位怎么样，预估哪里会成为瓶颈，是否需要提前治理等等。这些都是链路需要重点关注的地方。

在链路梳理中，也应该明确强弱依赖，比如说某个系统的下游依赖中，哪些是必不可少的强依赖，哪些是可以容忍出现故障的弱依赖，以及这些依赖的降级熔断配置、超时时间设置等等，都需要详细分析。

在分析流量路径的时候，要注意着重识别是否存在热点流量，例如产品一般在大促开始前对大量人群做push，那么用户点击push之后，跳转的落地页对应的接口可能会存在热点流量，要进行重点保障。

产出物:

• 一张能反应当前系统实际情况的链路关系图，要能够看到流量路径、反映出强弱依赖关系。

• 目前服务之间的依赖关系的检查结果List，是否存在风险项。

容量水位分析，是为了分析当前系统是否存在资源瓶颈，有无需要提前扩容的资源等等。如果暂时无法明确，也可以先输出现状，待压测之后再确认具体情况。

产出物:

• 一张当前系统入口的qps表格，包括目标qps、当前实际qps、是否需要扩容等。

  
  

参考格式：

无论是在常态化稳定性保障还是大促稳定性保障，监控告警的治理都是重中之重。

在大促场景中，需要特别注意两个点：

• 当前各个系统的监控告警配置情况，指标覆盖是否完善和阈值设置是否合理。包括基础设施监控、中间件监控、应用层监控、流量入口监控等等。

• 与本次大促有关的一些业务监控是否完备，是否能够通过业务指标观察当前大促的流量路径。比如说业务活动的转化一般是呈漏斗型，以「一个通过发放优惠券来促进下单」的场景为例：需要有一套对应的业务大盘，能看到从优惠券曝光、用户领取、下单核销等各个环节的情况。

产出物:

• 各项监控大盘的地址和梳理结果，监控监控的覆盖度是否完整，告警策略是否正常等。

• 监控指标check完了之后，要通过故障演练来模拟资源水位变化，看监控告警是否正常。

从以往的稳定性治理经验中可得，即使我们做了万全的准备仍然有可能出现意外情况。因此，大促保障中更是要对各种“可能出现”的意外情况，做好充分准备。比如说上面提到的链路梳理中，有些依赖可能需要手动调整，在系统压力过大的情况下需要屏蔽掉一些非核心逻辑，比如说为了保证极端情况下的用户用车，可以暂时关闭红包车检查等等。

按照大促时间轴，从“事前、事中、事后”三个维度来梳理预案，对于一些对业务可能产生的预案，要写清楚业务影响面和预期，以及提前与业务方沟通清楚。

• 事前预案：提前扩容、配置限流、缓存预热等、边缘业务降级等。

• 事中预案：即应急预案，动态配置开关等。

• 事后预案：大促结束后要做的预案，一般为系统缩容、恢复边缘业务等。

产出物：应急预案手册，可以用表格形式呈现，包括预案的类型、触发条件、执行动作、预估影响、执行人、生效速度等等。

一场大促会牵扯到多方，包括产品、业务、客服、其他关联部门等等。联动机制主要包括应急值班和信息同步机制，比如说大促进行中，出现了线上故障，在处理故障的同时，要把相关信息同步给关联方。某些情况下，需要执行预案了，这个执行预案的动作也需要同步给关联方。

• 应急值班: 包含值班人员名单和联系方式。

• 信息同步机制：包含与产品/业务/客服等的沟通通道和机制。

产出物：

• 值班干系人名单，值班信息。

• 各业务应急值班群&沟通流程。

想要顺利通过大促，除了内部的各种保障，也需要注意外部的一些合作方的保障。避免业务流量过大，影响了合作方的接口质量等，本次活动是否依赖外部合作方(开放API/外部HTTP交互等)，对于合作方的接口质量是否有监控告警手段，例如合作方接口的rt、错误率等指标是否可观测，是否具备切换能力，例如从A合作方切换到B合作方。

提前明确我方的流量目标，与合作方进行沟通，要求合作方制定相应的保障策略，例如让合作方在大促期间尽量避免变更等操作。最终一起与合作方输出流量评估结果和应急手段。

产出物：

• 与合作方的评估结果表格，包含: 业务场景、评估结果、合作方值班人、应急预案等。

上文我们提到过，在具体保障工作中，要结合各团队的业务特点，制定出相符的保障方案。在多业务形态的公司中，就有个比较典型的情况：前台业务和中后台业务的保障要点是不一样的。比如说，以哈啰的业务场景为例，会有下面的两个特点。

例如两轮、四轮、电动车、电池等等，核心的目标是保障用户体验和支撑业务流程，因为重点是保证自身和相关下游强依赖系统的稳定性。注意两个点：

• 全链路: 从业务流程开始到业务流程，整个业务链条的稳定性。

• 端到端: 从APP(小程序/H5)端开始，到网关、业务系统、存储等稳定性。

在整体的方案设计中，要结合业务逻辑，准备充足的应急预案。

例如用户平台、支付平台、交易平台、地图&AI等等，在保障全链路稳定性的基础之上，还需要格外注意多个上游之间的流量叠加之后的压力。例如在平时的时候，两轮和四轮的高峰期可能重叠度不高，大促期间进行了大量的营销推广，高峰期可能会叠加；以及具备对不同上游的流量做隔离的能力，例如某个业务对平台侧服务调用量过大，平台侧应该有自我保护机制，避免系统被击垮后影响了其他业务线。

930大促顺利结束了，对于哈啰来说，各项业务指标也上了新的台阶。

但是对于有追求的技术人来说，大促结束之后，并不是一切都结束了，稳定性保障工作想要精益求精，就是要在日常的细节中做到位，在项目复盘中，要回顾大促期间的系统表现，与此前的预估模型、压测期间的系统表现进行对比。有没有哪些系统资源的水位出现了异常，利用率是否出现了过高或者过低的情况。要反过来思考为什么在此前的方案制定、压测演练中没能发现这些问题。进而优化后续的保障工作。

同时，也要回顾一些应急预案执行、变更破网等情况，比如预案的执行过程、执行结果是否都符合预期，有无优化余地。一些手动预案能否变成自动化预案等等。破网的变更有哪些，是否都是必要的，后续的大促中，能不能尽量提前变更，降低大促期间变更风险等等。

稳定性的工作因为覆盖面比较广，事项比较大，因此大家总是觉得比较琐碎，我们要做的是从这些琐碎的事项中抽象提炼出共性的东西，对它进行归纳总结，将其形成我们自己的方法论，这样才能慢慢成长起来。这一次大促保障，不管是系统本身，还是我们的稳定性经验保障，都得到了很大的提升。但是技术是无止境的，我们也从不敢大意，仍然以谨慎的心态去做好稳定性保障。