还没有从“以后20后看90后就像90后看60后”的新年悲伤气氛中晃过神来？设计师们就更惨了，平时事情一大堆就不说了，年底工作量不减反增，活活把一个天真活泼的90后给逼成了60后！文摘菌之前慰问了一下设计师朋友，他说设计一张海报打开五六个浏览器都算事小，要在好几十个网页来回切换，一张一张地手动挑选差不多的图片，费时又伤眼。这样已经够悲惨了，还要面对甲方爸爸和上司的连环夺命call，“视觉冲击不够”、“方案太老套”、“不够创新”、“太想当然了”……要是这样，咬咬牙也就坚持下来了，毕竟都快过大年了，什么事不能年后再说呢。但是上周某企业被曝“职场虐待”，就让设计师们的新年过不好了。根据聊天记录截图来看，该企业创始人要求设计师“初一到初八每天100张海报，配文字”，对此设计师的回复是“每天上班时间7小时，一天一百张，三分钟出一张图？我百度去下载都做不到一天一百张”。这显然已经不是“再写一版”就能搞定的问题了。这件事不仅引起设计师们连倒苦水，不少路人也表示“这是故意找茬年前逼人走”。目前，设计师恶搞创始人的海报已经传疯，100张的量肯定是有了，甚至还有人做了一个小游戏，模拟了这场“海报风波”，大家也可以来试试手速，看看你能否“成功入职”：玩笑归玩笑，虽然这次上司的要求的确过分，但这也给我们提了一个醒，并非所有的工作任务都一定要自己手把手完成，巧用工具可以大幅度提高工作效率。就以此事为例，文摘菌在这里就是要告诉大家，一天100张海报根本不在话下，再来100张也完全没问题！当然，这可不能手工操作，否则只是去百度下载海报都来不及，为何向AI求助一下，就像俗话说的“取人之长补己之短”，最飒的难道不是往上司办公室扔去一百张海报草稿，然后潇洒转头，留下一句“老娘不干了”吗？海报速成，淘宝有“AI鹿班”说到海报，必定逃不过电商。在商品和消费者被屏幕隔开的视觉时代，商家需要用图片和视频展示商品，消费者的选择也严重依赖于图片。因此，海报的制作成为能否吸引消费者的决胜点。但是，制作一张海报可不是这么容易的事，设计师不仅需要根据商品的信息进行个性化设计，还要保证吸引眼球，况且设计师价格也不低，文摘菌随意在一家电商平台上进行了搜索，发现一张商业海报的价格达到了799元。如果商家都是这样操作的话，那在宣传上投入的资金和时间也太大了。早在2016年，淘宝就已经考虑到了这个技术缺口。那年淘宝推出了“AI鲁班”系统，据统计，当年双十一有1.7亿张海报banner都是由“AI鲁班”设计，约等于每秒做了8000张，如果全部依赖设计师手动操作的话，假设每张图需要20分钟，也不过就需要100个设计师连续做个小300年罢了。而且，注意到，用一时间内在淘宝出现的海报banner是不一样的，“AI鲁班”带来的直接结果就是商品的点击率提升了100%。到了2017年，“AI鲁班”的设计水平进一步提升，该系统学习了百万级的设计师创意内容，拥有演变出上亿级的设计能力。至于速度，“AI鲁班”已经能一天制作4000万张海报，没有一张带重样的。比如，“AI鲁班”在学习了SKII的品牌设计风格后，通过手动输入商品和文案，就会自动匹配素材生产相应设计海报，整个过程一键搞定，动作神速。2018年， 在第七届UCAN用户体验设计论坛上，“AI鲁班”正式改名为“AI鹿班”。据“AI鹿班”创始人乐乘表示，“AI鹿班”在设计能力上的提升，不只表现在设计淘宝的宣传海报，还可以向其他公司和行业进行输出，“共享”设计能力。2019年的双十一，“AI鹿班”火力全开，制作海报10亿张，针对新老客户、不同季节、不同性别，设计了不同的专属海报图。据了解，“AI鹿班”由学习网络，行动器，评估网络三部分组成，其原理是AI算法和大数据训练，机器学习设计，输出设计能力。也就是，通过将人的设计转化为设计的数据，再将数据变为某种模型，这个模型可以进行运算，运算之后再评估，评估打分之后，再进行运算的迭代。不过说白了，通过超级计算机建立设计模型，把基于规则的东西转换成基于数据和统计的东西，这不就是设计框架嘛。比如说，甲方爸爸常用的“清凉感”是什么组成的，浅色？花朵？海边？“AI鹿班”能根据关键词在素材库中抓取元素进行组合，然后评估，评估系统先经过了人工输入评分标准，最终完成设计要求。手工设计没灵感？还有神器来助攻当然，如果在设计上不想完全依赖AI，就只能自己动手了。其实，平时勤加练习，设计海报的速度也会大大提升。不过，在紧要关头，设计灵感可不是说来就来，往往这个时候有，下一秒就没了。怎么抓住灵感？这个谷歌、英伟达也都帮你想好了，他们都推出了神器助攻设计师，画纸上随意画上两笔，就能生成一张海报级大片，简直是无灵感福音。谷歌在2017年推出了这款名为AutoDraw的人工智能绘画工具，支持手机、平板、PC、浏览器多端使用。当开启程序后，你将有20秒绘画时间，绘画时神经网络会实时判断绘画内容，最后让你确认猜测结果是否正确。说得直白一点就是“你画我猜”AI版。互动过程中不仅绘画者的技能可以逐渐提升，同时程序也会随着时间和输入内容提高学习能力。现在，AutoDraw除了能根据画迹判断绘画内容，还能帮助把图案改得更专业更好看！修改而成的插图是邀请各地艺术家预先绘制而成，只需简单勾勒，AutoDraw会建议修改相关图案，一点立即套用。官方链接如下，还不赶紧上手试试：https://www.autodraw.com/如果说AutoDraw适用人群是初级绘画小白的话，那么英伟达的这款GauGAN瞄准的就是中高级绘画人群了。GauGAN是英伟达在2019年3月的GPU技术大会（GTC）公布的一种生成对抗性AI系统，用户可以利用GauGAN创建实际不存在的风景图像。说到GauGAN这个名字，也是小有来头，除了是“生成对抗网络”的英文缩写外，顺便还致敬了一下印象派画家高更，从简笔画秒变大片，这个过程也还蛮“印象派”的（不是）。在GTC上英伟达称，GauGAN相关研究是在之前Pix2PixHD基础上进行的改进，新模型的参数较少，可生成的图像选项较多。训练数据是英伟达从Flickr收集的，包含100万张图片。用户在操作的时候，只需使用画笔在画布上简单描绘几笔，模型在相应位置就能生成真实图像，生成内容与场景其余部分毫无违和感，简直就是马良神笔。该模型已经学习掌握了180多个目标之间的关系，包括雪地、树木、水流、花草、灌木，丘陵和山脉等。在同年下半年的Siggraph计算机视觉会议上，英伟达还对GauGAN进行了更新，更新后的版本上线了新的过滤功能，可以叠加上传照片的照明风格和样式。新版GauGAN改进了Pix2PixHD系统。用户通过使用画笔和漆桶工具，以及河流，草地，岩石和云等功能标签，设计出逼真的景观图像，而且这些样式转移功能还可以动态修改颜色和美感，例如，显示温暖的夕阳光，或显示城市天际线的冷光。同时，用户还能上传风景图像，GauGAN将其转换为分割图，描述对象位置的地图的细节，作为进一步艺术加工的基础。“我们希望我们的研究可以产生更多影响，”英伟达说，“GauGAN为人们创造了一个表达想象力和创造力的渠道，让艺术家们更好地创作，更自由地发挥想象力。”不管是AI自动生成海报，还是AI帮助你手动设计海报，AI赋能设计领域之后设计效率也得到了显著提高。当然，说了这么多，文摘菌并不是鼓励大家对上司的任何无理要求都有求必应，只是想借此告诉大家，不仅是设计师们，还有更多的行业，在AI已经全面赋能的时代，只要利用好AI这个工具，平时工作简直轻松愉快，上司还舍得放这条大鱼走吗？

