背景

　　众所周知，业务高峰带来的流量大幅增加会对系统造成巨大的压力和风险，就像消防局在火灾高发期需要加强火灾风险关注一样，货拉拉也需要在高风险时段投入更多资源识别和解决问题。而业务高峰通常还具备一些特殊意义，往往伴随着公司业务目标的达成，如单日订单破峰，如果因为系统故障导致目标未达成，影响也会非常恶劣。当前货拉拉会经历各种业务高峰场景，像新业务开城放量、优惠权益秒杀、节前货运需求激增等等，都要求系统具备高度稳定性和抗风险能力。　

　　自2020年下半年起，货拉拉开始系统化地进行业务高峰保障，经过三年多努力，技术团队累计发起34次业务高峰保障，且自2021年以来连续三年多在业务高峰期间保持零故障记录。接下来我将与大家分享在此过程中积累的实践心得和思路。

　　一、业务高峰保障应该如何开展？有哪些重难点？

　　1.1 明确业务高峰保障的目标

　　对于业务高峰稳定性保障，毫无疑问，我们最重要的目标是确保期间不发生任何系统故障。除此之外，要与业务部门充分沟通，对齐要保障的具体业务目标。比如，确定用户下单指标的具体目标数值是多少，100万还是200万。如果业务目标单量过于夸张，比如相比日常增长100倍，那技术团队肯定需要提前评估这一目标的可行性和成本。这样，我们才能向业务部门提供准确信息，帮助他们做出合理决策。　　

　　除了上述目标之外，技术内部也有一些关键过程指标，比如系统的SLA表现、线上问题的应急处理时效等。

　　最后，难度较大的目标还是关于成本的目标管理，在发展初期，稳定性保障往往需要较大的投入，成本管理也是较容易被忽视的点。这方面需要思考的主要问题，一个是我们在进行保障工作的过程中，人效是否能有所提高；其次，在相同增长规模下，服务器资源的单位投入是否有所降低：举例来说，如果之前业务高峰时，需要投入50万的服务器成本，那么下一次同样的单量增长情况下，投入的资源成本是不是能比之前要少？

　　1.2 业务高峰保障应该怎么开展（项目管理的视角）

　　定好目标之后，就需要从项目管理的视角出发，来审视和规划后续的工作。

　　我们先来看下业务高峰保障的特点。稳定性保障项目相比一般项目来说，参与的人数更多，涉及的部门跨度也更大。而且，业务高峰保障通常是一个不能延期的项目——有些业务开城或许可以适当延期，但像双11这样的大型促销活动，以及货拉拉随着市场需求增加而面临的高峰，是不可能推迟的。因此，保障项目组在整个过程中扮演着至关重要的角色。相比攻克技术难题，如何组织不同职能的人员共同达成目标可能更具挑战性。　　

　　可以通过以下这些措施，确保项目管理视角下的保障工作有效开展。

　　1）建立保障项目组。

　　明确组织矩阵——对于整个保障项目组，在一开始就要明确保障工作的组织结构。需要确定引入哪些人员，以及这些人分别负责哪些领域的工作。

　　对齐保障节奏——由于这大多数是一个倒排期项目，必须安排好整个保障项目的周期，确保每个关键里程碑的达成。

　　2）业务输入/更新。在整个大横向组织的对接中，保障项目组承担着向上接收业务输入和信息更新的任务。需要与业务部门对齐，明确业务高峰保障的具体时间、目标业务指标，以及可能发生的关键运营动作。

　　3）任务输出/验收。这部分主要面向保障工作的实际执行者——技术研发，下发保障具体工作任务，并对整体完成情况进行验收。在这个过程中，会采用一些常规的项目管理手段。项目Kick-off，项目整体进展定期沟通，包括保障大群、项目周例会等组织形式。

　　1.3 保障任务的具体内容（技术保障的视角）

　　从技术视角来看，整个业务高峰保障流程的核心是风险管理，从风险识别到风险消除，确保没有遗漏的风险点，并为每个已识别的风险制定解决方案。

　　在主体层面，可以将风险分为三个主要部分：公司内部、外部使用者、三方依赖。根据稳定性保障的通用经验，风险类别又可大致分为——容量风险、变更风险、链路风险、人员风险。结合风险类别和风险主体，可以构建起整个技术保障的框架。　　

　　1）外部客户。这方面可能带来的主要风险是流量冲击，要求我们根据系统承载能力的上限，提前设定合理的限流阈值。

