Co-evolution of Business and Technology: the Journey Alibaba CTO Went Through

程立，花名鲁肃，2005 年加入支付宝，是支付宝技术平台奠基人之一。他也 是阿里巴巴招收的第一位博士生，现任阿里巴巴集团 CTO。

本文内容来自湖畔创研中心的一次技术高管的培训交流，过程中鲁肃非常坦率 地探讨了一位合格 CTO 应该具备的素质，以及他自己一路摔打成长的心路历程。

文 / 程立

本文摘自《云栖战略参考》第2期

我的经历

我的经历很简单，2004 年之前一直在学校读书，读到 30 岁。2004 年跟着一个师兄做外包项目，为淘宝网做一个 重要的架构升级——把原来 PHP/MySQL 架构换成 Java EE 架构。2005 年 2 月份正式以实习生身份加入支付宝。

2005 到 2014 年，我主要的岗位是支付宝架构师。2013 年， 当时蚂蚁的 CTO 要回美国，蚂蚁当时的 CEO 彭蕾找我谈 过话，我当时对带这么大团队完全没有信心。我最没有信心 的不是带技术团队，而是 CTO 另外一半的职责，作为公司 经营管理的一部分，怎么跟 CEO 对话。

前任 CTO 会在公司管理会议上和业务吵得面红耳赤，我 觉得我做不到。后来王坚博士约我去喝茶，他说没有关系， 每个人都是不一样的，但是每个人都能用自己的方式解决 问题。这给了我信心。

于是，2013 年我开始带支付宝整个技术团队，经过一年 的考察，在 2014 年公司任命我为蚂蚁 CTO，2014 年到 2019 年我一直在这个岗位。

2018 年，公司发现技术确实会对在某些业务起到更加关 键作用，需要更强的技术背景同学进入业务。当时对技术 有很强需求的是蚂蚁的国际业务，就让我做了两年蚂蚁国 际业务的 COO。2019 年年底，转任阿里巴巴的 CTO。 又过了一段时间，菜鸟也需要一位 CTO，就让我兼任菜鸟 CTO。

商业与技术共同进化之旅 @ 蚂蚁

我挑了几个蚂蚁 CTO 工作的节点，非常好地印证了“商业和技术的共同进化”。最早期支付宝非常简单， 就是要做一个互联网的第三方支付平台，技术只要 能把业务需求实现就好了，项目最大特点就是快、 轻量。

2005 年，某个国际支付巨头要进入中国，很多同事很 紧张，那时陆兆禧是支付宝的 CEO。他说:这有什么 可怕的，他们一个需求两个月才能实现，我们支付宝 两天就能实现，他们肯定不是我们的对手。

到2007年，公司面临一个技术分叉点:互联网支付一 定会成为行业非常主流的支付方式，我们已经能够看到 业务的规模，但需要做一个判断——该用什么技术架构 支撑。

支付宝最早对技术架构没有很强的要求，什么好用就什 么。我们既有非常互联网的架构，脱胎于淘宝网;也有 非常金融的架构，2005 年我们敲锣打鼓、披红挂彩买 了一台小型机处理核心账务。

但在 2007 年我们必须做一个判断，未来我们更像一家 银行，还是更像一家互联网公司?幸好后来我们没有走 弯路，我们判断未来必须要用互联网架构去解决支付相 关的问题。

于是我们决定把系统做一个面向未来的架构设计:分 布式改造。整整一年时间，我们将核心交易、核心账务、 核心会员、核心支付，全部分布式化。

但涉及到一些核心技术如何解决的问题，比如在这么 大的分布式系统里，怎么解决核心事务的问题——这 其实不容易。

2007 年某个国际支付巨头也曾经想解这个问题，结果 系统上线后宕机两周，CTO 离职。在对这个问题的改 造过程中，我们也胆战心惊，但最终还是把这块硬骨 头啃下来了。

第二个关键节点是 2011 年，移动业务起来了，但移 动场景下支付到底是个怎样的形态，需要做一个非常 关键的判断。当用户拿着手机和商家支付时，到底用 什么方式进行?