作者｜白玙开源正在以开放(Openness)、分享(Sharing)、对等(Peering)、协作(Collaboration)以及全球化运作(Acting Globally)的方式，打破传统组织架构与商业模式，工业经济时代的运转逻辑被逐渐颠覆重构，并深刻影响到从业者思维模式、企业商业行为、组织治理方式。着眼于中国开源领域，在过去十年迎来了飞速发展。据昨日云栖大会发布的《中国十年开源洞察报告》显示，不管是开源仓库数量、活跃开发者数量、总体活跃度，还是开发者参与度迎来了大幅提升。开源软件生产流水线自动化水平大幅提升，2019 年后自动化协作呈现高速增长趋势。多个开源 KOL 持续在开源项目中高度活跃。RocketMQ 作为 2011 年诞生的消息中间件，也见证了中国开源领域的十年发展。成为阿里巴巴众多开源项目中最为要耀眼的代表项目之一。这不仅仅是指 RocketMQ 是首个进入 Apache 顶级项目的国内互联网中间件，也包括 RocketMQ 在物联网、大数据等领域发挥着巨大作用，让数以百万的企业以及开发者真真切切的受益，推动社会经济以及互联网技术的发展。十年间，RocketMQ 一直坚持开源、商业、内部三位一体的发展思路，内核演进和功能迭代协同并举。在集团内部支撑交易等核心链路完美度过历次双十一流量洪峰，创下超过 2 万亿条的消息流转的记录；在商业，RocketMQ 服务了互联网、金融、政企等多行业上万家企业客户；在开源，社区始终保持着极高的参与度，拥有超大规模的国内活跃交流群，ISSUE 上更是收录了来自全球海量高质量话题交流以及问题沉淀。在 2017 年发布 4.0 版本之后，时隔 5 年，RocketMQ 迎来了 5.0 版本，标志着 RocketMQ 正式从单一消息场景迈向更广阔的事件、消息、流一体化融合场景。作为继 2017 年发布 4.0 版本之后时隔五年的重大更新，5.0 版本对架构进行了大规模重塑，新增、修改超过 60% 代码，并实现对 4.0 版本所有功能及整体架构的无缝兼容，且未引入任何外部依赖。全新的 RocketMQ 5.0 版本坚持场景多元化和极致弹性的服务能力，面向多场景提供可分可合存算分离的架构；在全新布局的 Streaming 和 Eventing 领域，RocketMQ 全面发展上下游集成能力，采用开发兼容的思路去适配已有开源生态。例如和 Flink 的集成，RocketMQ 直接实现了 Flink 基础功能、算子，并首创性地兼容了 Flink/Blink SQL 标准以及 UDF/UDAF/UDTF。阿里巴巴一路走来，不断从开源中汲取营养，也持续贡献开源。开源像一根纽带，让阿里技术与全球技 术活水相通、共同进化。10 月 22 日，云栖大会-互联网架构分论坛，阿里云将发布全新 RocketMQ 5.0 版，带来存算分离新架构实践以及事件、消息、流一体化标杆功能，让更多企业能够获得与阿里巴巴同等的技术能力，敬请期待！👇戳下方链接，立刻查看企业互联网架构分论坛直播回看！https://yunqi.aliyun.com/2021/agenda/session184

