阿里巴巴DevOps落地实践

白凡

我跟大家大概讲一下阿里巴巴的一些经验和做的一些事情。我今天的PPT准备的比较简单，我借一个作为一个引子从各方面跟大家聊，尽量跟大家分享阿里巴巴做DevOps这么多年的故事。

大概分为四块：一开始讲我们现在的问题或者说我们对工具、平台等思考的问题；第二是平台相关的工具的事；第三是讲一下DevOps转型那一段时间发生了什么事，是怎么做的；最后是简单畅想一下未来。

其实阿里巴巴这个公司相对来说比在座各位场景都会简单一些，因为它天生是一个互联网公司，它的架构比较扁平，技术leader一进来的时候，对他的要求就比较高。所以他在做一些转型的时候，相对来说没有那么难，更多是工具的支撑、业务的调整和组织的变化，所以说可能会跟大家有点不一样。

还有一个点是阿里从2008年、2009年开始做微服务，就是服务化切分，那时候阿里阿里过渡成小团队作战的服务。当然我们现在的微服务也没有这么微，因为过了这么多年它又慢慢长大了，又变成中心式的巨型服务。所以团队比较小，小了之后职能必须内聚，也就是说这个团队天然就是全栈的，或者很容易承担自己服务的开发、运维、测试等职责。所以说，这是跟阿里本身的组织文化有关系的。

还有一个契机，前面的老师也讲到了中台。因为阿里巴巴有了中台，所以它打掉了很多“烟囱”。最早的时候天猫和淘宝是两个最大的“烟囱”，虽然它们的业务有高度的重合，但它们都是两波人做的，互相也都有点较劲，包括聚划算也是的。后来硬是通过组织结构调整，把相关的业务组合到一起，慢慢发展到现在的中台。所以说，这个事情也是在一几年左右发生的。当然到今年，他们又提出了电商操作系统，就是把中台做了升级，让它能够有更多的开放性长出其他的业务，这是后话。所以实际上真正到我们开始做DevOps转型的时候，前面这几个契机都已经打牢了，所以后面工具再一配套，技术再一上，就比较容易做到这一点。这是阿里巴巴的历史，所以我刚才说了几个点：微服务、中台再加上工具等配套，这一切才能让阿里巴巴在落地过程中比较顺畅。

我今天主要是讲工具和技术，我们从工具的角度是怎么思考DevOps工具链？

1. 技术管理者的烦恼

首先我们讲技术管理者的烦恼。业务开发工程师天天就是干这种事，就拉分支、本地开发验证、持续集成、合并请求、多环境测试、线上发布，同时还要保证运行的问题，解决日常的答疑、日常的BUG修复，所以这些都是他天天在做的事。可以看到很明显的一个问题，就是他的效率低下在于右边的点：第一，他天天在做重复的工作，如果重复的工作没有一个很好的支撑，这些开发工程师非常痛苦；代码质量不能保证，这是技术债务。但是对于阿里巴巴电商公司来说不像在座金融公司对质量要求那么高，说实话它有很多的手段去避免线上出现问题，比如它可以做灰度，搞一小波人的流量进来，可以搞内部众测，可以快速回滚或者说异地多活可以切流，所以它有很多办法将控制面控制在千分之一甚至万分之一的影响面。所以说，它对质量的话，相对来说要求没那么高。

所以说对于阿里巴巴来说，它是一个业务先行，就是业务一定要跑的快的公司，跟金融属性的公司可能不太一样。还有测试环境稳定性，一个庞大的系统，我们现在有5万多活跃应用，已经组成了一个网状的依赖的结构，测试环境是一个非常大的问题，只要这个链路上有一个服务有问题，大家就玩不了，天天都在沟通协调。线上环境稳定性就是我刚才说的，据统计线上工程师大概有20%的时间在处理线上问题，就是各种各样的稳定性问题、高可用问题、缺陷，当然不会出现大缺陷，前几天支付宝的那种大的缺陷（挂了20分钟），这种大缺陷很少出现，几年才出现一次，而我们可以通过灰度发布的手段让缺陷控制在一定比例，但还是有很多缺陷；还有是体验问题，就是你做的日常工作都分散在各种平台，这边有操作员，那边有操作员，数据对不齐，有一系列的问题。这是他本身比较痛苦的事情，这些事情导致开发工程师的效率低。

