如何迈出 DevOps 第一步?
前言DevOps 不仅仅是打通开发和运维之间的部门强,我们认为广义DevOps是提供从业务、研发、运营三者之间的一个完整的闭环管理,更高效便捷的实现产品的敏捷发布与管理。DevOps 构建整个IT交付的生产线,提升IT的工程化能力,实现工程效率的提升。 1、IT精益运营与DevOps随着企业的数字化转型问题,要求IT从对内服务向内外兼修服务方式转变。传统应用的特点是:服务内部用户;需求相对明确、功能全、覆盖广、大集成、适合稳定发展阶段;难以快速变化、维护成本高,快速变革的新业务态无法支持。新兴互联网应用的特点是:服务外部客户与合作伙伴;需求变动快、功能简单、独立和分散、分布式进化;应用规模变化大、大范围广泛的测试、易失败、对业务弹性、快速发布要求高。普元实践了大量企业数字化转型的客户,包括红领、蓝月亮等企业。从IT仅为内部客户服务到逐步转向 2C。转变的结果导致IT交付的压力变大。在传统企业 IT人员又少的情况下(互联网企业有大量的人员保障),怎样快速地把我们的 IT交付出来,这是 DevOps 要解决的一个重要出发点。让整个IT部门从传统的支撑部门慢慢的变成业务创新部门,需要将IT的精益运营与 DevOps 无缝进行整合。 mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TydqH2oQHUYiciaOBw3Lxzkibmg3DAIaD7w1Uo74EhlLW5eFfqvh9PusB7jw/0?举个例子来讲,在飞机晚点的商业时刻,需要服务商帮助客户做酒店变更,客户的会议日程也要做出变更,所有这些事情都要求IT是自响应的,不需要像传统的方式还需客户进行自我服务。这种创新业务对IT的交付要求变得异常苛刻。当然在IT建设的过程中有很多协作的问题、大量的技术债务、新的技术架构的冲击(微服务、容器等)。导致业务应用变得非常复杂,交付困难,在这种情况下,DevOps平台或者说理念就逐步的会普及开来,以支撑业务的敏捷、企业大规模敏捷。 2、对DevOps的认知提到 DevOps,可能每个人心里都有很多的图。有各种基于技术、流程、文化维度的,还有类似元素周期表的。 mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TydlJ8zuRn45ZMcX347zarVIKgUnfAibBuk7ibo022rm4rXx5Edmib991JCw/0?我想说的是,在做 DevOps 的时候,到底应该解决什么问题?其实这是我们必须要面对和回答的,只有回答了业务上带来的价值,才能让 DevOps更好的落地。在传统企业里面,我们投入钱做IT建设的时候,它要的是投资回报率,也就是说我投了1块钱在IT上,究竟给企业能带来多大的业务价值。结合我们实施的一个客户案例我们分详细 DevOps 实际带来的业务价值是什么? mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TydtoEeAibia7WiceE0iayCKfoOMKpDq1kUSgoOMj1zbVYnQnFcPiaOial7cYWw/0?确定了一个很明确的业务目标: DevOps 平台建设完成后,要求IT效率提升 50%,具体拆解下来包括几个维度:[*]测试环境和生产环境完全做到自动化部署;
[*]业务流量有峰值或者浪涌的情况下,要能支持20倍的应用伸缩;
[*]产品研发过程、项目管理过程完全能够做到数字化,对整个IT团队做数字化的考量;
基于具体业务目标而非技术目标,可以非常容易地在企业内部推广DevOps的建设。企业 DevOps 思维 VS 互联网思维互联网里面强调的一个字就是快(快到没有任何底线),要求你的业务快速上线,周上线、天上线,甚至一天多次上线;而对于企业来讲不能完全照搬互联网思维的快;在企业里面他们考虑的第一个是风险、质量。传统企业和互联网还有一点不一样的地方,在金融或者保险的行业它是有监管要求的,不是说要把所有东西都做自动化,那是不可能的。在企业里面更多的要把应用的快速交付和质量保证找到一个平衡点。DevOps 的本质是什么? 我们认为 DevOps 就是给IT的生产、研发、运维做了一条交付线。本质上是提升整个IT的工程效率,解决软件生产的工程化问题。 mmbiz_png/yNKv1P4Q9eXMjblM5xhEPOjXyHXib4eg11o4MpeNUaCwfkh7RJ4A37iaklMia8HkBgnKyrajzbhFjibicfqtt0pKicPQ/0?wx_fmt=pngDevOps 把生产、研发、运维和云平台(各种资源,IaaS、CaaS、物理机等)这样一个大的流程无缝打通。DevOps 建设的重点也是围绕这样一个大的流程做一个全链路的打通,固化企业各种流程和最佳实践。上午分享的专家也讲到,未来的运维要从传统的运维走向面向应用的运维。其实 DevOps 也是一样的,DevOps 一定要站在一个应用的视角去做管理和把控。站在一个应用的视角,我们要做什么?这个地方我给大家介绍普元 DevOps 平台对产品全生命周期的拆解: mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4Tyd53n8zOzq1On0qEgiaELPSaN1IaRwRltiaEkDmTZrOHvXIFHZGwknZibMA/0?主要包括产品(策划、研发、运营、推出)、项目(立项、执行、完工),而敏捷、持续集成、持续部署、持续交付都是 DevOps 的一个局部的阶段。 DevOps 在支持全生命周期的过程,要以产品的视角来看待,真正进行交付的时候,也要以产品为维度进行组织的设立(互联网公司通常如此)。但在企业里面,产品思维还没那么强,仍然按照项目的方式来实施。因此在企业实施 DevOps 建设中,要从产品、项目两个维度来进行考量与拆解,关注每个阶段管理的工件关键流程、关键度两点。普元自身在进行 DevOps 建设过程中采用了 OPDM 的方法论进行每个环节的拆分,进而梳理出 DevOps 在每个关键环节的支撑能力。DevOps核心观点一:DevOps平台需覆盖产品、项目的全周期接下来我会给大家以一个 OPDM 的模型对每个环节做拆分:
[*]第一个O是管理对象,也就是在 DevOps 每一个生命周期环节里面,首先要看我们的管理对象是谁;
[*]第二个P是要知道在这个环境里面,谁要在 DevOps 上使用,服务的角色是谁;
[*]第三个是D,有了这样的管理者和参与对象之后,要知道我这个平台关键的升级点是哪些,我要支撑哪些流程,有哪些最好的实践能够在这个平台上落地;
[*]最后一个是M,也就是度量,这是衡量在 DevOps 平台上落地能力最好的度量工具。
mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TydgpFcjicZEmoqL8q7iaBtHOksJvhoRY0bY6NHwvtn9zaMw55jZYfYAQyA/0?首先从产品策划这个角度来看,主要是产品经理使用;管理的工件是产品愿景、MRD(市场需求)、BRD(业务需求),以及产品间的关联关系。DevOps平台设计过程中需要关注不同产品级别的流程设计,以及提供整个企业维度的业务域的划分与管理,包括业务模块和产品线。这里面有一个最关键的点,你要针对企业未来生产的不同的产品,定义你的产品的运维过程、开发过程,以及它的支撑等级(每个级别的交付模式、运维模式都不同)。立项周期、市场需求到业务需求的转换率是组织最重要的度量点。 mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4Tydlf3g1dbwicTaMxRlA0NvN4hvFxy49edjl6fyK00kzWn44RwYT4ZpByw/0?从产品研发的视角来看,研发阶段主要是给产品经理使用;管理的工件是产品版本、 PRD、里程碑、路线图等。
DevOps平台设计过程中需要提供多版本的管理,以及类似版本号的最佳实践能力;PRD积压、PRD变更、路线图偏离度是重点评估的度量指标;在这个阶段我们最关心的是未来的 PRD 的积压,因为 PRD 的积压就说明了你的IT团队生产能力是什么样的。一旦我的产品需求大量进入backlog,团队知道部门的生产力跟不上,如果团队要多接的话,就要牺牲产品的质量。 mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TydoFKU4RyT50cULbOhh7AnDUkP54QdzX24b8wuBXIialpcwKmmdUp0Fdw/0?在产品管理中,小小的版本号其实内部藏着很大的学问,基于版本号可以快速了解产品的版本,发布情况。甚至根据产品发布后的版本号可以快速回溯到关联代码、关联设计、关联任务、关联需求。如果能做到这些维度的关联,大家对IT交付过程的管理就会达到一个较高的水平。另外基于版本号,非常容易实现产品的版本看板管理,随时了解产品不同版本的进展情况。 mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4Tyd9dvvgvq8c26ibU5k912l83sXvmht4ck9sT98n9FFVsqTBktOM1N70Bg/0?这是在普元 DevOps 平台上,我们的产品管理看板。在看板里,你可以明确知道我的IT产品里面有多少是正在研发的,有多少是在上线的,包括在不同环境里的产品状态。基于这个视角,我们认为 DevOps 要提供整个生产过程中最佳实践的孵化和落地的工作。DevOps核心观点二:DevOps平台更重要的是提供最佳实践mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TydWGUwxatictibqticJsp5cST210eaNqpAsEibg9R7MNg5HIGhXwAR7jw8rw/0?接下来是运营阶段,主要服务客服、运营团队、产品经理等角色;管理工件主要包括事件、问题、配置、服务的SLA;DevOps 平台设计过程中需要产品发布的演练、紧急发布、故障处理以及知识库等积累;客户满意度、MTTR、线上问题数是重点评估的度量指标; mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TydQ7F1EyaNbySRLpeg6P7rgxyD3lWbmvIPJ9zWNS6iaJjTmPPaSPiajesw/0?在整个项目启动和立项的时候,我们一旦把产品定义完以后,接下来就基于某个产品要做项目的开发。在项目的立项和启动阶段,最主要的是组建项目团队包括权限,提供环境的快速开通。DevOps 平台要提供整个团队管理的能力,提供不同的角色在平台上进行协作,分配不同的权限。DevOps平台需要提供关键的流程支撑,包括对过程的选择(Scrum、传统瀑布模式等),定义对应的交付流水线(每个不同的企业和项目对应的交付流水线都不同)。项目交付流水线的示例: mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TydIibMFEsp6oG8jkF5DiboY4Iqrk1CjCIo7yEgiaEmLAGIn8OtzXHuXwPUQ/0?个项目的交付流程一旦固定之后,整个团队按照 DevOps 平台上对项目的交付流程进行协作,在流水线环节上定义具体的业务动作(集成、UAT、预发等),并可以设定自动执行还是人工接入;可以把每次交付的过程完全数字化、图形化的方式展现出来。交付流水线确定后,相当于我们以前推动这种项目制度规范的事情,可以通过在平台上按照流程的方式执行,把企业的最佳实践能够固化到DevOps平台上。DevOps核心观点三:DevOps平台,让不同角色更好的在流水线上协作mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TydDvCR9Av99QicmWLcxwnQhQcN9hZ2JSzWuqaZ09MuXvEw9lCznlmyz1Q/0?再看项目需求阶段,对产品经理、项目经理和架构师来说,平台要提供基于敏捷的需求管理,包括 EPIC、Feature、 Story、Task;
DevOps 平台关键设计需要提供基于工作项的管理,包括需求、任务、缺陷的管理;需求变更率、任务燃尽图、积压线是重点评估的度量指标;通过 DevOps 平台需要做全流程的打通,打通了以后能够给我们带来的好处是什么?可以从一个缺陷反向追溯隶属的产品版本,对应的Task,对应的需求,这样其实是做到很好的全链路的回溯。 mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TydKon08vCT2iatU3vaOD1w59ibiajuXSJ1R1s4KibH7svFOuXk5rdG8prP2g/0?项目架构阶段主要提供给架构师、测试经理使用;管理的工件是系统关联、接口定义、部署容器、组件。
DevOps平台设计过程中需要提供部署拓扑图的设计,以及应用架构的设计(系统关联关系、接口定义等);设计变更率、设计偏差是重点评估的度量指标;在架构里面,最主要的是要把我们的产品关联组建拆分、以及要确定它的部署架构,包括有多少组件;有了这些设计后,DevOps 平台后续可以根据部署容器进行资源绑定,实现自动化部署;根据关联关系确定依赖,进行部署器的依赖管理工作。在部署设计中,提供了基于部署容器的概念,不同的部署容器可以编排依赖;在每个部署容器内部可以进行组件的编排。 mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TydsrC0BgsEuMzhXObs811MpSjxG0fNAbQGHfmkOgCibg0s8YNv4b9AELA/0?容器其实是一个最小的部署设计单元,在部署容器内部可以定义组件,包括依赖的应用服务器、JDK、甚至包括操作系统等。
这样前期就可以定义系统的部署架构,而不是全部开发完成才定义部署的设计和安排;可以有效指导和约束后续的开发工作,使得质量提前进行管控。DevOps核心观点四:DevOps平台,管理前移,有效指导和约束后续工作mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TydKacKEza0sn2gPY5UWjRYLzJXVkAibqxYK2SiazABFa66jrfteWn7XDKA/0?构建阶段主要管理的是代码库、代码的 Review、构建定义和构建执行。DevOps 平台设计过程中需要提供最优的代码库使用方式,完成整个关键的构建定义、构建策略等工作;代码行、代码提交频率、构建次数/频率、构建时长、构建成功率是重点评估的度量指标;对于代码开发模式,提供 TBD、GitHub、Git 多种不同的开发模式,让团队根据自己的实际情况选择不同的协作模式。比如 TBD,其实是基于主干的开发,需要在主干上随时可以打出最新的版本;当有新的版本需要发布的时候,需要进行创建分支;在对发布的版本进行维护的时候,需要将代码提交到对应的分支、同时需要提交到主干。 mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TydHXx455LBq7eseLmrYR50vg3o1kRfC6fQEBDjj5ibeCTmfgQ4mXmAWCA/0?DevOps 平台就是要把这些最佳实践固化进来,让项目团队成员去使用。再举个例子。我们都知道要做持续集成,做完持续集成之后,是不是能够把最佳实践展现出来。在代码提交即触发构建的情况下,如果编译时间特别长,你怎么解决?如果你每次代码提交完以后,三分钟可能开发人员还能忍受,5分钟、10分钟甚至更长的时候,就是实践的浪费。 mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TydatWRYxvpicCoHrq86pSiaG2qqx0mKVZwfRBMlT16iccSh9K2EtxeSWAwg/0?我们通过在 DevOps 平台上让开发人员设置超时时间,一旦超过这个时间,则认为构建失败。DevOps平台会自动向架构师反馈并提交一个缺陷,要么是架构拆分的问题、要么是构建存在过多的依赖,来实现架构的优化。
DevOps核心观点五:对于已有系统, DevOps平台不仅仅是通过新的工具链实现快速交付,更是一种驱动优化的变革mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TydFuSiaU3oXbgjCsSBn5YIf4KTesFbo2qqkRMnBDVGfwrJ0mvJvHwFsxQ/0?测试阶段主要管理的是代码质量、测试用例、测试计划、测试报告。
DevOps 平台设计过程中需要支持多环境的自动部署、多策略的部署,提供测试团队进行快速的集成测试;单元测试覆盖率、自动化测试比例、阶段 Bug 比例、Bug 打回率、部署成功率是重点评估的度量指标;在测试阶段,需要尽可能的对测试用例进行自动化测试,能够大幅提升测试回归的效率,产品负责人可以快速的评估产品版本的质量。mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TydI9VFnlD0juj8N6WPAuzKA0tFgLMMRmPJZrFsNRx88etutY8yh6xQlw/0?预发/演练、上线阶段主要管理的是部署环境、组件实例管理、部署计划、交付物管理。DevOps 平台设计过程中需要支持多策略的发布,包括全新发布、蓝绿、灰度、金丝雀;应用可靠部署模式(集群、多主、主备等);单元测试覆盖率、自动化测试比例、阶段Bug比例、Bug打回率、部署成功率是重点评估的度量指标;大家在讲 DevOps 一定要做自动化,但是我们认为在做 DevOps 的时候,肯定不是全部的完全自动化没有人工参与的。给大家举个例子,我们做滚动升级的时候怎么实现的? mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TydF4el9dJ70wd7UX3dAFjwwon5UTUjj2icygy72JSDvqJVHO7ibvoewIcQ/0?再基于步长的应用伸缩过程中,第一个步长绳索后,需要测试新增节点的可用性,在OK的情况下才继续做后续的伸缩并可以设定新的步长。
DevOps核心观点六:DevOps平台,并不是自动化一切,而是在可控中有选择的自动化总结一下,我们对 DevOps的认知:
[*]DevOps是一条IT生产线,核心价值在于提升工程效率;
[*]覆盖产品、项目领域
[*]体现出最佳实践
[*]加强协作
[*]优化架构
[*]可控范围的自动化
3、企业实施 DevOps 的建设难点 接下来为大家从业务、方法论、技术三个维度分析实施DevOps的建设难点。mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TydYBGMkTPlPy2icDxsRwpD3USKWN0EnUZ62KG88QBQrGPXtoevUSicfpibg/0?
[*]业务:
1、对于企业已有的工具,我们需要考虑怎么集成,集成哪些;绝不是大而全的集成。如果专业系统足够自动化、自助化,建议逐步纳入到 DevOps 平台,比如针对于底层的 IaaS 平台或者容器云平台,我们就只是进行接口调用,而并非功能的接管(专业的使用方式,还需要登录 IaaS 平台进行操作);而对于 jenkins 这种敏感资源,更倾向于把整个 jenkins 封装起来,不对外进行 。 2、关于 DevOps 的概念模型,平台的概念模型如图所示,划分为5大领域:产品域、组织机构与权限域,项目域、部署域、持续集成域,在实际DevOps平台落地过程中,可以从某个局部的域开始做交付。 mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4Tyd9kncYVeKy5Z57Bx214B6gx72IhGbxCg8UR9AhSFwRMbwXtvMIIJeHg/0?3、在实施DevOps平台时,需要把企业的标准、规范固化和落地的平台,如果我们仅仅是把工具打通,带来的业务价值是非常低的。
[*]方法论:
1、从方法论来看,首先建议大家从工程效率或者工程度量的角度来衡量; mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TydLFLx5ib6bPZPEtic8jma2Kc0VQMJNzC1jjggWoicQkCyOzdiaJcpOdrt8g/0? 2、采用可迭代的MVP的方式交付产品,每次交付的都是完整可用的产品,方便快速对产品进行验证和反馈;
mmbiz_png/yNKv1P4Q9eXMjblM5xhEPOjXyHXib4eg1MdbPa6U5oBjARnU7frRWalAsTUCcW6LyMjZH4Y8JK4vKkEnYbdegnQ/0?wx_fmt=png
[*]技术
采用微服务的架构进行平台建设,按照功能的维度进行微服务拆分,每个微服务内部严格定义 API、SPI;API 是 DevOps 平台对外提供的接口,可以方便集成;SPI 是对外集成的接口抽象,未来方便更换不同的集成工具; mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TydxfOCbewBqgIskr7fibQwLjbtayLwoZf2ttp650X4CHEmNHjVxCM5XQQ/0?4、DevOps 平台关键设计DevOps 平台完整功能如下: mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TyddNboY1jtiazEFb7jcylmDd67AicwcmicdHJRiaLA90M7Dia51ut0nP3jQ4g/0?
整个 DevOps 归类了六大块能力,分为敏捷过程、持续交付、度量和优化三大能力,其中敏捷过程包括产品、项目;交付流水线包括构建、部署、持续交付。关键设计一:支持多种应用架构DevOps 平台能够支持多用应用架构,对上层的应用其实是透明的。 mmbiz_png/yNKv1P4Q9eXMjblM5xhEPOjXyHXib4eg1dHGV1iaAH4THe8sLYd75wGibcJSnKcd380amfHhScxEfRxWibj3rdj6bw/0?wx_fmt=png关键设计二:支持异构设施的多策略发布 mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TydH4zzHCuH8lue94VnEicANfrcXYic8mJCSP4iczdDbLM1B4uvodapeiaOzg/0?设计阶段:将部署架构分为三层:部署装配、部署容器、部署组件。设计(Design),是在装配(Assembly)内对应用/系统的架构的描述;而应用/系统,是由含有多个组件(Component)的系统(Platform)组成的。
部署转换:将部署装配和资源(包括物理机、虚拟机、容器)进行绑定并生成部署计划,按照对应的部署计划进行执行,可以将应用推送到不同的环境中;支持灰度发布、全量发布、金丝雀、蓝绿部署等;组件运营:对产生的应用实例进行运营,支持启动、停止、重启、状态检查、应用伸缩能力;采用部署容器的设计,可以快速添加新的部署容器类型,下面给出了一个扩展支持移动应用的部署容器,可以快速的接入到 DevOps 平台中。 mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TydeXx6FyMiacH884eXuV8bpSzHNgaHk78FPg9CTodZsoMkXw1GYYPN1sA/0?关键设计三:将企业最佳实践固化到 DevOps 平台
需要总结梳理出固有的流程、规范和最佳实践,将其固化到 DevOps 平台中,可以将项目管理(日报、周报、会议)、实时沟通工具、各种模板、版本管理策略等最佳实践落地,保障所有的团队可以快速的掌握和使用这些技能。 mmbiz_png/yNKv1P4Q9eXMjblM5xhEPOjXyHXib4eg13SQ5mblaBnuWAa6akM8pBav0xg6nr2ALmkZ265KUwic9vkH27mzCM2Q/0?wx_fmt=png5、如何迈出DevOps第一步最后介绍一下我们是怎么在企业里面开始 DevOps 第一步的。mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TydmFSVfz8652t7icudmSmCGVhjct5QW7t2LaQ8YwCT1kZoGOsjhGUNO7g/0?这里我给大家建议了三个方向:
第一,从统一的组织架构、认证、SSO。企业里面有这么多IT系统,先做简单的打通,否则后面做 DevOps 是非常困难的;第二,从集成和自动化部署开始,这是最容易实现,也是最容易让你的业务部门和老板感知到DevOps价值的入口;第三,如果真正系统化地做 DevOps,我们需要把整个企业自身的研发过程和运维过程梳理出来,然后固化; 6、总结mmbiz_png/V3gR9ojUDjNu5EjepEicd0E32SZnM4TydiafzibNU68KTsDBmWdwHZmRoQJetNXta1KCKDYibMWgflW5vyTB7ZDGfg/0?最后总结一下,我们认为企业里面做 DevOps,本质上就是做企业的IT生产线,最终是实现整个企业级的数字化生产线。目前大家都在讲企业的数字化转型,相信通过 DevOps 可以先让IT部门进行数字化转型,最终实现企业的大规模敏捷。
页:
[1]