王坚、胡晓明、刘振飞、李津、汪海、唐洪、张东晖、徐常亮、汤子楠、林晨曦、冯春培……致敬云计算时代的使命驱动者。
“既然你先前做出了选择，那就得像结婚一样。现在你说不愿意嫁，有什么用呢？继续忠诚地履行你作为王坚博士小媳妇的责任吧。”果不其然，马云依旧用他最擅长的类比句式打发走了胡晓明。
2011年12月31日晚，开完年终大会的胡晓明，带着被飞天报警铃声折磨到神经衰弱的阿里金融高管们，浩浩荡荡来到阿里云。
“我们十分支持阿里云的发展。同时，我们很希望在2012年春节期间，阿里云能够确保我们能够好好度过一个春节，不要在半夜被飞天系统的报警铃声吵醒还得起来工作。”
紧接着，更加令人震撼的画面出现了——胡晓明和阿里金融高管集体俯下身子，向王坚和阿里云管理层无言鞠躬。
2009年，“飞天”稳定性和功能还略显稚嫩，林晨曦靠着三寸不烂之舌，从集团其他业务线，拉来了十个“内部客户”，运行在飞天上。
然而，不争气的飞天频频故障，每隔几小时就崩溃一次，于是，来自各业务线的雷霆怒火对准了王坚，他们对王坚进行式的指责。
那段日子，阿里云D座四楼的会议室被调侃成“钟馗道”，员工时不时会被拽进去讨论一些棘手问题，就像钟馗抓鬼一样。在“钟馗道”，王坚曾连续数个小时责骂团队成员，乃至拍桌子摔手机。
“博士压力很大，但依旧拍胸脯跟马老师说一切没问题。结果每个业务部门投诉不断。”这或许正是王坚发脾气的原因。
而承受王坚脾气的人，首当其冲就是负责飞天系统的林晨曦。由于飞天系统一直不稳定，林晨曦频繁光顾“钟馗道”，成了王坚的“受气包”。
当时，阿里巴巴有两座云梯：云梯1是基于一些已有开源软件Hadoop为基础而进行研发数据计算系统；云梯2则是基于“飞天”完全自主研发的数据计算系统，也就是后来的ODPS。
公司原计划于2009年年底用云梯2取代云梯1，然而飞天系统的不稳定让这一理想化成泡影，“云梯2切换云梯1”项目经理孙牧，遭遇到降职处分。更多幕后故事，添加作者程敏微信LCMfancyworld了解。
在项目复盘会议上，王坚发表了一句令人印象深刻的言论：“我一定要把飞天做好，除非公司不再做云计算了！”
孙牧站在那里，虽已遭受降职打击，但他依然信誓旦旦：“我会一直留在阿里云，我保证不离开阿里云！我对飞天系统的未来充满了希望，我愿意继续与团队共同努力，就算让我写文档，我也愿意继续与飞天一起战斗！”
虽然林晨曦和孙牧舍命死扛，奈何事故依然不断，王坚也逐渐意识到阿里云稳定性必须提升，否则仅存的四个客户也会不可避免地流失。
有一次，胡晓明和一位P7员工一起去拜访客户，由于时间紧迫，胡晓明让秘书买了两份炒面，他们端个纸盒，蹲在路边匆匆吃完，紧接着就火急火燎去见客户了。
据说，胡晓明在接管阿里云之后，他经常拜访王坚，并倾听他在关键事务上的意见，表达自己的尊敬之情。
然而，即使如此“会做人”，胡晓明在与阿里云的“联姻”过程中，依旧磕绊不断，甚至想“毁婚”。（加作者程敏微信LCMfancyworld，交流你所知道的胡晓明）
确实，技术出身的王安全有大条道理反对，毕竟使用Oracle更符合金融行业的“祖训”：安全、稳定、可靠。
然而，胡晓明非常强硬，他坚持要用阿里云，近乎逼迫着王安全说：“不用（阿里云）也得用，就算死，阿里金融也要死在阿里云上。”
与王安全持有同样立场的还有工程师蒋杰，他后来离开支付宝加入腾讯，并成功开发了一套系统，替换掉了朱会灿的台风系统。
阿里云给阿里金融带来诸多麻烦：数据报告出现错误，贷款发放速度滞后，机器故障无法开展新业务等等。
信用额度是指用户可以借款的最大额度，如果借款金额低于信用额度，就无需繁琐的审批流程，直接将款项打入用户账户。
然而，信用额度的计算是在阿里云进行的。一旦系统崩溃，就无法准确计算信用额度，进而无法发放贷款。
对于阿里金融来说，这是一场极其严重的业务事故，因为其业务的商业逻辑正是基于大数据的计算来实现借款的快捷性和简便性。
对于阿里金融团队来说，犹如背着一颗定时炸弹，随时引爆更多损失，但他们无计可施，只能被动承受。
胡晓明在一片混乱中，写了一封邮件询问马云：“可不可以放过我？能不能不用阿里云？我自己搭建Hadoop团队解决问题。”
阿里内网上曾有一篇帖子引起了轩然，对阿里云的可行性提出了质疑。帖子内容直言不讳：马云，你被王坚忽悠了，阿里云根本不可能实现！不久之后，这篇帖子迅速获得了超过2000个点赞，成千上万的员工加入了批评阿里云和王坚的行列。
就在一片漫骂声中，马云亲自在帖子下方回复：“博士是人，不是神！博士的不足大家知道，但博士了不起的地方，估计很少有人知道。假如，十年前我们就有了博士，今天阿里的技术可能很不一样。”
为了给王坚和阿里云打气，马云还在阿里集团年会上表态：“我每年给阿里云投资10个亿，投10年，做不出来再说，这是公司的战略。”
这番决绝的言论，昭示着马云从一开始就对云计算志在必得的决心，以及对王坚的无限信任和追求革新的不懈执着。
会上，工程师陈鹏宇向胡晓明反馈了阿里云的极其不稳定，每天都需要处理大量报警。为了缓解这种压力，陈鹏宇将报警铃声设置成他孩子的笑声，从而苦中作乐。每当听到孩子的笑声，他便立即起身处理报警。
听完这番反馈，胡晓明深知，如果阿里云系统持续如此不稳定，阿里金融的业务必将继续陷入危机，甚至有倒闭的风险。
当晚，他带领阿里金融高管浩浩荡荡来到阿里云，面对反复的系统崩溃，他异常冷静地说道:“我们十分支持阿里云的发展。同时，我们很希望在2012年春节期间，阿里云能够确保我们能够好好度过一个春节，不要在半夜被飞天系统的报警铃声吵醒还得起来工作。”
其次，阿里云做得这么烂，但又不得不用，现在阿里金融已经被逼到了墙角。我命（阿里金融）由天（阿里云）不由我，我来向你们鞠躬，你们看着办。如果问题不解决，阿里金融只能关门大吉了。
第一，建立“专项工作组”，委任徐常亮为“专项工作组”组长，并成为服务阿里金融的第一负责人，上一任负责人刘侃被调任。与此同时，大数据计算引擎将采用徐常亮团队打造的“干将莫邪”技术路线。这支队伍将常驻阿里金融，全面了解他们的需求和痛点，第一时间作出响应和改进。
第二，投入更多资源和人力来提升阿里云的稳定性，包括对服务器和网络设备进行升级，加强监控和故障处理能力，加大对技术人员的培训和招聘力度。
采用“干将莫邪”方案，是内部集体讨论和投票决定的，徐常亮没有想到第二天就会被推翻，难道王坚有了新的想法？
其实阿里云的大数据计算引擎，同时在跑两套技术方案：一套是徐常亮团队借助Hive SQL的壳打造的代码生成系统“干将莫邪”，另一套是孙冰团队研发的“SQL Engine”。两种路线都有各自的优缺点。
王坚其实倾向选择自研成分更高的“SQL Engine”。（更多两条技术路线争锋故事，可添加作者程敏微信LCMfancyworld交流。）
“如果让我来担任第一负责人，技术路线就由我来决定。要是非要采用其他方案，那我可就不干了！”徐常亮直言不讳地对王坚说。
之后有一次王坚赶飞机，特意让徐常亮陪同前往机场。一路上，王坚语重心长劝说：“技术路线选择要谨慎，两种路线切换成同一种路线要一步步来，不能操之过急。”
“我一定会权衡全局，渐进式切换。”徐常亮回应道，“具体的切换过程，交给我来拿主意就是了。”徐常亮的果敢和担当，赢得了王坚和团队的信任。
在这个时候，作为团队领导的张东晖也在推动组织和文化层面的融合，加速两条技术路线的效果。与此同时，张东晖带着15年的微软工程经验，在那两年帮助飞天版本收敛，推动版本发布走上正常迭代节奏。
其中之一是汤子楠，他一直在北京办公，但在2012年1月3日，他特意乘坐了北京飞往杭州的第一班飞机，加入了专项工作组。
在汤子楠记忆中，胡晓明是个十分“有意思”的人。汤子楠和其他兄弟阿里金融办公室讨论问题，胡晓明每次经过都冲着大伙们笑，然后回到自己办公室，泡几杯香茶，亲手送到攻坚一线。
就这样，汤子楠、徐常亮和其他专项工作组的同事全力以赴，他们扩容了系统，提高了计算效率，修复之前的Bug，开发新功能，解决阿里云的稳定性和性能问题。
汪海深知马云这个问题背后想要的答案，他思考片刻，决定顺水推舟：“马总，明年我们最重要的任务就是将大淘宝迁移到阿里云。”
有一次，他所管理的服务机集群之一，大约有几百台机器，使用的是SQL Engine进行安装，但下属误用了ODPS进行了安装，导致数据丢失。更致命的是，这些机器中还存放着流量统计的数据。
下属犯错，汪海毫不犹豫，挺身而出，承担责任，接受降级处理，可谓大义凛然。（幕后故事尤为精彩，添加作者程敏微信LCMfancyworld了解）
事实上，大淘宝使用阿里云并没有明显好处。因为使用阿里云的好处是整体性的，而不是体现在单一的业务部门。只有当阿里巴巴的所有业务部门都使用阿里云时，才能发挥出大约30%的成本节省效果。
阿里云就像一个电厂，每个业务部门都有自己“发电机”，可以独立发电。当整个电网达到一定规模的时候，成本可以降低一定的百分比，这就是规模效应发挥的效果。然而，在早期，这种优势并不明显。
一言蔽之：大淘宝有好处也不一定要用阿里云，用阿里云也不一定现在用，更何况大淘宝没有直接好处。
很多大淘宝员工发出灵魂拷问：“有人告诉你，开着车换引擎，换了引擎不一定比原来跑得快。你换吗？”
其次，云梯1系统无法跨机房同步数据，只能在一个机房内运行数据，单个集群更是受限于5000台服务器上限。一旦达到5000台的限制，就无法再增加机器，这可能导致业务无法继续扩展，或者需要停止业务来进行迁移数据。
一方面，需要满足大淘宝的需求，底层计算系统必须有能力独自调度 5000 台服务器的能力。另一方面，需要弥补云梯1的致命缺点。那么，大淘宝别无选择，只能转向云梯2（飞天），转向阿里云。
5K项目是阿里发展历程中极为浓墨重彩的一笔，它是为了解决阿里云飞天集群超过5000台机器的问题而专门成立的项目。飞天集群在创立之初并没有预料到，阿里的业务发展如此迅速，这么快就产生了如此庞大的数据，需要用到5000台机器的集群。
简单来说，5K项目要做的事就是把机房里的5000台机器当做一台来使用。“你扔1PB数据进去，它能够自己调度和计算，计算完再把结果合并统一输出。”这个过程听起来不复杂，真正要实现却非常困难，中间涉及到大量复杂的调度算法。
为了确保5K项目成功，数百名顶尖工程师投入了长达数月的艰苦攻关。其中包括刘振飞、汪海、唐洪、张东晖、徐常亮、汤子楠、林晨曦、孙冰、王乐珩等一众优秀骨干。
在5K项目中，团队面临着一个令人担忧的问题：5000台机器的网络通信会不会导致整个数据中心的崩溃？
多隆的方案是在规模上升之前，将一台机器模拟成多台，以降低成本。通过多隆的实验和设计，这个问题在一个月内得到了解决，使得从2000台升级到5000台的过程非常平稳，没有发生网络风暴。
多隆是技术大神，他热爱编写代码，喜欢沉浸技术世界；淘宝遇到问题时，多隆总是能够在最后一刻恢复系统，让其他人瞠目结舌；多隆有能力直接线上热改，不跑测试，突破所有传统工程纪律，时常带来意想不到的结果。
为了确保5K项目顺利进行，公司还专门抽调了一批技术人员值夜班，其中包括海公、无戈、介然、仲离、伯虔等人。
蝙蝠侠肩负着确保数据产出稳定性的重要任务。除了日常维护工作，蝙蝠侠们还有一个“特别任务”：每天早上6点，他们需要向马云发送一条短信，内容包括过去一天的盈利情况、成本和门店数量等经营指标。
这个“特别任务”对于蝙蝠侠们来说至关重要，因为必须在规定时间内完成整个数据处理流程，才能准时发送短信。
那是一个不平凡的夜晚，当蝙蝠侠们值班时，突然传来警报。原来，执行任务的速度异常缓慢，报警系统被迫拉响了紧急警报。
经过紧张排查，蝙蝠侠们很快发现了罪魁祸首 —— 一场看似平凡的淘宝商家营销活动，竟然导致了数据的严重倾斜，进而拖累了后续任务的执行效率。最令人担忧的是，如果这种情况持续下去，甚至可能导致次日早上6点前，关键报表数据无法按时计算完成。
面对危机，蝙蝠侠果断出击，他们重新对数据进行分片并修改了1000行SQL代码，最终在30分钟内解决了问题。
那时候，只有最优秀的工程师能够成为蝙蝠侠。正是这些蝙蝠侠的努力，才保障了整个集团对数据的应用。
包含蝙蝠侠在内的5K项目团队以周为单位紧急推进项目进度。回忆起那段岁月团队成员无不自嘲：“起早贪黑，仿佛一个月都没有见过太阳，我们不得不全力以赴完成这个项目。”
就这样，历经半年如火如荼的工程奋战，阿里云团队终于完成了5K项目，将大淘宝的海量数据全部迁移到了ODPS平台上。
5K项目后，负责阿里集团运维的刘振飞找到徐常亮问道:“我们是时候完成2009年定下的登月目标了吗?”
原来，早在2009年，阿里巴巴就制定了一项宏伟计划——“登月计划”，意在将集团内所有开源数据集群全部迁移至统一的ODPS平台之上，从而提高数据处理效率和稳定性，为业务发展提供支持。
原来，随着2013年用户和交易量的不断攀升，支付宝的Hadoop集群开始吃力了，亟需扩容。但这与阿里巴巴“所有业务数据上ODPS”的整体战略相悖，支付宝因此陷入两难境地。
幸好，阿里金融已在ODPS上稳定运行，表现出色。两者的作业逻辑何其相似，全然可参考。于是，冯春培灵机一动，萌生了将支付宝迁移至ODPS的想法。
与此同时，汤子楠也主动劝说支付宝团队：“ODPS的能力已经非常稳定，我们可以快速解决在迁移过程中遇到的问题。而且，一旦支付宝需要扩容，我们也能迅速实现成功的扩容。”
支付宝成为“登月一号”后，汤子楠更是巧妙地“借势”鼓励支付宝团队：“登月计划是一个伟大的项目，支付宝正是参与这一伟大项目的团队。”
经过一年半的努力，支付宝成功地将数据从Hadoop迁移到ODPS平台。这样一来，支付宝不仅解决了数据量激增的问题，还实现了与阿里巴巴整体战略的完美契合。
2014年，整个阿里内部的数据都统一存储在ODPS物理集群上，标志着支付宝ODPS迁移之旅的圆满成功。（“登月”背后的部门争执，添加作者程敏微信LCMfancyworld获悉）
支付宝接入ODPS是一个重要的里程碑。作为金融应用，支付宝必须满足严格的安全标准。为了满足这些标准，ODPS在安全性方面必须拥有出色表现。
在登月计划中，数千名工程师接力前行，2015年7月1日，最后一个也是最庞大的数据孤岛，用Hadoop搭建的云梯1系统正式停止运行。