作者：人月神话，新浪博客同名
简介：多年SOA规划建设，私有云PaaS平台架构设计经验，长期从事一线项目实践
今天准备谈下DevOps过程实施收益价值和难点分析。可以看到最近几年对于企业全面上云，云原生，DevOps，微服务，中台等新的概念层出不穷，对于传统企业IT架构转型和企业数字化而言，究竟应该如何实施？实施有哪些难点需要克服或提前准备，实施后能够带来哪些收益和价值等问题仍然没有一个全面的说明，因此今天这篇文章重点对这些方面进一步做下阐述。
对于DevOps基本概念的理解
首先看下DevOps的定义：
DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到，为了按时交付软件产品和服务，开发和运营工作必须紧密合作。
对于DevOps过程实践，其主要的推动来自两个方面：
- 业务和需求驱动下，推动敏捷方法论，更快的发布和交付。
- 技术和运维部门需要衔接，PaaS和容器技术发展下进一步推动自动化。
虽然是研发，测试QA，运维交付三方交融的地方为DevOps的内容，但是可以看到DevOps本身更多的是要解决两大类协同和自动化的问题
其一是开发部门和QA的协同
实际上该问题基于多年前已有的每日构建，持续集成方法论就可以解决。DevOps里面我们也看到这部分协同更多的是敏捷研发最佳实践进行融合。
其二是开发部门和运维的协同
该问题的解决当前由云平台，微服务架构，容器技术发展推动的自动化发布和监控运维。注意在持续集成的时候我们只解决了自动化部署问题，但是没有解决持续交付的问题。而在DevOps里面需要同时解决持续集成和面向用户的持续交付能力。
从业务和管理视角来谈DevOps实施收益
对于DevOps的实施，往往需要一个完整的DevOps过程支撑平台，DevOps支撑平台简单理解就是将DevOps最佳实践，包括研发过程管理，持续交付和技术运营全部融入到DevOps支撑平台，同时底层开发基于微服务开发框架，组件运行依托在容器化PaaS平台上，形成一个完整的整体。
对于DevOps实施收益，我们原来谈的比较多的都是自动化，敏捷，研发和运维高效协同等方面的内容，今天再从业务和管理视角来进行下实施收益价值的说明。
企业研发管理过程的标准化和规范化
注意，在DevOps实施过程中，会协助企业进行研发管理过程的规范化和流程化，不论是传统的研发过程管理模式，还是敏捷开发思路，都需要对研发过程进行标准化和流程化，再进一步的自动化。
这里面涉及到最基本的开发框架，开发规范，配置管理，变更和缺陷管理，测试管理，版本发布等诸多关键过程域，而这些在我们进行DevOps支撑平台实施的时候会协助企业进行这方面的优化和改进。
企业研发资产的可视化
在DevOps里面我们会强调研发和运维一体化，研发和质量管理一体化，这些都没有问题。
但是DevOps有一个关键就是本身是完全包括覆盖了传统的持续交付和持续集成最佳实践的。即整个研发生命周期过程应该进一步的可视化，同时通过微服务架构设计和模块拆分，进一步的实现短周期迭代开发。
迭代开发最终交付的用户可以使用的功能，而不是中间的半成品。但是如果半成品的输出过程不可视，如何确保最终的功能输出没有问题？
不论是甲方企业，还是软件企业本身，都需要对研发过程可视化，即对研发过程的关键中间节点做到完全可控，可视，而这里面最重要的就是做到中间输出结果本身的可验证。
注意在整个DevOps流水线作业中，增加的代码入库和静态检查，构建，自动化的单元测试等都是确保这些中间件节点可视，确实研发检入的代码是完整并可以编译通过的。
从整个项目一开始研发资产就是可视的，那么最终研发完成后资产本身也是完整和可视的。研发资产应该是属于企业资产而不是个人资产，对于甲方企业来讲，研发资产的交付应该是在整个项目或研发过程中持续交付，而不是最终项目完成后一次性交付，只有这样甲方对乙方的IT管控能力才能够提升。
协助企业进行微服务架构转型的关键支撑
在传统企业进行IT架构转型，或者说转向微服务架构后，带来的一个关键问题就是微服务模块会越来越多，模块之间的接口越指数级增长。这就导致我们在进行模块构建，模块部署，单元测试等工作的时候耗费大量的人力。
而DevOps支撑平台本身就集成了持续交付和集成各种关键工具集，通过平台可以高效自动化的完成代码检查，编译，构建，打包，部署，环境迁移等各类工作。极大的节约人力投入并提升过程效率。
原来传统模式下你部署一个业务系统可能感觉不到大的工作量，但是实施微服务架构后一个业务系统可能已经被拆分为了10多个微服务模块，那么要部署这些微服务模块，要准备应用服务器，要进行打包部署工作量都会指数级增长，而这些完全可以由DevOps支撑平台来帮你完成，同时在设计好流水线作业模板后，所有过程都是自动完成，而且在执行过程中可以做到完全可视，可管控。
在实施微服务架构的时候，我前面谈到过两点，一个就是前面的容器化技术支撑和持续集成自动化，一个就是后续的运维监控能力要跟上。这两个能力跟不上，那么微服务架构实施将由于企业本身的IT信息化成熟度不足导致大量的问题。
从一个问题案例进一步解释
对于DevOps收益价值我准备举一，两个我实际经历的问题场景来进一步说明。相信很多人也会遇到类似的问题场景，那么当你遇到这些问题的时候一定要去考虑如何解决。
研发成果没有转变为企业级资产
记得在几年前自己的一个朋友，原来是做工程设计咨询的，但是在规划设计项目中逐渐发现了有不少的信息化软件开发需求，刚开始的时候走的全部外包但是发现不好管理和持续。因此开始着手建立自己的软件开发队伍，跟我说起这个事的时候差不多也有了10多个人的软件开发团队。
记得是有一个晚上，朋友突然找我让我出去聊下有急事，过去后才知道是由于内部管理或利益分配的诸多原因，在这里不方便细问，这个开发负责人逐步要离职走准备去单独干，而且可能还准备把几个核心开发都带走。
由于我朋友本身也不是技术和IT出身，遇到这种事情本身还是一抹黑找不到对策，找到我的原因是问我这边的技术人员或团队能不能先把他那边的系统和开发工作先承接过去下。
前期没有完整的研发流程，需求文档也不完善，而且在离职的时候提交的文档，代码是否完备这些即使是有经验的技术人员去验证本身也存在相当的难度，到了最后离职谈判阶段实际上我朋友本身已经处于相当被动的地位。在这个时候来谈工作交接或找人接替本身也为时已晚。而实际上具体分析个人理解实际上这个问题很多非技术背景的领导都会遇到，造成的原因主要是。
- 核心研发资产，包括需求设计文档，源代码往往掌控在关键的一个人手里，或者干脆无文档
- 研发过程不透明，研发资产没有显性化，他人很难短期接手
而要解决这个问题，个人理解至少需要从几个方面来考虑。
第一就是我们常说的研发团队划分，岗位角色设置上面要考虑分离，关键岗位角色要考虑有备份和AB角，能够相互替代。
第二就是我们说的研发过程流程改进，研发资产的可视化。
而对于第二点，实施DevOps平台本身就是一个很好的支撑，即研发资产可视，过程可视，你每天新产生的代码都要检入，并进行相关的代码检查和自动化测试，整个持续集成和自动化构建确保了进入到我们配置管理库的代码是编译通过的。
其次，我们自动构建完成的部署包本身就是推送给测试人员进行测试的部署包，中间不需要开发人员去插手或增加小动作，那么测试人员测试通过的版本，一定就是当前代码已经实现的版本。
即在整个DevOps持续集成过程中，实现了研发资产的持续落地可视化，这个可视化不仅仅是整个研发版本的可视，更是中间各个阶段的可视化，即使你团队所有人员都离职，我们也应该能够确保当前研发资产库里面的代码能够自动化构建完成并形成当前的应用版本。
代码当前是全的没有遗漏，而且代码完全和当前功能对应。
研发资产无法转运维
还有就是，在实施SOA项目的过程中，我们也经常和甲方沟通，当时有一个甲方就提到一个关键点，当要给完整的业务系统招标选择了要给供应商来定制开发后，在项目验收完成后虽然提交了相关的文档，相关的源代码。
但是发现后续的运维甲方根本无法承接，包括乙方提供的源代码本身都无法编译通过，即使能够编译通过构建出来的版本功能也和当前生产环境功能有明显差异。甲方如果本身不是专业的IT类公司实际上很难在验收的时候发现这些问题，也就是说最终验收你得到的文档，代码等内容实际上完全无法支撑甲方运维。
而这个问题和前面一个问题很类似，就甲方来说如何加强对开发商的管控，如何确保开发商定制的系统版本和当前的研发文档，源代码资产等是时刻同步的。如何确保最终验收的研发交付文档，代码就是和当前生产环境运行的系统版本是一致的？
如果所有的事情都到了验收的时候才去处理，那么往往为时已晚，说得直白一点对应乙方提供给甲方的业务系统对甲方来说就是一个黑盒子，里面的东西甲方完全搞不懂，只有乙方能够进行后续运维和定制维护。也就是甲方不得不承认间接被乙方绑架的事实。
我们都知道最终的研发资产要能够移交，要能够可交维，但是里面的关键点究竟在哪里？
简单来说就是研发资产的验收交付必须是在一开始就持续增量不间断进行的过程，一个是按阶段进行持续的交付，一个就是按业务系统的功能点进行持续集成交付。
在整个过程中会分很多小的阶段点，在这些阶段点都需要植入相应的自动化检查和测试手段，确保最终入库的资产质量是满足的。整个持续集成过程在一开始配置完成后，研发人员就不应该过多的介入，而应该是流水线自动进行，确保中间没有人为不确定性因素的加入。
我们在给甲方推DevOps绝对不是简单的解决持续集成的问题，而是真正将研发过程管理的经验，包括研发资产的持续可视化融入到整个DevOps平台，实现真正的研发资产可控，过程可控，降低对单个人，乃至单个团队的强依赖。
我们在推DevOps平台，会过度强调了整个自动化，持续集成流水线过程，强调研发和测试的协同，而忽视了研发和运维过程的协同。而研发和运维的协同是整个DevOps的另外一个关键内容，研发的系统，包括每一个功能点应该是做到从一开始就是可运维的，具备运维属性。
一个系统的可运维，本身有一个潜台词就是系统可移交。
而对于甲方来说也可以很名正言顺的强调是为了整个研发管理过程的规范化，自动化和研发效率提升来推进DevOps平台工作。下面一篇将从完全云化角度来进一步思考DevOps平台的实施价值。
实施DevOps加强对开发商过程管控
对于传统企业，当大量的IT系统开发和实施都外包的情况下，如何加强对开发商的管控是必然面临的一个重要问题。其中对于稍微做的好点的企业可以看到类似上图，优点就是需求方案和统一发布控制一头一尾，确保需求正确并并高质量发布，但是缺点就是中间都是弱管理，对于中间过程监控较弱，中间过程执行偏差可能影响到一头一尾，这也是很多时候甲方项目管理存在的关键问题。
对于这点，在早期我也提出了很多关键思路，总结来说包括了：
- 打开过程黑盒，但是不是完全接管，而是增加各种管控点，包括评审，决策等各种机制建立
- 需求方案不仅仅是简单需求，而是业务方案+技术方案，防止后续走偏
- 配置管理要加强，特别是后续可能接管源代码管理和集中发布部署
- 加强各个项目执行中的项目执行监控，必须增加里程碑点监控和评审机制，及时发现问题
- 形成组织级的度量和KPI体系，切实用数据说话，通过数据分析形成持续改进机制
- 加强中间过程管理，制定各个开发商共同遵守的大过程管控机制
- 形成专家团队，做好各项评审工作，专家团队为虚拟团队，包括业务和技术专家团队等
- 需求方案+统一发布真正可以贯穿整个软件生命周期
- 由传统的被动发布，转变为围绕需求方案和优化更新的有计划有节奏的产品版本发布
在原来推持续集成的时候，我们还有一个重要目的就是能够打开开发商的黑盒，加强对中间过程的监控和管理，让质量问题及早地暴露出来，方面后续甲方能够顺利的接管运维。从这个目的来看，完全是和当前的DevOps思路是吻合的，即协同好技术，质量和运维三者之间的关系。对于甲方如果作为后续运维方，那么从一开始就介入到整个IT系统开发和实施的全生命周期管理过程中。
在DevOps思路实施中，仍然注意要推进两个重点：
- 其一是组件化和微服务架构
- 其二是和PaaS云和各种工具集成实现整个过程的自动化和流水线作业
在实施DevOps的时候，我们对开发商可以提出更多的方便后续运维和管控的要求，从一开始的开发环境，开发框架，单元测试，代码静态检查，持续集成工具，服务接口标准，配置管理环境，版本发布规则，环境迁移规则，包括甲方需要做的各种质量方面的人工审核和检查，这些内容都可以嵌入到整个DevOps流水线作业中。
在这种情况下，开发商从一开始提交的代码，代码的质量，单元测试的结果就全部可视化给甲方和客户，开发商想在这块藏着掖着就相当困难，这既方便了一开始就监控和暴露问题，同时也方便了后续基于整个代码质量的检查和工作量，规模的度量体系的建设。
对于开发测试环境，开发框架和工具，配置管理等从开发商自己管理到迁移到由甲方统一配置和管理将极大的提升甲方对开发商的管控力度。虽然在前期推行涉及到甲方和开发商本身的技术能力和成熟度是否能够达到，以及开发商本身对该方式的抵触思想等，但是整个趋势如此，在12年我们实施的私有云PaaS项目中，其实已经参考该思路在实施和验证。
为全面上云奠定基础
DevOps实施带来的另外一个关键价值，就是企业信息化的云迁移和乃至全面云化。
如何来理解，对于IaaS云平台大家都比较清楚已经发展了很多年，而且也相当成熟，但是对于大部分企业的理解来说，还是在申请云主机，申请存储，然后将自家开发的软件部署到互联网云平台上面，企业也不用单独再建设机房和数据中心。由于IaaS云更多的是停留在资源层面，因此我们也看到：
- 对于企业内部软件应用的开发和资源层的对接之间是存在断点的，或需要人为处理
- 开发，测试和生产各种环境之间的迁移没有办法兼顾，或者开发测试更多是在本地环境进行
既然有开发测试仍然是在本地进行，那么可以看到企业本身还是需要购买服务器资源来配置开发和测试环境，同时对于测试通过的应用还需要考虑如何迁移到和部署到云数据中心。或者说考虑购买的云主机上各类数据库，应用服务器中间件的安装配置，考虑基础数据的同步和导入等。
而里面真正的关键点就在于应用和资源之间还有一个关键的平台服务层，即我们说的PaaS层，PaaS层要解决的问题就是将资源层细节对最终客户屏蔽掉，而以服务的方式来进行提供。
也就是我们常说的必须具备最基本的应用托管能力，资源动态扩展能力。
或者说PaaS层是解决应用开发和资源层部署之间断点的一个关键，也是我们常说的DevOps实践中持续集成的一个关键，这些都需要PaaS层能力来衔接最终的应用层和资源层。
再来看下DevOps支撑平台，为了满足DevOps中的持续交付最佳实践，整个平台已经基于Docker容器和K8s实现了关键的应用托管和资源动态调度能力。而且这个能力本身不依赖于任何IaaS云平台，也就是说整个DevOps支撑平台本身和你选择哪个开放IaaS云平台没有关系，既可以部署在阿里云，也可以部署在华为云或腾讯云。
对于企业的云迁移不仅仅是将生产环境迁移到IaaS云，更加重要的是将测试环境，用户UAT环境等都迁移到云环境，同时也实现云端测试，生产各个环境间的自动化迁移和同步。
那么这样做的收益究竟在哪里？
- 企业不需要再考虑任何服务器资源的投入，也不需要有专门的本地机房运维人员
- 由于在公有云，可以更加快速的实现和用户间协同，企业内部多个团队之间的异地化协同
举个简单例子来说，传统我们做要给软件项目，我们的客户在北京，而我们的开发在武汉，客户提交了一个需求变更后，我们要在武汉开发，开发完成后在武汉本地环境部署测试环境供测试人员测试。测试人员测试通过后，开发人员还需要将部署包部署到客户现场再由客户进行UAT测试，整个过程相当的繁琐，开发和测试间的协同也很频繁。
但是我们看到如果全部迁移到云端后相关问题很容易解决。
即我们可以在云端部署一个SIT环境和一个UAT环境，我们的开发在本地进行，但是开发完成后的持续集成构建则直接在公有云SIT环境完成，完成后测试人员进行测试，测试通过后自动化的迁移部署到UAT环境供用户测试，整个后续过程不需要开发人员再进行干预，全部自动化流水线执行。
而这些如何完成？
就是前面我们谈到的DevOps平台提供的持续集成和交付能力，以及在这个能力背后的应用托管，灰度发布和资源动态调度等能力。正是因为有了这些能力，开发和测试协同更加简单了，应用开发到最终生产的交付也简单了，而且关键是可持续了。
DevOps最基础的一定是要实现持续集成，而持续集成在和Scrum敏捷方法论实践相结合的时候，才真正让我们能够感受到在短周期迭代开发中的功能持续可见，可测和可验证。
同时在我们开发测试迁移到云端后带来第二个关键好处，就是整个团队的异地开发协同更加方便了，两个异地的开发团队不再需要在本地建立开发测试环境，而所有测试环境都在云平台上面，每个开发团队只需要每日检入自己在本地编译构建和自测通过的代码即可，即使有合并冲突，我们也可以及时的发现和纠正。
DevOps实施和推进困难又在哪里？
在我前面讲解DevOps的文章可以看到，DevOps本身包含了敏捷研发管理，持续集成和持续交付，自动化测试，自动化运维监控，微服务和容器云等一系列的过程管理和技术实践。因此企业实施和推进DevOps绝非易事。
要分析DevOps实践在团队推行困难的原因还是需要从以上这些方面进行分析。
推动力不足，优化还是变革？
对于DevOps实践，特别是配合微服务和容器云的时候，我们可以看到对企业传统的IT架构是一次具体的变革而不是简单的架构优化。任何大架构的调整一定有推动力，那么站在CIO角度推动力在哪里？
这里面就存在技术驱动和业务驱动两个关键概念了。
- 技术驱动简单来来说技术发展趋势是这样的，我们要早点变革做长远打算。
- 业务驱动，即业务发展需要IT变革，否则性能，敏捷性都无法跟上业务发展需要。
现在真正驱动力一定是当前的IT系统本身通过简单的优化已经无法应对业务需求，这才是关键驱动力。否则当前IT系统本身运转良好，为了新技术发展趋势或远期规划而需要大量前期IT预算投入，估计CIO也没有这个能力申请到足够的预算。
其次，传统稳定架构转变为新架构一定带来一定的不稳定期和阵痛期，大部分CIO并不愿意承担风险。
因此没有明确的业务驱动力，再加上企业IT部门和大部分CIO都很难强势，这些导致了DevOps推行困难度增加。IT投入预算更多的是先解决业务问题和痛点，其次才是解决IT本身治理管控问题。
企业内部IT团队管理和技术基础薄弱
要明白，任何新的方法论和技术的推行和实践本身就是一个循序渐进的过程。这和小孩爬都没有学会就要学跑是一个道理，企业IT也很难进行跳跃式发展，而是必须一步步的逐步演进式发展提升企业IT成熟度。这里面的薄弱实际上可以总结为几个方面：
其一是软件工程和研发管理基础薄弱，比如企业是否有标准的软件研发管理，或者实施过类似CMMI软件过程改进，实施过敏捷项目管理，有最基本的研发管理过程规范和技术标准。如果这些都没有做过，你会发现进入到DevOps后你的研发过程管理能力跟不上，因为在敏捷状态下需要更加可视化，更加高频和可量化。
其二是研发技术基础积累薄弱，比如企业原来本身没有接触过微服务架构，容器技术等，如果企业要从头开始学习和实践这些，那么就需要一个长周期的学习时间，而且关键是自己摸索很大地方还无法彻底做到融会贯通。另外一个技术基础就是我们常说的持续集成，企业原来是否实施过类似持续集成，如果你原来实施过持续集成，冒烟测试，自动构建，自动化测试等，那么你会发现过渡到DevOps就相对容易。
团队文化影响，持续改进的意愿
最后一点，个人认为也是最关键一点就是你当前的团队文化究竟是如何的？团队文化是一种安于现状，乐于重复，拒绝变化，喜欢藏着掖着的文化，还是一种开放，透明和拥抱变化的文化。在各种敏捷方法论的推行过程中，我们始终会看到首先就会强调团队文化，敏捷文化。而敏捷文化就是一种开放，包容，乐于接受变化，可视化，对结果负责的文化。而这些正是推行敏捷方法论和DevOps的基础。
在推行DevOps后我们可以看到会让每个团队成员每天的输出成果，和输出质量更加可视化，完全暴露在整个团队，你自己想藏着掖着都不行。可想而知，对于原来一些本身自律性就差，喜欢耍小聪明和偷懒，对产出质量不重视，责任心不足的团队成员来说绝对是坏事。
这些人往往更加期望一种传统的非透明的管理方式，这种方式下他们可以更多的划水或得过且过。
而对于原来就高度自律负责，产出质量高的成员来说往往就更加喜欢这种敏捷和DevOps的方式，这种方式反而是进一步体现和量化对比了他们自己的价值。
在敏捷方法论里面我强调日事日毕，每天都能够反馈和总结，就这一点估计很多人就无法做到，也不愿意去做到。不是所有的程序员都热衷于新技术，更多的人还是希望是不太动脑的重复劳动。
预算和成本，投入产出比
最后我再谈一点就是推行DevOps的投入产出比的问题，要知道DevOps特别是微服务架构的实践往往是对原有架构一次大的变革，那么自然需要投入更多的研发资源，或者还包括外部技术产品和咨询服务的采购，这些都是需要大量的成本投入。
而这些成本投入在刚开始你往往看不到带来的具体收益。
举个简单的例子的，当前需要开发一个新的业务系统，用传统的架构方式可能成本在30万，但是采用微服务架构并实施DevOps后可能总体成本在100万。这个多投入成本在短期并没有价值，真正的价值是在后期运维，在需求变更的快速响应，在后期系统的弹性扩展上。那么多少人又愿意为了长远的打算提前做出成倍的投入。
以上即是企业实施和DevOps所面临的困难。