对于我们完全自主研发的DevOps支撑平台实际上在前面很多文章我都强调过，简单理解就是将DevOps最佳实践，包括研发过程管理，持续交付和技术运营全部融入到DevOps支撑平台，同时底层开发基于微服务开发框架，组件运行依托在容器化PaaS平台上，形成一个完整的整体。

对于DevOps支撑平台实施收益和价值，今天再从业务和管理层容易理解的视角来进行下阐述。

1. 企业研发管理过程的标准化和规范化

注意，在DevOps实施过程中，我们会协助企业进行研发管理过程的规范化和流程化，不论是传统的研发过程管理模式，还是敏捷开发思路，都需要对研发过程进行标准化和流程化，再进一步的自动化。这里面涉及到最基本的开发框架，开发规范，配置管理，变更和缺陷管理，测试管理，版本发布等诸多关键过程域，而这些在我们进行DevOps支撑平台实施的时候会协助企业进行这方面的优化和改进。

2. 企业研发资产的可视化

在DevOps里面我们会强调研发和运维一体化，研发和质量管理一体化，这些都没有问题。但是DevOps有一个关键就是本身是完全包括覆盖了传统的持续交付和持续集成最佳实践的。即整个研发生命周期过程应该进一步的可视化，同时通过微服务架构设计和模块拆分，进一步的实现短周期迭代开发。

迭代开发最终交付的用户可以使用的功能，而不是中间的半成品。但是如果半成品的输出过程不可视，如何确保最终的功能输出没有问题？

不论是甲方企业，还是软件企业本身，都需要对研发过程可视化，即对研发过程的关键中间节点做到完全可控，可视，而这里面最重要的就是做到中间输出结果本身的可验证。注意在整个DevOps流水线作业中，增加的代码入库和静态检查，构建，自动化的单元测试等都是确保这些中间件节点可视，确实研发检入的代码是完整并可以编译通过的。

从整个项目一开始研发资产就是可视的，那么最终研发完成后资产本身也是完整和可视的。研发资产应该是属于企业资产而不是个人资产，对于甲方企业来讲，研发资产的交付应该是在整个项目或研发过程中持续交付，而不是最终项目完成后一次性交付，只有这样甲方对乙方的IT管控能力才能够提升。

3. 协助企业进行微服务架构转型的关键支撑

在传统企业进行IT架构转型，或者说转向微服务架构后，带来的一个关键问题就是微服务模块会越来越多，模块之间的接口越指数级增长。这就导致我们在进行模块构建，模块部署，单元测试等工作的时候耗费大量的人力。而DevOps支撑平台本身就集成了持续交付和集成各种关键工具集，通过平台可以高效自动化的完成代码检查，编译，构建，打包，部署，环境迁移等各类工作。极大的节约人力投入并提升过程效率。

原来传统模式下你部署一个业务系统可能感觉不到大的工作量，但是实施微服务架构后一个业务系统可能已经被拆分为了10多个微服务模块，那么要部署这些微服务模块，要准备应用服务器，要进行打包部署工作量都会指数级增长，而这些完全可以由DevOps支撑平台来帮你完成，同时在设计好流水线作业模板后，所有过程都是自动完成，而且在执行过程中可以做到完全可视，可管控。

在实施微服务架构的时候，我前面谈到过两点，一个就是前面的容器化技术支撑和持续集成自动化，一个就是后续的运维监控能力要跟上。这两个能力跟不上，那么微服务架构实施将由于企业本身的IT信息化成熟度不足导致大量的问题。

记得在几年前自己的一个朋友，原来是做工程设计咨询的，但是在规划设计项目中逐渐发现了有不少的信息化软件开发需求，刚开始的时候走的全部外包但是发现不好管理和持续。因此开始着手建立自己的软件开发队伍，更我说起这个事的时候差不多也有了10多个人的软件开发团队。

记得是有一个晚上，朋友突然找我让我出去聊下有急事，过去后才知道是由于内部管理或利益分配的诸多原因，在这里不方便细问，这个开发负责人逐步要离职走准备去单独干，而且可能还准备把几个核心开发都带走。由于我朋友本身也不是技术和IT出身，遇到这种事情本身还是一抹黑找不到对策，找到我的原因无碍乎是问我这边的技术人员或团队能不能先把他那边的系统和开发工作先承接过去下。