但对技术管理者又考虑另外一个问题：第一是研发流程混乱。公司大了以后，每个团队都会自己搞一套研发的方法，其实这就很痛苦，第一是新人的加入怎么弄，新人会转岗到其他的团队，他们的流程研发和要求，就是我们刚才所讲的分支希望管理模式、上线的流程、人与人之间的沟通方法都不一样，怎么办？集团肯定要统一；环境管理低效是我刚才讲过的；还有资源浪费，你肯定要控制他的资源使用量，比如说这个应用到底是活跃应用还是非活跃应用，如果是非活跃应用要使用什么样的规格；还有是开源工具要畅通，否则无法做研发工具效能度量。

其实我们做这些事情很简单，我们一直都是要看业界最先进的理念和方法到底是什么。所以最近几年比较火的是持续交付和云计算，当然持续交付可以换成DevOps。这是我简单的数据，大家随便看好了。其实我们现在在公有云来看，绝大部分企业都已上云，80%几，但现在真正的DevOps公司并没有那么多。我做公有云，我在中小公司去看，虽然大量的公司都已经是互联网的情况，但实际上不是真正的DevOps。前面几位嘉宾讲整个发布上线流程都能贯通、都能做研发度量等等，其实都不是的，还有很多中小公司出去守观望状，这是现在的业界状态，所以我认为27%的数字还是有一定的代表性和准确性。还有是我们整体的效能，其实现在并不是特别高，也就是说其实现在48%的团队处于高效能，我们认为这个高性能不是特别高，只是说精英团队是我们追求的高效能，也就是说他一个小时发一个版本，一天可以进行一次发布，类似一个小时能解决一个故障，这都定义为精英团队。

再看一下持续交付和DevOps的概念。持续交付最核心的是要做到小批量的发布上线，其实做成小批量发布上线挺难的，前面几个嘉宾说几个月发一次，虽然能所谓的一个月出一次，但实际上阿里巴巴很多年前就已做到每天可以发多个版本，因为每天发多个版本，可以让我们很多事情变得简单。比如说分支管理策略就可以变得非常简单，因为它不会存在大量的并行分支，也不会出现长期分支，也就会导致它不需要频繁地从Master进入合并代码，比如说前面一个月发了一个分支，发布上线，后面还要再开发第二个月的版本的时候，我就不得不把前面一个月的代码合并过来，这种繁琐的代码管理在阿里不存在。因为大家发的快，所以有很多问题解决了。当然，业界还会讲，比如我们做主干开发，大家都往Master上合，基于主干开发，但这对工程的技术实力要求非常高，很少有团队做到。因为你一旦合进去代码，往外剥离就很难；还有是你一旦合进去，代码质量不高，你把主干搞挂了，主干永远发布不了。所以阿里巴巴没有采用主干开发，而是采用分支开发，但是为什么分支开发能这么流行？就是因为它能做到小批量。我们核心团队大概每周发两次，像我们这种云的平台可以按需发布，bugfix当天上，大功能一周发两次。只要做到小批量，很多工作就会变简单。

讲到DevOps，这个概念就比较复杂了，它可能代表了一种文化、代表一种组织，但实际上其实跟最近几年我们所谓的协作模式的变化有关系，我从另外一个角度来讲这件事情。实际上我们发现现在阿里巴巴越来越变得轻协作，就是一个人可以搞定一件事。比如我们最近几年提的全栈工程师，这个意思就是是一个人前面、后面都可以搞。第二个是微服务，就是这个服务一两个人三四个人负责，这一个人就可以搞定这件事。还有我们这几年讲的函数，我们把微服务下一级，把一个需求或者一个功能变成了一个函数，就是函数计算的概念。我们集团做的前端开发，他们就是用service技术实现了一个前端开发，可以把前端逻辑和后端逻辑都写了，以前前端开发只能写页面的JS部分，但是他现在可以把前端和后端逻辑都写了，并不需要关心服务器运维的事。所以这些事情都指向轻协作。阿里巴巴实际的数据统计也证明了这一点，我们有50%的人都是应用，他所涉及的人都是在7个人以内。我们有5万多个应用，有50%的应用都是7个以内的人在维护应用；另外，我们一次发布变更的数量是1.5（平均），也就是说你认为一个半，基本上没有什么集成，我发了，我的单需求就上了，因为它快。所以随着微服务拆分、随着快速迭代，协作的密度降低了，我不需要跟别人协作，我一个人就可以搞定。我一个人搞定了，我在运维、在写前端代码和写后端代码，再加上运维，这个事如果我还跟别人有交集的话，这个协作还是很重的，所以大家都在推DevOps、推全栈，就是我可以搞定一个人的需求，也可以搞定端到端的事，你会发现这个效率变高了，就是不依赖于别人。所以这是我们从现在整体的趋势的另外一个解读，就是所有的技术都在指向协作越来越轻、效率越来越高，就是一个人可以搞定一件事。所以说最终就会变成两个词，我们都是为了效率和成本做事情。