在电商时代，流量已成为企业核心竞争力，秒杀、抢购等活动成为必备营销手段。自淘宝开启双十一活动，各大电商平台以及品牌主的促销活动更是如雨后春笋般不断涌现。当需要向一个庞大群体提供服务时，可用性成为电商运营&网站运维的关键，面对电商大促带来的流量浪涌，如何在应对散布全球不同地区与国家的海量用户以及流量激增的同时，保障业务稳定运行已成为企业必须解决的问题。以拥有千万注册用户的某电商举例，在大促活动期间，该企业将面对近千万不同地区的用户同时涌入，系统可用性将影响着大促的成功与否。对电商网站而言，网站的加载缓慢或者不可用往往代表着前期的营销造势都付之一炬，这不仅仅是损失数千万元订单，更会对品牌口碑造成影响。在双 11 这种电商大促场景下，由于流量的增加，网站一旦发生可用性问题，造成的社会影响也会成倍放大。因此，针对双 11 这类大促场景，不管是电商平台还是自建站都会在前期进行压测，通过压测发现系统的性能瓶颈并做出对应的容量规划。但是仅仅做压测和扩容就够了吗？远远不够，压测这种场景更多的是从商家或平台的视角评估网站的性能和容量，缺乏用户视角的性能评估手段和方法。这样的网站优化不只是对 IaaS 层资源进行简单扩容那么简单，而是需要对整个网站浏览路径上的各环节进行优化调整。模拟全球不同地区用户的使用，如果没有仿真海量用户且模拟真实用户行为的测试工具，想预知这个复杂购物网站系统的性能、瓶颈或故障点位于何处，更像是一项不可能完成的任务。我们以某著名大型电商网站的产品预售活动为例，我们希望在产品预约、抢购活动开始之前，对网站系统的性能进行测试，找到系统瓶颈，进而帮助系统优化，确保预约/抢购活动的顺利进行。本次测试为全球范围的拨测测试，涉及到网站系统的店铺页、商品详情页、订单页。要对每个模块以及整个系统的性能进行测试。需要模拟大量全球不同地区的真实用户同时操作，查看页面响应时间，确保系统在不同地区用户浏览时响应及时，不会产生未知错误或者延迟影响网站用户体验。我们借助工具对相关性能与体验指标进行收集与整合后，就要开始进行相关分析，我们以真实用户的性能与体验数据为核心，那么分析流程应与真实用户访问流程大致为：终端—网络—应用—系统。在分析的过程中，我们需要确保拥有足够的样本量，以及自身对于不同指标对用户体验影响的权重评估。其中，我们着重关注终端、网络部分。（1）全地域可用性摸底在大促活动前，我们会针对自己面向的市场，选择全国不同省份的重要城市不同运营商的真实用户监测点，甚至是海外城市监测点，对网站的落地页地址发起多轮网络拨测，从延时、丢包率、可用性等指标维度评估域名、 IP、API 性能情况，形成可用性整体报表，针对可用性较差地域或运营商会进行重点治理。（2）核心路径页面用户体验评估用户体验决定着促销活动的效果，尤其是页面的大概速度，更是直接决定着用户的去留。有研究数据表明，如果网页的打开速度在 6-8 秒，大部分访客会离开，打开速度在 12 秒，99% 的用户会离开。在大促前对用户体验的评估也是我们需要重点关注的地方。针对于用户体验，我们前期会梳理出用户的核心浏览路径，在核心浏览路径上的页面会进行重点优化和治理。通过云拨测的浏览任务，我们会获得不同地域和运营商用户访问该页面的首屏时间、100K 时间等核心的体验指标。尤其针对整体首屏时间，要求核心浏览路径的首屏时间必须符合相应要求。（3）DNS 解析效果评估DNS 解析是最容易被忽略的地方，前端时间 Facebook 的教训还历历在目，所以针对 DNS 我们也会进行重点治理。通过遍布全球的 1000+ 监测点，包括真实用户监测，全天候 24 小时对目标域名发起网络请求，帮助用户监测 DNS 服务对可用性和解析性能，同时 DNS 拨测支持指定递归、迭代不同查询方式以及解析服务器，通过灵活的拨测参数配置尽可能模拟真实用户的访问。经过定时的拨测任务，阿里云拨测可以生成不同地区的 DNS 解析用时的报表，同时针对每次拨测都清晰的列出 DNS 请求对详情，包括 A 地址、DNS 用时、DNS 解析过程等，能给帮助用户快速分析和定位 DNS 解析的问题。另外，通过配置 DNS 告警，针对于 DNS 的可用性问题和解析性能问题，也可以先于用户感知并问问题的修复争取时间，提高用户的满意度，降低经济损失。（4）CDN 质量监测随着网站的图片、视频内容越发丰富，为了解决不同地区、不同运营商访问速度慢的问题，非常多电商网站都在使用 CDN 服务，提高网站加载速度，降低带宽成本，增加内容可用性和冗余。选取了目标用户群体，如北美、欧洲、南美洲、东南亚等主要国家的 LastMile（真实网民）监测点，配置浏览器拨测任务，对大促网站进行拨测。通过对拨测日志进行分析，实时了解 CDN 部署后的展示性能为多少，是否有提升台主机节点的性能情况，可用性是否稳定。目标客户是否正确命中对应主机节点，或匹配度是否合理，CDN 节点与源站同步、对元素发布是否提供到位并长期有效。并基于以上评估标准对 CDN 设置策略进行调整及优化。每年双 11 前夕，全链路压测成为企业的必备选项，不断地通过压测发现问题进行迭代优化、全方位验证业务的稳定性，而云拨测的出现，是对全链路压测的完美补充，从用户视角全面解析大促场景下的用户体验情况，让用户能够拥有更加优质的购买体验。并且随着业务的发展不断进化，持续发挥着不可替代的作用。关于云拨测云拨测作为面向业务的非侵入式云原生监测产品，成为最佳的选择。通过阿里云遍布全球的服务网络，模拟真实用户行为，全天候持续监测网站及其网络、服务、API端口可用性与性能。实现页面元素级、网络请求级、网络链路级细颗粒度问题定位。丰富的监测关联项与分析模型，帮助企业及时发现与定位性能瓶颈与体验暗点，压降运营风险，提升服务体验与效能。（一）全球监测节点覆盖全球超过 20 万 LM，500 余个 IDC 终端监测节点，海内外 400+ 运营商以及数十万量级注册会员，确保监测规模满足日益庞大的业务规模。（二）无需嵌码，开箱即用零侵入式监测，只需输入 URL 并进行简单配置即可，无需研发支持。数分钟即可获得完整的网站性能数据分析报告。资源包&按量付费多种购买模式，满足运维测试需求。（三）面向业务，预置多种分析模型监测周期精细至分钟级别，7 大类 20 余项监测关联参数设置、支持多种主流协议，为站点和业务端口等提供 7×24 小时细颗粒度故障实时监测、告警及性能分析服务。以最终客户视角，通过地域、运营商等多维度组合分析，下钻分析单样本详情，利用丰富的指标体系与图表类型，直观定位问题、受影响范围及其根因，压降分析时间，提升运维效率。真正做到精细化监测。（四）智能告警，精准定位针对首屏用时、整体性能、可用性实现实时告警，丰富的告警策略设置，与阿里云告警中心深度集成，有效缩短MTTR。支持发现页面元素级错误，问题归因精准定位至单次网络请求过程，提升问题定位效率。目前云拨测提供 15 天免费试用新用户购买更有 9 折优惠！扫描下方二维码，前往云原生官方群探索云原生的奥秘！点击下方链接，了解更多详情！https://www.aliyun.com/activity/middleware/website/performance/test?spm=5176.20960838.0.0.6d33305emfVIyC

https://www.aliyun.com/daily-act/ecs/ecs_amd_test-0901?userCode=c0fubz3ehttps://www.aliyun.com/daily-act/ecs/care?userCode=c0fubz3ehttps://www.aliyun.com/activity/new?userCode=c0fubz3ehttps://www.aliyun.com/activity/daily/bestoffer?userCode=c0fubz3ehttps://www.aliyun.com/daily-act/ecs/activity_selection?userCode=c0fubz3e

