\

本文要点

\\

• 如何使用DevOps协调企业各部分间的工作取决于由架构耦合方式导致的团队规模。\\t
• 为什么企业转型从解决开发过程中最为低效问题着手会更为成功。\\t
• 为什么改变人们的工作方式需要对当前自身的做法导致整个软件开发和交付系统低效的原因形成共识。\\t
• 使用度量指标按团队划分部署流水线是如何有助于理解软件开发过程中最为低效的问题。\\t
• 如何在增加部署频次的同时使用DevOps维护或改进质量与安全，去除流程中存在多年的低效问题。\

\\

在《在企业中发起和推广DevOps》一书中，作者Gary Gruver提出了一种基于DevOps的方法，用于持续改进大型企业中的开发和交付流程。书中的建议可用于部署流水线的优化、代码的频繁发布以及向用户的交付。

\\

InfoQ的读者可以下载到《Starting and Scaling DevOps in the Enterprise》一书的节选内容。

\\

InfoQ采访了Gary Gruver，访谈内容涉及：什么使得DevOps从根本上不同于其它的敏捷方法、DevOps是如何帮助优化需求和规划活动的、用于持续集成的指标、在紧密耦合架构的企业内推广DevOps和在松散耦合架构的企业内推广之间的不同之处、大型组织中损耗的类型及解决方法、为什么高管应该领导持续改进及应如何做到这一点。

\\

InfoQ：能介绍一下您撰写本书的原因吗？

\\

\

Gary Gruver： 当我开始和越来越多想要转变软件交付过程的大型企业共事时，我发现其中一个最大的挑战是开启持续改进之旅，并统一所有人对改变问题的认识。为使该工作得以开展并保持积极的势头，我强烈感受到持续改进过程应从对组织影响最为显著的改变着手。我发现自己已经花费大量时间分析了不同组织中的软件交付过程，帮助他们确定问题所在。在这一过程中，我看到了不少共性的问题，也发现每个企业都面临一些独特的挑战，不同的挑战导致改进中各项工作的优先级各异。我开始加班加点地优化在不同业务分析中自己所使用的过程，切实体会到了将方法形成文档的重要性，这些文档形成了我举办的讲习班的准备工作，并通过讲习班共享出来。为启动部署流水线的筹划，我会将这些文档提前发给组织中的几位关键领导，这样可为讲习班提供很好的素材。这样讲习班才能真正帮助每个人统一对最具影响的改变的认识，并让每个人对DevOps之旅的开始感到兴奋。我认识到自己不可能为每个有改进过程需要的企业举办讲习班，这就是我决定出版本书的原因，我认为其他人可能会发现书中的方法很有帮助。

\

\\

InfoQ：本书的意向读者是哪些人？

\\

\

Gruver：本书面向具有紧耦合架构的大型企业。本书对小型企业益处不大，对于亚马逊这样支持小型团队独立工作架构的大型企业也是如此。这些类型的企业最好是阅读DevOps细则手册，从中找到一些他们仍然未实现的好实践。本书并非面向这类企业，而是面向那些必须协调多人的软件进行开发、确认和发布的大型企业。本书为这样的企业提供了系统性的方法，用于分析他们的流程，识别能帮助改进企业效率的改变。

\

\\

InfoQ：是什么使得DevOps从根本上不同于其它的敏捷方法？

\\

\

Gruver：我尽量避免过分纠缠于具体的名称。只要变更正能帮助你改进软件开发和交付流程，谁又会关心这些变更叫什么呢？对于我自己而言，更为重要的是明白你正努力寻求解决的低效问题，进而确定最有帮助的实践。在很多方面上，DevOps仅是一种以更为频繁方式发布代码的敏捷原则，当敏捷扩展推广到企业级时就被抛弃了。在架构紧耦合的大型企业中发布代码比较困难，这需要协调多个团队间的不同代码、环境定义和部署流程。对如何解决该问题，处于大型企业中的小型敏捷团队尚未很好地准备好。因而在大多数企业的敏捷实现中，这个以频繁方式向客户发布代码的基本敏捷原则被抛弃了。敏捷团队倾向于聚焦在自身可以解决的问题，例如在特定环境中获得产品所有者的签名，这样的特定环境是隔离于与大型企业的复杂性问题隔离的。

\\