2. 阿里巴巴工具体系

再讲一下阿里巴巴工具体系。其实我们经历了这么多的阶段，主要是从2009年开始的微服务时代、容器化时代和云原生时代。从2009年开始成立团队，我是2015年来的，但是2009年我们这个工具和平台就开始做。
那为什么要做这件事？因为它做了微服务拆分，我们常见企业里面会有一个配管角色，专门做打包发布，还有PE（运维人员）专门做发布和运维，这些人就会成为瓶颈，这些人搞不定了，应用越来越多，所以我们必须做自动化发布工具。

到2013年的时候，应用爆发式增长，这些团队已经不能手工做这件事，所以就要构建一个平台。到2016年的时候容器化浪潮来了，所以我们借机会直接通过容器化技术，把运维的事直接切给开发。所以我们当时做了运维转型，组织上觉得运维角色功能，原来只做线上运维的事，第一他也做不好了，他管的东西太多了，第二他的技术空间出现瓶颈，所以这些人要进行技能转型，他可能要变成一个规模化运维，变成全栈稳定性保障的角色，所以他不需要做手工的事，他就把手工的事物全部用工具代替或者下放给开发做了，所以这就是所谓的DevOps转型。当时组织上的做法比较粗暴，就是这个团队职能变化，划掉，业务直接一刀切，就不用管了。那怎么办？在这个时候我们的工具基本上也具备能力了，所以开发顺理成章地接受了。其实这个事在当时有一个矛盾点，以我的例子告诉大家，我当时遇到了一个问题，他们开的线上数只有200，但是我现在想把线上数扩大一点，因为当时CPM跑满了，我认为还可以再扩大到300，那时候我找PE让他帮我做线上变更，但他一个人管的东西太多了，他不愿意帮我做线上变更，他认为你自己顶着，又没有挂。但实际上我破了300以后不用加机器了，但是他宁愿给我加机器，都不愿意给我改配置。所以你会发现那时候开发和运维之间已经有矛盾出现了。

大家也觉得效率太低了，有矛盾了，PE又都成瓶颈了，PE觉得自己本身的工作成长慢慢变小了。刚好组织下了这个决定，所有的事情都顺理成章了，所以那时候有这样的契机。所以我们当时做容器化、做docker改造，让大家接管线上运维，其实并没有遇到太大的组织上的阻力，开发觉得很自然，而且他是梦寐以求的觉得我终于能改线上了，我终于改配置不用找别人了，他们还觉得很爽。所以我在2015年来的时候就做DevOps平台，把所有的线上工作全部交给开发，这都是我们做的。所以说，我还是比较有体感的。

到了2017年，我们后面要搞云原生。我后面专门有一块跟大家讲一下云原生的事情，还有我们自己的展望，我们现在主要聚焦在下一代的软件研发平台。

后面讲几个技术细节。这是我们内部比较流行的分支研发模式，我们会给每一个需求开分支，分支都要关联一个需求，来看每一个需求上写的代码量。每一个分支上，系统会把合并的工作自动化掉，所以他也不需要管什么Master、Release，我们的平台全部包干了，他只需要选择一个分支进行提交发布，它就可以自动化跑了。提交到日常环境发布、提交到预发环境发布、提交到正式环境发布都可以的。提交发布完了以后，我们还可以自动打tag，如果它出现了线上的回滚，我们还可以自动把分支回滚掉，所以这些全部做到系统里，这是我们跟开源软件非常不一样的地方。开源软件很有可能只管到分支、触发、流水线，这样就结束了，而我们在上面做了一层研发模式，我们会把GitFlow的模式和分支研发的模式全部固化在系统里，或者说产品化掉。所以说做完这个事以后，阿里开发出去以后就有点不适应，因为他要管理这些东西，还要制定规则，而且还容易经常搞错。在内部就比较简单，他只需要干两件事：第一针对需求拉分支，第二把分支提交到相应的流程里，其他的他都不用管。所以在内部，有点像保姆式。当然它有好处，集团内80%都用同一种研发模式，所以他们去转岗或者去开发业务都非常熟悉，不会出现错误。这是我说的这三点，比较规范、高效和避免错误。

