次DevOps平台的研发经历，我的几点收获

做 DevOps 产品差不多三年了，中间经历了诸多架构变迁、团队变动、业务目标调整，终于在七月下旬，正式发布了 DevOps 产品的 5.0 LA 版本。这个版本从三月到七月，历经大概 150 天，每个阶段都面临着一些痛点，在此与大家简单分享。

先简单介绍下此版本的主要特性：

此版本覆盖了产品管理、项目管理、持续集成、自动部署、交付流水线、精益度量 6 个领域能力：

平台对外提供全面的开发运维一体化方案，已经受过大规模生产验证。

平台不强调全自动，更倾向于在企业流程体系下，通过持续运营，提升生产效率。

平台与微服务、容器无缝融合，兼容不同基础设施，为开发、部署等能力要求提供支撑。

写在前面：不满意随处可见

每一次版本研发，看着前序版本，都特别不是滋味（一般开发同时会很通俗的讲：“每次看到以前自己写的代码都想抽自己”）。

比如，之前的版本中太强调项目管理的敏捷，却完全没有考虑企业版本火车式的敏捷，记得去某个银行时，客户上来就问版本火车在 DevOps 平台怎么支持？我承认，真的没细想过。

再比如，之前的版本太注重基础能力的建设，没有太考虑 DevOps 要千人千面，把概念模型简单粗暴的映射到界面设计中，是个很严重的错误。

诸如此类的错误还是很多，暂且先不自我批评了，回到现在这个版本，我们在研发过程中遇到的一些挑战，是如何面对的。

三 / 四月：集成模型之痛

对于 DevOps 平台来说，核心价值在于将不同阶段、不同工具有机串联，数据打通（所谓横向打通部门墙，纵向打通工具链），所以势必要集成常用的一些工具链。

做集成类项目的同学都会比较清楚，集成类项目常常面临以下三个难点：

集成类项目最大的难点是模型适配，比如禅道和 jira，都是项目管理工具，但底层模型区别很大，这就要求在集成时能够抽象出通用模型，甚至要做一定的能力取舍，形成标准模型。

从技术来看，大部分三方工具都提供了 rest 接口或对应客户端，但对于一些长任务调用，需要考虑异步或者 CQRS 模式。比如 Jenkins 集成，通过 api 调用得到 key，后续通过任务 key 获取 pipeline 状态，也可以通过 pipeline 对 DevOps 进行 hook 回调。

从数据流来看，DevOps 平台现阶段的比较现实的目标，是支撑 80% 的日常工作，很多专业工作还是要到原有专业工具上进行，所以在集成时，需要分清数据流向（哪些以查询为主，哪些以操作变更为主等）。

举个例子，对 Jira 的集成，DevOps 模型是这样映射的：

可以看出，DevOps 做了不少取舍，同时引入了 jira 没有的产品概念，来统一管理需求。而对于数据流，DevOps 在项目管理中更注重看板与项目报表（进度、效率、质量），日常工作还是建议在 jira 上去做，毕竟 jira 的工作流等能力非常强，不是某个新的项目管理平台能够覆盖到的。

通过不断的抽象和调整，最终在这个版本里，集成了如下工具链：

五 / 六月：MVP 带来的变化

这个版本属于实施带动研发，客户要求月迭代上线，这对我们的计划安排、研发质量等要求都很高，遵循 MVP 的交付尤为重要。

先说说何为 MVP，如下图，要让每个阶段都能有可用的产品，全称“最小可行性产品”。

但顺着上图不难看出来，其实从可重复利用的角度来看，MVP 的方式反而有一定浪费。毕竟造出的滑板车，在汽车产品上是完全没用的。所以，如果是低质量的 MVP，后续耗费在迭代改进上的精力反而要更加恐怖（毕竟不是每个版本都是一刀切的）。

而对于大型产品来说，使用 MVP 交付最重要的一点在于故事的合理分配（大小、优先级等），回归产品经理的本质，在“人人都是产品经理”中，会告诉大家如何找到最有价值故事，优先交付：

从意愿角度来看，要做的故事往往是非常多的，在有限的时间里都完成是不现实的。

从竞争角度来看，业界都不易做的，往往价值更高。

从自身能力来看，不要一味的盯着那些还没有太好方案的需求，快速完成能做的。

当然，永远不能离开 MVP 的本质，要保证每个冲刺后交付的版本都是可用的，让大部分角色能参与进来。还有一句话，我觉得也很适合现在的大型产品研发模式：“think big, start small, do smart.”

结合上面的思路，在迭代过程中，我们对故事进行严格甄选，有机会大家看到我们产品时，会发现有些特性，在上面明显花了不少精力，而一些比较普遍的特性，可能反而没有做的很完善：