那时智能手机的格局并没有完全定形，一些手机还没 有摄像头。当时公司部署了很多方案，有扫一扫的， 当时叫悦享拍，拍一下就能完成支付;有叫“咻一咻” 的，让手机发出声波，商家接收这个声音;还有靠蓝 牙的。几轮下来之后，其实很多商家装了咻一咻的设 备，很多商家用二维码，最后发现用户能接受的是扫 码支付。

2013 年，也是我担任蚂蚁 CTO 的第一年，发生了很 多重要的事情。我们内部起了非常多的重要项目，编 号从 1 号到 9 号。

2013 年这一年， 1 号项目是网商银行;2 号项目是余 额宝上线，让支付宝业务实现真正破圈，真正做数字 普惠金融;3 号项目是花呗。当然还有 456，我们酝 酿了很多项目，有成功的，也有不那么成功的。

这个过程对整个技术架构造成了非常巨大的冲击，从 原来互联网支付脱胎的技术架构，开始往数字金融这 个方向走。在这个过程中，我反而觉得技术正好可以 发力，帮助公司技术实现变革。那一年支付宝开始正 式“去 IOE”，最后一台小型机下线。

商业与技术共同进化之旅 @ 阿里巴巴

阿里巴巴的技术其实非常广，后半程的发展会以阿里 云为主线。

第一阶段非常清楚，就是技术支撑商业发展，从淘宝网 上线开始。那时淘宝网为什么能够赢，除了它商业上有 很多创新之外，“快”也是非常关键的因素。在这个过 程中，CTO 要能在业务快速增长时，提前在技术上做布 局，让商业成长能够持续。2004 年，我做淘宝架构升级 外包业务的阶段其实是淘宝网非常关键的时期，Jave EE 架构的形成对淘宝的增长奠定了非常好的基础。

2009 年有一个神来之笔——那个时间点阿里巴巴敢于 判断云是未来，敢于为云写下第一行代码。阿里巴巴 内部很多人都不看好云，但是为什么那时候能判断对 呢?我觉得阿里巴巴有一句话说的非常好:“因为相信， 所以看见”。就像电商业务也一样，很早阿里巴巴就 判断电子商务一定是未来，先发先至，所以在很长的 一段时间，坚定相信这个方向、持续地走，只要时机 到来，就自然可以取得商业上的成果。技术其实也一样， 阿里巴巴很早就做了一个判断:大数据、云计算一定 是未来，后面所有发展都以这个为主线。

现在回头来看，后面每个关键节点都是和云相关的。 比如阿里云 2009 年写下第一行代码后，内部找了一 圈都找不到客户，这时候 CEO 就指定阿里小贷业务 必须用阿里云，给阿里云一个场景去打磨，这才给了 阿里云一线生机。2010 年孙权是阿里小贷的负责人， 后来当了阿里云的负责人。

我自己印象比较深的是 2013、2014 年，经过几年和阿里小贷的打磨，阿里云开始有一点技术了，大数据处理 开始慢慢成熟。当时有一个很重要的“5K 项目”，阿里云 开始具备 5000 台机器大集群处理数据的能力。具备这个 能力之后，公司又做了一个重要决定，阿里巴巴和支付宝 所有的数据全部要上到阿里云的大数据平台上，那时我正 好是蚂蚁的 CTO，我举双手支持——因为我知道即使不支 持，集团也会按下来。阿里云也因此又上了一个台阶。

2015 年，大家都听过“大中台、小前台”，听上去很牛。 “大中台、小前台”背后完成了一件事情:把阿里巴巴和 支付宝所有的基础技术全部统一到阿里云上，这是个重大 的技术变革，为了完成这个技术变革，阿里巴巴做了非常 好的组织设计，让当时的阿里巴巴 CTO 行癫兼任阿里云 CTO，把技术收在一起，加强阿里云。“大中台、小前台” 策略执行了三年，阿里云整个技术架构就非常完整了。阿里巴巴是集全公司之力支持一个技术战略的达成。