　　2）公司内部。这部分是主战场。

　　在容量风险方面，除了进行压测和系统扩容，还需要准备充分的预案，包括提前的营销场景数据预热和紧急情况下的降级预案。

　　变更管理是另一个关键点，我们通常会采取封网措施，规定在特定时间内不允许进行任何变更。同时，也会在高峰前对核心变更内容进行审查，避免已治理过的内容发生变动，以确保保障工作的效果是可控的。

　　链路健壮性方面，重点关注服务风险治理，包括各项超时、降级熔断、依赖关系等等的合理性。完成治理后，我们将在关键点进行攻防演练，以检验效果。

　　人员风险同样不容忽视。为避免在关键时刻找不到处理问题的人，我们要求团队提前安排好值班人员，并在高峰期间进行系统巡检和打卡。除此之外，设置小黑屋值班机制也是很有必要的，把各核心系统的关键负责人集中在一个大会议室里，方便快速沟通、将问题消灭在萌芽阶段。

　　3）三方依赖。这里特别要关注容量风险和降级手段。由于三方容量采购流程通常较长，需要确保提前准备到位。对于有备份或弱依赖的服务，要制定一键降级预案，并进行演练验证。另外在应急响应方面，也要提前通知所有厂商业务高峰期的时间，确保他们能够提供必要的支持。

　　1.3.1 云商重保

　　三方依赖这里，我将就云服务商的保障重点展开分享，因为云商的稳定性对完全上云的业务系统是至关重要的。

　　信息拉齐。货拉拉会由专业的云资源团队负责与云服务商对接。将业务高峰的信息拉齐是一开始的关键，要确保所有相关人员都能充分理解和重视业务高峰保障的重要性。

　　资源备货。提前备货是最重要的事项，因为云商的资源并不是无限的，有些特殊规格的资源存量较小，需要提前与云商协调准备好所需的资源。　　

　　资源预热。在高峰期来临前，某些资源可能需要进行预热。确保这些资源在高峰期前得到充分预热，以防止资源短缺或性能问题。

　　机器巡检。对底层物理机器进行必要的巡检工作，包括检查硬件是否存在风险。如果发现风险，可以进行硬件替换，以避免风险在业务高峰期间爆发产生故障。

　　聚合度管理。虽然服务架构和底层资源已经做到尽可能隔离，但在物理机视角上的资源聚合度仍需关注。之前曾遇到云商只挂了一台物理机，但对我们系统影响很大，主要原因就是许多核心实例都部署在了这台机器上，聚合度太高。因此，我们要求云商定期扫描聚合度，如果发现聚合度过高的情况，要提前进行资源打散操作。

　　变更通知。尽管无法要求云商在业务高峰期封网，但可以尽可能要求他们在此期间提前通知任何变更动作。这有助于提前准备，出现问题后快速确认及处理，缩短影响时长。

　　应急值班。货拉拉与主要依赖的两个云商都有相关的应急沟通群，这些群组设在我们内部的办公聊天软件上，以提高沟通效率，减少使用微信、钉钉等多个平台的麻烦。在一些重要的业务高峰期间（通常一年一两次），还会要求云商提供驻场支持，确保得到最大力度的保障。　　

　　1.4 业务高峰保障的重点

　　最后再次回顾下整个保障思路中的两个重点内容。　

　　1.4.1 项目组织

　　1）PMO 参与

　　必须高度重视项目组织工作。就像修建高楼需要各个工种通力合作一样，项目的顺利进行也需要专业的PMO人员。在货拉拉，有专业的PMO团队负责整体项目的组织与协调，确保项目按计划推进并统筹解决实施过程中的各种问题。

　　2）部门接口人机制

　　由于项目涉及的人员众多，可采用接口人机制。项目组与各部门接口人对齐，再由接口人与部门内部的具体实施者对接。这样可以有效降低保障工作的复杂度，明确责任分工，提升沟通效率，确保信息准确传递和任务顺利执行。

　　3）固定会议把控进度

　　确保项目例会制度严格执行，以把控整体项目进展。通过定期例会，各部门可以及时沟通任务进展、分享工作经验、暴露过程风险、提出诉求、协调资源配置等等，确保项目按计划高质量推进。

　　1.4.2 系统容量

　　另一个重点，作为系统工程师，在高峰来临前应当特别重视系统容量风险。业务高峰意味着流量的增加，如果系统健壮性不足，可能还有容错空间，但如果容量不足，问题一定会发生。在容量方面，应当关注以下几点：