研发模式固定了以后，技术栈也要统一。阿里巴巴一直坚持统一这件事，所以为什么中台做的比较好？它通过行政力量规定了所有的BU全部都要使用同一套技术，这是在业界绝无仅有的。这么大的规模，还能做到统一技术。你说痛不痛？肯定有痛，比如饿了么合并到集团，今年正在做改造，他原来用Python写的，全部要改成JAVA。所以只要是任何公司进入阿里集团，都要适配阿里技术栈。当然我们后面基于云计算走的时候，基于阿里云走的时候，这些问题就慢慢解掉了。之所以没解掉，实际上就是因为我们的技术没达到，所以才导致我现在搞了一个JAVA的大而全的技术栈，别人只能遵守。所以说所有收购公司，必须遵守阿里巴巴统一技术栈，这是底线。所以一个收购的公司进来，我们的研发平台先上，先把它的代码接管了，先把它的研发流程接管了，它的技术栈必须改，改完了上平台，然后就结束了。后面的话，所有的工具都用上了。所以这张图就是给大家介绍的：第一是研发模式，代码虽然是多语言，但多语言都是接入阿里巴巴技术栈，尤其是中间件和容器；第二，运维模板都是固定的，虽然我们也开放给开发定制，但基本上很少定制，基本上我们定制几套就结束了；还有运维模板、应用运维、系统软件，这些都用云了。

全云化测试平台。我们在阿里巴巴的测试工具有很多，有搞UI、搞算法、搞回放测试、要运维推荐、数据测试等有很多，但所有的执行引擎是一个。这些测试工具都会作为插件一样插到平台上，其他BU都可以共享，尤其是测试工具都可以共享，所以在我们集团有一个通用的全域化的测试平台。简单来说UT、代码扫描、安全测试等都是统一的，越往上越不统一，比如数据测试、UI测试，这都是他们自己做的。所以我们内部的开发并不需要关心下面运行测试运营的实体和运营的机器。很早以前，集团内部给开发者的体验就是一个云化的体验。但我们现在上到云以后带来的新变化是他可以选择更多的云产品，但内部就只有一套。

讲完测试平台，还有一个测试环境隔离技术，我们在一些大会上也讲过。其实这是阿里比较有特色的东西，我们为了减少环境的浪费、资源的浪费，我们需要给每一个开发提供独立的开发环境，而且这个开发环境又能力连接到我们的基础环境进行环境的复用。这里面的核心，除了环境是动态的，谁申请、谁有，还可以释放掉，就是不浪费。每一个环境都跟特性分支相关，就是你开发这个需求，申请一个分支，你就可以拉一个环境搞。还有最主要的是流量都控制、流量的隔离技术，就是说从你指定的开发发起的请求全部都会进入你的环境中，比如隔离环境A1、B1、C1，如果前面还有一个D1，它是基础环境，这样也可以的，就是说我们能做到不管你前面有多少个服务、后面有多少个服务，你是中间一环，我也能做到精确地从你开发机出来的流量能够打到分支部署的环境里面，其实这是一个流量控制技术。因为有了流量控制技术，你就可以给每个人提供一个独立的环境，我们的测试同学或者专门有一些保障环境稳定性的同学只需要维护基础环境的稳定性。我们还有很多降级的功能，比如我们会有多个环境来保证它的高可用。其实我们现在越来越像治理线上环境一样治理线下环境，因为所有的开发效率都是堵在基础环境，所以这里效率低的话，开发特别头疼，这是我们比较有特色的技术。

我们以前为什么没有把这个技术开放到外界？是因为这个技术是强耦合了阿里巴巴内部的技术栈，也就是整个中间件体系和运维体系。但是在云原生的条件下，就是在云上，我们现在正在将最佳实践落地到云上，用云原生的开源的技术栈来实现它，能达到同样的效果，这是我们正在做的事情。所以这个做好以后，大家就可以在云上使用我们的产品。