以我的经验看来，这种方法的问题在于大多数的大型企业中，最大的改进机会不在于每个团队是如何工作的方式，而是更多地在于所有不同的团队聚在一起为客户交付价值。这也是我确信DevOps原则会确有帮助的地方，该原则在维护或改进质量的同时，以更为频繁的方式发布代码。使用特定环境和分支可以使大量的低效问题不显现出来，但是所有人在公共主干上工作，版本发布更加频繁，这些问题就不得不解决。当你以低频率构建和发布企业版本系统时，每次发布发生类似的问题，团队都可以暴力地解决这些问题。增加发布频率需要解决企业中存在多年的低效问题。

\

\\

InfoQ：DevOps如何帮助优化需求和规划活动？

\\

\

Gruver：我认为DevOps就是要优化企业内部的价值流，从业务理念一直到交到顾客手中的解决方案。从这个角度看，DevOps需要分析规划和需求流程中存在的损耗和低效问题。事实上我认为分析流程反而是很多大型企业的最大损耗之源，因为它为开发人员建立了过多的需求库存。精益制造理念告诉我们，过量的库存会导致重做和推进形式的损耗，因此应尽可能地最小化库存。在DevOps社区中，还有一些人倾向于将DevOps看成是自开发人员开始并向外扩展的流程，因为很多的自动化和架构即代码的技术解决方案正是实现于该流程中。这里我也不纠缠于具体的问题名称。这不是关乎如何做DevOps，而是关乎如何解决企业中损耗和低效问题的最大源头。假定你可以在一天的时间内开发并发布代码，但新的需求要数月时间才能从积压的需求中给出。你可能需要对部署流水线采用一种更宽泛的端到端的看法，该看法中包括了你的规划流程，并将会迁移到一种对需求和规划更为及时的流程。

\

\\

InfoQ：您能推荐一些用于持续集成的指标吗？

\\

\

Gruver：第一步是理解持续集成中发现的问题类型。持续集成在设计上是让开发人员对代码问题提供快速反馈。我经常看到的问题是由于很多其它的原因导致持续集成失败了。例如，测试可能是不可靠的，环境可能并未正确配置，用于运行测试的数据可能无法获取。这些问题的解决应先于期待开发人员去对持续集成反馈做出响应。因而我倾向于从分析构建失败的原因着手。这是用于优先流程中改进的开始步骤之一。随后持续集成的指标取决于集成的内容。如果你是在小型的团队中集成代码，可能需要测定团队解决和修改构建问题的快速程度。如果你在做大型系统的复杂集成，那么更有兴趣的指标是如何保持构建是一路绿灯的和确保代码库的稳固性，这些指标是通过使用质量门去捕获部署流水线上游的问题而实现的，因为上游产生的失败会影响到大多数开发组中人员的生产率。书中给出了更多问题和指标的细节，因为该问题的确依赖于你在部署流水线的各个阶段集成的内容。

\

\\

InfoQ：您在书中区分了在紧密耦合架构的企业内推广DevOps和在松散耦合架构的企业内推广之间的不同之处。是什么问题导致了差异？差异是如何影响DevOps的推广的？

\\

\

Gruver：从我个人角度看，DevOps所做的多是关于协调企业中不同员工的工作，必须协调的人数取决于企业的规模和架构的耦合度。如果你面对的是小型企业或是具有松耦合架构的企业，那么你的协调工作可能是针对五到十人的规模，这种情况需采用一类的方法。另一方面，如果你面对的是具有紧耦合的大型企业，其中需要上百员工共同工作去开发、确认和发布系统，这种情况需采用另一类方法。重要的是搞清楚你正努力解决的问题是什么。对于小型团队环境，DevOps更多的是提供员工所需的资源、移除障碍并授权团队，因为他们对系统的掌控程度可以是端到端的。对于大型复杂环境，DevOps工作更多的是设计和优化大型复杂的部署流水线。解决这类挑战并非小规模授权的团队可以或是愿意去做的，这需要更为结构化的方法，需要人们着眼于整个部署流水线并优化系统。

\

\\

InfoQ：您在大型企业常见到哪些类型的损耗？

\\

\

Gruver：相对于编写新代码，大部分具有紧耦合系统的大型企业需要花费更多的时间和精力在创建、调试和修改自身企业级复杂测试环境中的缺陷上。很多时间里他们甚至并非真正想要去做DevOps，只是需要修正他们的环境。他们从所有的敏捷团队听说自己正在取得进步，但是由于环境问题，他们局限于自身发布新功能的能力。我通常从此处着手。企业具有多少开发和生产间的环境？企业在每个新环境中看到了哪些问题？企业在所有不同环境中定义环境、配置数据库和部署代码时是否使用了相同的流程和工具？这是一个使用通用工具自动化这些流程以获取一致性的问题，还是一个确由代码所导致的环境问题，通过其他团队影响其他组有效使用环境去验证新代码的能力。通常这些问题构成了最大的损耗源头，需要得到解决。

