2018年，双11迎来了十周年。

十年间，依赖于迅速崛起的互联网技术以及各项新兴技术的沉淀，阿里巴巴缔造了全球数字经济时代的第一“操作系统”。在这个操作系统上，让全球消费者和商家买、卖、逛、听、看、游得顺心、放心、舒心。

十年间，阿里巴巴的技术同学和全球开发者们，一起把互联网前沿技术转化为全球消费者、全球数字经济参与者可以感知的便利。

它如今已经不仅仅是全球消费者的狂欢节，更是名副其实的全球互联网技术的演练场。

第十个双11即将来临之际，阿里技术推出《十年牧码记》系列，邀请参与历年双11备战的核心技术大牛，一起回顾阿里技术的变迁。

今天，天猫技术质量部资深总监、双11大队长霜波，将带领大家，细数每一年双11的重要节点和突破，遗憾与不足。我们相信，无论是双11，还是你正在经历的项目，都需要敬畏和细致的态度。所有的成功，一定是每个人极致努力的结果。

双11大队长霜波

​​2009年

2009年是淘宝商城成立的第二年，这一年的秋天，运营的同学想搞一场营销活动，逍遥子喜欢四个一，而11.11又是网民创造的“光棍节”，所以就选择了这一天。谁也没有想到，这样一个带着点随意的选择，竟然在若干年后成为影响中国乃至全球的大事件，造就了电商行业最具影响力的品牌——双11。

第一届双11的活动口号是全场五折，拉了几十个商户参加，未曾想效果惊人，淘宝商城的成交额是平时的十倍。幸运的是，在2009年初，“五彩石”项目，将淘宝和商城的系统底层架构统一了，虽然商城的成交额增加十倍，但由于基数还比较小，这个成交额和淘宝的日常成交额比起来并不大，因此系统上没有出现特别重大的事故。

尽管如此，暴增的流量还是让工程师们措手不及。采访当年第一届的工程师四虎时，他回忆说：“第一年双11，作为交易系统的owner，接到老板指示，光棍节要搞个活动，你值一下班。那年我们啥都没做，就坐在那看服务器的情况。0点一到，发现服务器流量暴增，一下子服务器就挂了。我们就手忙脚乱地去重启服务器，恢复系统。系统起来后，发现店铺和商品图片又出不来了。第一次双11，可以说完全是意料之外，没有做任何准备的，不仅仅是把我们的交易和商品系统压挂了，同时把很多商家的外部图片空间也给压挂了。服务器容量、网络带宽容量、系统保护都是没有的。”

2010年

吸取了上一年的经验，2010年双11之前技术部门专门成立了大促小分队，负责保障稳定性的同学在创业大厦10楼集中办公。那一年，高峰不在0点，而是出现在第二天白天，早上10点左右CDN的容量很快达到上限，图片展示越来越慢，眼看就要出不来了。大家紧张起来，激烈地讨论还有什么办法。有人提出搜索的图片展示占了很大的容量，可以将搜索的大图降级为小图。然后给搜索的负责人打电话，通知他：“对不起了，我们要对搜索的图片降级了，双11结束就给你们恢复过来。”这一招帮助当年的双11渡过了容量的最大风险。

之后，每一年的搜索大图降级小图都成了双11的必备降级方法之一，虽然后面再也没有启用过。同时，每一年双11之前CDN都会拉一个大会，让所有业务评估自己双11当天的CDN使用量，提早2个月就开始扩容的准备。“所有的苦难都是用来帮助我们成长的”，这句话用在双11当中特别合适。

四虎回忆第二年的情景：“第二年，我们开始有了心理准备，预计流量是平时的3倍5倍，但是实际流量远远超出我们的想象，达到了平时流量的十几倍。不过基于前一年的经验，这一年我们做了很多工作，分布式系统的防雪崩、核心系统的自治，这些技术改进让我们的系统比上一年好了很多，虽然0点高峰还是出现大量的购买失败，但是服务器没有大面积宕机，流量下降后能够继续良好地服务。”

2011年

2011年淘宝商城成为独立的事业部，双11对于刚刚成立的淘宝商城技术部已经是一件相当重要的大事，各团队提早几个月就开始准备，并且上线了第一期的价格申报系统，完成了双11的商家商品报名的工作，一切似乎都很顺利，可是……

11月10日晚上23点，有人反馈设置的优惠价格写错了，3折的商品写成了0.3折。

23点32分确定砍掉折扣0.5%以下的商品，然后需要推送到整个商品库。执行到一半的时候，越来越多的人反馈商家把优惠理解错了，担心影响太大，决定砍掉1.1%以下的商品，但是由于之前的操作已经执行，所以先要回滚，然后再全部推送。

23点45分，开始回滚。

​

23点55分，回滚完成，开始重新推送。

11日0点10分，所有推送完成，同时开始收到大部分商品属性丢失的问题反馈。属性丢失意味着买的衣服没有颜色，意味着买的鞋子没有尺寸，当时用户由于很多商品都已经在购物车中准备良久，所以并不仔细观察就下了单，可是商家却没有办法发货。这是一个非常严重的系统Bug。当时唯一能做的事情就是通知所有有问题的商家下架商品，等待系统修复。