　　1）打好提前量

　　不论是三方容量还是云商资源，如果这一点有疏漏，当紧急需要资源时，将无计可施，大概率要牺牲业务或用户体验。

　　2）关注爬坡阶段

　　与秒杀场景不同，货拉拉的业务高峰在高峰当日会有一个缓慢的爬坡过程。在这段黄金时间内密切关注系统表现，迅速发现并解决短板容量问题，可以大幅降低故障发生的概率。

　　3）为最坏的情况做好打算

　　如果容量保障做得不够好，出了问题，需要准备保大舍小，部分用户可使用总比所有用户都不能使用要好得多。例如，是否可以将流量做进一步限制，以确保系统容量水位健康，或者根据前期准备进行必要的业务功能降级。哪怕业务因为降级而减半或者用户体验大幅受损，也比完全崩溃要好。

　　二、货拉拉具体是怎么做的？效果如何？

　　2.1 业务高峰保障的策略　　

　　首先，站在巨人的肩膀上，借鉴他人成功经验。如果完全靠自己摸索，效率会非常低。

　　其次，有意识做好本土化工作。因为从他人那里学来的知识或方法，不一定完全适用于自己的情况。

　　第三，必须不断优化。要通过不断的复盘和优化，确保每次都比上一次做得更好。

　　最后，保持激情至关重要。采用一些运营手段来激发团队的激情。相比简单地下达指令验收执行效果，我们更倾向于激发大家的主动意识。所有人自发地为即将到来的业务高峰考虑要做什么，能带来更好的结果。

　　2.2 策略落地

　　2.2.1 如何站在巨人的肩膀上？

　　我之前在阿里本地生活有几年工作经验，因此借鉴了阿里双11大促的保障经验，快速建立起了货拉拉业务高峰保障的初步方案。这样做的好处是，确保了整个保障工作覆盖的颗粒度足够细致。阿里的保障经验已经经过了大量优化改良和实践检验，可以有效避免重复别人已经踩过的坑。　　

　　货拉拉在业务稳定性保障发展初期只提供了一些高峰保障的待办事项列表，对问题的认知不够全面。现在已经有了一套完整的保障框架体系，主要围绕风险预防和应急快恢两大主题开展。

　　2.2.2 如何做本土化改善？

　　我们在实践过程中发现，按照最初的一套方案执行后，有些保障手段在货拉拉的收益并不大，同时存在可能还没有关注到一些风险。因为相比电商大促，货拉拉作为一个订单撮合平台，更关心供需特征订单匹配。　　

　　展开说一下。业务高峰时，需求量通常比供给量要多很多。用户下单量增长迅猛，但能够承接的订单的司机数量不会一下子增加，甚至还可能减少，比如在五一前，有些司机可能选择休假。这种运力不足的情况非常明显，直接导致系统里待配对的订单越来越多。

　　对于待配对的订单，我们的系统会有一些既有策略。例如，如果一个订单发布后没有人接单，系统会扩大搜索范围，比如从10公里扩大到20公里，从而圈选到更多的司机重复推送这个订单（实际策略要复杂很多）。所以在业务高峰运力不足场景下，系统的压力增长是非常恐怖的，单纯依靠扩容代价太大。

　　因此，我们将保障重心调整到了整个订单调度系统的稳定性保障上。在研发团队出色完成架构优化的基础上，结合着相关场景降级预案的梳理和演练，比如最严重的情况下可以完全关闭重推逻辑以降低系统负载，现在我们面对这种场景具备非常充足的信心。

　　2.3 具体实施

　　2.3.1 时空维度上的策划（宏观视角）

　　首先，我们会进行一个宏观视角上的策划。这个策划工作主要是在年初时，就会列出全年会遇到的业务高峰和重大事件的时间表。这样做的好处是，全年的保障工作计划都能心中有数，能够提前规划好在大概什么时间需要开展哪个业务高峰的保障工作，并给出消息提醒，避免遗漏。　　

2.3.1 图1 - 货拉拉全年大事件一览表

　　其次，所有保障工作都会进行文档沉淀，将相关信息统一存放在一个共享空间中，方便查阅。　　

2.3.1 图2 - 货拉拉高峰保障文档空间

　　2.3.2 项目视角下的管理（执行落地）

