2019 年双 11 来了。1 分 36 秒 100 亿，5 分 25 秒超过 300 亿，12 分 49 秒超 500 亿……如果没有双 11，中国的互联网技术要发展到今天的水平，或许要再多花 20 年。
从双 11 诞生至今的 11 年里，有一个场景始终在支付宝技术团队之中循环往复——每一年确定目标时，大家都将信将疑，或惊呼或腹诽：“不可能！太夸张了吧！”但每一年的夸张目标，到最后都能奇迹般地成为现实。
前一年需要拼命跃起才能够到的果实，后一年就会成为再普通不过的日常。不知不觉之间，双 11 已经从最初启航时的小船，成为了承载数十亿人快乐和梦想的巨舰。在这个举世瞩目的“奇迹工程”背后，是技术和技术人一起，十余年如一日，以难以置信的“中国速度”在不知疲倦地向前奔跑。
技术人的初衷往往极致单纯——既然决定要做，那就全力以赴，一往无前，但当他们一步一个脚印风雨兼程地走来，蓦然回首，就发现奇迹已经在那里了。
那时距离宕机只有几十秒
2009 年 11 月 11 日，对于支付宝工程师陈亮而言，本来是与往常没有任何不同的一天。
那年还没有支付宝大楼，更没有 Z 空间，他趟过早高峰的车流，坐到华星时代广场的工位上时，一封来自 CTO 程立的邮件发到了他的电脑里：今天淘宝商城要搞一个促销活动，预估交易量比较大，大家盯着点系统。
陈亮当时所在的团队主要职责是保障整个系统的稳定可靠。在促销活动的场景下，通俗地说来，就是要保障服务器“坚挺”，别被蜂拥而来的用户挤爆了。
淘宝商城在 2009 年的 8 月刚刚重组上线，日均交易量对于当时的支付宝而言，要稳稳接住不在话下。就算搞促销临时出现洪峰，不怕，扩容就好。
事实上也就是这么操作的。全团队的同学聚在办公室里，盯着电脑屏幕，只要发现交易量逼近系统承载上限，就马上进行扩容。
交易量的上涨有点不寻常，一片安静的办公室里本来只有键盘声，忽然有人高喊一声：“我秒到了！”紧接着又有人跟着喊：“我也秒到了！”办公室里嗡地一下，热闹了起来。
原来有人很好奇淘宝商城究竟在做什么促销让交易量涨成这样，点过去一看，发现有折扣高达 50% 以上的“秒杀”，忍不住出手一试。
“已经想不起当时究竟秒到了什么，只记得大家都特别快乐。”陈亮说。
快乐，是陈亮对于这个促销活动最初、也最鲜明的印象。
不过除了一整天都忙于扩容的同学之外，当时支付宝的大多数人都对这场促销并无感知。“事后才知道前一天有促销，同事说流量有点猛。”现在已成为蚂蚁金服研究员的李俊奎说，运维负责人很紧张地在第二天的复盘会议上提出“抗议”：“淘宝商城那边在搞什么？支付量一下子提升了这么多，万一我们提前准备的量不够，就危险了。”
淘宝商城搞了什么？站在今天回头去看，他们只是搞了一件不算很大的事：在“光棍节”当天，联合 27 个品牌做了一场促销活动，单日 GMV 5000 万。
当时没有任何人能够预计这个促销活动日后会成长为什么模样，不过支付宝从数据的增长之中嗅到了山雨欲来的气息：这个活动带来的交易峰值超过平日的 5 倍，虽然这次平稳过关，但已经逼近了当时支付宝的承载极限。
2010 年的年中刚过，支付宝就去跟淘宝商城通气：去年那个促销，今年还搞吗？淘宝商城说，搞。
好汉不打无准备之仗，如何筹备“双 11”被提上了支付宝每周稳定性会议的议程。首当其冲的是要准备充足的容量。但是按多少准备呢？谁都没经验。
“拍脑袋估个数据，然后按预估数据乘以三去买机器，简单粗暴。”李俊奎直言不讳。
为了检验这样拍脑袋的决策行不行，他还和团队一起搞了个测试：通过手动更改配置，把多台机器上的流量导到一台机器上，测试一台机器的能接住多大的流量。“现在想起来，那就是压测最早的雏形。”
他们甚至准备了一个备用的工作联络群。当时还没有钉钉，工作群都搭在旺旺上，“万一旺旺服务器也出问题了，不能及时联络怎么办？”
筹备的时间虽不长，倒也方方面面都有兼顾，“但是不管事先做了怎样万全的准备，每年总有意外发生。”金融核心技术部工程师赵尊奎说。他当年所在的团队是账务会计组，一举一动都关系到钱，丝毫不容有错。
意外真的来了。
11 日凌晨，促销活动刚开始不久，支付宝的账务数据库就容量告急。
病来如山倒。发现问题时，状况已经十分危急，“只能再撑几分钟！”运维心急如焚，如果不能马上找到解决办法，支付宝就面临宕机风险，交易链路一断，谁也买不成。
怎么办？运维把心一横，说，砍了会计系统吧，给核心的账务系统腾空间。
时间已经容不得多加斟酌，一群高管站在背后，支付宝中间件团队的工程师蒋涛感到前所未有地紧张，“操作的时候手都在抖。”
这个当机立断的决策将支付宝从距离宕机只差几十秒的悬崖边挽救了回来。事后的数据显示，2010 年的双 11，参与用户达到 2100 万，总 GMV 达到 10 亿，是上一年的 20 倍，这是任何人都很难在事先预估到的涨幅。
“能想到会涨，但谁也想不到涨势会这么猛烈。”赵尊奎说，“也就是从那年起，我们开始隐隐觉得，更猛烈的还在后头。”
代码的力量
85 后的肖涵和 90 后的郑洋飞，都是在读大学时就知道了双 11。
肖涵喜欢网购，09 年就成了第一批尝鲜双 11 的剁手族，还在一个技术交流群里认识了参与过双 11 的支付宝工程师；郑洋飞常买《电脑报》，那上面说 2010 年双 11 一天的销售额等于香港一天的零售总额，他一边惊叹，一边心生向往。
“觉得好牛 B，想进去看看。”
当年互不相识的两个年轻人，不约而同地产生了这样的想法。
肖涵在 2011 年加入了支付宝，那一年支付宝已经开启了“上半年搞建设、下半年搞大促”的模式，筹备工作从 5、6 月起就着手进行，他刚一入职，就被调去开发流量接入和调拨系统 spanner。
这个系统相当于支付宝交易链路的第一道门户，“好比餐厅上菜的推车。一般餐厅，一个服务员只能每次上一盘菜，但双 11 的挑战，就是要让一位服务员同时能上十盘菜，因此我们需要一个推车。不过业界没有现成的推车能满足支付宝的需求，我们得自己造。”
差不多一整年的时间中，肖涵和团队为这个项目废寝忘食，spanner 终于在 2012 年的双 11 迎来了第一次大考。
谁曾想，意外又发生了。
那一年支付宝的大促监控系统也已经上线，流量曲线能够秒级实时显示，零点将近时，所有人都紧盯着屏幕，翘首以盼。
——零点一到，流量进来了，曲线开始增长，形成很漂亮的弧度，所有人开始欢呼，但是忽然，它跌了下去，然后开始像心电图那样抖动。
监控系统没有问题，也没有报错，为什么流量会进不来呢？
一石激起千层浪。他所能看到的抖动，同样实时显示在了淘宝的作战指挥室里。支付宝工程师贺岩正作为支付宝的唯一“代表”，在那里和淘宝的技术同学一起备战。这是个极其考验心理承受能力的工作，在支付曲线发生抖动的时刻，“淘宝的技术同学们一下子就把我围在了中间。连问‘支付宝出什么事了’？”贺岩回忆道。
肖涵脑子里一片空白，唯一的念头是，“不能让交易停下。”
0:00 到 0:20，短短的 20 分钟里，10 分钟用来定位问题，10 分钟用来解决问题；同样在这短短的 20 分钟里，外面已经天翻地覆：“‘支付宝不能付款了’登上了微博热搜，家人、亲戚、朋友都给我打电话问是什么情况，手机都要被打爆了。”
关掉了一个健康监控模块之后，系统终于恢复了稳定。比起紧张，肖涵感到的更是前所未有的震撼：原来自己所做的事已经和千万人息息相关，每一点微小的疏漏，所影响的都是难以估量的庞大群体。
“没有身在其中过，就很难意识到自己敲下的每一行代码有着怎样的分量。”郑洋飞说。他在 2013 年加入支付宝实习，带他的师兄巩杰说了一句令他印象极深的话：你看看那些客服 mm，你敲代码时仔细一点，少出一个错，她们就不知能少接多少个报错电话。
架构革命
跨过了 2012 年的坎儿，DBA 就再三给出警告：扩容已经到头了，顶多再撑几个月，按这个增速，如果不想点别的办法，肯定坚持不到明年双 11。
祸不单行。另外的“紧箍咒”也接连落下：Oracle 数据库的连接数上限成为扩容的瓶颈，更要命的是，由于机房的一再扩容，杭州的电力已不足以支撑。有时候为了保机房供电，“大夏天的，办公室都会停电，不得不运冰块过来降温。”巩杰苦笑着说，杭州的盛夏，谁过谁知道。
治标的方法快要山穷水尽，必须要从治本的角度出发寻找新的解决方案，比如，从架构层面“搞革命”，做单元化。
革命不是请客吃饭，要从架构层面做根本性的调整，举步维艰：一来没有任何成功经验可以借鉴，只能摸索着走；二来牵涉到众多部门，大家需求不同，意见难免相左；三来，既然要革命，那目光必须放得更加长远，不能只是为了解决今年或明年的问题，至少也要做未来三年的规划。
与此同时，在和淘宝商城——现在叫天猫了——沟通之后，支付宝毫不意外地定下了又一个令人惊呼“不可能”的目标：支付峰值每秒 2 万笔。
事关重大，人人都很谨慎。“光是架构调整的方案就讨论了很久。”陈亮说，作为项目的架构师，他费了不知多少口舌去说服所有人都认同这个方案。
重担的一头落在他的肩上，另一头则交给了 2010 年抖着手化解危机的蒋涛，蒋涛更愁稳定性问题：“做技术架构变更的同时还得稳住业务，这件事非常复杂，技术风险也很高。”
留给他们的时间也不多了。LDC 架构的立项已是 2012 年年底，距离 2013 年的双 11 不足一年，对于这样浩大的工程来说，就一个字，紧。
陈亮最初构想了一个宏大的体系，要把所有系统都一口气单元化，但这个方案被程立否了：“主要问题在淘宝的交易上，先把淘宝做了。”按他的意思，哪怕先做第一期，2013 年也必须上线。
一堆不可能的目标聚集在了一起。但目标既然定了，就只剩向前这唯一的方向。
“立项之后，我们几乎每个月都做发布。”蒋涛说，这个频率是一般项目开发的好几倍，但即便如此，直到双 11 之前半个月，整套系统才算部署完成，小错仍然不断，不过，随着越来越多的小问题和被发现和修正，他终于感到，“心里总算慢慢有点底气了”。
2013 年，支付宝 LDC 架构首次在双 11 亮相，支付宝也第一次派“代表”前往双 11 的总指挥室——阿里巴巴西溪园区的“光明顶”。
这位“幸运”的代表就是李俊奎。“我就是去当‘炮灰’的。”他笑称自己一走进光明顶就感受到了热烈的压力。当年的总指挥李津当着全集团几百位工程师的面，指着大屏幕点名喊他：“向秀（李俊奎的花名）！你看看支付宝！”
这项压力山大的任务，李俊奎连做了好几年，乃至于做出了经验。“首先是不要慌，无论接到什么反馈，先说‘知道了，我看看’。因为你一个人在现场其实什么也做不了，你的职责其实是传达，以最快的速度，把问题传达给后方的伙伴，然后，相信他们。”
他说这是支付宝技术团队的重要制胜秘诀之一：你永远都不是一个人在战斗，你也无法一个人战斗，但你的身后永远有最靠谱的伙伴。
至于这一年的战果如何，按蒋涛的话说，“硬扛过去了”。新架构有惊无险，走出了第一步。
关公、灵隐寺和压测
2013 年双 11 的另一个特殊之处是，支付宝的备战室里多出来一幅关老爷的挂画。
挂画是郑洋飞“请”来的，不过“拜关公”作为支付宝技术团队的一项传统，早在他入职之前就由来已久。源头据说要追溯到支付宝建立之初，每到重要的系统更新时，工程师们就会在旺旺群里转发关公表情包，以求更新顺利，“别出 bug”。
隔了一年之后，关公像“升级”了，有同学去西安校招时看到了关公的皮影艺术品，就“请”了一个回来放在备战室。后来，程立买了一尊木质关公像放过来，去年，副 CTO 胡喜又买了一尊关公铜像。
除了拜关公，去寺庙烧香也是例行项目，视目的地不同，还分为“灵隐寺派”和“法喜寺派”两大派别。至于哪边灵验，说法不一，但据观察，每年双 11 过后，程立、胡喜就会亲自率队上山还愿，从支付宝大楼一路步行到上天竺法喜寺，回来的途中，还会沿途捡垃圾做公益。
技术是纯粹的科学。技术人难道真的相信求神拜佛能避免系统故障和 bug 吗？
“心理上，我觉得还是挺有用的。”陈亮说，“主要是表达对于不可预知之物的一种敬畏。虽然我们已经做了多年技术，但技术的道路上还是充满了很多不可预知的东西。”
不可预知，构成了工程师们每年面对双 11 最大的焦虑感来源。
他们用各自的办法缓解双 11 迫近的压力。有人是运动派，用跑步或打球放空大脑，有人是“强迫症”派，一遍又一遍地 check 代码才能安心，还有人是“吃货”派，迎战之前必定要先组团去吃海底捞。
全程参加了过去 11 年全部双 11 的赵尊奎，在被问到“哪年最不好搞”时，秒答曰：“哪年都不好搞。”同样“全勤”的陈亮则表示：“14 年之前，我们对于双 11 零点的信心，如果非要说一个数字的话，60% 吧。”
但他很快补充：“不过 2014 年之后，这个数字就变成 95% 了。”
陈亮的信心，来自于当年支付宝压测体系的建立。这一次不再是手动调配置测单机了，而是创建出仿真环境让系统去跑，提前找出系统的问题并及时修复，以免在正式战场被打个措手不及。
“压测让双 11 开始从一个不确定的事逐渐变成确定的事，它极大地改变了我们对于双 11 稳定性的保障方式。”有“压测小王子”之称的郑洋飞说。
虽然 2014 年的压测仅覆盖核心系统，但这个体系已经帮了大忙。在双 11 之前的一个月里，它至少让一百多个致命的问题提前暴露出来。“如果其中有一个没有修复，我们 2014 年的双 11 肯定就挂了。”陈亮说。
1%？或 10%？
压测这一“压”，既压出很多隐患，也压出了一个大问题：支付宝所用的 Oracle 数据库在压测之中“抖”了起来，性能眼见得触到了天花板。
2014 正是移动互联网大爆发的年份。指数增长的移动支付比例势必带来比往年更汹涌的流量峰值，Oracle 肉眼可见地支撑不住了。
再买服务器？成本吃不消，而且为了应对峰值而增添的机器，平日里没有用武之地，完全是资源的浪费。
还有没有别的办法？有的。阿里自研的分布式数据库 OceanBase，从淘宝被划到支付宝后，已经沉寂了两年，正在焦急地寻找一展身手的舞台。
但是一听说是自研的数据库，业务满脸都是狐疑。跟交易和金额直接相关的数据库，只要错一个数据，后果就不堪设想，别说双 11 这么大的流量，即使平日，要不要用这个没经过验证的产品，也颇要斟酌一番。
先切 1% 的流量给 OceanBase 试试吧。这是大家争论了好一阵后得出的方案。
但是 Oracle 在压测中的表现显示，缺口不止 1%，而是 10%。
OceanBase 说，我们来承接这 10%。
10%，听起来不多，但双 11 的 10%，相当于平日里的最高峰值。如果 OceanBase 能平安无事地接住这 10%，就意味着它可以担起支撑支付宝日常运行的重任。
OceanBase 必须证明自己有这样的能力。“我们找了淘宝的同学，协调了很多资源做了一个测试，主要校验淘宝订单的金额和支付宝交易金额是否能吻合。”DBA 团队的工程师师文汇说，当时的方案很谨慎，如果 OceanBase 出现了问题，随时都可以切回来。
测试结果，OceanBase 没有错漏一个数据。程立当即拍了板：10% 都切给你们。
这个决定成就了 OceanBase 在双 11 的首秀，“相当于 Oracle 和鲁肃（程立的花名）都帮了我们一把。”师文汇笑着说。
这时距离 2014 年的双 11，时间已经不足两周。可靠性虽然经受住了考验，但 OceanBase 毕竟是个诞生才四年的年轻数据库，小问题层出不穷，比如响应时间长达 10 毫秒，比 Oracle 差了好几个数量级。最后十来天，师文汇和全团队的同学一起，硬是把它优化到了 1 毫秒以下。
“做了这么些年，对它的容量和性能还是比较有信心的。”师文汇说。
他说得轻描淡写，但在这个曾经面临团队解散项目取消的产品身上，他和整个团队一起倾注了多少心血，除了他们自己之外，谁也说不清楚。
OceanBase 最初并不是为双 11 而做的，但在双 11 这个舞台上，它第一次获得了聚光灯下的位置，并且表现卓越，从此，支付宝开启了核心交易系统完全搬迁上 OceanBase 的进程。
到今年，OceanBase 对内 100% 承载蚂蚁业务的流量。对外，在被誉为“数据库领域世界杯”的 TPC- C 基准测试中，打破了由美国公司 Oracle(甲骨文) 保持了 9 年之久的世界记录，成为首个登顶该榜单的中国数据库产品。
【视频：使命必达——OceanBase 登顶 TPC- C 测试】
我赢了一只 apple watch
2015 年，李俊奎去拜访了上海证券交易所，那里的交易系统部署在 6 台大型计算机上，交易峰值能达到每秒 10 万笔。
他大为惊叹：10 万笔！何等高不可攀的数字！什么时候支付宝也能达到就好了！
回到杭州，他马上与同学们分享了这次见闻，结果同学们告诉他说，今年我们的目标就要超过每秒 10 万笔了。
李俊奎一想，这种一听就不可能的目标，是支付宝的作风，没毛病。
与此同时，郑洋飞则在为这个目标头痛不已。他刚刚跟他的主管打了一个赌，赌的是他作为 2015 年双 11 全链路压测的负责人，能不能保障双 11 的支付不出任何问题。赌注是一只 apple watch。
这一年是 90 后的郑洋飞第一次挑大梁，从双 11 的参与者转换角色成为一个项目的主导者。但这一年也是他和团队都“忍辱负重”的一年，上半年，因为频繁不断的可用率问题，他们做稳定性的团队也在频繁遭受打击，士气不振，不少同学选择了离开，内外的质疑声也接连不断，那几个月，空气里都仿佛写满了“难熬”二字。
“当时团队没几个人了，但是人人都憋着一口气，想着一定要把双 11 这个事情搞好。”郑洋飞说，“就是不想让人觉得支付宝不行。”
局面有如背水一战，如果失败了，想要“翻盘雪耻”就要再等一年。因为双 11 每年只有一次，不仅是一年一度的大考，更是一年一度的舞台。按照系统部资深技术专家杨海悌的说法，“人人都想把自己一年的努力拿到双 11 去验证和展示，不让上还不高兴。”
跟 2014 年的全链路压测比起来，2015 年主要要做几个方面大刀阔斧的改进：一是要从核心系统扩展到全部系统，二是要平台化，也就是打造一个全链路压测的平台工具，三是要跟整个集团的压测打通联动。
“老实说，非常忐忑。”郑洋飞心里没底。
当双 11 零点的洪峰扑面而来时，他已经忘掉了 apple watch 这回事。有一个压测没验证到的数据库定时任务，让曲线看上去不那么平滑。“稳定压倒一切”的宗旨之下，系统只要一抖，整个团队的心也跟着抖了起来。迅速排查的结果是，系统整体没出问题，但压测遗漏的一些细节，让结果不是那么完美。
“曲线不是特别好看。”他不无遗憾地说。
郑洋飞最终赢得了这只 apple watch，但对于他而言，除了奖品之外，这只 apple watch 更有了别样的意义，时刻提醒他即使做了再充分的准备，也没有万无一失。
对“丝般顺滑”的追求永无止境
其实每一位支付宝工程师的心中，都有一条的“完美曲线”。
理想之中，它应该是这样的：双 11 零点，洪峰来了，曲线漂亮地攀升，没有骤升骤降，不要用频繁的抖动去折磨大家脆弱的神经。
如果要浓缩成一个词，那就是“丝般顺滑”。
但是，每一次为此而做的技术演进和架构变更进行到一定阶段，“你都会发现一开始可能设想得非常美好，但到了一定的规模之后，挑战就接二连三地来了。”杨海悌感叹道，“量变产生质变，这句话不是虚的。”
双 11 的“量”，早已一骑绝尘地进入前所未有的领域，2016 年双 11 仅用了 6 个多小时，交易额就已超过 2014 年全天。这些年以来，都是自己在不断刷新自己的纪录。
在这样的量之下保障稳定，难度不止提高了一个数量级。
还记得 2012 年底制定的架构革命之“三年计划”吗？它真的持续了三年，这场最初是为了解决数据库连接数和机房限制而进行的架构革命，在三年的演进过程中，又衍生出很多其他的架构，比如异地多活、容灾，弹性的容量调度等，直到 2016 年，才算全部落地。这之中每一步的演进，都是为了让系统具备动态扩容能力，能够顺滑地进行弹性的扩展和伸缩。
“大”是考验，“小”也是考验。
师文汇体会最深刻的瞬间，不是 2014 年 OceanBase 一举成名的时刻，而是 2016 年一次小小的测试。在这个测试里，他发现了一个指标有一点异常——非常不起眼，2 毫秒的偏差。
“2 毫秒而已，如果在别的地方，很可能就会被判断为无关紧要，然后漏过了。”但他的团队中的一位小伙伴，非常认真地去检查了这个问题——万幸如此。后来事实证明如果不解决这个问题，那年的双 11 就会有大麻烦。
“即使资源不足、时间紧张、软件有各种不完善的地方，但我们的小伙伴不会放过任何一个问题。”师文汇感慨。
早些年，流量曾是实现完美曲线最主要的挑战，但是越到后来，随着业务的不断拓展，工程师们越来越清楚地认识到，稳定压倒一切不假，但技术更要着眼于未来。
2017 年，是贺岩加入支付宝的第九年。这一年支付宝实现了离线在线混布，离线任务的大量闲置资源可以被用于在线任务，从而大大提升了资源的利用率。
“在一些小的场景中，这种效率提升能带来的节约可能不那么突出，但在我们这样的体量上，它所带来的就是不可估量的一整个未来。”贺岩说。
有了前人积淀这么多年的基础，面向未来的路，就越走越顺利了起来。
2018 年双 11，支付宝其实保障了两个大促，天猫的大促，和支付宝自己的“码上双 11”等玩法。这一年的故障数比前一年下降了 70-80%，首次实现大促全天平稳。
大队长李铮非常淡定：“说白了，就是我们把各种风险通过系统化或工程化的流程，控制得比较好。峰值出现的过程，也都在我们的预期之内。”
2019，则是双 11 的“云原生”元年。
如果说技术是像叠积木那样一层一层累积起来的，那云原生就是最下面的基础，打好了这层基础，上层的应用就像是站在了巨人的肩膀上，生来就具备了一系列强大的能力。业务无需再过多地担忧技术问题，只需要专注于业务代码即可。
点亮全世界
故事讲到这里，不知大家是否还记得，当年因为每秒两万笔的峰值目标而惊呼“不可能”的同学们。
当年，每秒两万笔是他们举全体之力奋斗半年才能冲上的高峰，而去年，每秒两万笔已经成为支付宝再日常不过的状况，随随便便，一秒钟的事。
这样的巨变真实发生了，只是身处当时当地，谁也没有想那么多。几乎每一位工程师都表示：“每年搞完双 11，下一年的目标就出来了，然后我们就为着下一年的目标去进行相应的准备和努力。”
一个目标，又一个目标，在征服一个又一个“不可能”的过程中，曾经以为遥不可及的标高，都一一被甩到身后。当年高不可攀的每秒 10 万笔，今天看来不过小菜一碟。
只有当回头的时候才有所感觉，在某一天忽然发现，原来已经走出了那么远，原来已经攀登到了那么高的地方。
而当年那些惊呼不可能却又拼命将不可能变成现实的年轻人，已经纷纷长大，他们现在有着更多的从容淡定，上限在哪里没人知道，更大的可能是，没有上限。
流量数据的增长也早已不是双 11 技术保障的全部。更多复杂的业务和玩法，在技术的成果之中生长起来，反过来又为技术的发展提供动力。走出双 11，它们还能走入很多的场景：新年红包、五福集卡……
——或者走出支付宝和阿里巴巴。
那些由支付宝的工程师们创下的奇迹，正一一变成产品，服务更多的金融机构。至今已有数十家银行和金融机构用上了 OceanBase，压测平台、云原生等技术也纷纷走向产品化，支付宝通过历年双 11 沉淀下的技术和经验，正在拉动整个中国的互联网金融科技一起飞奔。
——或者走向全世界。
双 11 早已不仅是中国的双 11，而是成为了一场全球的狂欢。与双 11 一起，技术也在走向全世界。
“不过要是说到我们的理想，那就是将来某一年双 11，整个备战室空空荡荡，除了关公像之外，不需要有任何同学留守，智能化的系统能搞定一切问题，而我们只需要捧着茶杯或喝着酒，看着丝般顺滑的曲线。”
对于巩杰所展望的这种未来，现场就有同学笑了。“不可能吧！？”每年双 11 都如同打仗一般，救兵如救火。
但是谁说不可能呢？毕竟，他们是那样一群已经把太多的不可能变为现实的人。
本文作者：缪克卢汉
阅读原文
本文为云栖社区原创内容，未经允许不得转载。