一种是我们认为理解较好的，我们会优先并花更多精力去做，比如自动化部署：参考了 oneops 设计，将逻辑部署与物理部署架构分离，通过在线部署架构的设计，再将其与目标环境或资源、以及具体部署策略等关联。

拿标准的三层架构举例，nginx+tomcat+mysql，开发环境中 tomact 部署单点，生产环境中 tomcat 部署集群，其实就可以做到一套设计，多次转换形成最终的可执行脚本，完成整体应用的多环境部署。设计思路如下：

另一种是我们自认为有技术优势的，比如交付流水线：因为我们有流程引擎组件，使得面向不同的企业交付流程，可以做到动态可配。比如某个企业流水线上，是有预发这一步的，又或者上生产前是需要人工干预和多级审批的，对我们来说会比较容易实现，最终参考界面如下：

正是在这么一个个“有取舍“的迭代中，我们才能在有限的时间里，完成了近 30W 行代码的版本交付，并在每个月完成从测试环境到生产环境的发布。

七月：规模驱动工程优化

一直有客户在问，你们的 DevOps 有没有使用微服务架构？业务和技术上究竟是怎么拆分的？

我的回答是：早在 1.0 版本我们采用过微服务架构，将其拆成了十多个领域系统，但在这个版本我们合了。

做事要有激情，但切勿激进。同样是造车梦，马斯克和贾跃亭，至少从现阶段来看，结果是不一样的。

对于我们这么一家以产品为核心的公司来讲，如果产品线和产品线之间采用太多不同技术栈，产品部门与事业部（服务部门）不能一起往前演进的话，即使某个产品技术栈很先进，缺无法让公司所有人短期接受并掌控，就永远做不到全面推广。

话说回来也许有人觉得我们还是太保守，但事实确实如此，这没法和互联网或创业公司去比，传统企业在技术演进路上肯定是相对慢一些的，更追求工程化和稳定性。

在 7 月，随着外部项目的增多，DevOps 的实施面临着更多工程化管理的压力。如何从单一团队负责交付，发展到多团队配合？如何从孤立产品迭代，发展到企业版本火车交付？这些都是工程化要解决的问题。

我们的思路一直是，从 BAPO 角度来解决问题：

业务角度：多产品形态，往往不同客户的需求从大块上来看就是不一样的，有客户要 CI，有客户要 CD，有客户要项目管理，所以面向不同的业务目标，产品需形成对外多形态、插件化。

架构角度：微服务、容器等生态逐渐完善，前端技术也变成了 react 与 vue 等少数之争，这个时候我们对架构逐步升级，面临的风险会更小。

流程角度：DevOps 强调持续迭代、持续交付，面对不同企业，细节流程虽有不同，但开发流水线，测试流水线，发布流水线这些却都是必需品，所以可以通过流程梳理，形成落地实施规范。

组织角度：团队加强配合和学习，比如与事业部部门的代码共享，我们推荐使用 fork 模式，事业部逐步掌控，并能将一些实施过程中的优秀特性 pull request 过来，反向帮助提升产品。

后续：长期规划、短期见效

如何让 DevOps 平台保持生命力，我觉得最重要的是以下四点：

易扩展，平台作为企业产线的一部分，需要与大量的工具、平台交互，像拦截机制、hook 机制都必不可少，尽可能让平台与更多能力串接，才能形成一条全周期的生产线。

可度量，MVP 强调快速推出，通过有效的反馈机制，为后续优化方向提供参考。DevOps 面向的部门和角色较多，千人千面的需求更为明显，所以快速收集反馈，持续度量尤为重要。

连通性，这里更强调数据的连通性，是否知道 jira 上的某个 task，花费了多少行代码？是否知道 jira 上的某个 story，现在运行在哪台 server 上？这些都是数据联通的例子，也是 DevOps 设计中最重要的一环。

标准化，或者我们也可称为”最佳实践“，也许现在还很难标准化客户流程与规范，但在某些细分行业里，总会有一些榜样企业或标准，平台更应该将这些标准作为规范落地，通过模板配置、流程配置，帮助客户形成最佳实践。

目前我们的 DevOps 还无法覆盖全能力，比如测试管理与自动化，比如监控预警，都还需要逐步建立完善，从产品发展角度，我们更希望业务目标要大而全，但实现要快速见效（实现大而全，说实话确实也投入不起）。

最后分享下这个版本的主要功能矩阵，望大家对我们的一些经验和产品能力给予建议或指正：

作者介绍

现任普元信息主任架构师。长期致力于 IT 技术研究、产品设计与开发、架构咨询等工作，擅长 Web、OSGI、CI/CD、服务治理、云计算等领域技术。对 DevOps、自动化运维、微服务架构有着浓厚的兴趣。

