研发慢、宕机多、品牌弱怎么办？前携程 CTO 解密技术体系顶层设计
GTLC 峰会现场，伍涛与叶亚明的对话长谈
叶亚明 ( Eric Ye) 于 2011-2017 年在携程网担任 CTO 和 Chief Scientist 一职，帮助携程网完成从 call center 到移动互联网模式转型，同时为公司建立了领先技术系统和开放技术文化，驱动业务 10x 增长。2014 年，叶亚明荣获最具战略价值 CTO 奖项。近两年里，叶亚明作为资深技术顾问服务了多家 100+ 人技术团队的创业公司，结合 Ebay/Paypal 和携程大型互联网公司的技术体系的建设经历，针对创始公司的成长过程的经典问题，给予了解决问题的思路框架。在技术的顶层设计、战略规划领域有着独到的见解，以下内容根据 GTLC 峰会现场对话整理。
GTLC 峰会现场，伍涛与叶亚明的对谈场景
叶亚明：初创企业面临的一个比较典型的困境是，发展到一定阶段后，随着业务的发展和复杂度提高，研发问题会越来越多。起因于早期研发是解决各个需要，习惯于底层设计，开始时交付上线很快。经过几年的发展，随着模块及模块之间复杂度变大，以前缺乏系统性的设计，出现的问题也越多。必须投入更多资源救火，这样可用资源投入研发新的产品功能变少，症状之一：研发速度变慢，症状之二：宕机多。其他症状为组织协调变得困难，团队之间的矛盾和沟通成本逐渐增多、老的组织架构不适合当前业务发展等等。
因此，公司到了一定规模后，必须做技术体系的顶层设计，否则每天低头拉车，不看方向或者不会看方向（缺乏顶层设计），就必然出问题。
叶亚明：当时公司只有 5 个业务，后来扩充到了 20 多个业务，它们都需要在 Unified architecture 架构下工作。同时，业务总量快速增长，各业务研发急需工程师，所以技术团队从 600+ 到 3000+ 工程师快速扩充。另外，外部竞争激烈竞争格局发生巨变。挑战在于如何选择可以满足不同业务需求的架构，建立人才招聘培训锻炼体系，全力引入世界领先的开源技术，同时支持业务硏发的快速交付。在源头上做好一系列的技术体系的顶层设计，满足各方需求同时，有前瞻性地建设技术体系。比如，高品质的八大技术中间件建设，输出到各业务应用研发，起到了研发一次用多次效果（避免重复造轮子），促进团队协作。
产品硏发项目管理体系也很重要，从产品的概念、研发交付再到顾客体验的生产线都要建好；再有技术组织上要及时调整。要知道技术组织和技术体系是“一个铜板的两面”，如果组织体系设计不合理，那么问题就会反映在技术架构里。
所谓顶层设计——架构、框架、基础设施、大数据建设是一方面，产品研发的生产线建设是另一方面，提升产品的交付能力和基础设施的可扩展能力。还有一系列软的东西，比如：招聘培训体系化、开放工程师文化、技术品牌提升、注入世界级已验证过的架构、引进开源技术等等。
有了一系列技术体系的基础，在外部竞争激烈的情况，突显强大的竞争力。具有对突发险峻事情的应对能力。
叶亚明：小公司主要面临的问题是产品研发。当携程有 3000+ 人的研发团队时，每个礼拜要交付 1000+ 多个项目，业务成长十倍的情况下，就必须要有体系性的顶层设计。
有一段时间，携程业务发展非常快，如果没有统一架构，一年以后很容易出现问题。建高楼地基不牢没法建，必须要打好地基。比如中间件、微服务架构 2012 年做好，全面使用，所有的应用（100%）用它们来搭建。再说一个核心中间件 Mobile Qateway, 面向一个 Unified App （携程 App ），支撑二十多个业务， 里面有许多 advanced 功能，让每一个应用受益。 随着时间推进，中间件、基础设施越来越厚，团队技能越来越强，业务支撑越来越大，业务覆盖面越来越广。携程是在顶层设计的体系下，逐步建设，积极使用，马上见效。前后花了三年多时间迭代，从顶层设计到使用，全面形成了一整套技术体系。
举个好玩的例子, 一些前携程架构师技术或领导加入了创始公司。全面推行他们在携程学到的技术体系，遍地开花，也算是携程技术体系的输出。
叶亚明：我对开源还是蛮有感触的。我认为，开源是很好的对内对外技术交流的手段之一。
1991 年 从 Linux 开源，Browser, Jdk, Python,kvm, openstack, 后来很多有价值、大家使用得比较多的、很核心的技术也都陆陆续续被开源出来了,Kafka Hadoop, Android, Kubernets, Tensorflow. 开源不仅在技术层面上很成功，在生态建设上也很成功，大家都感受到技术社区对开源的热情。可以说，过去二十多年开源是推动技术进步的强大动能。
携程面对开源主要分三个阶段：
1、引进。筛选出一些优质的、对我们有实用价值的开源技术，引进并消化。使用开源的前提，是具有驾驭开源的能力。这一点很重要，一旦用了就要有驾驭的能力。
2、Commit 代码。改进开源代码里的缺陷，引进、消化反复做。做了一段时间后，团队能力就得到了进一步的提升。
3、Contribute 项目，自己贡献开源项目。
开源对技术体系搭建非常重要，它是站在巨人的肩膀上，推进技术向前发展，跟强大的技术社区交流，同世界技术接轨。可以这么说，如果突然停止使用开源技术，绝大多数的互联网业务就不能继续运行，就像停电一样，根本做不到。可见开源技术已经影响到工作生活的方方面面，只是人们没有感知而已。
GTLC 峰会现场，叶亚明坦诚分享自己在携程网的经历
叶亚明：我是主导这次事件恢复的总指挥，所以对情况前因后果非常了解。回头反思，虽然我们已经做了一系列顶层设计的措施，但有些地方仍然做得不够。第一是理念，理念说起来很简单，但真正要想清楚并落实不容易。不光要关注交互的数量和质量，还要关注网站的高可用性 High Availability。理念是网站的问题影响到顾客的工作和生活，当时的我在这个高度上重视不够。比如，HA 高可用性的顶层设计是什么? 同时，它会影响到所有业务应用，如何合理分配研发资源，尽量少地影响业务研发? 更让人头大的，是梳理现有的应用 (极其复杂的工作），全面使用新的架构。
事件回顾：那天大概是早上 9 点半，有人汇报，我们网站出现了问题，很多服务器逐步地不工作了。不工作的服务器面扩大，问题就变得严重了。我感觉情况不对，我停止会议，直奔“战斗室”，里面已经有很多人了。当时我们不知道是什么原因导致的问题，而且问题还在逐渐放大。
过了 15 分钟后，我们发现了问题，原来是某个程序正在删除服务器里的执行代码，所以导致服务器停止工作。本来应该是发布系统上传激活新版本后把老的版本删掉，但有一个工程师写了一段代码，不是把老版本的删掉，而是把整个生产代码的根目录都删掉了。What F*!
问题已经发生了，就需要搞清楚影响面有多大：大部分服务器不工作了，Build repository 中的历史代码也被删掉了，发布工具本身也损伤了，直接影响到打包、测试到上线的生产线，即是生产力的损失。有一点确认，客户数据无损。我们当时正在面对没有见过的、无法预演，可恶的现状。
当时，我们出了公关稿说，因为内部操作错误导致网站不可用，给用户带来不便请谅解，正在抢修中。但是，我自己不知道这个事情会花多长时间恢复，因为事件的影响面太大了。
11 点半的时候，基本上整个网站不能用了。
我清楚地意识到，这是领导力决胜负的重要时刻。有 3000 名工程师等待我的指挥和指令，是最紧迫、但需要冷静的时刻！我们没有退路，必须恢复全网站！
我要把大问题切分开，有些是基础设施，有些是应用类的，还有核心服务、账号、支付等。我将这些分而治之，还考虑它们之间的互相依赖，需要按秩序恢复；切分后我们同时抢修，要求底层系统先恢复。当时的工具一会儿工作、一会儿不工作，是否影响生产效率。
到 12 点时，一部分基础设施恢复了。我们内部看得到，但用户看不到，对于他们而言网站还是不能用。
因此，我们出了第二段公关，正在抢修中，请耐心等待。但实际上，我也不知道什么时候可以恢复全网。下午 2 点钟左右，携程可以工作了，客户一下子看到了他们的订单了。之后，酒店、门票、火车票、支付等逐渐恢复使用了，有迹象应用可以回来。大概下午 4 点时，25% 的应用也逐渐可以开始使用了，虽然不稳定。
下午 4 点，我很清楚地知道已经看到了希望的曙光，我们不再在漫长黑暗的隧道里。当时，我下的命令是晚上 9 点以前全面恢复，在晚上 9 点股市开盘之前。实际上晚上 7 点，全网基本全面恢复了，但仍有一些问题，一边发现一边修复。
业务产量的影响是 5-28 那天很差，第二天的订单量超过正常的 43%，系统经受了考验。后面三天的订单量全超出正常值。我们赢得了客人的信任。
经过这件事，让我深刻体会到——客户的日常工作和生活依赖了你。这个理念的重要性在于你不仅要做到交付的东西速度快、质量高，而且还要重视用户使用的稳定性，让客人出行有保障，这是第一要素。
我们或许做了很多事情，但如果顶层设计没做好，就是我 CTO 的责任。我及时反思了顶层设计做得不够的地方，现在想要和大家分享 3 点经验：
1、研发、测试，发布的生产系统的顶层设计重点性。当时，我已经知道发布系统哪些地方不够好需要做改进，但在改进不够快，前面的 HA 意识还不够强，投入的团队技能不足。把这个 DevOps 系统搭建好的难度高，大家都知道发布系统要做好是不容易的，它是研发、测试、生产等所有环节都要打通的核心基础设施，所以我们做了彻底的复盘，全新的顶层设计和实施。
2、2013-2015 年，两年半的时间里，我们招了很多新人，新人的研发习惯往往会带到生产环境上。而在生产环境上操作的员工一定要经过培训、考试，对生产怀揣着敬畏心。生产环境不能同开发环境一样，随意调试修改等。这也是高可用顶层设计的一部分，我们需要把人“管”起来。
3、事情发生后复盘，亡羊补牢是非常值得的。事情已经发生了没有办法，必须进行彻底补救。HA 顶层设计做得不足，把缺陷的地方都给解决掉。
衡量一个团队强不强，就看掉到低谷后，反弹得有多快、多高。因此，我认为碰到这件事情从正面看来，还是很有价值的。
叶亚明：从技术角度看，过去 30 年，技术演变的推进速度非常快，技术对社会也带来了很大的影响，在中国，消费互联网、移动支付、社交、游戏广告、出行用携程等等，都对生活带来了巨大影响。
全球的技术都是互通的，中美技术，尤其开源技术都是相通的，因此我认为贸易战是损人不利己，不应该去“掐架”，应该也必须互相理解、达成一个合理的协议。
对技术人员来说，开源是融入技术主流很重要的手段。虽然贸易战我们做不了太多的事情，但是技术开源这件事情，我们应该大力推进，从使用成熟的开源技术，到贡献开源的项目。宗旨就是融入世界技术主流，让技术更好服务于工作和生活，让技术处众所周知。
GTLC 峰会现场，参会者向叶亚明提问
叶亚明：不限在这里讲到的，重要的有 Unified Architecture, 快速产品研发及项目管理的体系、组织架构及管理、开源软件 program 等都是技术体系里的范畴，还有中间层、大数据，高可用 HA 都需要进行顶层设计、集中规划。还有技术品牌，人才体系建设等等。
重要的是技术体系的顶层设计是成长型公司必备技能，并且试之落地。
叶亚明：CTO 做这样的事情还可以，不是 CTO 做这件事还蛮难的。当然这件事情还涉及业务的关系，我两年前写的《CTO 六要素》文章可以参考。
当中有一条，技术一定要保证按时交付，做到了业务的快速交付；同时还需要注重顶层设计。我们一定要认真思考什么样的顶层设计，再告诉下面的人要做这件事情。其次再考虑如何推进，想清楚要什么，再执行实施就好了。你的团队不断地实现顶层设计，也随之锻炼成长，变得更强。让实现下一个顶层设计变得容易。
叶亚明：第一，今天的顶层设计算一个。你做的事情有没有顶层设计? 是思路的改变与技能的提高。
第二，三维看自己的技能—— 有技术深度；管理技术团队方法、提升技术品牌、培养年轻人；再有好的业务意识。
第三，利用好每一次机会，包括像“528 事件”，它让你变得更强大。