云原生 DevOps，助力企业上云

7x24 小时连轴转已成为运维工程师的常态，故而每年的 7 月 24 日被视为运维日。为致敬运维人，打造开放的运维技术生态，近日 CODING、腾讯云以及 TEG 技术工程事业群联合在深圳举办了首届腾讯运维技术开放日。来自腾讯和 CODING 的运维专家，与五百余名运维爱好者一起，分享交流了云计算时代，腾讯运维的技术沉淀和实践经验。

CODING CEO 张海龙先生发表了名为《云原生 DevOps，助力企业上云》的开场主题演讲，在他看来，企业除了服务器的上云，更需要架构的变革，以充分享用云所带来的如扩充能力、监控能力、云的数据库能力、云的缓存能力等多种能力。“我们现在也在和腾讯一起合作，做很多 DevOps 的产品，帮助一些企业上云，我们希望做到真的上云，是云原生。”

广泛的使用云厂商提供的 PaaS 及 SaaS 服务，使用工具替代人肉运维，将会大大提升研发团队的发版速度，做到一天数十次的版本发布，以便快速响应市场需求，持续交付高标准产品。从目前的客户案例来看，CODING 和腾讯云为客户提供的 DevOps+ 云能力，给客户带来了至少 200% 的效率增长。

演讲全文及现场视频

我今天要讲的话题与开发和运维都有关系，更多的是说我们将来这两个角色会是怎样的一个发展，以及从新的运维环境出发，运维该怎样发展？

现在有一个很热门的话题叫做上云，但是很多上云是伪上云，不是真的上云。只是把服务器搬到了云上而已，但是你所有的体系架构，所有的技术栈都是一模一样的。这种上云就叫伪上云，它并不是真正的云。

所以现在提出一个概念叫做云原生。真正的上云是说你要用到云计算的很多能力，比如说扩缩容能力，比如说监控能力，比如说云的数据库、缓存能力，云的各种存储能力，而不是说我只买了一个云服务器，所有东西都自己做，那不是真的上云。所以，我们现在跟腾讯一起合作做 DevOps 的产品，是通过云原生的方式帮助企业做上云的工作，上真正的云。

那么为什么要上云？因为企业数字化转型面临很多问题，很多新的技术、新的想法，需要快速实现，否则就会被市场淘汰掉。所以软件的复杂度、软件的稳定性、软件的上线速度尤其重要，但是现在很多企业一个月发一个版本。在云时代，云厂商希望能够通过底层基础设施，为企业提供一站式服务，让企业更专注，包括采用新的研发流水线、新的研发组织关系，来实现创新的快速迭代。

云计算时代的几个大的变迁，第一是资源时代，叫做 Hardwareless，大家再也不用扛服务器了，都变成了虚拟机，这就是我刚刚讲的伪上云，因为它只起了替代作用。再往上是现在很火的容器，OSless，用容器你不用关心底层的这些东西。再往上，云一定会迈入功能时代，你不再关注资源，这就是现在流行的 Serverless。从 Hardwareless、OSless 到 Serverless，这是一个更先进的理念。目前很多人都还停留在前两个阶段上。

伪上云的企业软件架构没有变，最早的是叫单体架构，所有的代码在一个系统里，就一个软件发布上线。那个时候运维的工作很重，还要保障软件的正常运行，各种代码的合并，重复的检查，都是运维要去干的事情。再往后可能年纪稍微大一点的开发都知道有个 SOA 架构（Service-Oriented Architecture），这是第二代。其实现在很少人在用这一代架构，老的企业可能会用这一架构。再往后比较新的是微服务架构，把一个大的系统按单体拆成一百个微服务，每个服务装在一个容器的集群里互不影响。这样就不再需要关注服务器在哪里，有没有资源，只要写代码就可以了。所以真正的云原生时代就在后面这两个架构体系。上云不光只是用上云，而是把架构也变成云原生架构。但这可能对很多运维岗的同学不太友好，因为用了云原生之后不用关注运行环境，扩充容，流量，全部都不用管，这意味着运维的技术一定会越来越深入，但普通的运维岗会被替代掉，我只要写代码的人就可以了，而且不会有闲置资源，用多少付多少，现在很多新的项目已经在用这样的架构，从不同维度给企业带来了很多好处。