次DevOps平台的研发经历，我的几点收获

做 DevOps 产品差不多三年了，中间经历了诸多架构变迁、团队变动、业务目标调整，终于在七月下旬，正式发布了 DevOps 产品的 5.0 LA 版本。这个版本从三月到七月，历经大概 150 天，每个阶段都面临着一些痛点，在此与大家简单分享。

先简单介绍下此版本的主要特性：

此版本覆盖了产品管理、项目管理、持续集成、自动部署、交付流水线、精益度量 6 个领域能力：

平台对外提供全面的开发运维一体化方案，已经受过大规模生产验证。

平台不强调全自动，更倾向于在企业流程体系下，通过持续运营，提升生产效率。

平台与微服务、容器无缝融合，兼容不同基础设施，为开发、部署等能力要求提供支撑。

写在前面：不满意随处可见

每一次版本研发，看着前序版本，都特别不是滋味（一般开发同时会很通俗的讲：“每次看到以前自己写的代码都想抽自己”）。

比如，之前的版本中太强调项目管理的敏捷，却完全没有考虑企业版本火车式的敏捷，记得去某个银行时，客户上来就问版本火车在 DevOps 平台怎么支持？我承认，真的没细想过。

再比如，之前的版本太注重基础能力的建设，没有太考虑 DevOps 要千人千面，把概念模型简单粗暴的映射到界面设计中，是个很严重的错误。

诸如此类的错误还是很多，暂且先不自我批评了，回到现在这个版本，我们在研发过程中遇到的一些挑战，是如何面对的。

三 / 四月：集成模型之痛

对于 DevOps 平台来说，核心价值在于将不同阶段、不同工具有机串联，数据打通（所谓横向打通部门墙，纵向打通工具链），所以势必要集成常用的一些工具链。

做集成类项目的同学都会比较清楚，集成类项目常常面临以下三个难点：

集成类项目最大的难点是模型适配，比如禅道和 jira，都是项目管理工具，但底层模型区别很大，这就要求在集成时能够抽象出通用模型，甚至要做一定的能力取舍，形成标准模型。

从技术来看，大部分三方工具都提供了 rest 接口或对应客户端，但对于一些长任务调用，需要考虑异步或者 CQRS 模式。比如 Jenkins 集成，通过 api 调用得到 key，后续通过任务 key 获取 pipeline 状态，也可以通过 pipeline 对 DevOps 进行 hook 回调。

从数据流来看，DevOps 平台现阶段的比较现实的目标，是支撑 80% 的日常工作，很多专业工作还是要到原有专业工具上进行，所以在集成时，需要分清数据流向（哪些以查询为主，哪些以操作变更为主等）。

举个例子，对 Jira 的集成，DevOps 模型是这样映射的：

可以看出，DevOps 做了不少取舍，同时引入了 jira 没有的产品概念，来统一管理需求。而对于数据流，DevOps 在项目管理中更注重看板与项目报表（进度、效率、质量），日常工作还是建议在 jira 上去做，毕竟 jira 的工作流等能力非常强，不是某个新的项目管理平台能够覆盖到的。

通过不断的抽象和调整，最终在这个版本里，集成了如下工具链：

五 / 六月：MVP 带来的变化

这个版本属于实施带动研发，客户要求月迭代上线，这对我们的计划安排、研发质量等要求都很高，遵循 MVP 的交付尤为重要。

先说说何为 MVP，如下图，要让每个阶段都能有可用的产品，全称“最小可行性产品”。

但顺着上图不难看出来，其实从可重复利用的角度来看，MVP 的方式反而有一定浪费。毕竟造出的滑板车，在汽车产品上是完全没用的。所以，如果是低质量的 MVP，后续耗费在迭代改进上的精力反而要更加恐怖（毕竟不是每个版本都是一刀切的）。

而对于大型产品来说，使用 MVP 交付最重要的一点在于故事的合理分配（大小、优先级等），回归产品经理的本质，在“人人都是产品经理”中，会告诉大家如何找到最有价值故事，优先交付：

从意愿角度来看，要做的故事往往是非常多的，在有限的时间里都完成是不现实的。

从竞争角度来看，业界都不易做的，往往价值更高。

从自身能力来看，不要一味的盯着那些还没有太好方案的需求，快速完成能做的。

当然，永远不能离开 MVP 的本质，要保证每个冲刺后交付的版本都是可用的，让大部分角色能参与进来。还有一句话，我觉得也很适合现在的大型产品研发模式：“think big, start small, do smart.”

结合上面的思路，在迭代过程中，我们对故事进行严格甄选，有机会大家看到我们产品时，会发现有些特性，在上面明显花了不少精力，而一些比较普遍的特性，可能反而没有做的很完善：