在10月19日举行的2021云栖大会智物智造峰会上，阿里云智能IoT事业部总经理王晓冬宣布将全力投入“智物智造”战略，助力更高效的硬件智能化和生产数字化。王晓冬表示，力争三年内通过“智物智造”的产品技术和生态，赋能10亿智能设备，改造10万家数字工厂。王晓冬表示，“智物智造”的本质是服务产业互联网的发展。在会上王晓冬表示，高度发达的消费互联网需要与产业互联网更好的结合，以满足不断升级的消费需求。而产业互联网发展存在三个普遍需求：产品数字化（设备智能化），生产数字化和产业链数字化，由此智物智造应运而生，其中智物服务产品智能化需求，智造则服务生产数字化和产业链数字化需求。 王晓冬表示，阿里云IoT将全力投入智物智造，并联动阿里巴巴9亿消费者、300万企业，整合IoT软硬件生态，推动消费互联网与产业互联网更好结合。在重庆，阿里云飞象工业互联网与重庆农投良品有限公司共建农产品工业互联网大数据平台，结合农投集团在乳、肉、蛋、种、鱼业5大领域的产业资源，制定供应链准入标准，建立以淘系电商为中心，包含订单、需求、企划、供应管理的智慧营销体系。以其中一个农产品“三峡蜜罐”为例，它完整应用了智物智造，阿里云帮助其在生产环节实现蜂箱及其他养蜂工具的智能化，并通过区块链溯源平台、产销协同溯源平台实现对蜂蜜质量的控制，同时依托整个工业互联网平台，完成订单、需求和供应管理。在完成全产业链重塑后，该产品原蜜成本降低50%以上，加工实现集约化，加工成本降15%以上，销售实现市场化，C端渠道销量增加20%以上。更多的企业在完成智物或智造的数字化转型。阿里云帮助绿源电动车实现无感开锁、老板电器利用上千个传感器的工业数据打造无人车间，智物与应用构成的AIoT解决方案广泛服务于城市管理者、共享服务商、新零售服务商等等。王晓冬表示，阿里云IoT联合达摩院、平头哥等阿里巴巴技术力量，为物联网打造了云网边端一体化的AIoT平台，具备99.99%的高可用性，在AI、低代码开发、安全等方面具有领先的技术优势。为了更好的服务三年目标，阿里云联合天猫、淘宝、天猫精灵、平头哥、达摩院等共同发布了“智物智造养成计划”，阿里云IoT将向智物智造企业提供亿元的免费物联网云平台、安全、连接等软硬件资源，并为10万开发者提供千万奖金池、数千万软硬件资源。天猫将在“双11”前对首次开播并完成相应任务的商家，最高发放50万个免费流量券；淘宝联盟将在“双11”全周期补贴10亿佣金。

阿里云服务器贵吗？阿里云服务器购买价格是多少？阿里云服务器报价主要看配置,阿里云一般在年初的采购季、年中618、年尾双11等大促时间都会推出60-70元左右的最便宜云服务器，而平常，阿里云一般都会推出一款配置为1核2G1M带宽的云服务器，作为吸引用户选择阿里云服务器的走量型云服务器，通常价格在80-90元左右，随着配置的升高，阿里云服务器的报价也会越高。阿里云服务器购买价格贵吗？阿里云服务器价格有高有低，主要看你的配置了。价格从几十元到上万元甚至十几万的都有，主要看配置的cpu，内存，带宽，我们个人刚开始做网站一般1核2G、2核2G的都可以了，如果后期网站流量大了，可以随时在后台升级配置，很方便的。阿里云服务器价格是多少？目前最便宜的阿里云服务器是一款共享型n4实例、1核2G1M带宽配置的云服务器，秒杀价格为72.60元，也可以选择3年，价格是217.80元。这个共享型n4实例是性能无约束的（不像以往的突发性t6实例有20%性能限制），适用于中小型网站搭建等应用，因此，阿里云这款目前最便宜的云服务器只适合于个人开发者建站或者一些简单的普通企业网站使用，如果是一些动态类的品牌官网或者数据量比较大的网站，则需要更高的配置了。阿里云服务器秒杀推荐：云服务器精选特惠在平常，我们可以通过阿里云小站平台去领取代金券和了解当下阿里云有哪些便宜的云服务器，可选实例规格和配置有哪些，优惠价格是多少，官方有什么新的云服务器需要促销，阿里云都会将配置和价格公布在云小站平台。热门配置的阿里云服务器价格一般用户购买比较多的常用阿里云服务器配置有2核4G、4核8G、4核16G、8核16G等，这些配置具有很强的适用性，例如2核4G配置可以满足品牌官网类网站，4核8G可以满足一些论坛、门户类网站。这些配置目前的报价如下：2核4G配置最低报价为200元/1年，实例规格为计算型c5，可选带宽为1-10M；4核8G配置最低报价为598.32元/1年，实例规格为共享型s6，可选带宽为1-10M；4核16G配置最低报价为1240.80元/1年，实例规格为通用型g5，可选带宽为1-10M；8核16G配置最低报价为1675.08元/1年，实例规格为共享型s6，可选带宽为1-10M；老用户如何便宜购买到阿里云服务器上面所说的这些云服务器都是仅限新用户购买的，如果我们是老用户，如何购买才能更便宜呢？目前最实用的方法是在阿里云小站平台上领取阿里云代金券，然后通过阿里云爆款特惠活动中的“ECS云服务器爆款榜单”专区去购买，里面的云服务器老用户也可以购买，折扣为3.5折起。

