首先说明下，我最近会花更多的时间去录制知识分享视频，因此对于图文的发布节奏会减少，最终我希望达到的一个效果就是图文发布和视频发布或做到逐步同步。

今天准备谈下我们在做DevOps后续产品规划时候的一些关键点思考，供大家参考。

◆ 开源和开放的逻辑

首先还是想强调下开源和开放的逻辑。

大家都清楚对于DevOps平台更多的是基于开源工具链做集成，最终形成一个统一的过程支撑和管控治理平台。底层的各种技术工具全部是开源的，那么最终做出来的上层管理平台就没有封闭的必要，而是应该采用开源的方式。

在云原生下，开源和开放是大趋势。

你只要相信你的产品足够好，你对自己的技术足够有把握，那么就应该尽早地采用开源测试。通过开源来快速地获取用户使用，获取用户对产品的反馈。这才是产品能够不断前进，持续优化的基础。

企业和团队要生存，不能说是只为了情怀做事情。对于开源同样也应该保证团队的可持续经营。产品免费，服务可以收费；对80%的用户免费，对20%的企业用户可以卖企业版。这就是最基本的开源产品的盈利模式和运作逻辑。

◆ 开源的上层还有哪些可做的？

对于DevOps实践，我在前面也有文章谈到过。

只要一个开发人员，有了3年左右的工作经验，基本上自己基于Jekins也可以很快的搭建一个CI/CD持续集成和持续部署环境出来，这个本身没有太多的难度。

那么在DevOps领域还有哪些可做的具体事情？

在这里我想提三个点。

第一个点是自动化安装。就是DevOps涉及到诸多的开源工具的集成，即使你自己去搭建基础的CI/CD也会涉及到大量基础工具的安装，配置，有时候还涉及到各个开源软件之间本身的版本不兼容等一系列的问题。

记得我自己去年在本机安装和搭建APISix开源API网关的时候，当时就出现了诸多的基础依赖库版本兼容性问题，导致花费了很长的时间才解决问题。

因此对于DevOps也是同样的道理，我们首先想做一个将各自开源工具链做集成后，可以一键部署和安装的东西。同时在各个底层开源工具做了升级后，这个工具还能够帮助你做一键的版本升级和迁移。

而你要做的事情很简单，你只需要准备基础服务器资源即可。

第二个点是高可用和高扩展。大家都清楚，如果仅仅是团队或项目级要用DevOps和CI/CD，自己随便折腾一下基本就可以了。但是如果是大型的集团，本身涉及到子组织，也涉及到上千个系统要上DevOps，那么这个时候平台的高可用和扩展性就很重要了。

在早期DevOps研发过程中，为了支撑高并发调用，我们就对GitLab，Jekins，Artifactory，Harbor等关键基础组件进行了分区分片设计。即不同的组织，不同的系统可以灵活配置，将其分配到不同的分片上面，以实现灵活扩展的目的。

当我重新思考CI/CD流水线设计的时候，实际和我前面谈到的MFT大文件传输平台的高扩展思路很类似。即整个分布式集群的构建不应该是类似etcd,zookeeper的思路，而是应该是类似分布式调度平台的思路来构建。

一个流水线本身包括了编译，构建，打包，部署等多个任务。

那么分布式调度平台应该能够做到将不同的任务分配到不同的节点或分片去运行。同时还能够做到支持重试，即构建任务在A节点执行不成功的时候，还能够重新将任务分配到B节点去运行。

也就是CI/CD的分布式可扩展实现基于分布式调度+分区分片。这个是我们后续构建一个高可用的CI/CD能力的基础逻辑。

底层一定要分区分配，单节点的能力你不要去要求他需要多么强大，同时又能够通过一个统一的管控平台来实现对节点的统一管控，这就是管控平台的价值点。比如早期我们在做DevOps项目的时候，整个Git库最终10多亿行代码，后续的管理，备份，代码统计等都出现大量的一致性和性能问题，这就是早期没有做分片或者分片规划不合理导致。

第三个点是混合云管理和桥接网关。这个也是我多次提到的，就是云原生时代短期仍然会处于混合云的一个架构模式，那么企业内部私有云和外部公有云之间的连接和交付就成为一个关键要解决的问题。

我在前面一篇文章里面谈到了阿里发布了CNStack产品，你可以将其理解为阿里云服务能力向企业内部的一个延伸，重点还是希望去构建一个混合云的管理能力。但是阿里做这件事情，那么自然所有的东西都要适配阿里，你采用的越多往往和阿里云服务绑定得越紧密。

企业对于云服务的选择我个人理解仍然应该是一种开放和中立的原则，追求的是服务和性价比，而不应该简单地被一个云服务厂商绑定。

那么我们做DevOps就希望去做一个企业内部私有云和外部多个公有云服务之间的一个桥接网关平台。

你刚开始的需求设计，开发测试都使用内部DevOps平台的CI/CD能力即可。在你最终测试完成后，这个平台又能够让你很方便地对接到外部的公有云平台，实现最终的应用向公有云服务的持续交付能力。这个事情本身是有价值的。

再次，我前面谈到云平台天生具备两大关键能力，第一个就是数据的异地备份能力，第二个就是资源的弹性扩展能力。一个企业内部的私有云构建完成后，完全可以早点实现和外部公有云平台之间的交付和对接。在业务压力不大的时候就全部用内部资源和能力，当持续类似年结，或大型活动促销的时候，就能够快速的扩展到外部云服务平台的能力，实现底层资源的弹性扩展。

而要做到这点，在私有云和公有云之间的DevOps持续交付和适配就很重要。这也是我一直希望我们的DevOps平台产品能够解决的一个关键问题。

◆ 云原生下资源到服务

最后再围绕云原生几个核心要素来谈下DevOps的一些关键能力支撑。

首先就是从资源到服务，从IaaS层过渡到PaaS平台服务层。云原生下的应用开发最好就是不要去涉及到任何资源层的内容。

举个简单的例子，你需要使用数据库能力，那么不是你去申请虚拟机，自己安装数据库。你需要使用缓存能力，也同样不是你去申请虚拟机安装Redis缓存。所有的需求都应该从资源的申请转变到对技术服务的申请。

即一个应用要最终上线，你可以看到过程变化为：

• 申请数据库服务

• 申请缓存服务

• 申请消息服务

• 开发业务功能，通过CI/CD过程交付

整个过程里面你不再去接触任何资源层的内容。

这个时候你会看到DevOps过程本身会进一步复杂，不只是简单的应用包的部署，还包括了数据库，缓存等各种技术服务的部署，配置的变更等。

而这些都需要通过一个完整的DevOps过程来全部实现。

再次，在一个应用最终上线后，基于不可变基础设施和声明式API的道理，我们需要考虑后续的变更如何持续交付的问题。

我举个例子来说明。

如果一个基础组件类似环境变更这种配置信息出现了修改，那么DevOps过程应该是只重新下发配置文件，对于部署包，镜像都不应该重新修改。

如果是基础组件的版本发生了变化，那么这个时候应该是重新制作镜像文档，但是在构建步骤做好的部署包不应该再出现修改或出现构建的情况。

如果是应用的软件代码出现了修改，那么才需要对整个DevOps流水线涉及到的编译，构建，打包，部署等各个环节全部进行执行。

最小化的变动和执行，这是DevOps的一个关键原则。

同时我们还希望所有对环境的修改都应该是声明式的，不要人为去修改生产环境。而是应该做一个声明式文件，DevOps按照你的声明去修改生产环境和资源配置。那么这个时候你才能够真正做到配置信息，代码信息和正式的生产环境完全一致。