在采用传统单体架构的时候，往往需要一个大的运维团队，不同的研发团队只有一个代码库，每周固定时间封版，运维团队开始构建。而这个时候，所有的问题、代码的冲突、构建编译不通过等等，都在这个时候被发现，运维的压力就很大了，出现问题还会相互影响。比如说两个团队都合并进去了，发现一边有 bug，要先定位然后等待 bug 被修复，这期间另一个团队的发展就会受到影响。所以这个时候会出现很多研发团队之间的矛盾，以及研发和运维之间的矛盾，迫使我们只能降低研发速度。所以为什么传统的单体架构只能一个月发一次，是因为它只能这样。

微服务架构就很好地解决了这个问题。云原生时代有三剑客：微服务、容器和 DevOps。一个大项目拆成了无数小项目后，微型服务团队之间完全是隔离的。团队可以自行测试、编译、构建结束后直接发版，整条线相互平行。这个时候运维干什么？运维就要把这个流水线给它做通了，你不需要帮助别人去发版，但是要提供一个工具，让别人能够自己发版，这就是运维干的活。所以对运维来说，人数变少了，但是要求变高了，普通的运维在这个环节已经被干掉。

采用微服务架构以后，需要 DevOps 来维持，需要那整个研发团队往 DevOps 方向转变，让你的运维和研发更高效更稳定，所以需要精简的组织架构。其实很多企业包括银行、政企事业单位，军工企业，他们都在关注 DevOps，但是跟他们交流时会发现，他们对 DevOps 的认知还停留在我是不是买了你这一套系统或者设备就能实践 DevOps 了的阶段。

这其实是不对的。本质上我们要去做的是人和组织的事儿，技术只在上图左下角这一块。我卖一套系统并不能保证客户就真的能够很好地用起来这个研发模式，因为它需要有人的影响，比如说我们需要的是一个全栈团队，团队的人不光要写后端的，前端你也得会，从前到后要在一个团队里形成闭环。

第二个比较重要的是与人相关的 —— 企业的领导方式。很多公司的领导方式依然是从上至下驱动。而在微型团队当中，团队遇到问题需要资源时再去找领导解决，这叫仆人式领导。我们在做微服务拆分时也发现了重要的一点：你要让团队做到内部闭环，让团队有自驱力、有责任心。

关于文化，最重要的是信任文化。这一点在互联网公司做的相对比较好。信任这件事情在深圳这样的一线城市可能觉得没有什么大不了，研发团队应该都能看到代码。但在中国，大量企业会把一个代码库分割成好几部分，每个部分由不同的人负责，每个部分是不能单独编译通过的，其目的是为了安全管控。这种文化下自然是难以实践高效运维。但我不认为这种文化就不对，它在特定场景下也许是对的，我只是说这种文化难以适应 DevOps 模型。

接下来是技术，稍后我会简要介绍一下我们的产品。我们提供了一整套的工具，如果你想去实践，我们有工具、方法论给到你。

最后一个重要方面是过程。企业如果一个月发一次版本，一定是堆了无数的东西发一次，压力会很大，所以运维不得已老加班。优秀的运维都是在白天发版本，不好的运维都在晚上发版。后来我们决定调整为白天发版，因为晚上发版是一种懒人文化：你在试图把问题都往后拖，不在开发的时候解决好问题。这个 MVP 是指最小可行产品，每天发一次版本，出现的问题的概率就很低，一个月发一次版本出现问题的概率很高。

在一些调研报告里面确实提到，如果我们把传统的研发模型、开发方式，调转为这种完全 DevOps、微服务化、微型团队化、自我闭环的模型，效率会变得非常高。我们公司现在能做到一天一次，但很多公司一天能够做到 N 次（N 大于等于 10），效率至少是两倍提升。数据看起来确实很令人激动，但在实际运作的过程中，并不是所有团队往这个方向转型都是对的。