最后把所有的东西串起来，跟我们看到的就没有太大的差别了。这是我们开发工程师常见的事，首先是开发应用，我给他推荐你要什么流程模板、技术栈、流水线，你要申请什么资源，全部都弄好，就是脚手架这一块从创建开始搞定，所有流程定了之后就写代码给你推，我会根据你不同的语言给你匹配不同的工具，这些是自动的。完了以后，我也帮你初始化好了你的环境，你就可以在这里面发布你的应用。因为运维模板也是我推荐给你的，你也不用关心了。我们的开发，虽然你是阿里巴巴工程师，但现在很多开发都不会写dockerfile，虽然我们都是全容器化，就是因为他不需要改，他为什么要关心这件事情。有很多人对怎么构建、怎么测试也不太清楚的，实际上这是通过工具把他们的技术认知门槛拉的很低了，当然未来上云以后会更低。另外是上线有很多卡点，包括测试卡点和发布窗口。部署过程会有很多灰度的策略。

3. 阿里DevOps落地

前面大概讲了工具，我们后面再结合工具讲一下我们在DevOps落地时候的思考以及我们为什么能觉得我们能做成这件事。
第一，阿里巴巴给DevOps转型做了很好的技术，我们一直以应用为中心的DevOps理念。这个理念虽然会觉得很重，你干一件事都要有一个应用，而不是从代码出发。我们普遍的认知，大家就是说现在有一个代码库写代码测试，最后要发布了再申请线上。但实际上在阿里是反着的，我们干一件事是先申请应用，也就是说所有的代码都是为了上线准备的，其实这是有点重的，这一点不好。但好的方面是因为我从一开始就有应用，所以说开发对应用的概念已经印到骨子里了。应用周边所有的东西都围着应用转，比如环境、测试规则、发布流程、代码、资源，还有最外面一堆运维保障平台，都是以应用原数据来的。所以，用这个东西打通阿里巴巴所有的工具链，比如我这里要建一个应用，我要发淘宝的前端，发到云上。没问题，我先写一个代码关联到应用，再给应用申请几个资源，流水线好了以后就发。发完了以后有报警，就到故障平台查，拿应用去申请DB，数据库会自动给我的应用进行授权，因为别的应用不能访问，所有的监控信息都挂在应用上，所有的中间件配置都是按照应用规则去配置的，可见应用还是很有用的。

所以说阿里巴巴在过去很多年就是以运维的视角在做开发，所以我们在做转型就比较容易了，所以说以应用串联整个DevOps链，另外一句话是开发定义应用，同时定义运维。

其实我们在做DevOps落地的时候做了很简单的事，以前的应用定义不是开发定的，是配管和运维同学定的，我们就是很简单粗暴的把应用开放给开发，让开发定义应用，让开发做上线流程，就成了开发定义应用，同时他就去定义运维了。还有一点简单粗暴的是开发为整个生命周期负责，因为工具化体系建设比较顺的情况下，他天然就可以接受这一点，因为所有的东西本身就是他管的，只不过工具做的好，他不需要有什么样的支持。比如他去监控平台，监控都帮他配好了，他只需要看一下就些行了，他不需要太多的知识和付出，就可以享受到DevOps的便利。所以，我们通过比较完善的工具，能够让他享受便利，而减少他认为这个工作是推给我，我对这个就有抗拒，就是把这样的工作做到最低，所以我们做这样的事就没有什么阻力。

这是我刚刚说的应用上线的全流程。可以看到像一个商业任务，从一开始创建任务，到后面初始化、推荐配置、构建配置、测试环境申请到最后的上线，你走完应用发布，你的代码就上线了，外部就可以看了。所以你只要走完这个流程，基本上DevOps的事就归你了，你后面就为它负责了。

还有是容器化的事。现在大家都在讲云原生，云原生是后一趴的事，我们在云原生之前要先做好容器化。因为容器化，所以让运维的复杂度降低了，这是非常大的受益。复杂度降低了，才能让开发接受这个事。大家可以看到我画的图，我们把很多事情全部用dockerfile替代以后，这件事情就全部是开发做了。常见的运维脚本，我们全部交给了工具开发的角色，有一部分PE（运维同学）转变成工具开发，还有我们，这两波人加起来做工具。然后他们会做规模化运营，所谓的规模化运营就是不太区分具体应用的运维，我们都叫做规模化运维，这些人会做规模化运维，通过命令通道下发批量的百万台机器。应用开发只需要关注应用运维，就是应用的容量够不够、需要扩缩容、怎么发布以及到报警怎么设，这都是应用开发。