一种是我们认为理解较好的，我们会优先并花更多精力去做，比如自动化部署：参考了 oneops 设计，将逻辑部署与物理部署架构分离，通过在线部署架构的设计，再将其与目标环境或资源、以及具体部署策略等关联。

拿标准的三层架构举例，nginx+tomcat+mysql，开发环境中 tomact 部署单点，生产环境中 tomcat 部署集群，其实就可以做到一套设计，多次转换形成最终的可执行脚本，完成整体应用的多环境部署。设计思路如下：

另一种是我们自认为有技术优势的，比如交付流水线：因为我们有流程引擎组件，使得面向不同的企业交付流程，可以做到动态可配。比如某个企业流水线上，是有预发这一步的，又或者上生产前是需要人工干预和多级审批的，对我们来说会比较容易实现，最终参考界面如下：

正是在这么一个个“有取舍“的迭代中，我们才能在有限的时间里，完成了近 30W 行代码的版本交付，并在每个月完成从测试环境到生产环境的发布。

七月：规模驱动工程优化

一直有客户在问，你们的 DevOps 有没有使用微服务架构？业务和技术上究竟是怎么拆分的？

我的回答是：早在 1.0 版本我们采用过微服务架构，将其拆成了十多个领域系统，但在这个版本我们合了。

做事要有激情，但切勿激进。同样是造车梦，马斯克和贾跃亭，至少从现阶段来看，结果是不一样的。

对于我们这么一家以产品为核心的公司来讲，如果产品线和产品线之间采用太多不同技术栈，产品部门与事业部（服务部门）不能一起往前演进的话，即使某个产品技术栈很先进，缺无法让公司所有人短期接受并掌控，就永远做不到全面推广。

话说回来也许有人觉得我们还是太保守，但事实确实如此，这没法和互联网或创业公司去比，传统企业在技术演进路上肯定是相对慢一些的，更追求工程化和稳定性。

在 7 月，随着外部项目的增多，DevOps 的实施面临着更多工程化管理的压力。如何从单一团队负责交付，发展到多团队配合？如何从孤立产品迭代，发展到企业版本火车交付？这些都是工程化要解决的问题。

我们的思路一直是，从 BAPO 角度来解决问题：

业务角度：多产品形态，往往不同客户的需求从大块上来看就是不一样的，有客户要 CI，有客户要 CD，有客户要项目管理，所以面向不同的业务目标，产品需形成对外多形态、插件化。

架构角度：微服务、容器等生态逐渐完善，前端技术也变成了 react 与 vue 等少数之争，这个时候我们对架构逐步升级，面临的风险会更小。

流程角度：DevOps 强调持续迭代、持续交付，面对不同企业，细节流程虽有不同，但开发流水线，测试流水线，发布流水线这些却都是必需品，所以可以通过流程梳理，形成落地实施规范。

组织角度：团队加强配合和学习，比如与事业部部门的代码共享，我们推荐使用 fork 模式，事业部逐步掌控，并能将一些实施过程中的优秀特性 pull request 过来，反向帮助提升产品。

后续：长期规划、短期见效

如何让 DevOps 平台保持生命力，我觉得最重要的是以下四点：

易扩展，平台作为企业产线的一部分，需要与大量的工具、平台交互，像拦截机制、hook 机制都必不可少，尽可能让平台与更多能力串接，才能形成一条全周期的生产线。

可度量，MVP 强调快速推出，通过有效的反馈机制，为后续优化方向提供参考。DevOps 面向的部门和角色较多，千人千面的需求更为明显，所以快速收集反馈，持续度量尤为重要。

连通性，这里更强调数据的连通性，是否知道 jira 上的某个 task，花费了多少行代码？是否知道 jira 上的某个 story，现在运行在哪台 server 上？这些都是数据联通的例子，也是 DevOps 设计中最重要的一环。

标准化，或者我们也可称为”最佳实践“，也许现在还很难标准化客户流程与规范，但在某些细分行业里，总会有一些榜样企业或标准，平台更应该将这些标准作为规范落地，通过模板配置、流程配置，帮助客户形成最佳实践。

目前我们的 DevOps 还无法覆盖全能力，比如测试管理与自动化，比如监控预警，都还需要逐步建立完善，从产品发展角度，我们更希望业务目标要大而全，但实现要快速见效（实现大而全，说实话确实也投入不起）。

最后分享下这个版本的主要功能矩阵，望大家对我们的一些经验和产品能力给予建议或指正：

作者介绍

现任普元信息主任架构师。长期致力于 IT 技术研究、产品设计与开发、架构咨询等工作，擅长 Web、OSGI、CI/CD、服务治理、云计算等领域技术。对 DevOps、自动化运维、微服务架构有着浓厚的兴趣。