文 / 程立 我的经历 我的经历很简单，2004 年之前一直在学校读书，读到 30 岁。2004 年跟着一个师兄做外包项目，为淘宝网做一个 重要的架构升级——把原来 PHP/MySQL 架构换成 Jave 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”目标:公司从互联网平台向数字普惠金融平台转型，我们的技术架构怎么去支撑? 需要重新定义支撑数字普惠金融新的平台。做平台架构这件事情，至少是我的 本行，大家认同。蚂蚁哪些核心技术是我们今年必须要突破的?当时定了两个核心点:一是 OceanBase 在这一年能落地;二是我们要把蚂蚁的平台建在云上。我们能不能在这一年大促的时候实现 3 万笔 / 秒的支付?大家知道从 2010 年开始，每年会有一次大考:大促能扛多高的峰值。前两年，蚂蚁都是非常吃 力的去扛。甚至 2012 年对团队来说是个很大的耻辱——大促前 50 分钟系统被 冲垮了，50 分钟后才恢复。2013 年大家都想一雪前耻:2012 年时峰值是每 秒 3000 笔，已经是性能极限了。我们定一个 10 倍的目标实现 3 万笔 / 秒!因为我们的服务不仅仅是支付，还开始提供金融服务，稳定性必须像银行一样， 甚至比银行更稳定。我们定下可运行目标 4 个 9(99.99%)，之前 3 个 9 都 很吃力。这四个目标，大家非常认同，虽然都很有挑战。年底的时候，经过大家的努力， 四个目标里实现了三个半:完成了平台的转型，余额宝、花呗业务都起来了; OceanBase 在蚂蚁系统里落地了;做到 4 个 9;但我们没有做到 3 万笔 / 秒， 只做到 1.5 万笔 / 秒，是 5 倍的提升。之后大家开始建立起对我的信任。 我到了阿里巴巴之后，第一件事情也是需要大家聚在一起，一起定下目标。 空降到一个平台，其实很难给团队定一个全新的愿景。如果新 CTO 上来就 先画一张未来的图，基本是不太靠谱的，还是要和团队一起定下非常扎实的 目标、一起达成目标。于是，我选择先在云这个关键战略上稳中有进，全面 上云必须全部完成。二是在云之上，如何从“上云”到“用云”，把云原生 做深入，将阿里巴巴中台做深入，包括 AI 中台、数据中台和业务中台。另 外一个目标是组织数字化，阿里巴巴虽然生于数字时代，但也需要做数字化 升级和转型，阿里巴巴数字原生商业系统和数字原生组织是去年和团队一起 确定的方向。CTO 和团队在一起要有一个面向未来的思考，不只是当下与业务的连接。未来是什么，关键的路径是什么，核心的几场仗是什么，这是 CTO 的牵引力。关键决策，扫清前进中的障碍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 要在关键决策中发挥作用，帮助团队下决心并把握好不确定性。应对风险，化危为机公司的技术风险有几类。 第一类，技术架构不能够支持业务发展，这是业务不能接受的风险。但这类的 风险，相对显而易见。阿里巴巴为什么在 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 中台等一系列技术中台。当我做一 个新业务的时候，我需要跟这么多中台打交道，需要他们去支撑我，过程中如 果有任何一个中台支持不能到位，我的业务可能就做不成。我们现在开始大力 推动中台能力进一步升级，改善中台的交付方式，把中台再升级。这里涉及到 很多技术架构的变化。为了防止温水煮青蛙就是要一直做系统化的梳理，再去 一个阶段一个阶段的解决。组织设计与治理 —— 平衡秩序与创新一个人当 CTO 的时间越长，专业能力下降得就越严重。我判断自己的专业能 力大概每隔两年会降一级。也有好处，你可以跟团队一起做，团队会更强。组 织设计的核心是要既有秩序又能创新。这是有矛盾的，创新是在一个混乱的土 壤里长出来的，秩序让效率高，但会把很多创新吃掉。这个过程有点像踩钢丝， 处理秩序和创新的平衡。 阿里巴巴围绕技术的组织，是有两条线的。一条线是实的管理线，是分层分布的: 前台，面向业务的，为客户赢;中台，是能力中心，中台的客户是前台，让前台 更加高效，让前台更有竞争力;底层后台，是强调技术先进性的，确保业务永续。 这个组织每一层都是独立的业务经营单元，现在我们在做一件事情，让每个独 立的业务经营单元都有 CTO。这个 CTO 会对这个业务经营单元负全责。实线 管理机制的核心就是把每一层之间的界面定义清楚。 这种治理让每一块业务都很灵活，都可以自主发展，但又带来了一个新问题， 我们该统一发展的技术怎么形成合力，所以我们有另一条虚线:技术委员会，下设二三十个核心的技术小组，把所有的共性领域横向拉通。通过技术委员会 和技术小组的专业领导力，实现策略通、人才通。这两条线会同时运作，随着 管理线越来越清晰的分层，这条专业的虚线就会变得非常重要。比如音视频技 术，每个业务里都会用到音视频技术，中台也有音视频能力，底层需要优化 以提升音视频技术的竞争力。前台、中台和底层跟音视频相关的技术专家组 成一个技术小组，由一个专家带领。这条虚线会转化成实线的管理决策，我们必须要打通这个链路，这个体系的 运作会比较有挑战。作为 CTO，我觉得要在过程中保持非常开放的心态，要 信赖每个领域技术专家的判断。技术专家意见不一致时要有独立思考，做出 自己独立判断，要知道创新和秩序的平衡点在哪里。 组织大到一定程度之后就会遇到这样的问题，我确实也不建议技术组织还不 大时就把组织结构搞的太复杂，这会带来额外的管理和沟通成本。凝心聚气、薪火相传凝心聚气其实是最重要，也是最难的，这是一个技术文化的事情。每隔一段时间，我们都会聚在一起讨论阿里巴巴的技术文化。去年我们讨论了一轮，三年前我 们也讨论过一轮。三年前定下阿里巴巴技术的 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 对话会有共同的框架， 这一点很关键。做“L”型职责设计。CTO 最怕做虚了，毕竟这是公司里非常高的位置，每件具体事情都有相应 的核心骨干帮你负责，但你手不伸下去就很容易做虚，看不到下面的实际 情况，会导致决策出错。 阿里巴巴怎么解决这个问题呢?就是给 CTO 一横一纵:横向管理的 CTO，也给你一个纵向的业务技术一号岗位，保持与一线的对接。比如我 现在既是阿里巴巴集团的 CTO，又是菜鸟的 CTO。行癫也曾经既是阿里 巴巴的 CTO，也是阿里云的 CTO，也是一横一纵。 CTO 应该具备怎样的特质?每个 CTO 都有不一样的风格，但有几点是共 通的:一是要求真务实，真正“No Data No BB”，永远不是高高在上地 做决定，而是做决定时能够看得到下面，这很重要;二是要有担当，在做关 键决策时敢负历史责任，有进取心;三是必须时时自省和开放。如果不具 备自省和开放的能力，是很难去进化的;四是一个大组织和大业务的 CTO 要有全局观，能够做架构，能把各方面、各种信息形成一张大图。曾国藩非常懂用人之道，他这么选人:“专从危难之际，默察朴拙之人， 则几矣”。我特别喜欢这句话，把自己的钉钉签名都写为“朴拙”，这是 对自己的要求。 到现在为止，我觉得自己很多方面做得依然不够，包括对未来的判断。 CEO 和 CTO 实际上是要共同成长、共同进化，在工作中形成默契的，这是非常重要的。