交付模式没有好坏，运维模式也没有好坏。并不是说没有采用 DevOps 就一定是个落后的公司。有些业务它不能快速迭代，比如军工企业，他们的业务就没有办法也不需要快速迭代，在快速迭代的方式下极易出问题甚至出人命。但他对错误的容忍度是零，那就只能用传统的瀑布方式去做，所有的环节都必须卡得很死，不能够并行，必须是由一个大团队去解决一个问题。所以你的工具需要同时适应这两种模型，这也是我们努力的方向，既能够兼容传统的开发方式，同时又要面向新的 DevOps 微服务组织结构和方法论。

我们在 2014 年就成立了一家公司，那个时候我们做的更多的是跟代码相关的事情。在 2018 年初的时候，我们开始全面扩张上下游，提出的概念叫做一站式 DevOps 解决方案。在我们的平台上从需求开始到最后发布上线，整个流程都是串起来的。而不是说你要搭建很多系统，系统之间账号不通，数据又不通。而且我们提供了公有云服务，你现在就可以在云上用到所有服务。

这个产品矩阵图是我们当前产品的功能模块以及功能模块的成熟度。下面有一条横线有颜色深浅变化，颜色越深，我们在这件事情上的成熟度就越高，颜色越浅就表示不是特别的成熟。我们今年会着重发力质量管理、持续集成、持续部署，今年会把它变成深色。这个研发大数据也很重要，在使用公有云服务时，统计大家的发布频率，就可以提供平均值给大家参考。

为什么我们要做一站式？其实业界早就有了每一个环节的工具，从需求到最后发版，开发环境管理、配置与安全。每个环节，业界都不止一个工具在做。我们希望一个工具解决所有问题，希望我们每一个客户在用这款产品的时候，只要开一个账号，所有东西都能解决。当然现在国外也有企业也在做这件事情，包括微软。

这是我们公司是如何发版上线，运维和开发是如何协同的方式。我们组建了全功能研发团队，设计、产品，前端、后端全都有，研发团队可以自我闭环。每个团队都可以独立进行迭代开发、持续集成、测试、构建物管理再到自行部署上线。部署环节由运维提供工具和服务，运维再也不负责发布这件事情，他只负责发布用的工具。我们希望能够做到这样，而且我相信很多研发团队也都在往这个方向努力。

我们的持续集成功能完全兼容 Jenkins，支持图形化编排，也可以用脚本化的编排方式，支持并行多个 job。接下来是我们的制品库功能。之前很少有人提“制品库”这个概念，最近这几年在中国研发领域，越来越多人意识到编译出来的二进制产物管理很不规范，很容易出错。所以制品库的概念越来越流行，我们也做了针对 maven、NPM、docker 镜像的制品库，我们还会做针对安卓的 APK 包等等。制品库不仅仅是把制品存起来，还可以对其进行扫描，比如可以知道安卓包里面有哪些调用是没有意义的，哪些组件是过时的，甚至有病毒的。

至于 CODING+，我们正在跟腾讯内部很多已有的运维开发工具做集成，比如有个产品叫做 CodeDog，它是腾讯内部做了多年的一个代码检查产品。你写完代码后，代码仓库会自动做扫描，比如 Java 代码哪里可能有内存泄露。我们把这些能力全部包装成一个完整的产品。

在云时代下，跟在座各位开发与运维人员有关的是职业发展方向会有一些变化，第一就是开发者自服务，这是 Netflix 提出来的这么一个概念，叫做全周期性程序员。以前叫全栈程序员，现在叫全干程序员。全栈只是前后端，全干了就什么都得干。

以前很多的流程和工具不支持你一个人干完所有事情。但现在有新的工具，新的流程，全生命周期的程序员效率会更高，因为你可以用到这个工具替代那些环节。对于研发来说，不能够只是在关注自己三分地，更多的是需要去上下游看一下。在研发领域，拥抱变化、工具思维、快速学习、加强协作也都是值得提倡的。那么云时代下的运维的苦日子何时到头？现在已经比以前好很多，在十年前运维人员基本上都要蹲机房，现在很少。DevOps、微服务的出现干掉了一些基础运维岗。Serverless 的发展会干掉中级运维岗，后面只剩下高级运维。高级运维是什么？云所需要的运维。每个客户不需要运维以后，腾讯云需要用运维，所以运维岗位会越来越聚焦，越来越深入。这一点值得每一个运维同学去思考。

最后就是 CODING 的 slogan —— 让开发更简单。谢谢大家。