11日凌晨1点，定位到错误代码是回滚程序的Bug。决定发布新的系统解决问题。

11日早上5点，系统Bug修复，通知商家重新上架商品。

时隔5年，回忆起那一晚，依然心有余悸。外界往往认为双11那一晚是精心准备的，技术是游刃有余的，可是每一年，我们都在匆忙中解决各种临时的突发事件。实际上真正痛苦的远远不止技术人员，还有那些被影响的商家。

​

在2012年的6月双11商家沟通会议上，我们问商家：“对双11最大的期望是什么？”反馈最多的期望就是：“系统稳定。”一个商家站起来说：“去年双11的0点我们被通知下架所有商品，当时团队10多个人，从0点到早上6点，没有一个人敢离开。我们借了款，备了平时十倍的货，如果这个双11卖不掉，我们回到家，对家人唯一能说的可能就是 ‘对不起，我破产了’，或者‘对不起，我失业了。’”

那个晚上，很多人无眠。

痛定思痛，我们在接下来的一年做了大量的稳定性相关的工作，我们上线了新的招商、价格管控、商品申报和优惠系统。我们做了csp的压测平台。我们做了系统限流sysguard自我保护系统。我们在2012年准备了接近3000的降级开关，做了4次大规模功能演习，确定了双11当天的指挥和决策流程。我们以为2012年我们能做到万无一失。

2012年

​

这一年双11的项目5月就启动了，当天晚上整个集团的核心技术几乎都all in在双11，我们准备了一个很大的房间，每个核心人员做好各种预案手册，当天晚上全神贯注就等着0点的到来。可是，那个0点，流量来得比以往更猛一些。

0点的时候，系统显示交易成功率不到50%，各种系统报错，立刻下单报错，购物车支付报错，支付系统报错，购物车的东西丢失。系统排查的大部分指向都是一个错误，取不到商品信息了。再进去看，商品中心系统的网卡被打满了，无法再响应请求。情况紧急，商品中心开启了事先准备的几乎所有降级方案，但效果并不明显。大约在1点左右，系统流量峰值慢慢缓和，我们的系统成功率才重新恢复到90%以上。

另一个发生问题的是支付宝的健康检查系统，和所有系统的自我保护系统一样，这个健康检查系统会定时扫描线上机器，根据机器应答返回时间判断是否正常，将超时严重的机器在应用列表中剔除，当时用了自研发的ssl 卸载 spanner 负载均衡算法有问题，导致服务器负载不均，应用那时候用的是apache ，连接数只有1K 多的性能瓶颈，在双十一的流量之下雪崩了。发现问题之后，我们快速启动了应急预案，同时做了流量切换，支付成功率重新回到了正常值。在1点之后，我们看到系统各项指标都恢复了，心情稍稍轻松了一些。但是白天新的问题又来了。

​

​

白天的时候，各种商家开始来电反馈一个严重的问题，系统超卖了。就是本来应该卖完下架的商品，在前台展示依然有库存，依然不停地被卖出。我们理应给商家一个正确实际的库存，可是由于0点的各种异常、降级和超时导致库存的状态已经不对了。由于数据过于凌乱，系统已经无法当场完成纠正，除了通知商家自己检查库存，尽快下架商品之外，我们已经无能为力了。那年的双11，很多商家由于我们的超卖不得不紧急重新采购，加工，补货。那年的双11，应该有不少用户要等很久才能收到购买的商品。

之后的双11技术复盘会上，所有技术同学达成了一个共识，我们一定要有一套系统能够最真实地模拟双11当天的流量，能够及时发现大压力下线上系统的所有问题和风险，保障双11的0点体验。所以2013年，集合了各个BU的力量我们创造了一套全新的压测系统：全链路压测。

​

一个全新的系统，从产生到全面实施从来不是一帆风顺的。刚开始，大家根本不敢到线上压，担心影响用户，直到有人大胆地承诺：“出了故障我来背！”到9月时，刚开始两次大规模的压测都失败了。有人开始怀疑方案的可行性，思考要不要回到之前的压测模式，直到有人坚决地前行：“我们这次一定要成功，让所有的开发一起来加入!”有人在打趣：“摩擦了一晚上都没有动静。”有人在宽慰：“第一次从来不会一把成功，我们多磨合几次。”我清晰地记得第一期的那些开发同学，在一个小小的会议室里面，晚上12点我回家的时候他们在，早上8点我来公司他们还在。眼睛里经常有血丝，但是说起话来还是中气十足。每次给我的答复都是：“我们会成功的。”感谢这些同学，无论现在是否依然在双11的岗位上奋战，但双11的功臣中一定会有你们的名字。

针对库存的问题，我们在2013年做了独有的超卖审计系统，会实时对账所有库存，一旦有超卖马上能收到报警，这个系统在这些年的库存保障中发挥了很大的作用。

​

2013年