工具开发，我刚刚说了它只管批量化运维。后面还有调度开发和规模化运维的角色，这就是SRE的角色。还有一个是所谓的容器平台的开发，这两个角色现在是在一起的，甚至是一个团队的。他们这些人管的是什么？管成本，比如阿里巴巴做过在离线混布，就是把在线的机器和离线大数据的机器能够放在一起跑，就是在线的应用可以跑到离线的大数据计算的机器上，这些全部都是交给规模化运维调度开发来做的。因为有了容器化，就是有了业界所谓的“牲畜”，所有的应用都可以是牲畜，牲畜可以被随意杀死，可以在随意一个地方拉起，所以可以随意漂移。所以因为有了容器化技术，这帮人够可以面对成本做很多的事。比如我给你动态扩缩，比如容量评估，比如在离线分布，甚至CPU share，就是一台物理机所有的机器都是共享cpu，类似这样的工作都由他们来做，而且对开发无感。开发不关心这些东西，开发说你不要把应用搞挂就行，其他的随便你。因为这些转变，有两个角色解耦掉了：一个是开发，他只关心使用工具，另外一波人是面向基础设施来做。所以说这个事，就解耦掉了我们整块关心成本的人和解耦掉了关心效率的人，开发是关心效率的，下面人关心成本，这两部分人的工作解耦掉了，不会互相依赖。以前的做法是这帮运维要干什么事，先要开发同意，开发不同意，说这个业务不能弄，我的稳定性要求非常高，我就不能动了。

阿里巴巴还有一个重大的契机，就是做了异地多活。大家感觉异地多活是为容灾做的，实际它还有一个非常大的功效：这个东西解耦掉了基础设施部分的开发和业务的两个角色。怎么理解？以前所有的基础设施变更，比如说网络要做变更，服务器要做变更，其实我是不太敢的，因为它没有多活，我随便发一个变更就搞挂了，故障太大了，背不起，所以这部分人都是缩手缩脚的。但是有了异地多活就不一样了，我就找一个机房，我先在这儿上，出了事，几秒钟切走，相当而言他敢干了，他做任何网络变更都可以找到一个实验田，出了事就是切流。所以阿里巴巴第一故障恢复的手段不是回滚，而是切流。上次支付宝的故障也是因为切流才恢复的。所以我们把异地活叫做非常大的架构变更，就是因为它解耦了一些事。

再讲一下云原生，云原生解耦了云开发、工具开发和开发者，这两个角色解耦掉了。以前中间件做了SDK，要让开发用，我得教你、培训你，你在你的代码里敲耦合这些东西，所以这两个是耦合的状态。因为云计算以后，他只需要调用云服务的标准，下面的中间件该怎么变、运维怎么变？上面的业务开发都不感知了，所以说这是云原生。实际上我们在软件工程领域一直在做解耦的事，就是不断地把开发的工作下沉掉，下沉到基础设施去做，不断下沉，把这两个人关系解耦掉，才能让整个技术快速发展。

最后讲理念上的事情。我想过很多理念，但是我觉得这个理念是阿里巴巴只所以做DevOps这么快的非常重要的东西，实际上我们就是松管控和强卡点。什么叫松管控？如果你的管控力度非常强，开发完全不能动线上环境，DevOps落地肯定很难。因为DevOps要让一个人全干了，所以你不能对他做松。比如我们在2016年以前所有的核心应用上线都是要PE审批，运维不审批你就不能上，他会review这些东西。后来2016内部有了很大范围的讨论，我们觉得转型的时机到了，我们把所有核心应用的审批全部去了，开发可以直接发上线，只要你遵守时间要求，比如要求周二周四几点到几点发，你到了那个时间窗口就可以随便发。当初我们去掉的时候也担心会不会出事，结果去掉之后，没有人关心这个事，也没有人反弹，也没有人出事，所以我们发现这个路子走对了——松管控，我们平台到现在一直坚守这个理念。当然，这是根据不同企业的特性不一样，金融企业像蚂蚁还是强管控的，但是除了蚂蚁以外所有全部都是松管控。你可以选择你的流水线类型，你可以选择你的规则、选择你的构建规则，你可以随便发，但你只要是经过灰度的，能够有快速恢复的工具，因为我们的工具做得好，秒级回滚的能力、秒级切流的能力、异地容灾的能力都有了以后，你出了事就可以切，所以出了事也不是特别关心。