文 / 程立 我的经历 我的经历很简单，2004 年之前一直在学校读书，读到 30 岁。2004 年跟着一个师兄做外包项目，为淘宝网做一个 重要的架构升级——把原来 PHP/MySQL 架构换成 Jave 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”目标:公司从互联网平台向数字普惠金融平台转型，我们的技术架构怎么去支撑? 需要重新定义支撑数字普惠金融新的平台。做平台架构这件事情，至少是我的 本行，大家认同。蚂蚁哪些核心技术是我们今年必须要突破的?当时定了两个核心点:一是 OceanBase 在这一年能落地;二是我们要把蚂蚁的平台建在云上。我们能不能在这一年大促的时候实现 3 万笔 / 秒的支付?大家知道从 2010 年开始，每年会有一次大考:大促能扛多高的峰值。前两年，蚂蚁都是非常吃 力的去扛。甚至 2012 年对团队来说是个很大的耻辱——大促前 50 分钟系统被 冲垮了，50 分钟后才恢复。2013 年大家都想一雪前耻:2012 年时峰值是每 秒 3000 笔，已经是性能极限了。我们定一个 10 倍的目标实现 3 万笔 / 秒!因为我们的服务不仅仅是支付，还开始提供金融服务，稳定性必须像银行一样， 甚至比银行更稳定。我们定下可运行目标 4 个 9(99.99%)，之前 3 个 9 都 很吃力。这四个目标，大家非常认同，虽然都很有挑战。年底的时候，经过大家的努力， 四个目标里实现了三个半:完成了平台的转型，余额宝、花呗业务都起来了; OceanBase 在蚂蚁系统里落地了;做到 4 个 9;但我们没有做到 3 万笔 / 秒， 只做到 1.5 万笔 / 秒，是 5 倍的提升。之后大家开始建立起对我的信任。 我到了阿里巴巴之后，第一件事情也是需要大家聚在一起，一起定下目标。 空降到一个平台，其实很难给团队定一个全新的愿景。如果新 CTO 上来就 先画一张未来的图，基本是不太靠谱的，还是要和团队一起定下非常扎实的 目标、一起达成目标。于是，我选择先在云这个关键战略上稳中有进，全面 上云必须全部完成。二是在云之上，如何从“上云”到“用云”，把云原生 做深入，将阿里巴巴中台做深入，包括 AI 中台、数据中台和业务中台。另 外一个目标是组织数字化，阿里巴巴虽然生于数字时代，但也需要做数字化 升级和转型，阿里巴巴数字原生商业系统和数字原生组织是去年和团队一起 确定的方向。CTO 和团队在一起要有一个面向未来的思考，不只是当下与业务的连接。未来是什么，关键的路径是什么，核心的几场仗是什么，这是 CTO 的牵引力。关键决策，扫清前进中的障碍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 要在关键决策中发挥作用，帮助团队下决心并把握好不确定性。应对风险，化危为机公司的技术风险有几类。 第一类，技术架构不能够支持业务发展，这是业务不能接受的风险。但这类的 风险，相对显而易见。阿里巴巴为什么在 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 中台等一系列技术中台。当我做一 个新业务的时候，我需要跟这么多中台打交道，需要他们去支撑我，过程中如 果有任何一个中台支持不能到位，我的业务可能就做不成。我们现在开始大力 推动中台能力进一步升级，改善中台的交付方式，把中台再升级。这里涉及到 很多技术架构的变化。为了防止温水煮青蛙就是要一直做系统化的梳理，再去 一个阶段一个阶段的解决。组织设计与治理 —— 平衡秩序与创新一个人当 CTO 的时间越长，专业能力下降得就越严重。我判断自己的专业能 力大概每隔两年会降一级。也有好处，你可以跟团队一起做，团队会更强。组 织设计的核心是要既有秩序又能创新。这是有矛盾的，创新是在一个混乱的土 壤里长出来的，秩序让效率高，但会把很多创新吃掉。这个过程有点像踩钢丝， 处理秩序和创新的平衡。 阿里巴巴围绕技术的组织，是有两条线的。一条线是实的管理线，是分层分布的: 前台，面向业务的，为客户赢;中台，是能力中心，中台的客户是前台，让前台 更加高效，让前台更有竞争力;底层后台，是强调技术先进性的，确保业务永续。 这个组织每一层都是独立的业务经营单元，现在我们在做一件事情，让每个独 立的业务经营单元都有 CTO。这个 CTO 会对这个业务经营单元负全责。实线 管理机制的核心就是把每一层之间的界面定义清楚。 这种治理让每一块业务都很灵活，都可以自主发展，但又带来了一个新问题， 我们该统一发展的技术怎么形成合力，所以我们有另一条虚线:技术委员会，下设二三十个核心的技术小组，把所有的共性领域横向拉通。通过技术委员会 和技术小组的专业领导力，实现策略通、人才通。这两条线会同时运作，随着 管理线越来越清晰的分层，这条专业的虚线就会变得非常重要。比如音视频技 术，每个业务里都会用到音视频技术，中台也有音视频能力，底层需要优化 以提升音视频技术的竞争力。前台、中台和底层跟音视频相关的技术专家组 成一个技术小组，由一个专家带领。这条虚线会转化成实线的管理决策，我们必须要打通这个链路，这个体系的 运作会比较有挑战。作为 CTO，我觉得要在过程中保持非常开放的心态，要 信赖每个领域技术专家的判断。技术专家意见不一致时要有独立思考，做出 自己独立判断，要知道创新和秩序的平衡点在哪里。 组织大到一定程度之后就会遇到这样的问题，我确实也不建议技术组织还不 大时就把组织结构搞的太复杂，这会带来额外的管理和沟通成本。凝心聚气、薪火相传凝心聚气其实是最重要，也是最难的，这是一个技术文化的事情。每隔一段时间，我们都会聚在一起讨论阿里巴巴的技术文化。去年我们讨论了一轮，三年前我 们也讨论过一轮。三年前定下阿里巴巴技术的 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 对话会有共同的框架， 这一点很关键。做“L”型职责设计。CTO 最怕做虚了，毕竟这是公司里非常高的位置，每件具体事情都有相应 的核心骨干帮你负责，但你手不伸下去就很容易做虚，看不到下面的实际 情况，会导致决策出错。 阿里巴巴怎么解决这个问题呢?就是给 CTO 一横一纵:横向管理的 CTO，也给你一个纵向的业务技术一号岗位，保持与一线的对接。比如我 现在既是阿里巴巴集团的 CTO，又是菜鸟的 CTO。行癫也曾经既是阿里 巴巴的 CTO，也是阿里云的 CTO，也是一横一纵。 CTO 应该具备怎样的特质?每个 CTO 都有不一样的风格，但有几点是共 通的:一是要求真务实，真正“No Data No BB”，永远不是高高在上地 做决定，而是做决定时能够看得到下面，这很重要;二是要有担当，在做关 键决策时敢负历史责任，有进取心;三是必须时时自省和开放。如果不具 备自省和开放的能力，是很难去进化的;四是一个大组织和大业务的 CTO 要有全局观，能够做架构，能把各方面、各种信息形成一张大图。曾国藩非常懂用人之道，他这么选人:“专从危难之际，默察朴拙之人， 则几矣”。我特别喜欢这句话，把自己的钉钉签名都写为“朴拙”，这是 对自己的要求。 到现在为止，我觉得自己很多方面做得依然不够，包括对未来的判断。 CEO 和 CTO 实际上是要共同成长、共同进化，在工作中形成默契的，这是非常重要的。

