内容简介：如何迈出 DevOps 第一步？
作者简介：
刘相
普元 产品部副总经理、SOA 主任架构师，计算机应用技术硕士
十年IT行业经验，专注于企业软件平台，擅长分布式计算、SOA、BPM、DevOps、企业架构设计等领域。先后主导公司微服务应用开发平台、BPM 流程平台、云 PAAS 平台、DevOps 平台等系列产品的架构和设计工作。著有国内首本解析 SpringBatch 的中文原创图书《SpringBatch 批处理框架》
前言
DevOps 不仅仅是打通开发和运维之间的部门强，我们认为广义DevOps是提供从业务、研发、运营三者之间的一个完整的闭环管理，更高效便捷的实现产品的敏捷发布与管理。DevOps 构建整个IT交付的生产线，提升IT的工程化能力，实现工程效率的提升。
1、IT精益运营与DevOps
随着企业的 数字化转型 问题，要求IT从对内服务向内外兼修服务方式转变。传统应用的特点是：服务内部用户；需求相对明确、功能全、覆盖广、大集成、适合稳定发展阶段；难以快速变化、维护成本高，快速变革的新业务态无法支持。
新兴互联网应用的特点是：服务外部客户与合作伙伴；需求变动快、功能简单、独立和分散、分布式进化；应用规模变化大、大范围广泛的测试、易失败、对业务弹性、快速发布要求高。
普元实践了大量企业数字化转型的客户，包括红领、蓝月亮等企业。从IT仅为内部客户服务到逐步转向 2C。转变的结果导致IT交付的压力变大。在传统企业 IT人员又少的情况下（互联网企业有大量的人员保障），怎样快速地把我们的 IT交付出来，这是 DevOps 要解决的一个重要出发点。让整个IT部门从传统的支撑部门慢慢的变成业务创新部门，需要将IT的精益运营与 DevOps 无缝进行整合。
举个例子来讲，在飞机晚点的商业时刻，需要服务商帮助客户做酒店变更，客户的会议日程也要做出变更，所有这些事情都要求IT是自响应的，不需要像传统的方式还需客户进行自我服务。
这种创新业务对IT的交付要求变得异常苛刻。当然在IT建设的过程中有很多协作的问题、大量的技术债务、新的技术架构的冲击（微服务、容器等）。
导致业务应用变得非常复杂，交付困难，在这种情况下，DevOps平台或者说理念就逐步的会普及开来，以支撑业务的敏捷、企业大规模敏捷。
2、对DevOps的认知
提到 DevOps，可能每个人心里都有很多的图。有各种基于技术、流程、文化维度的，还有类似元素周期表的。
我想说的是，在做 DevOps 的时候，到底应该解决什么问题？其实这是我们必须要面对和回答的，只有回答了业务上带来的价值，才能让 DevOps更好的落地。
在传统企业里面，我们投入钱做IT建设的时候，它要的是投资回报率，也就是说我投了1块钱在IT上，究竟给企业能带来多大的业务价值。
结合我们实施的一个客户案例我们分详细 DevOps 实际带来的业务价值是什么？
确定了一个很明确的业务目标： DevOps 平台建设完成后，要求IT效率提升 50%，具体拆解下来包括几个维度：
-
测试环境和生产环境完全做到自动化部署；
-
业务流量有峰值或者浪涌的情况下，要能支持20倍的应用伸缩；
-
产品研发过程、项目管理过程完全能够做到数字化，对整个IT团队做数字化的考量；
基于具体业务目标而非技术目标，可以非常容易地在企业内部推广DevOps的建设。
企业 DevOps 思维 VS 互联网思维
互联网里面强调的一个字就是快（快到没有任何底线），要求你的业务快速上线，周上线、天上线，甚至一天多次上线；而对于企业来讲不能完全照搬互联网思维的快；在企业里面他们考虑的第一个是风险、质量。
传统企业和互联网还有一点不一样的地方，在金融或者保险的行业它是有监管要求的，不是说要把所有东西都做自动化，那是不可能的。在企业里面更多的要把应用的快速交付和质量保证找到一个平衡点。
DevOps 的本质是什么？
我们认为 DevOps 就是给IT的生产、研发、运维做了一条交付线。 本质上是提升整个IT的工程效率 ，解决软件生产的 工程化 问题。
DevOps 把生产、研发、运维和云平台（各种资源，IaaS、CaaS、物理机等）这样一个大的流程无缝打通。DevOps 建设的重点也是围绕这样一个大的流程做一个全链路的打通，固化企业各种流程和最佳实践。
上午分享的专家也讲到，未来的运维要从传统的运维走向面向应用的运维。其实 DevOps 也是一样的，DevOps 一定要站在一个应用的视角去做管理和把控。站在一个应用的视角，我们要做什么？
这个地方我给大家介绍普元 DevOps 平台对产品全生命周期的拆解：
主要包括产品（策划、研发、运营、推出）、项目（立项、执行、完工），而敏捷、持续集成、持续部署、持续交付都是 DevOps 的一个局部的阶段。
DevOps 在支持全生命周期的过程，要以产品的视角来看待，真正进行交付的时候，也要以产品为维度进行组织的设立（互联网公司通常如此）。但在企业里面，产品思维还没那么强，仍然按照项目的方式来实施。
因此在企业实施 DevOps 建设中，要从产品、项目两个维度来进行考量与拆解，关注每个阶段管理的工件关键流程、关键度两点。普元自身在进行 DevOps 建设过程中采用了 OPDM 的方法论进行每个环节的拆分，进而梳理出 DevOps 在每个关键环节的支撑能力。
DevOps核心观点一： DevOps平台需覆盖 产品、项目 的全周期
接下来我会给大家以一个 OPDM 的模型对每个环节做拆分：
-
第一个O是管理对象， 也就是在 DevOps 每一个生命周期环节里面，首先要看我们的管理对象是谁；
-
第二个P是要知道在这个环境里面， 谁要在 DevOps 上使用，服务的角色是谁；
-
第三个是D，有了这样的管理者和参与对象之后， 要知道我这个平台关键的升级点是哪些，我要支撑哪些流程，有哪些最好的实践能够在这个平台上落地；
-
最后一个是M，也就是度量， 这是衡量在 DevOps 平台上落地能力最好的度量工具。
首先从产品策划这个角度来看，主要是产品经理使用；管理的工件是产品愿景、MRD（市场需求）、BRD（业务需求），以及产品间的关联关系。DevOps平台设计过程中需要关注不同产品级别的流程设计，以及提供整个企业维度的业务域的划分与管理，包括业务模块和产品线。
这里面有一个最关键的点，你要针对企业未来生产的不同的产品，定义你的产品的运维过程、开发过程，以及它的支撑等级（每个级别的交付模式、运维模式都不同）。
立项周期、市场需求到业务需求的转换率是组织最重要的度量点。
从产品研发的视角来看，研发阶段主要是给产品经理使用；管理的工件是产品版本、 PRD、里程碑、路线图等。
DevOps平台设计过程中需要提供多版本的管理，以及类似版本号的最佳实践能力；
PRD积压、PRD变更、路线图偏离度是重点评估的度量指标；
在这个阶段我们最关心的是未来的 PRD 的积压，因为 PRD 的积压就说明了你的IT团队生产能力是什么样的。一旦我的产品需求大量进入backlog，团队知道部门的生产力跟不上，如果团队要多接的话，就要牺牲产品的质量。
在产品管理中，小小的版本号其实内部藏着很大的学问，基于版本号可以快速了解产品的版本，发布情况。甚至根据产品发布后的版本号可以快速回溯到关联代码、关联设计、关联任务、关联需求。如果能做到这些维度的关联，大家对IT交付过程的管理就会达到一个较高的水平。
另外基于版本号，非常容易实现产品的版本看板管理，随时了解产品不同版本的进展情况。
这是在普元 DevOps 平台上，我们的产品管理看板。在看板里，你可以明确知道我的IT产品里面有多少是正在研发的，有多少是在上线的，包括在不同环境里的产品状态。基于这个视角，我们认为 DevOps 要提供整个生产过程中最佳实践的孵化和落地的工作。
DevOps核心观点二： DevOps平台更重要的是提供 最佳实践
接下来是运营阶段，主要服务客服、运营团队、产品经理等角色；管理工件主要包括事件、问题、配置、服务的SLA；
DevOps 平台设计过程中需要产品发布的演练、紧急发布、故障处理以及知识库等积累；
客户满意度、MTTR、线上问题数是重点评估的度量指标；
在整个项目启动和立项的时候，我们一旦把产品定义完以后，接下来就基于某个产品要做项目的开发。在项目的立项和启动阶段，最主要的是组建项目团队包括权限，提供环境的快速开通。
DevOps 平台要提供整个团队管理的能力，提供不同的角色在平台上进行协作，分配不同的权限。
DevOps平台需要提供关键的流程支撑，包括对过程的选择（Scrum、传统瀑布模式等），定义对应的交付流水线（每个不同的企业和项目对应的交付流水线都不同）。
项目交付流水线的示例：
个项目的交付流程一旦固定之后，整个团队按照 DevOps 平台上对项目的交付流程进行协作，在流水线环节上定义具体的业务动作（集成、UAT、预发等），并可以设定自动执行还是人工接入；可以把每次交付的过程完全数字化、图形化的方式展现出来。
交付流水线确定后，相当于我们以前推动这种项目制度规范的事情，可以通过在平台上按照流程的方式执行，把企业的最佳实践能够固化到DevOps平台上。
DevOps核心观点三: DevOps平台， 让不同角色更好的 在流水线上协作
再看项目需求阶段，对产品经理、项目经理和架构师来说，平台要提供基于敏捷的需求管理，包括 EPIC、Feature、 Story、Task；
DevOps 平台关键设计需要提供基于工作项的管理，包括需求、任务、缺陷的管理；
需求变更率、任务燃尽图、积压线是重点评估的度量指标；
通过 DevOps 平台需要做全流程的打通，打通了以后能够给我们带来的好处是什么？可以从一个缺陷反向追溯隶属的产品版本，对应的Task，对应的需求，这样其实是做到很好的全链路的回溯。
项目架构阶段主要提供给架构师、测试经理使用；管理的工件是系统关 联、接口定义、部署容器、组件。
DevOps平台设计过程中需要提供部署拓扑图的设计，以及应用架构的设计（系统关联关系、接口定义等）；
设计变更率、设计偏差是重点评估的度量指标；
在架构里面，最主要的是要把我们的产品关联组建拆分、以及要确定它的部署架构，包括有多少组件；有了这些设计后，DevOps 平台后续可以根据部署容器进行资源绑定，实现自动化部署；根据关联关系确定依赖，进行部署器的依赖管理工作。
在部署设计中，提供了基于部署容器的概念，不同的部署容器可以编排依赖；在每个部署容器内部可以进行组件的编排。
容器其实是一个最小的部署设计单元，在部署容器内部可以定义组件，包括依赖的应用服务器、JDK、甚至包括操作系统等。
这样前期就可以定义系统的部署架构，而不是全部开发完成才定义部署的设计和安排；可以有效指导和约束后续的开发工作，使得质量提前进行管控。
DevOps核心观点四: DevOps平台， 管理前移 ，有效指导和约束 后续工作
构建阶段主要管理的是代码库、代码的 Review、构建定义和构建执行。
DevOps 平台设计过程中需要提供最优的代码库使用方式，完成整个关键的构建定义、构建策略等工作；
代码行、代码提交频率、构建次数/频率、构建时长、构建成功率是重点评估的度量指标；
对于代码开发模式，提供 TBD、GitHub、Git 多种不同的开发模式，让团队根据自己的实际情况选择不同的协作模式。
比如 TBD，其实是基于主干的开发，需要在主干上随时可以打出最新的版本；当有新的版本需要发布的时候，需要进行创建分支；在对发布的版本进行维护的时候，需要将代码提交到对应的分支、同时需要提交到主干。
DevOps 平台就是要把这些最佳实践固化进来，让项目团队成员去使用。
再举个例子。我们都知道要做持续集成，做完持续集成之后，是不是能够把最佳实践展现出来。在代码提交即触发构建的情况下，如果编译时间特别长，你怎么解决？如果你每次代码提交完以后，三分钟可能开发人员还能忍受，5分钟、10分钟甚至更长的时候，就是实践的浪费。
我们通过在 DevOps 平台上让开发人员设置超时时间，一旦超过这个时间，则认为构建失败。DevOps平台会自动向架构师反馈并提交一个缺陷，要么是架构拆分的问题、要么是构建存在过多的依赖，来实现架构的优化。
DevOps核心观点五： 对于 已有系统 ， DevOps平台不仅仅是 通过新的 工具 链实现快速交付，更是一种驱动 优化 的变革
测试阶段主要管理的是代码质量、测试用例、测试计划、测试报告。
DevOps 平台设计过程中需要支持多环境的自动部署、多策略的部署，提供测试团队进行快速的集成测试；
单元测试覆盖率、自动化测试比例、阶段 Bug 比例、Bug 打回率、部署成功率是重点评估的度量指标；
在测试阶段，需要尽可能的对测试用例进行自动化测试，能够大幅提升测试回归的效率，产品负责人可以快速的评估产品版本的质量。
预发/演练、上线阶段主要管理的是部署环境、组件实例管理、部署计划、交付物管理。
DevOps 平台设计过程中需要支持多策略的发布，包括全新发布、蓝绿、灰度、金丝雀；应用可靠部署模式（集群、多主、主备等）；
单元测试覆盖率、自动化测试比例、阶段Bug比例、Bug打回率、部署成功率是重点评估的度量指标；
大家在讲 DevOps 一定要做自动化，但是我们认为在做 DevOps 的时候，肯定不是全部的完全自动化没有人工参与的。给大家举个例子，我们做滚动升级的时候怎么实现的？
再基于步长的应用伸缩过程中，第一个步长绳索后，需要测试新增节点的可用性，在OK的情况下才继续做后续的伸缩并可以设定新的步长。
DevOps核心观点六: DevOps平台，并 不是自动化一切 ， 而是在可控中有选择的自动化
总结一下，我们对 DevOps的认知：
-
DevOps是一条IT生产线，核心价值在于提升工程效率；
-
覆盖产品、项目领域
-
体现出最佳实践
-
加强协作
-
优化架构
-
可控范围的自动化
3、企业实施 DevOps 的建设难点
接下来为大家从业务、方法论、技术三个维度分析实施DevOps的建设难点。
-
业务：
1、对于企业已有的工具，我们需要考虑怎么集成，集成哪些；绝不是大而全的集成。如果专业系统足够自动化、自助化，建议逐步纳入到 DevOps 平台，比如针对于底层的 IaaS 平台或者容器云平台，我们就只是进行接口调用，而并非功能的接管（专业的使用方式，还需要登录 IaaS 平台进行操作）；而对于 jenkins 这种敏感资源，更倾向于把整个 jenkins 封装起来，不对外进行暴露。
2、关于 DevOps 的概念模型，平台的概念模型如图所示，划分为5大领域：产品域、组织机构与权限域，项目域、部署域、持续集成域，在实际DevOps平台落地过程中，可以从某个局部的域开始做交付。
3、在实施DevOps平台时，需要把企业的标准、规范固化和落地的平台，如果我们仅仅是把工具打通，带来的业务价值是非常低的。
-
方法论：
1、从方法论来看，首先建议大家从工程效率或者工程度量的角度来衡量；
2、采用可迭代的MVP的方式交付产品，每次交付的都是完整可用的产品，方便快速对产品进行验证和反馈；
-
技术
采用微服务的架构进行平台建设，按照功能的维度进行微服务拆分，每个微服务内部严格定义 API、SPI；API 是 DevOps 平台对外提供的接口，可以方便集成；SPI 是对外集成的接口抽象，未来方便更换不同的集成工具；
4、DevOps 平台关键设计
DevOps 平台完整功能如下：
整个 DevOps 归类了六大块能力，分为敏捷过程、持续交付、度量和优化三大能力，其中敏捷过程包括产品、项目；交付流水线包括构建、部署、持续交付。
关键设计一：支持多种应用架构
DevOps 平台能够支持多用应用架构，对上层的应用其实是透明的。
关键设计二：支持异构设施的多策略发布
设计阶段：将部署架构分为三层：部署装配、部署容器、部署组件。设计（Design），是在装配（Assembly）内对应用/系统的架构的描述；而应用/系统，是由含有多个组件（Component）的系统（Platform）组成的。
部署转换：将部署装配和资源（包括物理机、虚拟机、容器）进行绑定并生成部署计划，按照对应的部署计划进行执行，可以将应用推送到不同的环境中；支持灰度发布、全量发布、金丝雀、蓝绿部署等；
组件运营：对产生的应用实例进行运营，支持启动、停止、重启、状态检查、应用伸缩能力；
采用部署容器的设计，可以快速添加新的部署容器类型，下面给出了一个扩展支持移动应用的部署容器，可以快速的接入到 DevOps 平台中。
关键设计三：将企业最佳实践固化到 DevOps 平台
需要总结梳理出固有的流程、规范和最佳实践，将其固化到 DevOps 平台中，可以将项目管理（日报、周报、会议）、实时沟通工具、各种模板、版本管理策略等最佳实践落地，保障所有的团队可以快速的掌握和使用这些技能。
5、如何迈出DevOps第一步
最后介绍一下我们是怎么在企业里面开始 DevOps 第一步的。
这里我给大家建议了三个方向：
第一，从统一的组织架构、认证、SSO。企业里面有这么多IT系统，先做简单的打通，否则后面做 DevOps 是非常困难的；
第二，从集成和自动化部署开始，这是最容易实现，也是最容易让你的业务部门和老板感知到DevOps价值的入口；
第三，如果真正系统化地做 DevOps，我们需要把整个企业自身的研发过程和运维过程梳理出来，然后固化；
6、总结
最后总结一下，我们认为企业里面做 DevOps，本质上就是做企业的IT生产线，最终是实现整个企业级的数字化生产线。目前大家都在讲企业的数字化转型，相信通过 DevOps 可以先让IT部门进行数字化转型，最终实现企业的大规模敏捷。
如果有更多疑问
欢迎与作者联系
好友暗号「 GOPS 」
近期好文 ：
《Jenkins 创始人：持续交付的 What、Why 及 How》
《腾讯QQ日请求12亿的运营平台到底有多diao(三声)？》
这将是一场
更深
更广
更久
史诗级 · DevOps 盛会
【DevOpsDays · 上海站】
点击 “ 阅读原文 ” ，享受专有特惠
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
HTML Dog
Patrick Griffiths / New Riders Press / 2006-11-22 / USD 49.99
For readers who want to design Web pages that load quickly, are easy to update, accessible to all, work on all browsers and can be quickly adapted to different media, this comprehensive guide represen......一起来看看 《HTML Dog》 这本书的介绍吧!
