桔妹导读：抗击疫情，桔妹提醒大家出门带好口罩，勤洗手，多通风。武汉加油！中国加油！在大家开工之际，桔妹邀您阅读滴滴全民拼车日背后的运维技术揭秘。
滴滴在2019年12月举办了空前盛大的全民拼车日活动，期间拼车价格优惠幅度空间巨大，有26个城市参与活动，数百万乘客参与。面对此类大型活动，如何保障好活动期间业务的稳定性，是摆在技术同学面前的一个挑战。本文重点从容量管理、监控报警、预案建设和流程规范等几方面，给大家分享了滴滴运维部同学近几年在多次活动实战中积累的技术沉淀和经验， 希望可以给大家后续的稳定性工作提供参考与借鉴。
1.
背景
#123滴滴全民拼车日# 拼成只要1折！最高优惠100元！
滴滴在12月3日举办了空前盛大的全民拼车日活动，期间拼车价格优惠幅度空间巨大，只需要1折！当天共有26个城市参与活动，310万乘客参与拼车日，68万人首次体验拼车服务，分享了空座位数195.2万个，同时还有一系列的返场日活动！想必大家应该都感受到此次的1折福利。
为了保障活动的顺利举行，技术同学做了一系列的工作，本文主要针对稳定性保障，和大家分享下背后的相关运维技术。
2.
稳定性抓手
下面咱们就正式开始介绍稳定性保障相关的技术；通常情况下，大型活动的稳定性保障主要从以下几方面开展工作：
团队组织
容量管理
业务预估
服务扩容
容量压测
监控报警
基础监控
系统监控
业务监控
预案管理
平台建设
限流/降级
多活灾备
流程规范
风险排查
变更封线
现场值守
复盘
第三方合作
接下来，就按照这几方面跟大家介绍下，在滴滴我们是如何做大型活动的稳定性保障的。
▍1. 团队组织
在项目确定要做之后，首先要确定的就是团队人员，谁适合或是应该做这个事情；我们一般是根据活动所涉及的业务系统，拉取相关的稳定性负责接口人，启动项目 kickoff，组成本次活动的稳定性保障FT，让大家尽早地参与进来，尽力让大家有足够的时间进行准备，期间会根据实际情况，通过例会、周报等方式来同步信息和进展。
▍2. 容量管理
2.1 业务量预估
在开始大型活动的稳定性保障工作之前，我们首先需要与活动发起方确认预计的业务量，可以通过业务活动预算、运营活动的形式、触达能力、小范围提前试点等等，最终评估出业务量。而对于节假日高峰应对来说，可以参考历史数据，做出一个预估；此次拼车日活动属于首次，为了更准确地预估出业务单量，我们选择了在几个城市提前进行了试点，再通过这几个城市的业务数据建立模型估算出此次活动的整体业务单量。各个公司可能会因业务类型不同，业务量预估的方式不同，但相同的是都需要有一个预估量作为目标，为后续的工作提供数据基础。我们这里介绍下，在确定出预期的业务量后，如何评估出当前业务系统中哪些模块需要扩容多少资源。
随着业务单量的增长，业务系统中的各模块的流量会相应上涨，这些模块所占用的 cpu 等基础资源也会相应上涨。之前我们大都基于业务单量、模块流量和模块资源使用率三者之间是线性关系的前提假设，再加上经验值来确定出系统容量的缺口。为了能准确评估出业务单量、模块流量和模块资源使用率三者之间的关系，我们实现了一套容量预估机制，分析处理业务量、模块流量和模块资源利用率的相关历史数据，经过多次回归训练和验证，预测出业务单量与模块流量之间、模块流量与模块资源利用率之间的准确关系，从而可以轻松准确地获取到在预估业务单量下，各模块的流量和基础资源负载的预期增长量，并通过全链路压测或哨兵压测获取到各模块的性能安全基线，来计算出存在容量缺口的模块及其所需的资源数目，进一步的详细信息可以查看晓庆同学的《滴滴内部线上系统的容量评估方法》这篇文章。
2.2 服务扩容
评估出容量缺口数据后，就进入了协调准备机器资源和服务扩容的阶段。对于托管在公有云的公司来说，在公有云平台申请资源即可。但对于拥有自建机房的公司，比如滴滴，通常情况下会保留出一定数量的备机来应急，如果备机数量不够，则需发起采购流程（通常周期会较长）。因此，业务方和系统运维之间要做好信息同步，尽力确保基础资源规划与预算的准确性。
近几年，业内普遍推进服务的容器化，滴滴也不例外。滴滴自建了一套基于 Docker+Kubernetes 的容器编排管理平台，并整合了滴滴内部的监控、部署、日志收集等系统，解决或优化了服务扩容环节中系统环境初始化、依赖资源准备、服务/数据部署和服务引流检查等问题，稳定高效地支撑了业务服务的弹性扩缩容；目前已接入近6W 个容器，90%的云化服务能在5-10分钟完成扩容。
2.3 容量压测
在完成业务单量预估，并根据容量缺口完成服务扩容后，我们就需要通过压测手段，来验证当前线上系统的容量是否真的能够扛住预估的业务单量。为此，滴滴早已建设了一套基于线上环境的全链路压测方案，通过压测标记透传、压测数据隔离手段保障了线上数据、压测数据的物理和逻辑隔离，关于该方案的详细信息，可以查看晓庆同学的《滴滴全链路压测解决之道》这篇文章。此次拼车日，我们依据线上业务数据、活动规模，建立了专属的拼车日压测模型，包括业务单量峰值、快车拼车等全品类比例、排队预约多场景比例等多项指标，并通过少量城市提前试点，修正压测模型，最终累计压测近十次，发现各类问题几十例，成为拼车日活动容量保障的有效手段。
▍3. 监控报警
监控报警是运维的一个传统技术方向，是问题发现的重要手段，一般从 cpu、mem、服务存活等基础级监控，rpc 调用状况等系统级监控、单量等业务级监控等方面丰富完善监控数据和报警策略；除此之外，滴滴还把各个业务的核心业务场景和核心服务模块的监控数据以卡片的形式汇聚在一起，简洁清晰地展示出了各个业务系统的健康状态，方便故障问题的模块级定位，我们内部称之为灭火图；为了能够准确监控业务系统的容量状况，我们根据源于服务历史峰值的安全流量值和实时收集的当前流量，并结合 cpu、mem 等基础资源指标，量化出了服务的实时容量水位。
针对监控覆盖度和准确性问题，我们实现了一个监控信用分机制，量化出了各个业务线的基础资源监控、存活监控、报警策略有效性等数据，有效暴露出监控盲区和问题点，让大家更高效准确地进行监控建设。
在大型活动的稳定性保障中，我们还会根据业务特点，与业务一起梳理出最核心业务指标，并建设成监控大盘，能够最直观最简洁地展示出此次活动期间业务系统的健康状态。
▍4. 预案管理
预案作为潜在或可能发生的稳定性故障问题事先制定的应急处置方案，是故障止损和缩短故障时长的重要手段；预案管理主要涉及以下几方面工作：
完备性：是否覆盖了所有潜在或可能发生的场景，是否覆盖了100%的核心业务流程
有效性：如何保证在故障时执行预案是有效且符合预期的，怎么避免因服务的迭代变更等导致预案无效的问题
执行效率：故障时预案执行是否简洁高效，生效过程是否快速
为了解决以上的问题，滴滴制定了一套预案触发决策、效果评估、定期演练等相关的制度，并建设了一个预案管理平台，集成了业务系统的切流、限流、熔断等预案，提供了快速止损、高效接入和有效演练的整体解决方案，有效保障了预案的完备性、有效性和执行效率。在大型活动稳定性保障前，只需要重新 review 以上的预案相关信息，尤其是此次活动所涉及或依赖的服务预案。
下面再讨论下限流/熔断和多活切流两个较为常见的预案。
4.1 限流/熔断
即使前期做好了容量预估、扩容和压测，确保系统可以扛住预估的业务单量压力，也无法完全保证百分百稳定，因为业务可能因各种各样的原因导致业务单量超出预期，这个时候就需要有限流能力，即使在单量超预期的情况下，保证业务系统也不会被打崩，依然能够处理之前预估的单量。当系统内部分服务出现异常的时候，也要有熔断能力，确保系统整体不被拖垮；在滴滴，我们要求线上核心服务都要具备限流和熔断能力，尤其是入口环节。
在应对大型活动时，我们应该重点把控好入口的限流阈值，确保限流阈值是经过真实流量或压测验证过的安全值，保证流量超出预期后，业务系统依然运转正常。
4.2 多活切流
对于稳定性要求较高且资源相对富裕的业务，一般会进行业务多活建设，即同时将业务部署在多个机房，互为灾备；因业务特点和机房专线等因素不同，各公司的双活建设的挑战和实现方案不尽相同；目前滴滴的核心业务早已实现了同城双活，在单个机房的服务出现异常的时候，能够快速完成切流动作，缩短故障时长，保障滴滴业务的高可用。
在大型活动前，我们会举行多活切流演练，一是验证切流预案本身的有效性，二是对各机房的容量压测摸底，三是打平各机房流量，让各机房处于最“舒适”的状态。
▍5. 流程规范
为了保障稳定性，各个公司的运维团队都会梳理制定一系列的运维相关的流程规范，比如说灰度发布、通告流程、操作规范等等，这里就不展开讲了。我们想跟大家分享的是，滴滴专门针对大型活动稳定性保障，制定的部分运维流程规范。
5.1 风险排查
在滴滴的大型活动开始前，涉及到的业务各方，都会对各自的基础资源、系统网络、业务架构等各个方面进行全方位、深层次的风险排查，发现并及时解决或规避掉潜在的风险点。
5.2 变更封线
对运维工作有所了解的同学都应该知道，相当一部分的故障都是源于线上变更。一个异常的线上变更，轻则会影响线上系统的性能或用户体验，重则会直接带来业务的不可用时长。控制好线上变更，是稳定性的一个重要工作。
虽然滴滴对线上变更，不管在流程规范，还是平台工具方面，都做了很多的工作，很大程度上降低了线上变更对业务稳定性的风险，但在面临一些大型活动的时候，我们为了追求更高的稳定性，会在活动前后的一段时间内，对业务活动相关的服务，进行封线，最大程度地规避掉线上变更带来的潜在风险。
5.3 现场值守
在活动高峰期间，为了更早地发现问题和更快地响应问题，我们会创建专门的沟通群，并安排大家时刻保持在线状态，实时关注监控数据，及时通报系统健康状态。为了便于大家的高效沟通，尤其是故障期间（假如有的话），我们甚至会提前安排大家坐在一起进行值守，我们称之为现场值守，从我们历来的经验来看，现场值守能够尽可能地缩短故障的发现，定位和决策止损时间，是一个重要的稳定性保障抓手。
5.4 复盘
在滴滴流行着一种复盘文化，稳定性工作更是重视复盘文化。我们会在大型活动结束后，积极推动进行复盘，回顾活动前后整个周期的工作，总结出各个阶段各个方面的经验和不足，并孵化出一些项目来进一步地优化和改善稳定性体系，为后续的活动保障提供更坚固更实用的基础与支撑。
▍6. 第三方合作
在我们自身开展稳定性工作的同时，我们会及时向所依赖的第三方合作伙伴同步活动信息，让第三方合作伙伴有更充足的时间进行容量评估等稳定性准备工作，也会推动第三方合作伙伴在活动期间尽力减少相关的变更，更多地关注与我们的交互状况。
3.
总结
综上所述 ，我们从团队组织、容量管理、监控报警、预案管理、流程规范以及第三方合作六个方面，对滴滴大型活动稳定性保障工作做了一个初步的介绍，希望可以给大家后续的工作提供参考与借鉴。
此次活动在给大家带来了1折福利的同时，对我们滴滴运维技术来说，也是一次非常好的挑战和成长：
再次验证了滴滴长期以来持续的稳定性建设，并完善和加固了现有的稳定性保障体系
对参与其中的每个技术同学是一次非常好的历练和成长
为后续大型活动的保障积累了丰富的经验和数据
最后，想给大家说的是，稳定性建设不是一次性工程，需要持续不断的投入和加固，尤其是在业务持续增长和优化的时候。上述给大家分享的稳定性抓手，也不是在一次活动保障后就完全具备的，而是滴滴这几年在一次又一次的稳定性挑战和考验中反复提炼和打磨出的，并仍会继续改进和优化。
本文作者
▬
张卫民
滴滴 | 运维专家工程师
目前就职于滴滴出行基础平台部的运维部，担任运维专家工程师，主要负责拼车、两轮车、代驾、顺风车、金融等业务运维，以及网络监控及优化、运维效率提升等工作。
推荐阅读
▬
更多推荐
▬
滴滴开源/ Open Source
FastLoad|Levin |AoE |Delta |Mpx | Booster |Chameleon |DDMQ |DroidAssist |Rdebug |Doraemonkit |Kemon|Mand Moblie |virtualApk|获取更多项目
技术干货 / Recommended article
高频 golang 服务接口超时排查&性能调优|一种线上系统的容量评估方法|浅谈滴滴派单算法|阅读更多