再谈DevOps支撑平台实施(11.23)

最近自己准备把DevOps能力成熟度模型再仔细看一遍，然后和我们当前的支撑平台已有功能进行一下对标，看下还存在哪些关键缺少。而对于DevOps平台的实施，我前面也谈到绝对不是简单的上要给技术平台，而是帮助企业进行传统IT架构转型，包括实施敏捷研发管理和微服务架构等，给出一套完整的解决方法。

而这个实施里面对技术团队而言本身也存在一些前期的技术储备要求，虽然DevOps支撑平台已经对开源的持续集成过程的工具链进行了集成，也对底层的容器化PaaS平台进行了集成，但是我们再实施过程中仍然还需要准备一些配套的工具技术以开展整个实施过程。

而这些前期准备包括了

1. 微服务开发框架： 比如我们常用的SpringCloud框架的使用

2. 标准规范类准备： 包括了需求规范，设计规范，编码规范，特别要注意的就是里面的接口规范

3. API网关搭建： 这个要作为一个独立的产品进行搭建，通过API网关来暴露接口服务能力

4. DevOps平台搭建： 搭建我们自研的DevOps持续交付支撑平台

5. 基础技术服务准备： 这个可以做为我们实施的增值服务能力提供，包括各类消息，缓存技术服务能力提供

6. 研发管理工具： 比如我们选择禅道或者Redmine来进行我们的敏捷研发过程管理

而上面这些都是最基础的前期准备，这些准备好了往往才能够开始实施整个DevOps过程，这也符合在DevOps能力成熟度模型里面的敏捷开发管理和持续交付，包括后续的技术运营。

在前面很多文章我已经谈到了研发过程管理和持续交付过程的协同，另外一个关键协同就是整个研发交付过程和后续的运维支撑过程的协同，对应到后续的技术运营过程域，这个在后面专门写文章来谈。

最近我们在交流过程中会遇到一个疑问，就是感觉DevOps平台往往仅仅适合于大企业和大团队，而对应小企业和团队往往并不适合。而这里我想强调的是DevOps平台本身适合的是敏捷开发团队和采用了类似微服务架构的敏捷交付过程，而不分大小企业。即使我们在大企业实施DevOps平台，我们也可以看到实际上我们也会把团队划分为10人以下的规模，形成敏捷开发团队，每个团队负责一个项目或微服务模块。

因此只要你采用了微服务架构又希望敏捷研发管理和持续交付，那么这个平台就适合。

这个平台本身是使我们的交付过程更加敏捷，快速和自动化，使研发，测试和运维团队更加高效的协同。不是增加了工作量，而是真正降低了我们在交付过程中的工作量。同时我们在看DevOps能力成熟度模型的时候经常会看到一个词就是价值交付，即交付本身是带来业务价值的，是业务驱动的。这也是我们期望通过DevOps实施带来的一个大的转变。

对于DevOps平台的产品研发是我们明年的一个重点产品规划和方向，其次就是配合DevOps的微服务架构咨询，敏捷研发管理咨询等配套能力也需要同步增强，以为客户提供完整的解决方案和咨询实施服务能力。

我们自己做的DevOps平台，我们公司当前自己的产品研发就完全基于该平台进行，自己做的东西自己就在用才能够不断的持续改进。公司的产品研发在明年全部迁移到DevOps平台也是我们的一个重点。