2017 年之后，这个阶段用行癫的话讲，是“用技术创造新 商业”，开始去探索技术本身能不能成为商业的一个部分， 城市大脑就是典型的由技术创造的商业。2017 年达摩院成 立，同样是“因为相信，所以看见”。因为我们判断未来一 定是数字经济，围绕数字经济所需要的核心技术达摩院要进 行布局，无论是 AI、计算，还是芯片，都是围绕数字经济的 核心问题的思考和布局。

2020 年，我已经是阿里巴巴集团的 CTO 了，我们完成了 上云的封顶，所有核心业务基本都跑在云上，包括最具挑战 性的业务，比如搜索、推荐、广告业务，云都能支撑，我觉 得这是云非常大的技术进步，也是集团非常重大的技术变革。

现在我们进入一个新的时代，要把云和业务技术的边界定 义清楚，边界就是云原生。我们未来业务应用全是云原生的应用，这是一个云原生时代。另外，云本身也在升级， 就是大家都知道的“云钉一体”。

不同业务阶段下的三种技术领导力

三种技术领导力，我是受到俞永福的启发，他觉得企 业发展就是这样波浪式的发展过程:一开始要先找到 一个方向，进入一个业务的轨道;如果这个方向判断 准了，企业就会进入快速增长阶段;发展到一定阶段， 就必须要脱离现有的惯性，再去找新的发展方向—— 就是这么一波波的过程......

在波浪式发展过程中，技术在每个阶段起的作用不一 样。在入轨的阶段，CTO 应该是整个公司业务一号位 班子的成员，是支持一号位的二号位，班子一起看清 方向，把业务带入正轨。

一旦入轨之后，业务进入快速增长期，CTO 的核心不 是看方向，而是怎么做好技术，这时首席架构师会变 得非常重要，技术让业务更高速增长、加速成长，业务不要被技术拖慢增速。同时，组织设计在这个阶段和技术架构一样重要。然 后不能等到业务停滞时才去判断未来，CTO 要提前判断未来会发生什么，第二 曲线是什么，设计一条未来的路线。

我是觉得整体上组织需要有两种领导力:一、专业的领导力:CTO、首席架构师、 技术总监和 VP;二、组织设计的管理领导力。CTO 在不同时候戴着不同帽子， 有时会承担一个专业角色，有的时候会承担一个管理的角色，有的时候会承担 一个战略的角色。

很难说一个 CTO 是万能的，CTO 一定有强项和短板。比如我自己，我的定位是 一个工程师，工程能力是我相对比较强的一项能力，组织是我的弱项。在这个过 程中，一个核心班子里需要非常好的配合，具备不同的领导力，给不同的人戴上 不同的帽子。

CTO 的职责

1.建立商业与技术的“共振”连接

CTO 在一个公司中到底扮演什么角色和 职责?

我觉得第一个非常基础的职责，是要建立 起商业和技术连接。前面讲到商业和技术 是共同进化的，而共同进化的过程中两者 要发生很好的共振连接。为了实现社会价 值、客户价值，企业要判断需要怎样的核 心能力?这个判断不是一个纯粹技术判 断，也不是纯业务判断，而是一个公司核 心班子共同的判断。

这个过程中，CEO 和 CTO 怎么对话就 变得非常关键了，能不能说一样的语言? CTO 要和 CEO 问清楚几个框架性的问题:一是我们公司服务谁，要把客户定义的非常清楚;二是我们为这些客户创造什么样的核心价值、差异化价值;三是我们的商业模式，用什么样的商业模式实现核心价值;四是为了实现这样的商业模式，我们需要什么样的能力、走过什么路径、构建什么样的组织。把这些问题理解清楚之后，技术就能理解业务要干什么了。

我在阿里巴巴接到任何一个新业务，都一定要对它进行新的理解，后续可能还 会有多的问题、更深入的理解，但这是我做的第一件事情，这是 CTO 的职责。

