作者：唐小智，记者：张晓楠、刘燕、赵钰莹
每年的双十一、618 等电商大促，InfoQ 都有从技术的角度去策划专题内容。双十一从 2009 年到现在，刚好也走过了第 11 个年头，交易规模也从第一年的 0.5 亿迅猛增长到了 2018 年的 2135 亿。世界范围内也很难找到这样高并发、高复杂度的电商场景，背后支撑的技术能力也从最开始的捉襟见肘、拆东墙补西墙到现在的游刃有余，吃着火锅唱着歌就把洪峰般的瞬时流量给完美承接下来。这背后，少不了程序员们的辛勤付出。
如果等会儿出问题，我就从这跳下去。
阳振坤是支付宝背后自研分布式数据库 OceanBase 的负责人。
2009 年，第一次双十一大促开始，当时谁都没想到电商大促会这么成功，正如也没多少人预见当年诞生的 Redis、MongoDB 等非关系型数据库能在业界掀起一场 NoSQL 革命一样。加入阿里之后，阳振坤发现无论对淘宝还是支付宝，关系数据库都扮演着十分关键的角色，在使用上根本不可能摆脱。但已有的数据库，无论是商业数据库还是开源数据库，都有非常多的局限，远远无法满足如淘宝、支付宝这样的互联网和金融业务对高扩展、高并发、高可用和低成本的需求。
单机数据库已经走到了尽头，下一步只能走向分布式。2010 年，OceanBase 项目启动。
OceanBase 遇上了阿里巴巴集团去 IOE 的天时地利，但人和却来得比较迟。直到 2013 年，支付宝也开始去 IOE 以后，阳振坤向鲁肃毛遂自荐了 OceanBase 的解决方案，得到了攻坚 2014 年双十一的机会。
大促开始前的凌晨，各个团队都在自己的作战室里热火朝天地准备。当时任蚂蚁金服董事长的彭蕾去了 OceanBase 团队的作战室，问大家： 有没有信心？ 阳振坤跟彭蕾开了个玩笑说： 你看我们窗子都已经打开了，如果等会出问题，我们就准备从这跳下去。
最终阳振坤并没有跳下去。
最初的计划里，OceanBase 只会承接双十一大促流量的 1%，剩下 99% 的流量由 Oracle 数据库负责。但因为当时的 Oracle 数据库支撑不了汹涌而来的巨大流量，最后 OceanBase 承接了 10% 的双十一流量，十倍于最初计划。
后来，OceanBase 团队获得了 2015 年蚂蚁金服的 CEO 大奖，这也是第一次由技术团队拿到这个奖。彭蕾希望借这个奖鼓励那些能够沉下心来、扎扎实实地把一项技术做好做扎实的技术人们。
后来发生的故事大家也都知道了，OceanBase 不仅走出了支付宝，走向了金融业界，也成了国产自研分布式数据库的佼佼者。可谁能知道，当初这个团队数度面临解散危机？如果不是双十一获得的巨大成功，也许 OceanBase 还在蛰伏中。
*以上内容来自此前 InfoQ 对阳振坤的采访
这是我这么多年双十一过来最没有底气的一年。
今年是四虎第十一次参加双十一。
2009 年，四虎第一次参加双十一，值班守交易的服务器。在此之后的每一年，他都深度参与了双十一大促。2017 年开始的三年间，他开始参与双十一的指挥层，作为负责双 11 的技术团队的业务研发线大队长。
作为根正苗红的双十一亲历者，四虎表示 2012 年之前，阿里巴巴的系统设计是没有考虑到能够支撑上百倍的流量压力的。所以系统如何做到高压情况下不宕机是他们前几年主要努力的方向。随着全链路压测技术的成熟，技术团队可以很快定位系统水位短板，提升高压下的突变应对能力。
2012 年以后，主要解决的就是业务问题：超卖、重复下单、优惠复杂性，这些严重影响消费者和商家体验的难题是技术团队需要逐个突破解决的。2016 年，开始做系统吞吐量的提升工作，让业务快速发展的时候，保证服务器数量，到了今年全面上云成了最重要的工作。
2017 年双十一，四虎遇到了一个难题。
当时双十一活动中，主互动发奖出现中奖用户和金额数据计算不一致的问题。如果把错误的金额发给了消费者，会让辛辛苦苦参与了 20 多天前序活动的消费者拿不到应有的红包，在双十一这种全民参与的购物狂欢节下，这个 Bug 对于用户体验的损害有多大不敢想象。
在当时的情况下，技术团队不仅需要紧急开发程序重新计算发奖，同时还需要修复系统故障确保下一次开奖能够保证准确不出错。
解决时间只有 2 个小时。
活动发奖系统是用 Python 写的，但四虎带领的技术团队主开发语言是 Java。只能临时拉集团熟悉 Python 的项目组同学火线救援。
我们只能抓狂地在边上出主意，实际 bug 排查和修复我们都没法帮上忙，哪怕是代码 review 我们也做不了，这是我这么多年双十一过来最没有底气的一年。
最终 2017 年双十一在前台层面风平浪静地度过了，但背后技术团队的惊心动魄却无人能知。
双十一已经做了十一年，各种组织保障和流程都已经很完善，同学们也大部分都比较熟练。四虎说，最怕的就是大家看起来做的井井有条，但是实际上有很多漏过的事项。
技术团队为此做了各种攻防和破坏性演练，在考验系统抗风险能力的同时，锻炼组织的协作能力，以及项目成员在高压力情况下的紧急处理故障的应变能力。在全链路验收的时候，加入了对云机房的攻击演练，通过这次演练还真发现了不少较严重的问题，可以针对性地做预案、解决。
四虎双十一筹备期间，每天早上 9 点到公司， 晚上回家时间不定，大部分是在 0 点前后。跟平时来比早上来晚了，晚上回去也更晚了。因为平时会在 8：00 左右到公司，晚上在 20：00 左右回家。
过程中我会尽量抽空回家陪陪家人，来补充能量。双 11 当天一般会睡 4 小时，当然我们期望没有问题，可以好好的睡上 8 个小时。
如果以后不做双十一了，希望能和家人一起躺在被窝里 shopping。
从未想过放弃。无论 618 还是 11.11，都是工作的一部分。
这是刘海锋在京东的第 7 个 11.11。参加工作十年后，刘海锋已是京东技术副总裁、零售基础架构负责人。
他曾先后带领团队负责分布式存储、商品图片服务、中间件平台、容器云平台、CDN、数据可视化、各种数据库系统、全链路压测、统一数据中心调度等一系列技术基础设施。
刘海锋说，这些年大促备战，技术准备时间的整体趋势是越来越短。这两年基本上在国庆节过后开始正式启动备战工作，持续大约一个月的时间。这背后，既是大促团队的业务熟练度达到了一个高的水平，同样也是技术上的基础设施等保障发展到了一个很高的水平，才能做到这样的游刃有余。
机器虽然比人力可靠，但也避免不了出错的时候。
2015 年 11 月 11 号当天，我们团队负责的微服务注册中心发生了故障，持续时间很长。而这个模块是公司几乎所有线上服务的强依赖。那一天，灰头土脸。
高光时刻似乎没有特别的印象，研发人员在大促的使命就是为业务保驾护航。使得系统平稳运行，是我们应该做的事情。
从前线开发到带团队一起攻坚大促，刘海锋的心境发生了挺大的变化。
2013 年双 11，独立开发的第一个系统上线，服务订单履约中心与物流 WMS 两个业务，整体运行非常平稳，如同看着自己的孩子考试成绩出色那样开心。
2014 与 2015 年，我负责的核心系统多了起来，也成为公司技术备战的中坚力量，感觉压力但也充满责任感。
2016 年，第一次作为一线负责人来协同整个公司的大促备战。对架构与公司业务的关系有了更深的理解。
2017 年晋升为公司的技术 VP，整体带领基础架构部门，支撑各个在线业务的应用开发以及大促备战。
这些年来，亲身经历互联网零售业务的高速发展以及相应技术领域的逐步成熟，应对大促高峰流量，越来越有信心。
刘海锋：左起第五位
电商大促对于技术团队而言有多累，不言而喻。纵览业界，不乏因为太累、忽视了家人的感受而选择离职的电商技术团队同学。但刘海锋表示，自己从未想过放弃。
无论 618 还是 11.11，都是工作的一部分。
如果以后不负责大促了，想写个程序来测试几个主要电商平台的性能指标。
空吼无益，实干维稳！
如果说双十一对于技术人员来说是一场沉重的考验，那运维人员也许是最累的那些人之一。
普智，2015 年加入蘑菇街运维团队，到今年为止已经参加五次双十一。
2016 年，普智第二次参与双十一大促活动，就遇上了滑铁卢。
当晚 0 点高峰时发生部分业务容量不够，服务器网卡被打爆的情况。当时我们团队慌了神，做了对节点进行紧急扩容的决定，但扩容上去后发现新的节点又发现引爆其他的问题，反反复复折腾了一天，用户体验也不太好。
现在回想起来还心有余悸。当业务现实流量大于预估容量时，我们从内心是希望系统能处理每一个请求，不希望让用户出现不可访问的场景；但实现场景下，我们必须拒绝这种幻想。业务限流是应对超出预估流量合理处理方案。
今年双十一是蘑菇街全面云化后的第一次大促，对服务的稳定和性能挑战非常大。为了应对本次双十一，普智的团队和业务同学一共组织了多达七次全链路压测。
通过每次压测检查去发现每条链路的问题，不断核对各个接口量和响应时间是否符合预期。如果不满足，就针对该节点进行优化或扩容；通过一次次加量压测，确保服务可靠稳定；如果按 100% 预估容量压测通过后，我们还会组织 120%，140% 的流量压测，确保流量大于预期情况下业务系统限流是有效的。
在双十一的筹备期，普智所在团队的大部分人员作息时间仍旧根据公司日常上班时间走，只有在全链路压测的时候会全体轮流参与值班。
轮流的目的是为了团队的人通过压测更加了解熟悉业务各个系统情况，能把日常工作互备起来。总体来说我们团队的工作压力还好，如果压力大的话，我们会搞搞聚餐，楼下运动运动啥的。
双十一当天，对于很多技术团队而言都是一个不眠之夜。能睡几个小时通常不是由技术同学决定，而是看业务情况，系统负载情况，普智说双十一是团队作战，不是单兵攻坚，睡眠一般还能得到保证。
不同于其他技术团队在双十一前喊出的各种口号，普智觉得喊了狠话以后精神压力反而会更大， 空吼无益，实干维稳！
我们团队是运维保障部门，双十一貌似是躲不过的。如果不负责双十一了，除非换一个工种。当一个产品如何？让业务开发抓狂一下。
双十一，我家老二出生了。
2014 年，乔新亮以顾问身份参与苏宁的双十一筹备。
当时的他还在 IBM，苏宁请他做顾问去带领双十一的技术团队。2014 年的双十一，是他最全面组织并下到一线组织、最没有经验的第一次双十一。
当时，苏宁在 818 过后的 8 月底就启动了 2014 年双十一的筹备。乔新亮一手组织，包括搭建准备双十一的项目团队，调集所有研发中心参与准备，分析双十一有什么风险，分析核心系统设计中影响高可用、影响业务连续性的设计，针对不能通过系统设计自动处理的部分，明确应急方案，响应机制。
2014 年的双十一，自己就带领团队建立了完整的双十一保障体系，确保了自己负责的第一个双十一就是一个成功的双十一。不过从后续几年的进一步深入准备看，也有运气的成分。细节决定成败，很多事故都是小概率事件，整个双十一的保障就是要确保每个小概率的风险都在掌控中，不能有任何侥幸心理，后续每年的双十一都在不断完善体系，优化设计确保每个极低的风险都在掌控中。
2014 年双十一后，乔新亮就加入了苏宁，经历了历届双十一的大促活动，整体负责了 2015-2018 年的双十一大促，不过逐步从一线指挥转向了幕后指挥，值得自豪的是从 2014 年开始，每年都是一个稳定成功的双十一。
2014 年那次双十一，其实跟我自己生活还稍微有点关系。我女儿是 11 月 7 号生的，我记得印象特别深，本来预产期应该是在双十一之后，结果提前出生了。当时因为苏宁在南京，7 号打电话说生了以后，8 号又飞回北京看了孩子，然后继续回来组织双十一的大促。回到南京后收到了团队成员很多的祝福，带着女儿出生的幸福继续投入双十一的保障准备中。
在乔新亮看来，历届双十一没有出现故障的原因除了运气好，更多是因为事情做在了前面，大促保障，工作在平时，检验在大促。2014 年，是乔新亮组织的第一次双十一，当成功度过以后，他长出了一口气。
人很有意思，人必须是在压力下，就是有挑战的时候才会觉得印象深刻，没有压力没有挑战的时候觉得其实也就这样吧。人生就是个旅程，经历双十一，让自己更愿意不断接受挑战，享受那种经历极大挑战然后又尽在掌控的感觉，还有那种和团队庆祝成功的喜悦是难以形容的，一句话，一起扛过双十一！
乔新亮认为类似的大促场景，一定要把设计做到足够完善，才能应对高并发流量带来的冲击。技术负责人必须得有价值主张：第一，少出事故；第二，故障时间短；第三，故障影响小；第四，尽量用低的成本。与之对应的就是高可用、容量足、容错强、要做变更、可视化、全生产链路压测等等。
双十一未来只会越来越轻松。最终那些东西都会归到基础的云平台去，都是成熟了的技术。
一个企业这种大促的成功，绝对要靠体系化的管理，而不是仅仅只依赖一线员工的责任心或者能力。
乔新亮离开苏宁以后去了环球易购，仍旧在筹备双十一的主战场上。
一个人再有能力，还是需要平台的，需要这种机会去锻炼实践的。所以我觉得也借这个机会对老东家苏宁表示一下感激，祝福老东家越来越好，也期盼环球易购能够做得越来越好，希望两家公司都能在双十一大卖。
写在最后：致敬技术人与这个时代
2009 年到 2019 年，双十一已经走到了十一年。中国互联网也从 Web 2.0 到移动互联网时代，再到 5G 时代。
对于身处其中的消费者而言，双十一、618 等大促意味着全年最实惠的价格，最狂欢的购物体验，屡创新高的消费金额。但对于背后的技术人员来说，这是一次技术实力的考验，也是一次超大压力的辛苦旅程。在这个过程中，哪怕稍有差池，系统故障，流量告警，宕机，影响到的都是以亿计的消费者，程序员们太不容易。
让我们致敬技术人默默做出的贡献，真正让技术普惠到了商业的发展。
让我们致敬这个时代，能让中国技术持续生根发芽，长成参天大树。
谨以此文，献给这个时代下，向阳生长的各位技术人们。