右边强卡点是要坚持的，这是集团最近几年越来越坚持的事情，代码审核、质量红线，我们做的代码规约也可以认为是一种质量红线，包括单测覆盖率等等都有很多团队在追。其实阿里巴巴从单测覆盖率、单测成功率来讲，做的并不比在座各位公司强。其实阿里巴巴是属于一个要跑得快的公司，所以这部分的历史债务很重，当然最近几年也在追。我刚才说的代码检查、代码规约，这是一定要追的，不能有block的东西。还要是要坚持发布、封网窗口，比如大促的封网，我们现在能做到在一个规则平台上配，所有集团几百个变更平台全部都不能变更，这是这几年重点在再的。还有一些发布计划的事。

下面写了我对于理念的总结，其实我认为持续交付的核心就是要快速交付，如果你要卡着让它变慢，它一定没有办法做到快速交付，不能做到快速交付，很多的研发过程的问题就会暴露出来，复杂度就会变大。所以，轻协作是我们追求的目标。
而在这个趋势下，我们一定要给开发最大的自由度。负责开发和运维的全部过程，这是我们工具平台一直坚持了理念。我们要做什么？在监控、故障防控工具、功能开关的配合下，可以在保障用户体验和快速交付价值之间找到平衡点。比如我现在通过AI的技术，通过算法，我去自动判断你发布了一部分机器以后它上面会不会有异常日志、有没有监控值的波动，我通过工具帮你进行防控。你出现问题，可以快速回滚或者快速把功能下掉，这是要求开发必须有的能力。通过一系列的保障，最终保障我们没有什么大的故障，你有小问题，但不会成为主流问题。从业务视角来讲，这是最好的结果，就是有一点小问题没有关系，但是业务一定要跑的快，因为市场不等人。

4. DevOps未来

前面讲的工具核心理念以及落地想法和过程，最后畅想一下未来，这也是我们最近一年思考比较多的东西。第一，我要讲云原生。我刚刚讲云时代已经到来了，我认为DevOps下一个场景就是要往云原生做。云原生是一种技术，但实际上它现在慢慢变成了一种理念，也就是说你完全使用云来进行开发应用程序，好像就是云原生，但这个云不一定是公有云，私有云也是云，混合云也是云，公有云也是云，但你要使用云的技术来进行技术开发、应用程序，你就会变成云原生。

传统应用和云原生开发有什么样的区别？我这边做了对比。可以看到原来开发者需要关注所有细节，要关注中间件怎么做、服务方向怎么做，还有虚拟机在哪儿、机房是什么情况甚至都要关心操作系统，开发是要全链路关注的。但是，人的精力有限，要不然就是开发很贵，要不然开发做不好，因为他要关注太多东西，效率很低。而且这个东西是非标的技术栈，比如阿里巴巴搞一套，腾讯搞一套，百度搞一套，但是都不一样，这是很麻烦的事。

但是在云原生时代，这件事情发生了质的变化。云原生一直倡导的理念：开发者仅关注业务逻辑，除了业务逻辑，其他的东西尽量都往基础设施沉，都标准化掉。比如我们最近说K8S，其实K8S就是标准的技术栈，这些技术包括后面的CNCF的标准技术，其实它都是开源承认了，而且它的马太效应非常强，一旦出现一个巨头，其他的全部都干了，这是现在业界的技术趋势，所以大家都在抢标准成为技术巨头，包括阿里巴巴和腾讯都在抢。谁成为技术标准核心的leader，谁就掌握下一个时代的技术发言权。原来docker出来的时候是docker企业版，K8S出来以后全杀死了，所有人全干掉，这就是一个非常不一样的东西。还有数据规范性会变好，统一的API开放性会变好。这边的图，就是说开发了以后只关心的上面的这一块，就是应用层的应用逻辑开发。到了下面，直接不需要关心服务，直接都是本地调用，对他的感觉就是全部调本地我不关心云在哪儿，就会发现所有的开发又回到了十年前开发单机程序的感觉。所以我们内部就在讲我们要把所有开发的行为回到十年前，开发巨型应用、开发本地应用的感觉。因为我们会发现原来开发本地应用是那么快，本地起来就能够跑，单体应用什么都不依赖，效率非常高，现在又要慢慢回去了。从Service Mesh以下都是云，开发不需要关心在哪儿，只需要调用，然后就会出现普惠的机会和智能的机会。