2.一张图、一场仗、一颗心，愿景牵引前行

很多时候，牵引团队往前是非常有挑战的事情，小团队还可以靠关系。大团队 里大部分人你都不能认识，怎么还能“一张图、一场仗、一颗心”?这时候就 需要有领导力了。

我分享几个例子，比较有挑战，也有很多不一样的方法。

第一个例子，我在团队里建立领导力的方式，是跟团队一起定义非常清晰的目 标。2013 年经过一番犹豫之后，我决定接受负责蚂蚁整个技术团队的任命。 当时我遇到的最大的挑战就是和团队之间的信任——本来大家都是平级，突然 我要成为这个部门的总负责人。当时大家给我的反馈是，觉得鲁肃做技术可以， 但不懂业务技术。

我觉得信任是要靠跟大家一起把事情做成，甚至没有必要让大家建立起对领导者的认同，就看大家能不能相信共同的目标，并把目标实现。2013 年，我跟 团队共识了“1234”目标:

1. 公司从互联网平台向数字普惠金融平台转型，我们的技术架构怎么去支撑? 需要重新定义支撑数字普惠金融新的平台。做平台架构这件事情，至少是我的 本行，大家认同。

2. 蚂蚁哪些核心技术是我们今年必须要突破的?当时定了两个核心点:一是 OceanBase 在这一年能落地;二是我们要把蚂蚁的平台建在云上。

3. 我们能不能在这一年大促的时候实现 3 万笔 / 秒的支付?大家知道从 2010 年开始，每年会有一次大考:大促能扛多高的峰值。前两年，蚂蚁都是非常吃 力的去扛。甚至 2012 年对团队来说是个很大的耻辱——大促前 50 分钟系统被 冲垮了，50 分钟后才恢复。2013 年大家都想一雪前耻:2012 年时峰值是每 秒 3000 笔，已经是性能极限了。我们定一个 10 倍的目标实现 3 万笔 / 秒!

4. 因为我们的服务不仅仅是支付，还开始提供金融服务，稳定性必须像银行一样， 甚至比银行更稳定。我们定下可运行目标 4 个 9(99.99%)，之前 3 个 9 都 很吃力。

这四个目标，大家非常认同，虽然都很有挑战。年底的时候，经过大家的努力， 四个目标里实现了三个半:完成了平台的转型，余额宝、花呗业务都起来了; OceanBase 在蚂蚁系统里落地了;做到 4 个 9;但我们没有做到 3 万笔 / 秒， 只做到 1.5 万笔 / 秒，是 5 倍的提升。之后大家开始建立起对我的信任。

我到了阿里巴巴之后，第一件事情也是需要大家聚在一起，一起定下目标。 空降到一个平台，其实很难给团队定一个全新的愿景。如果新 CTO 上来就 先画一张未来的图，基本是不太靠谱的，还是要和团队一起定下非常扎实的 目标、一起达成目标。于是，我选择先在云这个关键战略上稳中有进，全面 上云必须全部完成。二是在云之上，如何从“上云”到“用云”，把云原生 做深入，将阿里巴巴中台做深入，包括 AI 中台、数据中台和业务中台。另 外一个目标是组织数字化，阿里巴巴虽然生于数字时代，但也需要做数字化 升级和转型，阿里巴巴数字原生商业系统和数字原生组织是去年和团队一起 确定的方向。

CTO 和团队在一起要有一个面向未来的思考，不只是当下与业务的连接。未来是什么，关键的路径是什么，核心的几场仗是什么，这是 CTO 的牵引力。

3. 关键决策，扫清前进中的障碍

CTO 需要帮团队解决问题，扫清一些障碍，做出一些关键的决策。在蚂蚁做 CTO 时，第一个关键的决策是技术架构往金融方向还是互联网方向?最后决策 是互联网。第二个关键决策是关于 OceanBase 的转型。