前期没有完整的研发流程，需求文档也不完善，而且在离职的时候提交的文档，代码是否完备这些即使是有经验的技术人员去验证本身也存在相当的难度，到了最后离职谈判阶段实际上我朋友本身已经处于相当被动的地位。在这个时候来谈工作交接或找人接替本身也为时已晚。而实际上具体分析个人理解实际上这个问题很多非技术背景的领导都会遇到，造成的原因主要是：

1. 核心研发资产，包括需求设计文档，源代码往往掌控在关键的一个人手里面，或者干脆无文档。

2. 研发过程不透明，研发资产没有显性化，他人很难短期接手。

而要解决这个问题，个人理解至少需要从几个方面来考虑，第一就是我们常说的研发团队划分，岗位角色设置上面要考虑分离，关键岗位角色要考虑有备份和AB角，能够相互替代。第二就是我们说的研发过程流程改进，研发资产的可视化。

而对于第二点，实施DevOps平台本身就是一个很好的支撑，即研发资产可视，过程可视，你每天新产生的代码都要检入，并进行相关的代码检查和自动化测试，整个持续集成和自动化构建确保了进入到我们配置管理库的代码是编译通过的。其次，我们自动构建完成的部署包本身就是推送给测试人员进行测试的部署包，中间不需要开发人员去插手或增加小动作，那么测试人员测试通过的版本，一定就是当前代码已经实现的版本。

即在整个DevOps持续集成过程中，实现了研发资产的持续落地可视化，这个可视化不仅仅是整个研发版本的可视，更是中间各个阶段的可视化，即使你团队所有人员都离职，我们也应该能够确保当前研发资产库里面的代码能够自动化构建完成并形成当前的应用版本。代码当前是全的没有遗漏，而且代码完全和当前功能对应。

还有就是，在实施SOA项目的过程中，我们也经常和甲方沟通，当时有一个甲方就提到一个关键点，当要给完整的业务系统招标选择了要给供应商来定制开发后，在项目验收完成后虽然提交了相关的文档，相关的源代码，但是发现后续的运维甲方根本无法承接。包括乙方提供的源代码本身都无法编译通过，即使能够编译通过构建出来的版本功能也和当前生产环境功能有明显差异。甲方如果本身不是专业的IT类公司实际上很难在验收的时候发现这些问题，也就是说最终验收你得到的文档，代码等内容实际上完全无法支撑甲方运维。

而这个问题和前面一个问题很类似，就甲方来说如何加强对开发商的管控，如何确保开发商定制的系统版本和当前的研发文档，源代码资产等是时刻同步的。如何确保最终验收的研发交付文档，代码就是和当前生产环境运行的系统版本是一致的？

如果所有的事情都到了验收的时候才去处理，那么往往为时已晚，说得直白一点对应乙方提供给甲方的业务系统对甲方来说就是一个黑盒子，里面的东西甲方完全搞不懂，只有乙方能够进行后续运维和定制维护。也就是甲方不得不承认间接被乙方绑架的事实。

我们都知道最终的研发资产要能够移交，要能够可交维，但是里面的关键点究竟在哪里？

简单来说就是研发资产的可交维必须是一个在一开始就持续增量不间断进行的过程，一个是按阶段进行持续的交付，一个就是按业务系统的功能点进行持续集成交付。在整个过程中会分很多小的阶段点，在这些阶段点都需要植入相应的自动化检查和测试手段，确保最终入库的资产质量是满足的。整个持续集成过程在一开始配置完成后，研发人员就不应该过多的介入，而应该是流水线自动进行，确保中间没有人为不确定性因素的加入。

我们在给甲方推DevOps绝对不是简单的解决持续集成的问题，而是真正将研发过程管理的经验，包括研发资产的持续可视化融入到整个DevOps平台，实现真正的研发资产可控，过程可控，降低对单个人，乃至单个团队的强依赖。

我们在推DevOps平台，会过度强调了整个自动化，持续集成流水线过程，强调研发和测试的协同，而忽视了研发和运维过程的协同。而研发和运维的协同是整个DevOps的另外一个关键内容，研发的系统，包括每一个功能点应该是做到从一开始就是可运维的，具备运维属性。

一个系统的可运维，本身有一个潜台词就是系统可移交。而对于甲方来说也可以很名正言顺的强调是为了整个研发管理过程的规范化，自动化和研发效率提升来推进DevOps平台工作。下面一篇将从完全云化角度来进一步思考DevOps平台的实施价值。

返回上页