业界有很多大促流动，像 618、双 11、双 12 等等。每一次大促不只是给业务带来了新高，对于技术同样也有很重要的意义，纵观一些优良的技术团队，都是跟着业务一起成长的。在高并发大流量的背景下，如何撑持好业务经营，是一件很有挑战性的事件，它能够从多方面测验咱们的技术能力，对咱们的零碎架构和应急保障都提出了很高的要求。
哈啰在去年 9 月 30 日开启了首届的假日狂欢节，咱们也做了很多的稳定性保障工作，最终大促顺利度过，业务体感十分顺滑，所以借此机会总结下咱们在稳定性保障这方面的一些工作，分享给大家。
一、大促保障与日常保障的差异
相比日常的稳定性保障来说，大促的次要特点是 工夫短、流量大、玩法丰盛 。大促的过程个别都只有几天甚至数小时，为了尽可能冲到新的业务指标，要充分调动用户的积极性，所以营销玩法个别都比拟丰盛。因而，咱们在大促的稳定性保障中，重点从 容量布局、压测演练、应急预案、变更管控 这几个维度来做保障。
哈啰因为多业务状态共存，每条业务线有本人的倒退特点，因而大促开始前，要充沛剖析业务特点，制订针对性的保障计划。例如两轮业务(共享单车和共享助力车等)，与典型的通勤场景是统一的，在早晚的上下班高峰期，后盾的零碎流量也会特地大。而四轮业务(打车、逆风车、送货等)，则是跟着节假日有较强的关联性，每到节假日前夕，零碎可能会面临数倍于日常流量的峰值。
二、大促的整体流程
顺着大促的时间轴来看，个别会蕴含流动晚期的计划制订、压测演练，流动中的应急预案和联动等，流动后的收尾工作等。上面按程序介绍下其中的一些重点工作。
1、组织保障
公司级大促，须要多个业务线独特合作，波及多个部门泛滥人员，这个时候须要有一个相似 大促保障组之类的组织来兼顾协调，这个组织是大促保障的决策机构，它是大促保障的第一责任人，同时也赋予相应的权力: 在波及到资源抵触的时候，大促保障组有权拍板，能与业务经营沟通需要，非凡状况下，能够停掉一些非必要的迭代需要，保障大促的事项顺利推动。
同时，各个业务研发团队，也须要明确各自的 大促负责人 ( 也称大促技术 PM)，大促技术 PM 是本业务研发团队大促保障的首要负责人，要依据业务特点制订具体的保障计划，配合本业务实现大促指标。
在分工上，大促保障组负责要害里程碑的设定，比如说大促我的项目需要上线工夫、什么时候开始压测、什么时候进行封网、封网之后的变更审批 (破网) 流程，以及给出整体的保障计划框架，例如大促保障模版、技术指标拆解形式等等，能够供业务线的大促技术 PM 来作为参考根据。
在沟通机制上，大促保障组要可能从 全局视角给出以后的整体工作进度和危险详情 ，及时汇报给管理层。同时 各个业务线的大促技术 PM 也须要定期向大促保障组汇报工作停顿，包含各业务线的大促需要研发停顿、以后已知危险、资源瓶颈等等。
2、指标拆解
咱们下面提到过，大促的外围在于对流量的把控，因而指标拆解的目标次要是从 业务指标拆解为技术指标。
在业务指标设定的时候，个别会思考用订单量 /GMV/DAU/PV/UV 等各类指标作为指标，然而在咱们做保障计划的时候，须要明确地晓得技术指标，个别是 QPS、用户数等等。
所以这里须要有一个转化的过程，首先是与业务经营深刻沟通，搞清楚这次大促的次要策略和玩法，外围点是弄明确这个问题: 相比日常的业务流程来说，这次的流量从哪里来，这个玩法是如何吸引用户的，用户的操作门路与以往会有哪些不一样 。搞清楚这个，就明确了 流量门路。比方以两轮骑行为例，会思考通过一些骑行工作来晋升用户的骑行志愿：骑行 N 单之后给 X 元处分。那这外面就须要关注骑行流程、营销流动、工作处分等这几个平台相干的各个系统。同时进一步深入分析，还发现在大促流动中须要保证供给侧有足够的车辆，线下运维可能会进行一些额定的调度工作等等，这外面就须要关注运维零碎相干的流量变动。
总的来说，即 技术指标 = 业务指标 -> 实现门路(策略、玩法) -> 找到依赖的零碎 -> 明确零碎的 QPS。
3、压测演练
技术指标设定好之后，就要进行压测了，而后依据压测的后果进行调整和优化。在设定技术指标的同时，咱们还要依据业务线的具体业务玩法，设定对应的应急预案，这些预案也要通过演练来验证。
因为压测演练讲得比拟多，这里就不做过多开展，感兴趣的同学能够翻阅以往的文章。
4、变更管控
变更是导致线上故障的最大起源之一，因而大促期间，变更须要提前做好管控。依据大促的具体节奏，提前设定好相应的封网打算，包含利用公布、配置变更、运维变更等等，同时也筹备好相应的应急流程，对于某些非凡状况须要变更的，做好记录，以便流动完结后进行复盘。
5、内灰上线
大促流动因为有工夫窗口限度，所以在正式上线之后要做充沛的测试，防止出现意外状况。在做好灰度公布的根底上，对于大促的流动业务逻辑，也要进行灰度验证，个别能够用外部、外灰逐渐放量、扩全的形式进行。这次大促流动正式上线之前，咱们采纳了内灰的计划进行验证，先让公司外部共事退出到灰度白名单，去体验一下大促玩法等等。然而要 留神数据的隔离，防止内灰测试中，耗费了实在的处分等等。
6、应急值班
大促开始前，要 明确好信息同步机制，即大促值班纪律和标准，比如说系统核心 owner 必须到作战室进行值班，同时在 IM 中提前标准各个沟通群的名称和作用，把相应的研发、产品、业务、经营、客服都关联同学都拉到对应的沟通群。
比如说能够建一个全员沟通群，用于信息同步和相干告诉。同时为了高效决策，还须要把一些有决策权的 TL 拉到会议室一起值班，呈现问题之后疾速决策，下发执行等等。
小结
下面次要是大促过程中的几个关键环节，看完了这些，置信大家对大促保障曾经有一个整体意识了，接下来咱们重点聊一下保障计划具体怎么做，如果你是大促技术 PM，你会如何制订保障计划？
三、大促保障计划详解
大促保障计划是一个整体的框架，在理论的工作中，是由大促保障组产出了这个框架，而后各个大促技术 PM 依据业务特点，制订出具体的保障计划，接下来大家一起评审并进行相应的压测演练验证。
为了让大家了解统一，每个模块下都有了明确的 产出物要求，即具体要做什么事件。
1、链路梳理
大促的关键点在于流量，想要治理好流量，就须要对流量门路做到一目了然。比如说，本次大促有哪些要害入口，这些入口对应了哪些后端系统、波及了哪些资源，目前这些零碎和资源的水位怎么样，预估哪里会成为瓶颈，是否须要提前治理等等。这些都是链路须要重点关注的中央。
在链路梳理中，也应该 明确强弱依赖，比如说某个零碎的上游依赖中，哪些是必不可少的强依赖，哪些是能够容忍呈现故障的弱依赖，以及这些依赖的降级熔断配置、超时工夫设置等等，都须要详细分析。
在剖析流量门路的时候，要留神着重辨认是否存在 热点流量 ，例如产品个别在大促开始前对大量人群做 push，那么用户点击 push 之后，跳转的 落地页对应的接口可能会存在热点流量，要进行重点保障。
产出物:
- 1、一张能反馈以后零碎理论状况的链路关系图，要可能看到流量门路、反映出强弱依赖关系。
- 2、目前服务之间的依赖关系的查看后果 List，是否存在危险项。
2、技术指标 & 容量水位
容量水位剖析，是为了剖析以后零碎是否存在资源瓶颈，有无须要提前扩容的资源等等。如果临时无奈明确，也能够先输入现状，待压测之后再确认具体情况。
产出物:
1、一张以后零碎入口的 qps 表格，包含指标 qps、以后理论 qps、是否须要扩容等。
参考格局
3、监控告警
无论是在常态化稳定性保障还是大促稳定性保障，监控告警的治理都是重中之重。
在大促场景中，须要特地留神两个点：
- 1、以后各个系统的监控告警配置状况，指标笼罩是否欠缺和阈值设置是否正当。包含基础设施监控、中间件监控、应用层监控、流量入口监控等等。
- 2、与本次大促无关的一些 业务监控是否齐备 ，是否可能通过业务指标察看以后大促的流量门路。比如说业务流动的转化个别是呈漏斗型，以「一个通过发放优惠券来促成下单」的场景为例：须要有一套对应的业务大盘，能看到从 优惠券曝光、用户支付、下单核销 等各个环节的状况。
产出物:
- 1、各项监控大盘的地址和梳理后果，监控监控的覆盖度是否残缺，告警策略是否失常等。
- 2、监控指标 check 完了之后，要通过故障演练来模仿资源水位变动，看监控告警是否失常。
4、应急预案
从以往的稳定性治理教训中可得，即便咱们做了万全的筹备依然有可能出现意外状况 。因而，大促保障中更是要对各种“可能呈现”的意外状况，做好充分准备。比如说下面提到的链路梳理中，有些依赖可能须要手动调整，在零碎压力过大的状况下须要屏蔽掉一些非核心逻辑，比如说 为了保障极其状况下的用户用车，能够临时敞开红包车查看 等等。
依照大促时间轴，从“事先、事中、预先”三个维度来梳理预案，对于一些对业务可能产生的预案，要写分明业务影响面和预期，以及提前与业务方沟通分明。
- 事先预案: 提前扩容、配置限流、缓存预热等、边缘业务降级等。
- 事中预案: 即应急预案，动静配置开关等。
- 预先预案: 大促完结后要做的预案，个别为零碎缩容、复原边缘业务等。
产出物:应急预案手册，能够用表格模式出现，包含预案的类型、触发条件、执行动作、预估影响、执行人、失效速度等等。
5、联动机制
一场大促会牵扯到多方，包含产品、业务、客服、其余关联部门等等。联动机制次要包含应急值班和信息同步机制，比如说大促成行中，呈现了线上故障，在解决故障的同时，要把相干信息同步给关联方。某些状况下，须要执行预案了，这个执行预案的动作也须要同步给关联方。
- 应急值班: 蕴含值班人员名单和联系方式。
- 信息同步机制: 蕴含与产品 / 业务 / 客服等的沟通通道和机制。
产出物:
- 1、值班干系人名单，值班信息。
- 2、各业务应急值班群 & 沟通流程。
6、内部合作方保障
想要顺利通过大促，除了外部的各种保障，也须要留神内部的一些合作方的保障。防止 业务流量过大，影响了合作方的接口品质 等，本次流动是否依赖内部合作方(凋谢 API/ 内部 HTTP 交互等)，对于合作方的接口品质是否有监控告警伎俩，例如合作方接口的 rt、错误率等指标是否可观测，是否具备切换能力，例如从 A 合作方切换到 B 合作方。
提前明确我方的流量指标，与合作方进行沟通，要求合作方制订相应的保障策略，例如让合作方 在大促期间尽量避免变更等操作。最终一起与合作方输入流量评估后果和应急伎俩。
产出物:
1、与合作方的评估后果表格，蕴含: 业务场景、评估后果、合作方值班人、应急预案等。
四、不同团队的保障要点
上文咱们提到过，在具体保障工作中，要联合各团队的业务特点，制订出相符的保障计划。在多业务状态的公司中，就有个比拟典型的状况：前台业务和中后盾业务的保障要点是不一样的。比如说，以哈啰的业务场景为例，会有上面的两个特点。
前台业务保障要点
例如两轮、四轮、电动车、电池等等，外围的指标是保障用户体验和撑持业务流程，因为重点是 保障本身和相干上游强依赖零碎的稳定性。留神两个点：
- 1、全链路: 从业务流程开始到业务流程，整个业务链条的稳定性。
- 2、端到端: 从 APP(小程序 /H5)端开始，到网关、业务零碎、存储等稳定性。
在整体的方案设计中，要联合业务逻辑，筹备短缺的应急预案。
中后盾业务
例如 用户平台、领取平台、交易平台、地图 &AI 等等，在保障全链路稳定性的根底之上，还须要分外留神 多个上游之间的流量叠加之后的压力 。例如在平时的时候，两轮和四轮的高峰期可能重叠度不高，大促期间进行了大量的营销推广，高峰期可能会叠加； 以及具备对不同上游的流量做隔离的能力，例如某个业务对平台侧服务调用量过大，平台侧应该有自我爱护机制，防止零碎被击垮后影响了其余业务线。
五、预先复盘
930 大促顺利完结了，对于哈啰来说，各项业务指标也上了新的台阶。
然而对于有谋求的技术人来说，大促完结之后，并不是所有都完结了，稳定性保障工作想要精益求精，就是要在日常的细节中做到位 ，在我的项目复盘中， 要回顾大促期间的零碎体现，与此前的预估模型、压测期间的零碎体现进行比照。有没有哪些系统资源的水位呈现了异样，利用率是否呈现了过高或者过低的状况。要反过来思考为什么在此前的计划制订、压测演练中没能发现这些问题。进而优化后续的保障工作。
同时，也要回顾一些应急预案执行、变更破网等状况，比方预案的执行过程、执行后果是否都合乎预期，有无优化余地。一些手动预案是否变成自动化预案等等。破网的变更有哪些，是否都是必要的，后续的大促中，能不能尽量提前变更，升高大促期间变更危险等等。
写在最初
稳定性的工作因为覆盖面比拟广，事项比拟大，因而大家总是感觉比拟琐碎，咱们要做的是 从这些琐碎的事项中形象提炼出共性的货色，对它进行演绎总结，将其造成咱们本人的方法论，这样能力缓缓成长起来。这一次大促保障，不论是零碎自身，还是咱们的稳定性教训保障，都失去了很大的晋升。然而技术是无止境的，咱们也从不敢粗心，依然以审慎的心态去做好稳定性保障。大家在日常的稳定性工作中有什么领会么？欢送大家在留言交换！
（本文作者：孟闯）
本文系哈啰技术团队出品，未经许可，不得进行商业性转载或者应用。非商业目标转载或应用本文内容，敬请注明“内容转载自哈啰技术团队”。