2010 年，阳振坤老师带着团队开始打造 OceanBase。最早 OceanBase 还 不是一个真正的数据库，当时第一个场景是解决淘宝的收藏夹问题，需要海量 数据但不需要很强的数据处理能力。但到了 2012 年，OceanBase 面临一个 发展决策，要不要成为一个真正的数据库。

蚂蚁团队对 OceanBase 的怀疑有合理的理由，我们现在的业务对数据库要求 这么高， Oracle 那么先进的数据库团队打造了几十年，才刚刚能满足我们的 业务需求。阳老师带着几十个人花两年时间打造一个数据库，能把 Oracle 替代掉吗?

我觉得王坚博士是很有领导艺术的，当时他做了一个选择，他说:“把 OceanBase 送给支付宝吧。”到了蚂蚁这边就成了我当时定的“1234 目标” 中“2”的部分:看 OceanBase 能不能再往前发展。

当时我们采用了什么办法呢?第一先了解清楚 OceanBase 能干什么;第二， 既然公司整体不能做，就搞一个小场景，在蚂蚁的核心交易里切了 1% 的流量 给 OceanBase，让它在 1% 流量里证明能力。OceanBase 也很珍惜这个舞台， 撑住了 1% 的流量，最终在这一年完成了从非关系型数据库向真正关系型数据 库的转变。2014 年我们再大胆往前迈一步，把“双 11”大促 10% 的流量切给它， 让它进核心账务系统——账务系统比核心交易系统要求更高。当时这个决策是 有一些冒险的，但现在回头看，正是这些决策让 OceanBase 有了不一样的未来。

后面几个决策也类似，作为 CTO 如何拿捏好风险和稳定，是非常关键的。

比如余额宝上线的第一天我们就知道这个产品一定会成功，因为它的客户价值 特别清晰，让用户每一块钱的余额都有收益。但我们没有料到，它成功得那么快， 一个月时间迅速就把原来准备的系统容量全部用掉了。我们自己还好，因为蚂 蚁的平台已经完全分布式化了，可以快速扩容。但我们的合作伙伴天弘基金， 因为老系统无法支撑余额宝这么快速的增长，扩容成了核心难题。

于是我们做了一个非常重要的决定:把天弘的系统搬到云上，用分布式架构重 写一遍，三个月内必须完成。这件事也证明了金融云的价值，金融云的业务也 就起来了。

这些都说明，CTO 要在关键决策中发挥作用，帮助团队下决心并把握好不确定性。

4. 应对风险，化危为机

公司的技术风险有几类。

第一类，技术架构不能够支持业务发展，这是业务不能接受的风险。但这类的 风险，相对显而易见。阿里巴巴为什么在 2009 年启动“去 IOE”，就是判断 到这个风险早晚会出现，“IOE”架构已经不能支持公司业务发展，必须去掉。 蚂蚁在 2010 年开始启动“去 IOE”，因为那一年“双 11”大促让我们看到原 来架构基本不能支持业务了。

2010 年的“双 11”大促被我们称为“人肉云计算”。大促开始，我们看到 流量疯涨，判断白天肯定会冲破设计容量，就赶快把服务器库存全部加进去 了，结果发现还是不行，又马上去“杀”服务，把不必要的服务全部关掉， 把容量放在核心关键链路上，结果还不够，我们又去看关键服务里还有没有 能“杀”的。那年“双 11”最后几分钟，我们的核心账务数据库和会计数据 库都到了极限，还有 10 秒钟就要挂掉了。最后关头，团队非常果断，把会 计数据库杀掉了。会计记账本身很重要，但断个几分钟还能承受，核心账务 不能挂，否则整个业务就全部中断了。就这样，2010 年的“双 11”大促是 硬撑下来的。

其实后来很长一段时间，都是“人肉云计算”，人在做资源调配的事情，人来做 决策判断。这太痛苦了，这一切逼着蚂蚁非常坚定地拥抱云的分布式架构，要上云。

第二类风险不是技术架构的问题，而是稳定性出现重大问题。CTO 必须要判断 出这个情况，CEO 一定要给 CTO 相应的资源支持。

