作者简介
阿里巴巴双 1 1 技术团队：负责双 1 1 所有产品的开发，保障系统稳定性和用户体验，覆盖了几乎阿里所有事业部的技术团队，由天猫、手淘、业务平台、淘 宝、蚂蚁、聚划算、中间件、搜索、菜鸟、阿里云、安全、基础架构、商家事业部、AliExpress、飞猪、阿里健康、数据平台、村淘、阿里妈妈、集团客服、钉钉、阿里通信、优酷等二十多个BU共同组成的技术团队。
目录
序一IX
序二X
双11大事年表XII
引言XIII
第1章阿里技术架构演进1
1.1五彩石，电商架构新起点3
1.2异地多活，解除单地域部署限制的新型双11扩容方式9
1.3混合云，利用阿里云弹性大幅降低双11成本17
1.4OceanBase，云时代的关系数据库23
1.5手机淘 宝，移动互联网电商新时代30
1.6蚂蚁技术架构演进36
第2章稳定，双11的生命线43
2.1容量规划，资源分配的指南针45
2.2全链路压测，大促备战的核武器51
2.3全链路功能，提前开始的狂欢盛宴58
2.4自动化备战，喝着咖啡搞大促65
2.5实时业务审计，从系统可用到业务正确70
2.6故障演练，系统健壮性的探测仪75
2.7系统自我保护，稳定性的最后一道屏障82
第3章技术拓展商业边界89
3.1招商报名，活动基础设施建设91
3.2会场，小二与商家共同打造的购物清单99
3.3搜索，大促场景下智能化演进之路107
3.4个性化推荐，大数据和智能时代的新航路114
3.5供应链，从飞速增长到精耕细作120
3.6蚂蚁花呗，无忧支付的完美体验127
第4章移动端的技术创新之路133
4.1Weex，让双11更流畅135
4.2互动，让购物变成狂欢143
4.3VR&AR，移动端创新体验153
4.4奥创&TMF，让双11多端业务腾飞163
第5章繁荣生态，赋能商家171
5.1聚石塔，开放的电商云工作台173
5.2菜鸟电子面单，大数据改变物流179
5.3生意参谋，数据赋能商家的“黑科技”184
5.4阿里小蜜，用智能重新定义服务191
5.5阿里中间件，让传统企业插上互联网的翅膀198
5.6蚂蚁金服，金融机构间协同运维的探索和实践205
展望213
索引216
序言
推荐序
序一
2016年“*猫双11全球狂欢节”又攀上了新的高峰——单日交易额定格在1207亿元。数字背后更重要的是，在五年、十年以后回过头来看2016年的双11，这是整个社会走向“新零售、新制造、新金融、新技术、新资源”的起点。
正是阿里巴巴集团坚强的技术后盾，支撑起了全球范围内都难得一见的庞大且复杂的交易体系和交易规模。在2016年双11当中，阿里巴巴的技术团队又创造出非常惊人的纪录——每秒同时创建17.5万笔订单以及1秒钟同时完成12万笔支付。正是八年双11的锻炼，使得阿里巴巴集团沉淀出了这样的技术能力。
展望未来，云计算、大数据将成为未来社会的新引擎和新能源。我们坚信数据将在商业变革中发挥重要的作用，整个商业变革一定会跟互联网、跟技术去完美拥抱。我们坚信这样的变革最终会产生化学反应，产生全新的结合和全新的价值。而这样的价值的创造，毫无疑问会让社会商业出现很多新的模式、新的业态。阿里巴巴集团希望通过各种方式，赋能给合作伙伴和客户，并输出成为商业社会的基础设施，让整个商业社会的变革更加高效、顺畅。
《尽在双11——阿里巴巴技术演进与超越》以双11为着眼点，从技术的角度，展示了阿里巴巴的演进、变革与发展，系统地阐述了阿里巴巴重要阶段的技术进步历程。进无止境，我们希望将我们的经验分享给更多人，并希望与大家一起共同探索未来。
张勇
阿里巴巴集团CEO
序二
双11诞生的2009年，恰逢中国互联网第三次浪潮元年。大数据、云计算、无线在这个时期逐渐成为主流技术。在双11八年的发展历程中，阿里人从互联网发展的大潮中汲取了丰富的技术能量。
作为双11这个阿里巴巴*大的集团级项目的技术负责人，这八年里，如何在技术上持续创新、调动和提升工程师的工作效能、激发战斗意志和创造力是巨大的挑战。从技术管理的角度上，我分享三点，与大家共勉。
第一，既要有梦想，又要有实力。如果没有对梦想的坚持，以及对实现梦想的不懈努力，今天双11很可能与一般的线上大促没有什么区别，更不会成为中国乃至全世界普遍关注的社会现象。阿里巴巴是一家使命驱动的公司，双11是阿里人自主创新、追逐让天下没有难做的生意的梦想的具体体现。同时，实现这个梦想需要有强大的技术实力作为基础。以计算为例，双11有大量的计算，一切关于搜索、推荐、人工智能的“梦想”都需要计算平台的强力支撑，阿里巴巴如果不打破传统Hadoop框架的藩篱，自研非常高效的离线和实时计算平台，用户在交易的过程中就不可能有“丝滑般的顺畅感受”。
第二，鼓励技术创新。没有阿里人在技术拓展商业边界上持续的突破，就没有双11持续的成功。双11当天交易峰值较平时增长400倍，平日运转良好的系统面对突发的业务流量，所有的问题都会被重新定义。全链路一体化方案通过逼真化模拟实际大促时的流量特点，以自动化的方式评估、优化和保护整个交易链条，确保了双11的稳定性。全链路方案是阿里工程师的创造，无论在国内还是国外，都是前所未有的。类似于全链路压测这样的技术创新在双11中还有很多。
第三，协同的重要性。业务发展到一定阶段都会遇到“飞机在全速飞行的前提下换引擎”的问题，是在现有框架下对两个业务分别改造，还是推倒现有模式建立一个技术共享的新模式？这不仅是对架构能力的挑战，更是对团队的协同作战能力的考验。五彩石项目就是一个生动的例子。作为该项目的负责人，我亲历了将*宝网和*宝商城（后更名*猫商城）两个系统，在会员、商品、交易、店铺、优惠积分等数据层面打通的全过程。五彩石项目是一次协同角度上的伟大的技术变革，提出了“共享服务化”的理念，为包括双11在内的几乎所有阿里业务所采纳，并与分布式中间件架构一起成为互联网电商业务事实上的标准。
我推荐《尽在双11——阿里巴巴技术演进与超越》这本书，它是迄今为止对双11技术演进最客观、最翔实的还原。无论是互联网工程师，还是商业领域的从业者，以及工程或商业专业的在读学生，都可以从书中找到自己感兴趣的内容。
最后，在阅读这本书的过程中，那些年、那些人、那些事儿重新回到眼前。谢谢所有参与《尽在双11——阿里巴巴技术演进与超越》撰写的同学们，你们用另一种方式又走过了一遍双11。
行癫
阿里巴巴集团CTO
引言
不知不觉中双11已经走过了八年，从刚开始的全新概念，到现在的举世关注，有偶然也有幸运的成分，但是细细数下来，每一步，每一刻，都是好多人殚精竭虑、费尽心思的结果。对技术而言，每一年的双11都是一场严峻的考验，从被流量冲击得溃不成军，被迫奋起抗击，到现在通过技术的力量不断改写双11的用户体验和参与感，阿里的技术伴随着双11成长起来，强壮起来，自信起来。
从组织上来说，双11从第一年的突发奇想，野生无序，逐渐发展下来，已经成为一场整个阿里及其生态联动的战役，双11已经不仅仅是*猫的双11，也不仅仅是阿里所有事业单位的双11，而是整个互联网生态的双11。
2009年我们技术部门只有几个人临时安排值班，高峰每秒只有400个请求，到2016年阿里有23个事业单位、几千位技术人员一起加入了双11的备战。杭州西溪园区1号楼的7楼、6楼和5楼都成为了双11的集中作战室，实现了每秒处理1.7万条请求的技术奇迹。为双11做出艰苦备战的还有商家、银行、物流公司，他们和我们一起迎接流量高峰的挑战，一起为了互联网更加完善的用户体验不断努力和前进。
面对新的挑战，我们从不敢放下的是对用户的敬畏和感激之心，借由本书，借由双11的历史，将阿里这些年在大流量管控上所做的技术创新共享给关注我们的朋友，并答谢所有双11的贡献者、参与者、传播者、提及者和知晓者。
2009年：双11诞生效果惊人
2009年是*宝商城（*宝商城：2008年4月成立，是一个高品质商品的综合性购物网站。2012年1月11日上午，*宝商城正式宣布更名为“*猫”。）成立的第二年，这一年的秋天，运营部门想搞一场营销活动，逍遥子（逍遥子：现任阿里巴巴集团首席执行官，同时是阿里巴巴集团董事局董事。2008年逍遥子是*宝网首席运营官兼*宝商城总经理。）喜欢四个一，而11.11又是网民创造的“光棍节”，所以就选择了这一天。谁也没有想到，这样一个带着点随意的选择，竟然在若干年后成为影响中国乃至全球的大事件，造就了电商行业具影响力的品牌——双11。
第一届双11的活动口号是全场五折，拉了几十个商户参加，未曾想效果惊人，*宝商城的成交额是平时的10倍。幸运的是，在2009年年初，五彩石项目将*宝网和*宝商城的系统底层架构统一了。虽然*宝商城的成交额增加10倍，但由于基数还比较小，这个成交额和*宝网的日常成交额比起来并不大，因此系统上虽然出现一些小问题，但是没有产生特别大的影响。
尽管如此，暴增的流量还是让工程师们措手不及。采访当年第一届双11的工程师四虎（四虎：2007年加入阿里，参加第一届双11的开发，连续参与双11八年，现在是聚划算技术负责人。）时，他回忆说：“第一年双11，作为交易系统的owner（所有者），接到老板指示，光棍节要搞个活动，你值一下班。那年我们啥都没做，就坐在那看服务器的情况。零点一到，发现服务器流量暴增，一下子部分应用的服务器就挂了。我们就手忙脚乱地去重启服务器，恢复系统。应用系统起来后，发现店铺和商品图片又出不来了。第一次双11，可以说完全是意料之外，没有做任何准备的，不仅把我们的交易和商品系统压挂了，同时还把很多商家的外部图片空间也给压挂了。服务器容量、网络带宽容量、系统保护都是没有的。”
2010年：搜索降级渡难关
吸取了上一年的经验，2010年双11之前，技术部门专门成立了大促小分队，队员包括各个核心系统的开发人员和技术保障部软硬件维护人员，当时还成立了大促指挥团，由振飞（现任阿里首席风险官。2010年任技术保障部副总裁。）、周明（现任基础架构事业群资 深 总监。2010年任技术保障部总监。）、范禹（现任*猫事业部技术部资深总监和研究员。）统一负责大促技术方案的相关决策。
负责保障稳定性的人员在指定地点集中办公。那一年，高峰不在零点，而是出现在第二天白天，早上10点左右，CDN的容量很快达到上限，图片展示越来越慢，眼看就要出不来了。大家紧张起来，激烈地讨论还有什么办法。有人提出搜索的图片展示占了很大的容量，可以将搜索的大图降级为小图。然后给搜索的负责人打电话，通知他：“对不起了，我们要对搜索的图片降级了，双11结束就给你们恢复过来。”这一招帮助当年的双11渡过了容量的大风险。之后，每一年的搜索大图降级为小图都成了双11的必备降级方法之一，尽管后面再也没有启用过。同时，每一年双11之前CDN都会开一个大会，让所有业务评估自己双11当天的CDN使用量，提前两个月就开始做扩容的准备。“所有的苦难都是用来帮助我们成长的”，这句话用在双11上特别合适。
四虎回忆第二年的情景：“第二年，我们开始有了心理准备，预计流量是平时的3~5倍，但是实际流量远远超出我们的想象，达到了平时流量的十几倍。不过基于前一年的经验，这一年我们做了很多工作，分布式系统的防雪崩、核心系统的自治，这些技术改进让我们的系统比上一年好了很多，虽然零点高峰时还是出现了大量的购买失败，但是服务器没有大面积宕机，流量下降后能够继续良好地服务。”
2011年：匆忙中解决突发事件
2012年：系统超卖了
2013年：有惊无险
2014年：最顺利的双11
2015年：移动端购买率大大提升
2016年：实现云化
（注：以上2011—2016年双11的具体描述见书中的“引言”，这里省略）
从2010年开始，为了双11的顺利进行，阿里每年都会任命一个双11技术部团长来整体负责双11技术的稳定性工作。在团长之下，会成立一个大促小分队，然后在各个事业群选拔最合适的同学作为各个事业群的队长。队长在负责本BU技术工作的同时，还负责和其他BU进行联动和消息共享沟通。队长通过周会的形式来互报进度和风险。为了双11当天的稳定，每年都会安排4至6次的功能回归演习和全链路压测验证工作，这些工作会在几十个事业群中同步进行。通常参加一次全链路压测的技术人员都会在300人以上。
这么多年双11下来，有些人好奇：“做了这么多年了，该准备的都准备好了，为什么每次技术部还那么紧张啊？”听完了这些历史，也许能有一丝明白，每年的双11，我们的玩法都在变化，我们的流量不断挑战高峰，我们的技术也在效率和创新上实现着自我突破。双11没有一年不辛苦，没有一年不紧张，没有一年不需要加班熬夜通宵，没有一年不是战战兢兢。有人在解决问题时一边哭泣一边写代码；有人在双11结束的第二天就会去找主管“我明年再也不要干双11了”；有人由于身体或者家庭的原因申请离开。但庆幸的是，每年都会有更多的人加入进来，带着新的热情和梦想，明知路难行，明知山有虎，但总需要有那样一群人，咬着牙，红着眼，在再大的压力下，在再苦的环境下，在已经通宵神志不清的情况下，把问题一个个解决掉，然后笑着告诉大家：“今年我们一起又把双11扛过去了。”
这是我们阿里技术对所有用户的态度，我们不完美，我们会犯错，我们没有提供给用户好的体验，我们很抱歉，我们会在深夜哭泣，哭泣我们不小心的遗憾，哭泣我们一个疏忽给用户带来的严重影响。但是我们在努力，我们在前进，我们在错误中不断反思，继而成长。感谢这些年用户对我们的接纳和信任，请相信我们在努力。也借这本书答谢所有参加过双11的朋友们，谢谢你们对我们的信任，我们会带着这份信任一路前行，让中国互联网的声音响彻全世界。
文摘
2.2 全链路压测，大促备战的核武器
全链路压测被誉为大促备战的“核武器”。如果之前关注过阿里双11相关的技术总结，对全链路压测一定不会陌生，这个词的出场率几乎是100%，从对双11稳定性的价值来看，用“核武器”来形容全链路压测毫不为过。
2.2.1 背景
历年的双11备战过程中，很大的困难在于评估从用户登录到完成购买的整个链条中，核心页面和交易支付的实际承载能力。自2009年第一次双11以来，每年双11的业务规模增长迅速，零点的峰值流量带给我们的不确定性越来越大。2010年，我们上线了容量规划平台从单个点的维度解决了容量规划的问题，然而在进行单点容量规划的时候，有一个前提条件：下游依赖的服务状态是非常好的。实际情况并非如此，双11 零点到来时，从CDN到接入层、前端应用、后端服务、缓存、存储、中间件整个链路都面临着巨大流量，这时应用的服务状态除了受自身影响，还会受到环境影响，并且影响面会继续传递到上游，哪怕一个环节出现一点误差，误差在上下游经过几层累积后会造成什么影响谁都无法确定。所以除了事先进行容量规划，还需要建立起一套验证机制，来验证我们各个环节的准备都是符合预期的。……全链路压测的诞生就解决了容量的确定性问题！
2.2.2 全链路压测1.0从无到有
提前对双11进行模拟听起来就不简单，毕竟双11的规模和复杂性都是空前的，要将双11提前模拟出来，难度可想而知：
• 跟双11相关的业务系统有上百个，并且牵涉整条链路上所有的基础设施和中间件，如何确保压测流量能够通畅无阻，没有死角？
• 压测的数据怎么构造（亿万级的商品和用户），数据模型如何与双11贴近？
• 全链路压测直接在线上的真实环境进行双11模拟，怎样来保证对线上无影响？
• 双11是一个上亿用户参与的盛大活动，所带来的巨大流量要怎样制作出来？
2013年8月中旬，当时高可用架构团队的负责人叔同（叔同：高可用架构&运维产
品&基础产品团队负责人、资深技术专家）接下了这个巨大的挑战：打造一套全链路压测平台。平台需要在2013年双11之前上线，错过了这个时间点，我们就必须再等一年。从立项到双11，留给我们的时间只有短短两个多月，时间非常紧，我们需要在这么短的时间里应对一系列历史级的挑战。2013年阿里搬到西溪园区，其他同学都是搬到新工位，全链路压测项目组直接搬到了项目室，进行闭关攻坚。
业务改造升级
2013年核心交易链路就有几十条，牵涉多个BU的几百位研发人员，这些业务链路绝大部分是没法直接压测的，需要进行相应的业务改造和中间件的升级。推动几百号人在短时间之内完成业务的改造在很多公司几乎是不可能完成的，何况还牵涉中间件的升级，中间件的升级一般会有一个相对比较长的周期，有不少业务系统的中间件版本都非常古老（5年前的版本），需要确保无风险直接升级到最新版本。
在业务端我们需要逐条链路进行一一梳理，从请求进来的系统到请求的最后一个环节（复杂的业务会经过几十个系统），每一个有阻压测流量往下走的地方都进行特殊的逻辑改造。改造的业务点牵涉100多个，包括登录验证码、安全策略、业务流程校验等。在基础设施和中间件上，我们需要让业务系统的代码尽可能不需要修改，通用的技术通过基础设施和中间件来屏蔽掉，比如压测流量的标识怎样在整个请求的生命周期中一直流转下去，怎样来对非法的请求进行拦截处理。
参与全链路压测改造的技术人员体现了良好的协作精神和执行力，为了同一个目标齐头并进、相互补位，原本认为几乎不可能的事情，最终在一个月内完成了相应的业务改造和中间件升级。
数据构造
数据构造有两个核心点：
• 双11的买家、卖家、商品数量都非常庞大，需要构造同数量级的业务数据；
……
为此我们专门搭建了全链路压测的数据构造平台，对业务模型进行系统化的管理，同时完成海量业务数据的自动化构造，如图2-5所示。
数据构造平台以线上数据为基础，借助数据dump（dump：在特定时刻，将储存装置或储存装置之某部分的内容记录在另一储存装置中）工具进行数据的抽取，并对关键数据进行相应的处理（脱敏、订正等）后进入基础数据池备用。基础数据池是压测数据的超集，具体压测数据的构造基于基础数据集进行数据的再加工。
除了需要有足够量级的数据，我们要解决的另一个问题是数据的模型应该是怎样的。借助BI工具结合预测算法对数据进行筛选建模，并结合每一年双11的业务玩法进行修订，产出一份最终的业务模型。业务模型的因子牵涉几百个业务指标，包含买家数、买家类型、卖家数、卖家类型、优惠种类、优惠比例、购物车商品数、BC比例、移动PC比例、业务的量级等。
数据隔离
全链路压测要不要做数据隔离、怎样来做数据隔离，在项目立项阶段经过了非常多的讨论甚至争吵。在最开始的时候，我们想做逻辑隔离，直接把测试数据和正常数据写到一起，通过特殊的标识区分开，这个方案很快就被放弃了：线上数据的安全性和完整性不能被破坏。接下来我们提出了另一个方案，在所有写数据的地方做mock（mock：软件开发概念，指模拟），并不真正写进去，这个方案不会对线上产生污染，但评估时还是被放弃了：mock对压测结果的准确性会产生干扰，而我们需要一个最贴近实际行为的压测结果。
经过反复讨论，最终我们找到了一个既不污染线上，又能保障压测结果准确性的方案：在所有写数据的地方对压测流量进行识别，判断一旦是压测流量的写，就写到隔离的位置，包括存储、缓存、搜索引擎等。
4. 流量构造
双11是一场“剁手党”的狂欢，零点的峰值流量是平时高峰的几百倍，每秒几百万次的请求如何构造同样成为大难题。我们尝试通过浏览器引擎或者一些开源压测工具的方式来模拟用户请求，经过实际测试，要制作出双11规模的用户流量，浏览器引擎和开源压测工具需要准备几十万台服务器的规模，成本是无法接受的，并且在集群控制、请求定制上存在不少限制。既然没有现成的工具可以使用，我们只好选择自己研发一套全链路压测流量平台，如图2-6所示。
全链路压测的流量平台是一个典型的Master＋Slave结构：Master作为压测管控台管理着上千个Slave节点；Slave节点作为压测引擎，负责具体的请求发送。Master作为整个压测平台的大脑，负责整个平台的运转控制、命令发送、数据收集、决策等。Slave节点部署在全球各地的CDN节点上，从而模拟从全球各地过来的用户请求。整套全链路压测的流量平台在压测过程中平稳输出1000多万/秒的用户请求，同时保持过亿的移动端用户长连接。
正式上线
在两个多月的时间里，项目组的成员披星戴月，有一半时间在通宵，另外一半时间是凌晨3点以后下班。2013年10月17日凌晨的1号楼，全链路第一次登台亮相（如图2-7所示），这一天对整个全链路压测项目组的人都意义非凡，辛苦了两个多月的“大杀招”终于要派上用场了！当压测开始的按钮被按下去，大家都全神贯注地盯着各种系统等着流量上来，1分钟、2分钟过去了，我们的业务系统却丝毫没有流量进来。忙活了一晚上，第一次亮相狼狈收场，当时全场有200多号人，每一次让大家准备好却没有流量发出去的时候，面对着全场200多双眼睛，压测项目组每一个成员的手都是抖的。好在第一次的失败让我们吸取了充分的经验，又经过好几个昼夜的奋战，第二次的压测比第一次进步了很多，到了第三次就已经能完全达到我们的使用预期了。
2.2.3 全链路压测2.0平台升级
全链路压测诞生之后为系统稳定性带来的改变立竿见影，2013年经过了几次全链路压测，双11零点的表现比以往任何一年都平顺。全链路压测也在阿里一炮而红，越来越多的业务希望能接入进来。
1. 平台化
海量的业务接入给全链路压测平台带来全新的挑战：当时的全链路压测操作都需要压测项目组的成员来进行操控。随着越来越多的业务接入全链路压测平台，压测项目组很快就成了瓶颈，压测平台的能力急需升级。2015年，全链路压测“平台化”项目启动，我们着手将全链路压测朝着平台化的目标推进和实施，做到压测能力开放、业务方自主压测，让更多业务方能够享受到全链路压测的优势和便利，如图2-8所示。全链路压测平台化项目的上线大幅提升了全链路压测平台的服务能力：2015年大促备战的3个月内，压测平台总共受理近600多个压测需求（比2014年提升20倍），执行压测任务3000多次（比2014年提升30倍）。
2. 日常化
全链路压测的压测流量和正式流量经过的路径是一致的，如果链路中某一个节点被压挂或者触发限流，势必会影响线上用户的正常访问。为了减少影响，全链路压测一般都安排在凌晨，通宵达旦，非常辛苦！为了减少熬夜，提升压测幸福度，我们启动了白天压测的项目：将线上运行的机器动态隔离出一部分放到隔离环境中，这部分机器上只有压测流量可以访问，白天在隔离环境的机器上进行压测。隔离环境与线上环境几乎一样，从流量入口、中间件、应用后端实现完整隔离。隔离环境完全打通了配置中心、服务注册中心、消息中心、地址服务器等基础设施，不需要业务系统做任何改造即可完成。并且是直接从线上机器按照特定规则选择到隔离环境中，机型配置跟线上基本一致，使用完毕之后直接恢复到线上集群中，不会影响线上集群的容量。大促备战期间，我们可以白天在隔离环境中进行小目标、小范围的全链路压测，用极小的代价提前发现问题。由于隔离环境场景相对于其他线下环境更加真实、操作快捷、不占用额外机器资源，在预案演练、破坏性测试、线上问题排查、故障演练等其他场合也获得了比较广泛的应用。
2.2.4 全链路压测3.0生态建设
2016年在三地五单元混合云部署架构下，电商一半以上的资源部署在云上。在庞大的电商系统背景下，如何能够在最短的时间内完成一个单元的搭建和容量准备成为摆在我们面前的一道难题，而全靠“经验之谈”和人工介入是不可能完成的任务。2016年初，“大促容量弹性交付产品”立项，旨在减少甚至释放活动场景的容量交付中的人工投入，并将大促容量交付的运维能力沉淀到系统中，使全链路容量具备“自动化”调整的能力。我们提出了大促自动化备战的想法，将大促容量准备的各个环节进行系统层面的打通，从业务因子埋点、监控体系、模型预测、压测数据构造、压测流量发送、压测结果分析、压测报表进行自动化串联，大幅缩减了在大促容量准备阶段的人员投入和时间周期。围绕全链路压测的核心基础设施，全链路压测的周边生态逐步建立起来，打通建站、容量、监控等配套技术体系，如图2-9所示。
全链路压测在保障系统稳定性的同时，也为业务稳定性的保障提供了强有力的支持，2016年我们落地了全链路功能测试、大促功能预演等一系列项目：创造性地在隔离环境提前将系统时间设置到双11的零点。……
2.2.5 总结
每年双11前夕，全链路压测都要组织好几次，不断地通过压测发现问题进行迭代优化，全方位验证业务的稳定性，我们的业务系统也只有在经过了全链路压测的验证之后才有信心迎接双11零点的到来。全链路压测将大促稳定性保障提升到新的高度，是双11、双12等大促备战最重要的“核武器”，并且随着业务的发展不断进化，持续发挥着不可替代的作用。