\

\\

InfoQ：消除这些损耗需要做什么？

\\

\

Gruver：这取决于损耗的源头。不同人实现流程的方式不同，这会产生的重复性工作和手工错误，花费在此上的时间构成了大部分的损耗，这类损耗可以通过自动化得到解决。需采用的方法是架构即代码以及部署和测试过程自动化。问题在于过程的实现需要一定的时间，因此应该从能为你的企业提供最大价值的改进着手做起。这就是为什么我们要做映射以确定着手之处。

\\

还有一些损耗与开发人员所工作的代码相关联，这些代码不能和其他正开发中的代码一起工作、不能用在生产环境中或是不能的达到客户需求。降低这类损耗需要改进对开发人员反馈的质量和频次。开发人员都希望能写出好的代码，好的代码是安全的、运行很好的，并达到业务的需求。但是如果需要很长时间开发人员才能获得对代码优劣的反馈，就不可能真正地期望开发人员会取得改进。因而，消除这类损耗的关键在于改进反馈的质量和频次。

\\

最后一点，为了发现损耗的源头，很多企业浪费了大量时间对问题做鉴别分类。为解决这类问题，需要减小批处理规模，建立质量门，并在问题影响到企业中的更多地方之前从源头捕获问题。

\

\\

InfoQ：为什么高管应该领导持续改进？他们应如何做？

\\

\

Gruver：在大型紧耦合系统中，需要一些人能超越整个团队去优化整个部署流水线的流程。正如我们在上面所讨论的，这并非在小规模授权团队的位置上可以推动的事情，这需要使所有不同团队对各自的工作达成共识。我时常看见不少人从底层开始做工作，于是由于在尝试说服同级同事和上级支持改变的时候受到了挫败，于是他们的很多倡议失去了推动力。如果要在紧耦合系统中以更频繁的方式发布代码，需要所有团队保证每天的代码库都更加稳定。即便十个团队中有九个在关注稳定性，这也不会起作用。所有团队需要认同工作中的差异性。这需要发挥高层的作用。高管可以把团队拉到一起，分享过程，并让每个人认同自己将要去做的改进。这样随后可让人们对他们的提交负起责任。这些工作不能通过下指令管理，因为在将过程映射给团队前，高层通常感觉不到过程的低效问题。这需要更具执行力的领导方式，其中高层负责将所有人拉到一起，并使他们对改变取得一致意见，进而引领连续改进过程。

\\

上述针对高层的建议是面向大型紧耦合系统的。这些建议对于具有可独立工作小型团队的企业而言并非十分重要。

\

\\

InfoQ: 最后对于那些想采用DevOps的企业，您还有哪些建议？

\\

\

Gruver：不应仅是为了启动DevOps、精益或是其它任何能听说的最新趋势，你应该聚焦于原则，分析企业所独有的特性，并开始自己的持续集成之旅。这还需要判断力。理解你努力地通过流程改变修复的是什么，然后使用常规检查点评估改变是否具有所需的效果。带上你的团队在流程中一起前行，在每个检查点审查完成情况，还有哪些尚未完成。在流程迭代中学到了什么，并对下一次迭代中的优先事项取得一致意见。重要的是开始持续改进之旅，并使所有人与你一道。在此过程中你可能会犯一些错误，发现你认为问题所在之处其实只是洋葱的第一层。但是如果你们作为一个团队共赴前途，将可达成你从未认为可能的突破。

\

\\

关于本书作者

\\

Gary Gruver是一位经验丰富的企业高管，具有可靠的在大型组织中转变软件开发和交付过程的工作业绩。他最初是LaserJet固件（FW）组的研发主管，实现企业对嵌入固件开发方法的完全转变，此后在Macy’s.com担任QA、发布和运营的副总，领导了持续集成之旅。现在他为大型组织提供顾问服务，举办讲习班，帮助这些组织转变软件开发和交付过程。他是《在企业中发起和推广DevOps》一书的作者，并合著了《引领转变——大规模应用敏捷和DevOps原则》和《大规模敏捷开发的实用方法——HP是如何转变LaserJet FutureSmart固件的”》这两本书。

\\\\

查看英文原文：Article: Q\u0026amp;A on Starting and Scaling DevOps in the Enterprise

\\

感谢王纯超对本文的审校。

\\

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号：InfoQChina）关注我们。