比如蚂蚁的“527”。2015 年我们实现了整个支付宝系统的异地多活，华南机 房和华东机房异地可以做分布式交易，这在金融系统里应该是第一次。我们还 特地做了断网演练，直接把华东区域全部关掉，华南直接接管业务，结果非常 成功，大家非常开心。我还给当时的 CEO 彭蕾发了一个战报，说蚂蚁首次实 现了异地多活，你们可以放心睡觉了，以后任何情况下系统都会稳如磐石。

2015 年 5 月 27 日，我开车在路上收到了报警，通常遇到这种情况团队就直接 处理了，但那个报警就一直响。我就把车停在路边，才发现光纤被挖断了，系 统中断将近 2 个小时。原来异地多活，光纤一断，系统就切不过去了。从那之后， 我再也没有发过任何一份战报，没有和 CEO 报过任何一次喜。

当时这个事情对蚂蚁技术团队打击非常大，公司受到最大的打击是客户的信任。 外面有很多文章调侃蚂蚁的技术，蚂蚁的技术形象和外部的信任丧失了。内部 从我到整个团队与 CEO 的信任也开始出现了危机——以后再讲话，别人只听 一半，因为说的话不见得靠谱。

危机也可以是好事情。“527”之后，我们做了几件非常关键的事情，第一， 开始跟公司沟通，我们需要在蚂蚁成立一个专门的部门，叫技术风险部。这个 部门就一个职责，守住蚂蚁技术底盘的风险，公司额外拨 10% 的技术资源给 到这个团队。也就是说，我们愿意付出额外 10% 的技术资源专门确保蚂蚁系 统未来没有风险，这件事情至少帮我们争取到这个资源。第二，立刻启动实战 演练，前面说其实我们做过异地多活的断电演练，但这是有准备的演练。从那 一天开始我们要做无准备演练，一直到今天。第三，我们确定把 5 月 27 日这 一天作为蚂蚁的技术日，蚂蚁未来无论是存在 102 年还是更长的时间，所有技 术工程师都要记住这一天，让我们永远能够记住风险。

这三件事情做完，反而让团队更加凝聚了，蚂蚁技术的风险防控水平有很大的 提升，我觉得这是转危为机。

第三类风险，可能是 CTO 和 CEO 都最担心的，一个新技术出现之后会不会颠覆原有的业务模式。不仅是很多发展中的公司会担心，即便阿里巴巴这样规 模的公司也非常担心。当一个新技术出现，无论公司大小，都有被完全颠覆的 风险。蚂蚁面对移动互联网时代时，我们有一段时间很担心，通过好几年努力 定义移动支付，基本上算是渡过这个危机，但当时对蚂蚁的挑战还是非常大的。 当比特币开始成为一个现象时，我们也是非常担心的:它会不会把支付完全颠 覆了? 2019 年 6 月 Libra 出现，更让人担心了:全球支付会不会被一种新的 货币重新定义，这是一种降维打击。

这时候 CTO 必须要站到一号位班子里去，帮助 CEO 做判断。每一次对未来危机的判断，都可以触发未来新的商业机会。大的策略是:面对任何技术风险不能只是看，要亲自去试，需要公司投入一些有价值的浪费。

第四类风险，是温水煮青蛙。技术会不会反过来伤害公司，它不像风险那么直接， 但是如果因为技术、架构或组织问题让公司效率变慢了，公司会慢慢丧失竞争力、 创新力。随着时间的推移，这是最大的危机。阿里巴巴的中台就是一个很好的 例子，中台的优点在于可以减少很多重复建设，让业务可以基于中台快速创新， 因为重复建设的繁忙约等于效率低下。但阿里巴巴的中台已经非常完善了，开 始进入了另外一个阶段。目前，业务中台里有面向核心电商的中台、数字供应 链的中台、职能线业务中台、数据中台、AI 中台等一系列技术中台。当我做一 个新业务的时候，我需要跟这么多中台打交道，需要他们去支撑我，过程中如 果有任何一个中台支持不能到位，我的业务可能就做不成。我们现在开始大力 推动中台能力进一步升级，改善中台的交付方式，把中台再升级。这里涉及到 很多技术架构的变化。为了防止温水煮青蛙就是要一直做系统化的梳理，再去 一个阶段一个阶段的解决。