　　从项目管理的视角出发，确保整个保障团队的构成清晰明确。我们需要知道每个领域的接口人和负责人是谁，他们主要负责哪些内容，以及整个领域的协作成员包括哪些人。　　

2.3.2 图1 - 业务高峰保障组织

　　在明确了团队成员和责任分配之后，我们会和各领域团队成员进行沟通，商讨制定保障方案，并进行KO会议。在会议中，我们会收集大家的反馈，看看方案中有哪些地方需要补充或改进。　　

2.3.2 图2 - 业务高峰保障方案框架

　　随后，PMO会设立一个项目进度看板，用来跟进整个项目的进度和完成情况。　　

2.3.2 图3 - 业务高峰保障项目进度看板

　　2.3.3 组织运营提振士气

　　高峰当日，我们会有一个被称为“小黑屋”的作战室。在这里，会确定关键人员的名单、时间安排，以及一些物资的准备工作。这些准备工作包括为团队成员安排下午茶等福利，以确保他们在紧张的工作中也能得到适当的休息和营养补充。　　

　　其次，在保障工作结束后，我们也会注重仪式感。PMO会提前准备一些物料，比如横幅、KT板等，组织大家一起进行合影留念。这样的活动不仅能够增强团队的凝聚力，也能让团队成员对参与高压力工作的辛苦付出有一个难忘的回忆。　　

　　2.2.4 复盘总结更进一步

　　在业务高峰过后，第一件事就是开展全面的复盘总结工作。

　　首先，我们会回顾目标达成情况。　　

　　接下来，我们会进行两个重要分析：

　　1对每一个保障子项进行深入分析。检查保障的目标是否达成，以及在治理过程中是否存在可以后续优化的点。　　

　　1收集复盘参与方的反馈和建议，帮助我们识别出后续改进项。这些改进项将被跟踪并反馈到下一次的保障工作中。　　

　　2.2.5 踩过的一些坑

　　货拉拉在业务高峰保障过程中，也遇到了一些教训——

　　1只关注研发服务发布配置变更，结果因为其他领域的变更出了问题。之前在封网前只关注了研发自己服务的发布和配置变更。但问题却出在了其他领域的变更上，比如运营的一些配置变更，或者是业务上的AB实验变更，包括安全策略等的变更。后续我们把这类变更也被纳入了整个保障范围。

　　1有个服务和业务流量负相关，结果出现在了待扩容名单里。我们在容量管理方面一直做得还不错，但在成本控制方面，确实也经历了一些摸索。比如有一个服务实际上与业务流量负相关，即业务单量越多，它的压力反而越小。这个服务和订单热力图有关，而订单热力图的作用是告诉司机哪里更容易接到订单。但在业务高峰时，司机其实并不缺单子，因此对热力图的访问量并不大。后来，我们对这类服务实施了更精细化的管理。

　　1缩容的时候没有精打细算，如果缩掉特定的服务器，能更省钱。在缩容时，需要注意的不仅仅是扩容后的机器要缩容回来，更重要的是要思考缩容哪些机器才能更节省成本。因为扩容时扩的是新机器，但缩容时，并不一定非得缩容这些新扩的机器，而是可以选择已经在使用中的机器。这样做会涉及到一些成本计算规则，能够帮助节省更多的成本。在这方面，我们有专业的云成本团队来帮助我们进行管控。

　　3.3 业务高峰保障成效

　　经过2020年至今3年多时间的建设，货拉拉已经具备了非常成熟的业务高峰保障能力。截止目前，货拉拉技术稳定性团队已累计发起34次业务高峰保障；且2021年至今，货拉拉业务高峰期间已连续3年保持0故障水平。同时，业务高峰保障也帮助强化了日常稳定性水平，货拉拉全年故障数也在逐年下降。　　

3.3 图 - 货拉拉全年故障数逐年下降

　　三、总结与展望

　　未来的目标之一是逃不掉的降本增效，我们主要关注两方面的成本——

　　1）资源成本。各系统扩容资源的精细化管理；极致把控服务器资源使用天数，明确资源回收对象；

　　2）人力成本。加强各保障工作的工具化能力；关注多平台间的联动，打造流水线式的稳定性保障产品生态。

　　另一个目标是实现高峰保障的日常化。每次高峰保障都是对整体技术稳定性的一次加固，也是对日常治理工作的一次反哺。未来在提效的基础上，应该把风险识别风险治理手段放到每一天来做，自然可以大大提高全年系统稳定性水平。