10月全链路压测终于成功了，几次压测中发现了600多个Bug。参加的技术同学纷纷感慨称之为“神器”。但是在0点开始之前还是出现了一个小插曲。通常双11之前所有日志都会清理一遍，但是那一年这个常见的操作却遗漏执行了，技术同学就在10号晚上发现问题时，临时手工写了一个简单脚本处理日志清理，可是脚本发生了一个小问题导致日志文件被删掉，由于害怕日志输出找不到文件会影响性能，所以决定分批重启机器，重启时又发现已经执行的提前预案中有一个Bug，在启动初始化时有报错，导致应用启动失败。最后只能紧急发布修复了Bug。所有机器重新启动完成的时间是10号晚上11点55分。当时大家盯着时间，盯着系统一台机器一台机器地发布，和时间赛跑的感觉历历在目。再后来每次大促之前我们会提前准备一份作战手册，写好所有的内容，细化到时间点和执行人，防止再出现任何的意外。那一年，有惊无险。0点的成功率满足期望。而且系统容量和0点的峰值差不多吻合。用户体验刚刚好。

2013年的时候由于各个系统的预案加起来已经超过2000个，无法靠人来控制和梳理了，我们做了一个所有预案的控制系统，提前降级的开关可以准时执行，准备好的预案可以录入并且做好权限和通知管理。

2014年

2014年，由于用户和数据的急剧增长，杭州的机房已经容纳不下我们的系统扩容了。于是我们在上海建立了新的机房，双11当天，真正启动并且实现了异地多活的梦想。那一年是最顺利的一次双11，系统和用户体验都没有问题。但是在双11的总结中我们发现了一个特别明显的趋势，就是无线的占比越来高，双11当天0点已经超过50%，如何在手机这么小的屏幕上推荐给用户他真正想要的商品也成为技术必须解决的难题。

2015年

2015年，第一次有了双11晚会，晚会现场可以压团队，可以现场抽奖，技术部的同学实现了线上和线下的同期互动。效果超出期望的好，然后我们的客户端注册系统当场就被用户的热情打爆了，紧急扩容解决。

0点无线端导购的流量大大超过了我们的预期，而我们的物流系统和导购部署在同一批物理机之上，机器资源发生争抢，有10%的物流机器被打死，无法响应，那么落入这批机器的用户就会购买失败。在0点10分的时候，我们做了一个决策，直接剔除了这批死掉的机器，系统的成功率重新恢复到正常值。当时的决策有点风险，因为0点10分的时候流量依然很大，我们无法推测剔除这批机器的风险，那90%的机器如果扛住了，我们就成功了，如果扛不住，可能所有交易就会跌到零。我想一定是用户的热情创造了奇迹。我们幸运地扛住了那个0点。

2015年我们在会场页面实现了全面的个性化，每个用户看到的会场推荐都带入了自己的喜好和偏向，这一变化，让无线的点击和购买率得到了大大的提升，也为下一年的全面个性化打下了基础。

​

2016年

​

2016年开始，我们的全链路压测加上了导购的流量，而且在2016年我们的导购峰值也从之前的10号10点转移到了11号的0点，和交易的峰值完全重合，0点峰值的压力进一步加大。

为了能快速释放和节省双11的成本，我们实现50%的云化，在双11之后一周内就将机器资源释放出来，提升机器循环使用的效率。

我们手机客户端自己做起了直播。晚上就可以在手淘和天猫客户端一边看晚会一边参加抽奖和互动游戏。

​

产品玩出了跨店的红包和购物券，可是由于0点的限流产生，就发生了这些组合下单的商品一单被限流支付失败的情况下其他一起下单的商品由于享受了组合的优惠所以也一起无法下单。双11前一天已经评估出了这个风险，所以准备了一个后台程序帮助回补没有使用的红包和购物券。可是由于流量的长时间的持续，限流时间超出预期，我们的后台程序也在大压力下挂掉了。技术的同学只能对后台程序进行扩容，从准备的几十台机器扩展到几百台机器，终于在早上6点完成了红包和购物券的回补。

2017年

​

2017年的零点是过往历史上最顺畅的一年，包括我们新上的混布系统都在零点很顺利的扛过了我们零点的高峰。

​

可是一点预售付尾款的那一刻，我们却发生一个功能的bug。飞猪预售订单无法支付尾款，这也导致飞猪发出的很多红包无法使用，从而大量的用户开始投诉。无法回滚，因为回滚意味这很多功能要缺失，不敢切开关，不知切换开关之后对其他bu会不会有影响，我们只能小心地修改代码，重新测试上线，所以直到早上6点，这一问题才被解决。而导致这一bug的根本原因是11月8号晚上的一个紧急发布引入的一个问题，由于太晚发布没有赶上功能回归的时间节点，于是遗漏到了线上。最终，变成2017年双11的最大遗憾。

总结

2018的双11越来越近，第十个双11，一定要做到十全十美，以史为镜，每一年的问题都不同，但是阿里的技术人绝不会让同样的错误重复两次，我们一起加油！