温州网站公司,昆明做网站哪家好,菜单微网站,常德 网站建设DevOps 精要:业务视角#xff08;三#xff09; 第3章 原则3.1 价值流3.2 部署流水线3.3 一切都应存储在版本控制系统中3.4 自动化配置管理3.5 完成的定义3.6 小结 第3章 原则
将原则从实践中分离出来#xff0c;这是一种很有用的做法。当然了#xff0c;这两个词分别有着… DevOps 精要:业务视角三 第3章 原则3.1 价值流3.2 部署流水线3.3 一切都应存储在版本控制系统中3.4 自动化配置管理3.5 完成的定义3.6 小结 第3章 原则
将原则从实践中分离出来这是一种很有用的做法。当然了这两个词分别有着不同的含义因而需要先对其定义达成一致。说到原则我们是指DevOps所基于的关键思想如果未被采纳或应用DevOps就没有多大的意义。说到实践我们是指为了取得预期成果而实施的与原则相匹配的活动。原则对任何应用DevOps的组织来说都是不变的而实践的采纳和调整很可能取决于具体的上下文。 “对于方法数量可能多达成千上万但原则只有少数几条。把握原则的人能够成功选择自己的方法。只尝试方法但忽略原则的人肯定会碰到麻烦。”——哈灵顿·爱默生Harrington Emerson 本章将给出全球DevOps专家所描述的核心原则。在第4章中我们将讨论实践部分。
3.1 价值流
DevOps的关键概念之一是价值流借自精益生产。这个概念本身已经使用了很长一段时间但随着实际应用的扩展出现许多新的出版物从实践角度充分探讨这个话题。
我们可以从创造价值以响应客户请求的角度来考虑组织中的工作。完成请求所需要实施的相关行动可以按顺序排列起来这称为“价值流”。通常组织处理着多样化的不同请求。同时传统组织多半工作在多个产品或服务上。这样一来公司中就存在很多个价值流。
价值流可视化的工作称为“价值流映射”。它开始于对拟分析产品的选择有时是有着最大优化机会的地方有时是承诺作出最快速重大改变并为方法的研究提供资源的地方。价值流映射可以通过两个步骤来完成
首先创建当前as-is图景然后创建未来to-be图景。
研究未来图景之所以也很重要有两个原因。
第一它有助于避免局部优化我们稍晚一些会讨论这一点。第二理解目标状态使得我们能够建立一个有清晰越清晰越好改进方向的现实改进机制。
实际上价值流映射的活动很简单需要识别处理请求的关键步骤记录每个步骤中实施的工作将这些步骤组织为一个创造预期结果的活动序列。困难之一是过度细化这时最终的映射图在一页纸中容纳不下。有些作者建议图中区块的数量限定在15个以下使基于这个图的进一步工作更容易开展。第二个困难是对到底有哪些步骤、这些步骤是如何执行及由谁执行达成一致。有些组织对流程并没有共同的理解这会导致长时间的争论。
一旦价值流图创建出来就可以往里面填充进一步的重要细节。写上负责的角色或人员名字比较有用。明确标出待处理队列出现堆积的步骤或者由于等待一个预先计划的事件而产生延迟的步骤例如月度CAB会议或者季度预算审批会也是一个好主意。最终最有价值的信息是流中每个步骤的3个度量数据即前置时间Lead TimeLT、处理时间Process TimePT及完整度与准确度百分比the Percent Complete and Accurate%C/A。实践中计算这些度量的数值对于没有部署相关的工具与实践的组织来说是一个很大的挑战。进行价值流映射的人易于低估LT和PT指标的值有时则相反人们诉诸极端的案例如被处理过长时间的请求这样会过高估计前置时间Lead Time的值。对于%C/A情况就更糟因为每个步骤的这个值人们是经常不知道的因而只能靠猜测。重要的是记住一点为了绘制当前价值流图需要研究真实的实践而不要指望不同指南中记录的文档信息这些信息也许只存在于管理者的幻想中或者仅仅用于极少数特殊的案例。
图3.1是一个价值流图的例子 我们为什么需要价值流映射为什么流的概念对DevOps如此重要
首先这个活动创建了一个映射可以帮助了解关键度量指标的当前as-is的数值这使得流程的参与者对此可以有清醒的认知。通常许多人知道当前的实践在某些地方比较低效但没有人知道问题的实际影响程度尤其是无法通过量化的数字来体现。在前面的例子中花在创造预期成果价值创造上的工作时间比例仅占总开销时间的18%。这个例子中给出的价值分析与现实中差别并不大在常规IT部门中类似的占比数字相当普遍。对%C/A指标来说假如组织习惯于发现任务不完整或偏离原本任务而将其回退到前序步骤中指标的情况甚至会更糟。其次过程的可视化呈现有助于聚焦到被创造的价值上而不是被实施的动作上。员工和管理者往往都能很好地理解自己的日常任务“做什么”而忽视预期的成果“为什么”。再次价值流图有助于识别和消除瓶颈并避免局部优化的陷阱即把时间和精力花费在根本没有效果甚至带来负面效果的约束消除上。基于高德拉特Eliyahu Goldratt提出的约束理论任何系统在任何时间点上有且仅有一个真正的瓶颈这个瓶颈拖慢了工作同时花在除了消除这个瓶颈点之外的任何事情上的精力都可以说是浪费。因此把一个价值流视为一个完整的系统是十分合理的。
在进行价值流映射之后通常可以提出以下几个问题。
1[%C/A]为什么这些工作步骤的%C/A值低于100%我们如何才能完全杜绝错误从一个步骤被传递到下一个步骤并因返工而浪费时间和资源2[LT]除了生产产品的时间具体有什么因素导致了前置时间lead time增加我们如何能够大幅降低队列和等待所损耗的时间3[PT]我们如何改变工作实践来降低每个步骤的处理时长
值得注意的是优化工作不应该只限制在分析当前as-is价值流图以尝试改进指标。相反有必要绘制未来to-be价值流图这也许会显然不同于当前工作的实践。这正是DevOps工具和实践能够发挥作用帮助改变IT工作方式的地方。最后对价值流的了解有助于实现DevOps的关键思想构建一个顺畅、一致流经各个步骤的价值流使得我们能够持续地、有节奏地、没有非必要的延迟并以最优的资源使用方式来交付成果。
3.2 部署流水线
理解价值流是通往DevOps的路上必经且重要的一步但是在”纸上”与价值流一起工作是不足够的。1.1节中描述的因素可以帮助我们采取接下来的重要步骤构建部署流水线。构建类似于流水线的需要可以用下面的例子来清晰阐释尝试关注应用中一行新代码在生产环境中生效所需的时间。如果这个结果是用天、周或者月来度量就说明价值流的确需要进行一些优化。部署流水线用以帮助实施这个优化这意味着变更尽可能自动化传递流经价值流上的所有步骤起始于“开发完成”这个结点然后一直到“完成部署进入运维”。
部署流水线的操作可以通过图3.2来阐释。 开发人员在版本控制系统中放入新的代码之后流水线就自动开始运行同时变更的信息被记录下来谁进行变更什么时候变更变更什么内容基于这条新的变更记录一套所需的临时测试环境就被自动化创建出来然后预先开发好的测试有序地启动运行。排列测试顺序的逻辑很简单能侦测到大部分错误的测试放在流水线的起端所有需要手工进行如果有的测试放到流水线的末端。未能通过的任何测试会造成这个变更的流水线中断并提供反馈给开发人员。要想重启流水线开发人员必须修复程序代码。除了测试环境外也可以自动创建流水线所需要的其他环境。这些环境占用的资源在使用完毕后自动释放掉。当然了如果测试逻辑允许且没有流水线的前序步骤本可拦截的变更而导致后续测试资源无效使用几个测试并行执行也是可能的。
因此流水线有助于处理几个重要的DevOps任务。
第一它节约资源在前序步骤没有完成之前不会启动后续步骤。第二流水线确保产品的质量未按要求实施的变更不会抵达生产环境系统总是处在可工作的状态中这一点后面再谈。这里的质量意味着与功能、性能、可用性、安全等相关的所有方面。第三流水线通过最大化各个步骤的自动化程度加速变更向生产环境的交付。第四流水线时常留下审计日志记录这使得所有进行的变更都能够受监控并且能够准确地度量流水线中的所有步骤这提供了可用于优化的非常有价值的数据。
实施部署流水线带来了以下挑战
1忽视理念流程、人与文化对自动化的过度热情导致创建出数量可观的自动化流水线但是没有人用它们。解决方案显而易见DevOps不只是自动化每一个团队成员都应当理解这一点。2在一开始没有足够的已开发的测试来确保流水线的稳定运行。解决这个问题除了增加测试的代码覆盖率也许也没有更好的办法累积的技术债务迟早都要偿还。3在实施后期有非常多测试在运行以至于一个变更流经流水线要花过长的时间并消耗庞大的计算资源尤其当有大量的微小变更时。经历过这类问题的公司一般都主动使用被称为“测试影响分析”的方法。在这个略显不准确但已被使用的名称之下是一些这样的实践测试系统使用专门的标记或人工智能工具从大量测试中选出那些与本次发起变更相关的测试而无需执行余下的测试。
还有三个与部署流水线有关的对DevOps很重要的概念持续集成、持续交付和持续部署。它们的含义各不相同下面的描述来自提出这些概念的专家的观点。
很多人认为“流水线pipeline”这个名称是类比自生产线例如来自汽车制造工厂的装配线。还有些人认为“流水线”这个词引用自流经水管的液体或其他物质而部署流水线应该是参照了这些类比。这两种观点都不太准确。
作为这个术语的作者Jez Humble韩捷和David Farley大卫·法利曾解释这个想法源自于现代处理器的传输管道在这里性能改进无法通过单纯的增加时钟频率来做到。被应用的架构解决方案是并行执行原本串行到达的指令。为了做到这一点处理器必须“猜测”并行流中的处理结果“假定”它们会在当前的流中按照预期来执行计算。否则计算的结果会被丢弃。虽然“运气不佳的猜测”会导致时间损失但由于那些“猜测”正确而获得加速的好处会获得比损失更多的补偿。
因而一个被正确实施的部署流水线允许开发和测试在时间上彼此独立这假定测试能够成功并进入下一个批次的处理中。同样的逻辑也被应用到并行测试上。
持续集成通常理解为持续地集成程序代码的过程持续意味着每当开发人员把变更的内容放到版本控制系统之后就会触发集成动作。软件开发实践一般涉及许多独立的代码分支不同的程序员和团队都要工作很长时间几日、几周或几月才能创建新的功能。在每一部分开发完成时甚至在等待工作在同一个产品上的所有团队完成各自的开发后把所有变更集成到一个构建中的痛苦过程就开始了。因为有很多程序员他/她们大体上异步地工作每个人都长时间工作在一个很大的变更上集成的过程本身变成一个很消耗时间的任务也许需要花几个星期。确实要全盘考虑所有的变更将它们与其他变更做比对更新测试以覆盖变更及对比重写部分或全部早前开发的功能然后重复以上所有工作直到新代码被流转进入运维状态。集成是软件开发中的重要环节并且集成事实上就是最初的测试。进一步的工作严重依赖于集成是否成功。
持续集成最初的描述出现在1999年Ken Beck肯特·贝克的书《极限编程解析》中。他提出简化集成并将其变成例行的工作。期望程序员工作在最小数目的分支理想情况下使用一个共用的统一代码库。这也假设开发人员可以做出最小的改变将工作分解成小片每个小片带一点风险但可以立即启动集成过程同时每个程序员至少每日一次将其代码放到版本控制系统中每次集成自动执行并允许立即识别与更正错误这意味着系统总能保持可工作状态。
持续交付由作者在同名书中进行了详细描述它扩展了持续集成的想法每次变更的代码在版本控制系统中的保存动作将触发集成过程以及整个部署流水线。因此所有尚未被完整及成功测试的变更不会被验收通过并需要立即进行修正。所有没有差错的变更进入对生产环境部署完全就绪的状态。
持续部署意味着从“当所有变更就绪时系统随时可以部署”的状态转化到“任何变更都被立即部署到生产环境”的状态。这个转化需要重新定义“发布”release这个术语它不再是IT的事情而是一个关于某个特定的新功能何时可用的业务决定。技术上在部署与测试完成之后功能已经在生产环境中但当业务例如市场部门需要时可以通过额外的程序设置来激活它。这个实践称为“影子发布”shadow release或“暗发布”dark launch。
在任何一个案例中所有这些实践都基于上述同样的部署流水线原则。
3.3 一切都应存储在版本控制系统中
现代软件开发人员已经习惯于使用图3.3所示的版本控制系统。最初这种类型的工具出现在20世纪70年代称为“源码存储系统”。如今已经很难找到一个不熟悉GitSubversion或Mercurial的程序员。而且不光只是程序员有很多的网站不光使用这些系统来存储源代码也存储生产环境的拷贝比如解析后的互联网系统或网站。 DevOps扩展了这些系统的使用如同它扩展很多其他领域一般。存储的不光是源代码还有与IT系统有关联的几乎所有一切测试、创建及修改数据库的脚本、构建脚本、环境创建脚本包括开发环境、部署脚本、工件、类库、文档、配置文件、甚至开发工具如编译器与IDE等。在前面列出的所有元素前面加上“所有”两个字也是合适的所有测试、所有脚本等等。唯一的例外是编译后的二进制代码因为它通常会占用很大的空间尤其是在每次变更之后重新创建而且如果其他一切都在存储系统中就可以重新生成。
这个原则实现了对运行中的系统各组成部分的空前级别的控制这些组成部分不可以通过其他工具来获取。当然了这个原则的应用需要改变如何与信息及配置一起工作的文化。
应用这个原则的一个结果是有能力确定变更了什么内容、何时变更以及谁做的变更。另外一个重要的特征是有能力将系统重置到过去任何一个时间点包括以最小的代价回滚出错的系统到一个有保证的工作状态。还有一个涌现出来的不是特别重要的特征是允许团队的任何成员自由删除不再需要的文件和文档而无需承担意外损失重要信息或产品的风险。我们都知道随着产品的不断开发引入的变更越来越多伴随的文件数量也不断增长清理这些碎片的风险很大除非有能够持续创建的受控的拷贝。
3.4 自动化配置管理
对上述原则进行拓展DevOps完全重构了对生产环境以及任何其他环境的管理。许多组织的传统实践是这样的通过一个预先定义的镜像创建出一个新的服务器然后管理员手工设置、安装及配置附加的软件包这些软件包既有系统层面的也有应用层面的。如果需要变更这些软件包或者它们的配置管理员用自己的账号连接到服务器上然后手工进行必要的设置。
这样的实践在DevOps的世界里完全不可能因为任何环境的任何变更都只能通过存储在版本控制系统里的脚本来实施。例如如果需要明天在测试环境增加一个新的类库管理员应该更新创建测试环境的脚本测试并放到版本控制系统中。当部署流水线运行时环境的创建就自动完成了。
前面提到的DevOps与日常实践之间的很多差别主要影响到开发和测试偶尔才会引发运维的兴趣。这个原则需要完全重构IT支持和运维的工作。确实这个时候管理员再也没有权限用其以往的方式挪动生产环境中的任何东西。
有一个常见的误解是当开发人员得到生产环境的管理员权限时DevOps就彻底实现了这混淆了职责也削弱了系统的可靠性。
实际上可以认为就算是管理员现在也被剥夺了生产环境中的权限因为从现在开始不再允许他/她们改变任何东西除非通过完全受控的脚本。
DevOps配置管理提供的收益如同从全面版本控制中获得的收益只不过主要的受益者运维人员。现在所有的变更都是受控的系统可以被快速重置到稳定状态。如果关键成员离开知识也不会遗失。
有些DevOps信徒狂热地捍卫这个实践他/她们建议使用全面IT基础设施审计系统来检测在任何地方发生的任何非授权变更然后立即解雇试图手工配置服务器或网络的员工。假如有几千台服务器和几百个工程师为了确保可持续性、质量和速度除了这样做可能也没有其他更好的选择。
有些团队走得更远不同环境的管理员密码会定期自动重置并且不会把新的密码告诉IT员工。这防止了对生产环境的未授权变更这个实践也应用到所有环境中包括开发环境、测试环境以及其他环境。
3.5 完成的定义
普通员工对工作的日常态度可以大致定义为下面两个阶段我在工作和我完成工作了。的确员工由于他/她们所完成的工作而获得报酬。分析师定义功能需求就算是工作完成了。开发人员写出程序代码就算是实现了整个业务中其所负责的部分。测试人员进行了测试也完成了其所负责的部分以此类推。然而在DevOps中这一切截然不同。
有一个关键原则不是说当有人干完了他/她们那个部分的工作就可以算是“完成”而是要等到客户接收到或者开始接收其所预期的价值。如图3.4所示这意味着整个价值流已经被完整地流经一直到生产环境只有这时工作才会被标记为“完成”。 虽然这个原则看起来显而易见但对原则的遵循并不会自然发生而需要一些管理上的努力。这些努力可以获得如下的收益。
1团队不是聚焦于完成的工作上我们做什么而是聚焦在结果即客户价值上为什么我们要做。2消除掉对具体领域工作的有限的责任“没有人抱怨这个钮扣”取而代之的是对团队整体结果的共有责任“这套衣服必须合身”。
有些想法激进的DevOps信徒坚持一个更加严格的完成定义Definition of Done。他/她们建议只有当应用运行在生产环境上并且所有的集成、测试和部署活动都自动化完成时新功能的创建才可以被视为“完成”。
3.6 小结
总结这一章我们先回顾一下本章开始时给出的对原则的定义。我们说过原则是指DevOps所基于的关键思想如果未被采纳或应用DevOps就没有多大的意义。
的确如果不理解、接受及应用价值流、部署流水线、全面版本控制系统、自动化配置管理以及完成的定义这些重要原则我们也许仍然可以玩各种DevOps实践想玩多久就玩多久但永远无法取得显著的成效。