5. 组织设计与治理 —— 平衡秩序与创新

一个人当 CTO 的时间越长，专业能力下降得就越严重。我判断自己的专业能 力大概每隔两年会降一级。也有好处，你可以跟团队一起做，团队会更强。组 织设计的核心是要既有秩序又能创新。这是有矛盾的，创新是在一个混乱的土 壤里长出来的，秩序让效率高，但会把很多创新吃掉。这个过程有点像踩钢丝， 处理秩序和创新的平衡。

阿里巴巴围绕技术的组织，是有两条线的。一条线是实的管理线，是分层分布的:

前台，面向业务的，为客户赢;中台，是能力中心，中台的客户是前台，让前台 更加高效，让前台更有竞争力;底层后台，是强调技术先进性的，确保业务永续。 这个组织每一层都是独立的业务经营单元，现在我们在做一件事情，让每个独 立的业务经营单元都有 CTO。这个 CTO 会对这个业务经营单元负全责。实线 管理机制的核心就是把每一层之间的界面定义清楚。

这种治理让每一块业务都很灵活，都可以自主发展，但又带来了一个新问题， 我们该统一发展的技术怎么形成合力，所以我们有另一条虚线:技术委员会，下设二三十个核心的技术小组，把所有的共性领域横向拉通。通过技术委员会 和技术小组的专业领导力，实现策略通、人才通。这两条线会同时运作，随着 管理线越来越清晰的分层，这条专业的虚线就会变得非常重要。比如音视频技 术，每个业务里都会用到音视频技术，中台也有音视频能力，底层需要优化 以提升音视频技术的竞争力。前台、中台和底层跟音视频相关的技术专家组 成一个技术小组，由一个专家带领。

这条虚线会转化成实线的管理决策，我们必须要打通这个链路，这个体系的 运作会比较有挑战。作为 CTO，我觉得要在过程中保持非常开放的心态，要 信赖每个领域技术专家的判断。技术专家意见不一致时要有独立思考，做出 自己独立判断，要知道创新和秩序的平衡点在哪里。

组织大到一定程度之后就会遇到这样的问题，我确实也不建议技术组织还不 大时就把组织结构搞的太复杂，这会带来额外的管理和沟通成本。

6. 凝心聚气、薪火相传

凝心聚气其实是最重要，也是最难的，这是一个技术文化的事情。每隔一段时间，我们都会聚在一起讨论阿里巴巴的技术文化。去年我们讨论了一轮，三年前我 们也讨论过一轮。三年前定下阿里巴巴技术的 slogan 叫“技术创造新商业”， 再之前的 slogan 是“技术拓展商业边界”。

除了 slogan，阿里巴巴的技术文化底色是务实、有一说一，不要打花腔，不要 做包装，事实是什么样就什么样，用事实说话。没有数据、没有事实的时候， 就不要说话。如果大家都能践行这个文化的话，很多事情会变得特别简单，但 其实践行文化并不容易。

我们有一些技术土话，比如“面向未来去思考”、“因为相信，所以看见”, 是 需要看准未来，敢于投入，真正做到先发先至。因为如果别人做、你再去做， 永远是追赶者，会非常累，但看准未来、敢于投入，也不会轻松。

这些文化、愿景能不能在一个大的场景里形成共识，尤其这个组织每年都有人离开、有新同学进来，还能保证一致的文化，其实是非常有挑战的。但只有文化做好，很多事情才能顺理成章。

CTO 可能不是思想家，但一定是行动派

前面是我思考的 CTO 的六个职责，虽然不完整，虽然不可能每件事情都做得 非常好，但核心思考是，我是相信 CTO 或者说技术团队需要跟着公司业务发 展不断进化。我从蚂蚁到阿里巴巴，差不多经历了前面六个阶段，我称之为 CTO 的六步曲:

1.跟团队先一起定义好目标，先一起做成一些事情。

2.多了解团队、了解业务，知道未来要去哪里，跟团队一起共创一个愿景，把大家热情点燃。

3.CTO 的一个核心工作，是怎么能够让自己不要成为团队的天花板，而是把自己当成团队的地板，用人做事。如果 CTO 是公司技术天花板的话，那你把 公司技术就压在一定的高度和范围内，公司技术永远是在一个小的、狭窄的领域。当 CTO 的技术能力是公司的地板时，公司可以通过新同学扩展边界。成 为 CTO 还是用人做事为主，而不是做事用人为主。

4.一切都很好时，别忘了晴天去修屋顶，永远居安思危。一旦危机出现，乐 观地看待，每个危机背后都有机会，转危为机。

5.过程中不只看当下，也要布局未来，为公司建立技术纵深。在业务发展早期， 技术的纵深就是一个点。当发展到像阿里巴巴现在这个规模时，技术纵深就是 一个多面体，必须有充分的、多面的布局，才能支撑一个大公司的发展。决定 布局投入多少，要和 CEO 充分对焦。

6.最后一点，人才。薪火相传，人才才是公司未来发展的关键。我记得阿里 云曾经有一位技术负责人分享说:什么是一家公司技术的最高境界，就是谁来 当 CTO 都能当好，我觉得这是我要努力的一件事情。

如何发展与培养 CTO

最重要的事情放在最后，就是人才。

前面讲到我们的分层分布治理，每个经营单元要有一个小 CTO，这个 CTO 怎 么培养?基本上我们让他在战场里去练，为他设计发展路径，也有“奇点营” 这样的班专门培养业务小 CTO。

当然最难的事情就是培养接班人，自己的接班人和团队的接班人，这件事情其 实是我上任第一天就在想的事。但选准人、选好人，有非常多的挑战。

我有两个小经验:

1.CTO 发展是“Z”字型的路线。

直线成为 CTO 的人，往往会因为路径太单一、没有足够磨炼而出问题。行 癫负责过淘宝的业务，负责过 B2B 业务，再做阿里巴巴的 CTO，再做阿里云的总裁。我做过蚂蚁的技术，做了两年蚂蚁国际业务，再做阿里巴 巴的 CTO。做过业务再回头看技术，跟 CEO 对话会有共同的框架， 这一点很关键。

2. 做“L”型职责设计。

CTO 最怕做虚了，毕竟这是公司里非常高的位置，每件具体事情都有相应 的核心骨干帮你负责，但你手不伸下去就很容易做虚，看不到下面的实际 情况，会导致决策出错。

阿里巴巴怎么解决这个问题呢?就是给 CTO 一横一纵:横向管理的 CTO，也给你一个纵向的业务技术一号岗位，保持与一线的对接。比如我 现在既是阿里巴巴集团的 CTO，又是菜鸟的 CTO。行癫也曾经既是阿里 巴巴的 CTO，也是阿里云的 CTO，也是一横一纵。

CTO 应该具备怎样的特质?每个 CTO 都有不一样的风格，但有几点是共 通的:一是要求真务实，真正“No Data No BB”，永远不是高高在上地 做决定，而是做决定时能够看得到下面，这很重要;二是要有担当，在做关 键决策时敢负历史责任，有进取心;三是必须时时自省和开放。如果不具 备自省和开放的能力，是很难去进化的;四是一个大组织和大业务的 CTO 要有全局观，能够做架构，能把各方面、各种信息形成一张大图。

曾国藩非常懂用人之道，他这么选人:“专从危难之际，默察朴拙之人， 则几矣”。我特别喜欢这句话，把自己的钉钉签名都写为“朴拙”，这是 对自己的要求。

到现在为止，我觉得自己很多方面做得依然不够，包括对未来的判断。 CEO 和 CTO 实际上是要共同成长、共同进化，在工作中形成默契的，这是非常重要的。

责任编辑：kj005