这是我写的我认为未来影响开发者的三大工具体系：1.Cloud IDE，这是离开发者最近的。我下面总结是不关心在哪里开发，他用了工具以后，这个工具跟本地ID有什么区别？有几个区别：

第一，他不需要关心环境，不需要依赖本地环境，环境都是标准化的；
第二云IDE的迭代速度远远大于本地IDE，因为技术栈都不一样，我们现在写的就是网页版，而网页的迭代速度？我以前发一个本地IDE插件，需要所有人都推一遍，很慢，还要开发者自己升级，而以后在云上全部升级掉了，所以它的开发工具的迭代速度会非常快，当然能够给开发者带来的体验会非常好，很容易定制。每一种语言，每一种技术栈，每一个企业的基础设施什么样，他有什么用户习惯，都可以做定制，而且非常快，甚至一个外包前端的工程师都可以做工具，以前他们做IDE插件还是有门槛，所以这个东西可以改变很多东西，而且有大量的数据和智能的应用可以用，它都是在云上跑，实时算开发者的行为和开发者需要的东西，比如做代码推荐、缺陷智能预测等类似的数据应用；

2.运行态。我们认为叫做不关心调用到哪里，它全部像本地开发。所以这里会积累非常多的数据，比如说服务注册数据、调用链路数据全部在云上，标准化了，这些数据都有非常大的价值，我们可以去挖掘；3.运维态，我们现在讲DevOps，以后会不会变成NevOps，就是你都不用管了。其实工具慢慢发展以后，开发需要关心的东西越来越少了，实际上就不需要关心关心机器在哪里，所有的东西都是工具和智能化软件帮你算了。其实慢慢的是工具代替人。其实我们现在内部已经有一些了。所以这一块总结亮点：一是关注点转移，所谓的DevOps，后面Ops不用管了，关注点变了；二是关注业务逻辑，他更关注业务创新，这是越来越快；对平台工具层就是全部标准化数据，从开发到全链路都在云上，很容易标准化。这是我对未来技术和方向的一些畅想。

我们现在正在走向云+智能时代，我简单讲一下我们现在做的智能化应用。我把这儿分成两部分：单点效率，就是要解决开发工程师天天在干的事；协作效率，更多是技术管理者关心的。单点效率，比如我现在写代码的时候可以自动化帮我推荐成块的代码，这是数据算出来的。比如我写一个文件操作的时候，它可以把常见的文件操作算法推荐给我，我只需要在上面删除一些，经过修修改改就好了，效率非常高；

第二是智能代码评审，我有很多智能化的应用，比如说自动推荐，谁来帮你评审最合适、你需要多长时间、上面有什么缺陷、你有多少影响性能的问题，都是机器算出来的，它会根据线上的数据和你自己原来代码的数据以及历史上别人评价的数据进行计算，来给你一个评审意见，就是机器慢慢辅助人。我觉得AI永远不会代替人，但可以辅助；

还有敏感信息扫描，就是我帮你扫你现在的代码里面有没有暴露特殊的密钥，因为我们发现这个东西对企业非常重要。一旦出现密钥泄露，被别人拿到你的软件包，对公司来说就是致命打击，因为它会丢失核心数据。所以使用代码源头，它会帮你扫掉，这些东西都是用算法扫的，不是规则匹配的；

还有发布风险控制，就是我刚刚说的发布完以后，我自动化帮你对比发布前、发布后的情况，你在发布过程中自动帮你阻断，比如你现在发布有问题，你要等一等，或者你要看什么报警项，然后再决定是否往下发。

在协作这一块分为几点：出现故障之后链路怎么排查，像微服务的链路非常长，我们通过服务图谱，就是将一些开发的数据、线上运行数据、服务关联数据、链路数据、机器运维数据全部都组成一个知识图谱，对它整个出现的故障点，根据图谱进行搜索，来判断故障源头到底在哪里，当然业界有很多人在做，包括在金融领域推的很广；还有业务全景监控，就是站在整个业务视角下，整个链路成本、效率、稳定性是怎样的；代码搜索是开发工程师要学习别人的代码，要检索别人的代码；还有代码分享，有好的代码可以呈现出来，分享给其他。

这是我们现在正在做的事，对未来的畅想，以及我们认为未来开发平台应该长成什么样，还有历史上阿里巴巴落地的经验，大概就是这些。