Cloud-native: The Shortest Route to Digitalization and Innovation本文全面回顾了阿里巴巴十五年云原生实践历程，并重点解读了在数字经济的背景下， 企业如何通过云原生实现应用云化，充分发挥云的价值，快速激活数字创新能力。今天，数字化成为企业的核心竞争力，千行百业都在拥 抱云计算、拥抱云原生。2020 年是云原生落地的元年， 2021 年将是云原生加速推动企业数字创新的关键节点。阿里巴巴十五年云原生实践 阿里巴巴拥有十五年的云原生实践经验，在这过程中，我们 经常会面临一些关键决策点，在这些决策点上的每一步选择， 都对阿里巴巴的技术创新进程产生重要影响。阿里巴巴为什 么全面拥抱云原生，每一步决策背后是如何思考的?2006 年，我们开始探索互联网分布式架构，这是阿里巴 巴云原生的一个起点。为什么要做互联网分布式架构?当 时淘宝在快速发展过程中遇到了技术支撑瓶颈和技术迭代 效率瓶颈。传统“IOE”架构的可扩展性不足，无法支撑 海量 C 端用户访问;300 人开发 3 个系统，带来巨型应用 代码合并冲突、多项目环境并存、发布变更冲突等，进而 导致研发效率低下，业务推进不够敏捷。因为这些痛点我们提出要做服务化拆分、去“IOE”，研发 互联网分布式架构。2008 年淘宝的整个服务 拆分已经完成，形成了三大核心中间件，并对 行业进行了开源 (Dubbo、RocketMQ 等 )。2011 年，我们开始推进容器化落地，那时全 球做容器化改造的公司屈指可数。原因是随着 业务规模的高速增长，技术成本问题开始凸显， 我们开始重点优化资源利用率。从资源供应的 角度存在几种形态，比如用纯粹的物理机，这 就意味着切分粒度比较粗，CPU 利用率不高， 如果用虚拟化技术进行隔离，在内网可信环境 中会产生一定的资源损耗和性能消耗。2011 年阿里巴巴开始做容器化技术改造——T4 项 目。容器解决三个核心问题，一是提高部署密度， 二是实现标准化运维，三是轻量级资源隔离。 随着 Docker 的出现，容器镜像的标准化能力 对自动运维产生了更强的推动，使得应用可以 实现标准化交付。基于此，阿里巴巴将 T4 和 Docker 集成，推进更标准化的云原生技术。2015 年，当阿里巴巴的云原生产品技术锤炼 成熟后，就开始推进全面商业化，阿里云推出 EDAS、ACK 等核心产品。在这段时期，阿 里巴巴自身的业务发展也开始全面享受云计算 的红利。比如“双 11”、“双 12”这样的流 量峰值型业务，通过云平台去享受资源池化后 的弹性能力。从 2015 年开始，阿里云开始全 面支持“双 11”电商业务。与此同时，阿里巴 巴开始落地基于容器的统一调度以及统一资源 池，并通过混合部署、分时复用、极致弹性等 技术，实现技术栈的统一、数据的统一，用四年时间让“双 11”的万笔交易资源成本下降了 80%，大幅降低 了技术成本，更好地推进了业务的创新发展。2019 年，对于阿里巴巴而言意义重大。2019 年阿里云支撑了 阿里巴巴“双 11”核心系统 100% 上云，在线业务容器规模 200 万、100% 采用神龙弹性裸金属服务器、计算性价比提升 20%。在 2020 年，阿里云完成了核心系统全面云原生化，云 原生产品开始全面支撑阿里巴巴业务，成为全球最大规模的云原 生实践。这背后的原动力，就是利用云原生的平台、产品、工具， 实现应用和业务“云上生、云上长”，大幅提升资源效率、运维 效率和研发效率。阿里巴巴全面云原生化，就是认准了云原生技 术趋势的未来，利用云原生快速降低技术成本、提升技术效能。 设想一下，如果一家公司有 1 万名工程师，提升 10% 的研发效 率，就能节省 1000 名工程师的人力，1000 名工程师意味着一 个可研发中型产品的团队，这将释放出巨大的生产力，带来更多 的商业创新机会。在云原生时代，云产品的立身之本就是开放标准、快速迭代， 持续具备技术领先优势，持续做先进生产力的代表，赋能客户 的业务创新。目前，阿里云拥有国内最丰富的云原生产品家族， 有超过 300 款的云产品，包括云原生 DevOps、aPaaS& 微 服务、消息和事件驱动、可观测 & 高可用、Serverless 架构， 以及云原生数据库、云原生大数据与 AI、云原生安全能力等。云原生的价值就在于让更多的开发者和企业可以快速利用云的 能力，比如弹性、分布式算力、软硬一体化加速和全 API 服务化， 无需关心底层基础设施，将精力都聚焦在应用层和业务创新上。 云原生技术一定是兼容开放标准、无门槛的，云原生开源让云 计算变得更加标准化。面向开发者社区，我们持续构建开源生 态，把云计算的研发成果回馈给全球顶尖基金会，更好地促进 整个技术生态的发展。我们建设了大量的开源项目，构建开放 标准的技术体系，让更多的开发者使用更先进的云原生技术。今天，阿里巴巴的开源项目总数已经超过 2600 个，涵盖了操作系 统、大数据、数据库、AI、中间件、容器、Serverless、前端 等领域。其中的一些开源项目也成为了该领域的事实标准。比如 Dubbo 已经成为国内影响力最大、使用最广泛的开源微服务框 架;RocketMQ 是国内首个互联网中间件的 Apache 顶级项目， 也是常年霸榜国内前三的开源中间件项目。此外，我们还推出了 应用管理引擎 KubeVela、边缘计算项目 OpenYurt，以及首个 Serverless 开发者平台 Serverless Devs，它也是业内首个支 持主流 Serverless 服务 / 框架的云原生全生命周期管理平台。随着云原生的发展，云计算的使用界面在逐渐上移， Serverless 带来全托管、免运维，极致弹性、快速上线等 特性，让研发人员可以将更多精力投入到业务逻辑中。今 天，Serverless 逐渐成为云计算的主流技术。3 月 25 日， 权威咨询机构 Forrester 发布 2021 年第一季度 FaaS 平台 (Function-As-A-Service Platforms) 评 估 报 告， 阿 里 云 函数计算凭借产品能力全球第一的优势脱颖而出，在八个评测 维度中拿到最高分。阿里云比肩亚马逊成为全球 FaaS 领导者， 这也是首次有国内科技公司进入 FaaS 领导者象限。阿里云对云原生的三个断言 Gartner 报告曾指出，到 2022 年，将有 75% 的全球化企业将 在生产中使用云原生的容器化应用。在企业上云的趋势下，我们 正在看到越来越多的企业和开发者把业务与技术向云原生演进。云原生是云计算的再升级，阿里云对云原生提出了三个断言: 第一，对于云平台而言，云原生将成为云计算的新界面。容 器彻底改变了云的使用方式，它创造了新的架构可能性。容 器化是走向云原生的关键，如果说云原生是一栋大厦，那么 容器化便是这座大厦的地基。容器向上支撑多种应用工作负 载和分布式架构，向下封装基础设施，屏蔽底层架构和异构 环境的差异性，并形成应用打包、镜像分发、交付的标准。 阿里云容器服务 ACK 向下封装了 30 款云产品，对于整个 云平台的交互使用、弹性交付形成了一个新的界面，从而提 升了业务应用的弹性、自动化和韧性。除了弹性释放容器也 向下推动了软硬一体化加速，典型就是“神龙裸金属服务器 +ACK 容器服务”的最佳组合。第二，对于开发者而言，云原生正在重塑整个软件生命周期。我们看到云原生向下延伸推动软硬一体化，向上延伸推动架构 现代化，水平延伸解决研发运维全生命周期的挑战，包括代码 开发、应用框架、DevOps、CICD 流程、运维变更、可观测等。 云原生与开发者的整个开发流程息息相关，每位想不断提升自 身价值和生产力的开发者，都可以找到最完整丰富的云原生工 具和技术产品。第三，对于企业而言，云原生是企业数字创新的最短路径。云 原生对于企业技术演进的价值在于，它可以助力实现基础设施 云化、核心技术互联网化、应用架构现代化、业务数据化智能化。 这些特性给企业带来最直观的业务价值就是资源弹性、系统稳定、应用敏捷、业务智能、可信安全。生长于云原生时代的企业， 可以完全把自己的 IT 体系基于云去构建。数字化创新中的云原生实践 企业数字化创新需要经过三个步骤:IT 基础设施云化，提升 IT 资源利用率、运维效率和用户体验，只有基础设施云化了， 才能让传统 IT 架构变成随需应变的数字化基础设施，才能够 满足前端不断变化的业务需求;核心技术互联网化和架构现代 化，传统 IT 架构实现服务化重构升级，构建低耦合和强韧性 的系统，提升技术可扩展和业务敏捷性，打破数据孤岛，构建 双中台，用数据驱动业务，促进业务的创新发展;应用数据化、 智能化，当管理端、生产端、消费端所有业务打通形成数据化 沉淀后，企业就进入到应用场景的智能化阶段，需要驱动一切 数据的业务化。通过 IoT 技术将物物连接，生产更多的数据， 通过机器学习、人工智能等大数据技术手段，深入挖掘数据的 价值，拓展认知边界，解决过去无法解决的业务洞察和业务创 新问题，找到解决业务问题的数字化钥匙。数字化转型 或许没有统一路径，但经实践检验，云原生是企业实现数字创 新的最短路径，企业沿着“IT 基础设施云化、核心技术互联网化 & 架构现代化、应用数据化智能化”三个步骤，通过因云而 生的云原生，将实现真正的数字化创新落地。

没用ECS之前之前一直使用的是钉钉的内网穿透之HTTP穿透（官网更新时间：2021-06-21）导语部分是这样说的鉴于很多开发者在临时体验开发时往往没有公网域名或者公网IP，本工具提供了一个公网代理服务，目的是方便开发测试。注意：本工具不保证稳定性，仅适用于开发测试阶段，禁止当作公网域名使用。如线上应用使用本工具造成稳定性问题，后果由自己承担。如使用本工具传播违法不良信息，钉钉将追究法律责任。我自己就是用这个，但是这个不是很稳定，人一多，我的网站就相当于是“双十一”一样，还有我们学校宿舍晚上要熄灯不说，而且挂久了会失效。重生之偶遇ESC一次偶然的机会，经过同学介绍，得知了阿里云学生计划，我就有了自己的14天ECS体验，起初最开始的2小时体验是图形化界面，有控制台是linux的操作面板，有一个浏览器，但是我不是很熟悉Linux的操作面板，我选择了宝塔Linux面板，之后就一帆风顺了。给大家看看我的网站培训服务部（这是一个超链接）遇到困难HTML方面基础的还是会的，我用的是Adobe Dreamweaver和Jetbrain Webstorm（学生认证）CSS方面这个有点费脑筋，不过还是勉勉强强，感觉自己像个前端小天才。JavaScript方面糟糕不妙，这个需要函数和逻辑了，加油。GitHub方面之前是很卡，现在找到了加速器，秒开不在话下调用API方面可以学习各大平台的开放平台，学习SDK，小程序等等实例，给自己的网页加了一个音乐播放器。接下来我还会学习什么MySQL接入数据库，让网站不再是花瓶留言板、FAQ等等Vue.js和React等社会目前主流的前端技术，不与社会脱节（人在高校，现读大二未来可期），提高格局。虽然是土木工程专业，但因为热爱，我相信Make it possible and come ture是可以的。