《DevOps 精要:业务视角》- 读书笔记（四）

第4章 关键实践

4.1 和传统实践的关键区别

在前面的章节里，我们讨论了DevOps的背景和起源、它的基础、它与敏捷开发和精益生产的关系以及让DevOps成为可能的重要原则。此时此刻，一个有心的自我角色定位清晰（例如编码、分析、架构）的读者，应该已经理解了DevOps是什么、为什么需要DevOps、谁需要DevOps以及DevOps包含什么。不幸的是，作为IT管理的公开出版物，例如ITIL、COBIT或DevOps，只讲这些内容还不够。读者很可能了解所有的这些高级话题，但他们真正想要得到的是搞清楚具体的问题：DevOps实际上到底是什么？具体应该做什么？怎么做？

幸运的是有一种绝佳的方式，通过与常见的“传统的”实践进行比较，可以清晰列出表象之下隐藏的本质：突出显示差异将有助于抓住要点。我在Cleverics交付的DevOps培训课程、工作坊以及业务的演练中，都运用了这种方法。这一实践帮助我尽可能简洁地进行比对、去除不必要的细节并选取出最生动的范例。

4.1.1 发布是日常活动

对IT部门而言，日常工作中每一次发布都是一个巨大的挑战。按照惯例，一次发布包含针对多个客户发起的多个变更请求；此外，IT部门发起的变更，通常也被包含在发布中，比如用来保持系统运行正常的或提升性能的的变更，以便系统更稳定、更安全、更快速或诸如此类的，同时也包含用来测试和验证这样大的发布的相关活动。这些都需要大量的关注以及时间，并且占用了大量的资源。所有人都知道，对于任意的一个发布，无可避免会出现某些错误，也正因为如此，IT专家才会采取以下行动。

• 文档化一切变更（事实上，并非所有的变更都需要文档化）。
• 确保做备份（对于大型系统而言，需要大量的空间和时间，在系统以及网络上产生额外的负载；尽管如此，依然有人忘记备份一些重要的文件）。
• 计划专门的措施以及开发按步骤操作指南以便恢复系统，如果有可能，出错时能够恢复到原始状态（当发布的部分已安装而部分未安装时，会特别麻烦）。
• 根据确认过的变更时间排期来进行发布计划；如果一切正常，在事先达成一致的发布窗口停止系统；或出问题时，在突发状况下停止系统。发布窗口通常会落在周五到周一之间的漫漫长夜中。
• 最后，通过相当大量的手工运维操作进行部署和发布，并且不会记录中间结果。

根据前述列表中每项工作被执行的彻底程度，整个部署的时间往往从数天到数周不等。管理员和开发人员不眠之夜的数量，则取决于发布的大小、IT系统的状态以及准备和分发版本的工作量。

在DevOps中，发布是日常活动，发布会每周甚至每天进行。当然，需要显著减少所引入的变更数量；不仅如此，还需要从根本上优化版本发布的准备与分发相关的实践……让我们回想一下持续集成和持续交付流水线的实践：在版本控制系统中记录所有变更，通过自动化工具执行绝大部分的运维操作，部署后立刻建立起针对新引入的或发生变更的组件进行监控。一旦部署中发生任何问题，流水线都将自动停止部署，回滚已经发生的变更，同时通知团队采取措施。

在过去至少四年的时间中，Puppet公司与其他一些组织，一直在发布年度DevOps状态报告。2017年的报告基于约3000份来自不同经济体不同公司的调查对象，历年来总共超过27000位调研对象。报告的作者将所有被调查象分成三组：高生产力、中生产力和低生产力的IT团队。“发布是日常行为”这一最佳实践可以从部署频率的差距来体现：对于低生产力的IT团队，发布频率的中位数在每周到每月之间，而高效能团队则每天部署数次。

4.1.2 发布是业务决定

严格讲，前面章节中并没有完全正确地使用“发布”这一术语。原因是ITSM中的“发布”与DevOps中的“发布”有着不同的定义。对于经典的IT管理（把ITSM称为经典的IT管理是否合适？），一次发布是将一组整合后的变更部署到生产环境中。DevOps中的发布意味着让一个新的功能完整或部分地开放给用户用。准确讲，我们应该在第3章中用“部署”一词来替代“发布”。

在日常实践中，一次发布是一个IT决策。有一个发布策略和一个发布日程表，用来对发布的频度和规模进行定义，甚至版本的命名以及编号的规则。需要新功能的业务单元排队等待发布：如果足够幸运的话，可能会包含在下一个发布中，但往往是在一个或两个季度之后。

当采用DevOps的持续部署时，新功能一旦开发并测试完成，就被部署到生产环境。直到功能被激活之前，用户都不会感知到新功能。业务部门基于市场、营销或其他计划和考虑来执行激活动作。这一实践在前面也提到了，这不仅允许将版本交付到客户手中，还能获得下述额外的一些收益。

• 首先，发布时的宕机时间急剧下降，甚至为零（即零宕机发布）。
• 其次，这让蓝绿部署成为可能，即在生产环境中有两套拷贝：“绿”和“蓝”。不到一秒钟，就可以将客户从一个正在与前一版本交互的环境，切换到另一个新版本已经运行的环境。
• 再次，拥有大量用户的公司可以采用金丝雀发布技术，即新功能首先针对一小部分用户可用，当从技术和市场的角度都确定一切正常后，再将所有其他用户都切换到新版本上。业务部门对金丝雀发布范围的划分决策，会基于对他们重要又熟悉的方式：基于位置、收费计划、客户忠诚度以及其他的信息。
• 最后，许多公司开始主动采用A/B测试来验证业务假设，即一部分用户（参考组）使用老的版本，另一部分（试验组）采用新的版本。通过对比关键的指标组，可以测试并验证业务想法并在系统后续的开发中进行调整。

以上所有这些只有在改变发布的定义并且将决策权移交给业务时，才有可能发生。

Facebook的一个工程师曾经被问到一个具体用户参与Facebook的某些实验中并且毫无感知的可能性有多大？这个工程师如此回答：“100%肯定，我们会持续并同时采用超过20种实验。”

4.1.3 一切都是自动化的

对于IT，可以把一句著名的俄罗斯谚语“懒惰是发明之母”改写为“一个懒惰的管理员会写脚本来减少工作量。”在传统的IT部门，写完一个脚本需要很长时间，而且没有统一的存储库，性能也会成问题，所以大部分的运维都是手工执行的，经常重复的操作也不例外。

• 创建环境（测试环境、中间环境等）。
• 配置基础设施组件。
• 执行测试。
• 部署和分发，包括监控工具的配置。

对DevOps而言，提升管控级别至关重要，正如3.3节中所描述的：“一切都应该存储在版本控制系统中。”应该自动化一切手工操作，尤其是前面列举的。

部署流水线所需要的环境应该自动由脚本创建，并且在流水线控制系统的管控之下。同时，在用完之后，这些环境会自动退役，并释放资源。IT基础设施元素的配置在3.4节中详细讨论过。快速的流水线操作要求最大化测试自动化的程度，手工测试应该始终是最后采取的手段。如今，不仅可以针对组件、集成、回归、功能和性能进行自动化测试，同样也能针对用户界面、可用性以及验收等做自动化测试。借助于对系统和应用监控进行必要的调整，部署和分发作为流水线的最后一步，也是自动化的。不能低估监控的作用，这一环节对新发布提供了快速的反馈。无论怎么让测试环境尽可能地与生产环境相似，部署以后两个环境依然会有差异。在这种情况下，监控系统的事件记录可以触发已部署变更的自动回滚，以保障环境和应用的稳定性。

此外，从传统单体应用迁移到微服务时，迫切需要对组件进行完整的监控，这是唯一可以用来追踪可用性的方法，同时也用以追踪具体的服务或服务版本被其他服务实际调用的情况。没有这样的控制，就无法实现演进式架构，那些已经消亡但依然相互连接的服务，将被永久堆积起来，5.3节将讨更多细节）。

4.1.4 事件要立即

解决当用户报告故障时，一个典型的服务事故管理流程是下面这样的。

• 用户通过电话、电子邮件、门户网站、在线聊天或移动应用，联系到一线支持。
• 一线借助于用户、自动化系统或人工智能的帮助进行支持，记录并核实工单，通常也包括设置优先级来决定后续处理的速度。
• 工单进入队列，等待处理，可能会很快，但有些时候也可能很慢。

当IT专员或监控系统汇报系统故障时，对基础设施的故障处理，大致也是同样的结果，最终止于处理队列。队列是一种重要的控制机制，它有助于让所支持的任务有序，同时也可以均衡承载资源。队列也非常有必要，因为事故的处理通常需要大量时间。每一个事故都需要调研、诊断、鉴别以及进行变通方案的实施，并且在大多数案例中，所有这些都是手工完成的。

在DevOps中不是这样。事故将被回溯到最近的一次部署，流水线控制系统将自动回滚到已知的最近一个稳定状态。此时依然需要人工介入进行变更分析并纠正，但会更快，也更容易，因为变更是最近刚发生的，而不是几个月或几年以前发生的。所有关联的信息都是已知的：需要解决的问题、用户、开发人员和测试人员。

通常，当某些事情“破坏”基础设施时，此时的决策是断开失败的组件（例如，应用服务器），而无需做过多调研。与此同时，使用此前创建这一组件的现成脚本来重建这部分基础设施。相比传统的流程，这样的操作节约了大量时间。但事实上，如果IT部门只需要控制几十台服务器，还可以手工进行配置，逐一起一个独特并且优美的名字，照顾并呵护这些服务器。但如果IT部门需要管理成百上千个服务器，这种方式有太多的限制，不再有效。相较而言，DevOps的选择方式经常被称为“牲畜与宠物的对比”。回忆一下1.1.2节所述，DevOps意味着最大化物理硬件虚拟化。

4.1.5 缺陷是立即被修复的

在传统IT部门的工作过程中，测试环节所遗漏的缺陷，最终会在运维环节中被识别出来，然后被评估、排优先级并最终进入队列。这种方式看起来没有什么问题，但事实上大多数错误会永远停留在这个队列里而造成技术债务的累积。当一个缺陷被分配较低优先级时，团队会推迟很久才进行修复。到那时，所有人都早就忘记了是什么缺陷、为什么产生以及该如何修复，同时，更多的重要并且紧急的工作又进来了。此时，团队修复缺陷需要额外的资源来恢复上下文，同时还要持续支持更重要的事务，这让消除非高优先级缺陷的可能性降为零。

另一个现实挑战是如何减少持续增长的缺陷列表。10个缺陷是否可以忍受？那么50个呢？如果是500个？怎么对这么多缺陷一一设置不同的优先级、重要性以及影响程度？已经在队列中等了一周的缺陷，是不是能稍微再等一下呢？如果是一个月了呢？一年的又如何？再考虑到缺陷列表可能深深隐藏在ITSM工具的某个角落，当意识到它的存在时，已经造成严重的问题。如果考虑到，诸如“我们没必要修复这一问题，反正无论如何也计划会在六个月之内替换掉这一组件”时，问题会变得更有意思。为了让这一场景变得更加真实，我们必须补充说明，这个缺陷很有可能已经在队列中停留了一年以上，并且“我们计划替换”并不意味着“我们要替换”，通常更不会是在六个月之内。

在DevOps中，会以另一种方式进行缺陷修复。基于“系统必须总是可工作状态”这一原则，同时为了控制技术债务，绝大多数缺陷将被设置优先级以便尽快修复，如果团队采用的是Scrum，会在当前冲刺或下一个冲刺中修复。如果是次要的缺陷，可能会推迟一段时间，但不能太长并且必须重视。

如同其他DevOps实践，立即修复缺陷需要对计划、排序以及运维进行大规模的优化调整，同时需要谨慎修改核心工作原则。很多管理者并不认同立即修复缺陷的想法，同样，他们此前也不同意ITSM有关“所有接收到的报障都应该记录下来”的原则。在这种情况下，一种方法是以对待新功能同样的方式来对待缺陷。缺陷与用户故事进入到同一个队列并且被平等对待。选择实现一个用户故事还是选择修复一个缺陷，是基于统一的原则。给一个新功能的优先级高于一个缺陷修复的优先级，是基于同样的IT系统、同样的资源、同样的用户前提下做出的决策。这样，用户就逐渐参与技术债务的管理中，这会极大地改变对这一工作的重视程度以及对结果的负责程度。

4.1.6 流程是持续更新的

传统IT部门修改工作流程的方式更加糟糕，通常由外部咨询顾问或一个由员工组成的工作小组甚至一个特定的部门来开发新的指南。通常，他们会描述一个模型来体现预期操作方式。像所有的模型一样，真正需要的实践与指南的描述之间总会存在差距。

• 很难预先设想到所有的情况以及存在的偏差，也很难描述激发团队动机的部分，并且很难在保证足够细节不至于让人困惑的同时不将员工变成机器人。
• 在现实与文档化指南之间的第二个差距发生在实际表现和预期不匹配时。在某些情况下，员工会抄近道，在另一些情况下，他们的表现又比指南所描述的更好。
• 第三个差距来自于流程自动化，此时高度依赖于流程。在很多时候，流程自动化工具的配置远远落后于新流程的引入。工作早已按新的方式进行，而自动化系统却还未变更。或者更糟的情况是工作并没有按正确的方式进行，因为无法修改自动化工具。我知道有一家公司，ITSM系统修改的平均间隔是两年，导致流程优化严重滞后。

所有这些差距会对工作实践产生极端负面的影响。因此，DevOps采用不同的方式，所有识别出来的流程短板都应该立刻消除。例如，如果一个部署流水线脚本无法正确工作，应该立即修复。此外，与传统实践推迟问题不同，DevOps建议尽可能重复执行可能有问题的步骤，这有助于更好地理解应该如何改进并且对工作进行调整。

4.1.7 像初创公司一样行动

有些DevOps团队出现在创业公司，他们拥有独特的文化，与传统企业的员工相比迥然不同。尝试实施DevOps的企业，试图采纳企业家精神和创新精神。但这到底意味着什么呢？两者到底有什么差别？关键的差异如图4.1所示。

传统企业与初创公司的文化差异

对于这些特性，DevOps的文化与传统文化表现截然不同，这当然是沿袭传统工作风格的组织中产生直接和快速变化的阻碍。图4.1总结的主要差异，也让我们继续针对每一个DevOps实践进行细节分析。记住，这些实践中的大多数是从其他来源借鉴而来，但不会降低这些来源的重要性，也不会降低DevOps的重要性。

4.2 非同寻常的团队

在图4.1中，“初创公司文化”一列展示的差异，让采用传统职能型管理方式的公司的变革不可能或异常困难。尤其是，自治、产品导向以及网络式的组织结构促使改进专业人员的组织方式，以便达成最优效率。团队，而不是结构化的部门，成为工作的中心。

DevOps团队是一个令人吃惊的作战单元。它负责一个小而定义清晰的IT系统或IT基础设施。有了这样的聚焦，团队成员不可避免最终成为领域专家，并且保持对系统全权负责。

DevOps团队不是临时的项目团队。与此相反，它是为长期存在而组建的。与此同时，通常团队的存续周期不是预先设定，也不是固定的。只要与团队所工作的领域相关，团队会始终负责。如果领域方向发生变化，团队随着所负责的领域一起“转向”；而如果这个领域被放弃，团队则切换到另一个领域。关于是否有必要时不时地拆分团队，还没有在实践中达成共识。一方面，将一个成功团队的成员分布到其他团队里，可以让能力和经验得到快速传播。然而，许多专家提出，建立一个卓有成效的团队花了大量的时间和资源，应该在保留团队的同时再次投到其他的任务上；他们建议，知识分享可以并且也应该与团队的构造无关，知识分享应该通过其他方式进行。

团队成员将100%的时间放在团队中工作：共享的资源、四处绑定的责任、替代另一个部门生病的同事或类似的事情不复存在。每一个成员全情投入简化了协作，移除了对外部因素的依赖，排除了出现额外工作负载的可能。另一方面，这种方式增加了人力资源的成本了参见1.3.1节。

DevOps团队是跨职能的，这意味着团队应该也有能力完成负责的领域价值流上的所有工作。这是对完成的定义（Definition of Done）建立共同且准确理解的唯一方式，只有这种方式能够保证所有的任务都完成，并且彻底消除未完成的工作。

团队的大小非常重要。一方面，团队不能太小，太小的团队无法做到跨职能，如前面所述。另一方面，超过二十人的团队很难协调，或需要管理层级，或逐渐拆分成更小的团队。此外，大型团队要承受额外的沟通成本以及团队成员之间不可避免的信息丢失。所有这些都影响了工作速度。

小的规模以及跨功能的需要，对DevOps团队提出了额外的诉求：团队成员应该尽可能具备多种技能。我们很熟悉清晰的专业划分：这个是程序员，那个是测试人员，而那个是信息安全专员。但DevOps团队要求打破这些边界。理想的情况是，每个人都能够做所有的工作。这并不意味这每个人都将成为能力平平的程序员或数据库管理员。显然，员工在一定领域有专长并且也应该很深厚。然而，多面性让团队成员可以相互帮助，交换能力，同时从专家的层面来理解工作是如何开展的。所有这些平衡了负荷，并创建了一个作为整体单元共担责任的团队，而不是单个的大师和英雄。

在小型DevOps团队的成员中，没有正式的领导，没有协调人或上司。团队应该有能力独立地解决浮现出来的所有管理问题，并且在遇到困难时寻求专家或导师的支持。类比Scrum，产品负责人（PO）并没有比任何一个团队成员具有更高的话语权，Scrum Master也不是一个特定的人员，而是一个角色，时不时地从一个团队成员换到另一个。换言之，这应该是一个自组织的团队，这对小团队来说更容易达成。

所有团队成员都在同一物理位置非常重要。经常面对面的接触是必要的，远程的电子化沟通并不足够。这一诉求基于如下原因。首先，无论是采用何种媒介（电子邮件，即时通信，正式文档），“写—读”式的沟通隐藏了情感部分，例如用词的准确性和情绪的表达。在很多明显的情况下，接收者可以很清楚他们到底是被夸奖还是被批评，但在其他情况下，发送者传递的主要情感信息存在于场景中。有时看起来无辜的评语会导致滔天的愤怒，与一些名人进行比较被认为是公开的羞辱。这些反应如果能够被及时发现还好.然而，更糟糕的是很多IT专业人士偏内向，倾向于控制怨恨。如果带着负面情绪，加以几乎无限的技术能力，与访问源代码以及生产环境相结合，结果将会是爆炸性的。

其次，整个团队坐在同一个房间，让每天每个人之间的接触无可避免。一封电子邮件可以在邮箱里被忽略几周。在高工作负荷、会议以及类似情况下，电话呼叫很可能都无法被接听。而一个同事站在那里提出的问题会被立即回答：编程人员现在无法躲避测试人员，测试人员也同样无法躲避运维专员。低质量的工作、缺陷和事故将不只是被发现并登记在某些信息系统中，它们会立即得到更正，这有赖于团队的集体付出。这样的团队工作风格不需要领导者、协调者或是导航员。

DevOps团队对使用的工具负责。如何构建一个流水线、采用哪种技术或是哪个库版本，所有的这些问题都是团队的职责范围。团队应该能够评估任何变更所造成的影响。这里并不否认遵循相关标准的需要，包括架构领域、信息安全以及审计标准。

举一个所有团队都能理解的案例，让我们回想一下杰夫·贝佐斯在2001年对从单体应用变更为微服务架构的著名决定。他在发给技术人员的信息中提到以下几点。

• 1．所有团队都必须通过服务接口来暴露数据和功能。
• 2．团队必须通过这些接口进行彼此通信。
• 3．不允许有其他进程间通信方式。
• 4．具体采纳什么技术没有关系。
• 5．所有的服务接口，毫无例外，必须从一开始就设计为对外的。也就是说，团队必须计划并设计可以暴露给外部世界开发者的接口。毫无例外。
• 6．任何人不这样做都会被开除。

前述DevOps团队的特性会导致规模化的困难：需要协调不同领域的工作，使用共同的IT基础设施时尤为重要。当有几十个团队时，可能导致管理层的介入，这在一定程度上不利于提升速度和减少浪费。这些困难可能表现得很严重，但在通常的功能型组织中并不存在。事实上，扩展传统的组织结构看上去很容易：可以增加一个部门，任命一个管理者；可以玩政治并交换管理者；随着公司成长，可以相应增加管理的层级；可以引入代理机制以及组合角色，诸如此类。但是，很明显，这些把戏有一堆缺陷，隐藏并粉饰了真正的交互问题，减慢工作速度的同时增加了浪费。

最后让我们总结一下DevOps团队的关键特性，如图4.2所示。

4.3 工作可视化

正如2.1.2节中所提及的，IT工作不像生产系统，基本上都是不可见的。你无法触及到产品，仅仅依靠查看“部分就绪”的产品或条目，无法评估它的就绪程度。相反，很难了解工作量是否已经溢出了队列。这种不可见性让员工和管理者无法在任何时间回答诸如以下的关键问题。

• 目前接受了多少任务（所以我们正在做这些）以及具体是什么任务（我们正在做的具体任务是什么）？
• 哪一个步骤正在积压工作而导致瓶颈以至于链条上的剩余工作无法有效展开？
• 哪个领域的产能潜在存在不足，很快会拖慢其他领域？
• 在价值流的哪一个点或阶段，资源几乎被耗尽或接近于满负荷？
• 哪些任务被阻塞了以至于无法在这个迭代完成？
• 还有哪些未完成的工作在等待进行？
• 如果没有时间完成本次迭代所接受的所有工作，哪部分值得尽力完成以便可以达到最有用的结果？

事实上，我们在讨论确保价值的流动（参见3.1节），在这里，约束理论的原则和方法完全适用。与此同时，考虑的不仅仅是开发的部分，而应该是完整的链条，整个端到端的流水线，直到软件被最终消费者使用。可视化工具可以支持流动并帮助找到上述问题的答案。基于列表的系统虽然很流行，但并不会完全处理所有的任务，即便是安装仪表盘插件。它们很难显示任务从一个阶段到另一个阶段的流动。一个看板更有吸引力，简单版本的看板如图4.3所示。

整个团队的待办事项在最左侧的待办事项（To do）栏输入。然后，从左向右，是任务逐渐移动的工作阶段；这个区域通常被称为“进行中”（In progress）。流程的终点，“已完成”（Done），在最右边。在这个相对基本的标记方法基础之上，可以加入几条来自高阶DevOps团队实践的重要标注。

• 首先，将任务放在待办事项列表中，并不意味着就开始工作，这与被广泛接受的实践相反。从字面上看，在待办事项列表中的任务意味着如下含义：这是一个好主意，一旦做出了决策，它就可以被实现。然而，一旦第一个阶段的负责人从待办事项列表中拿取了任务，代表整个团队承担起快速执行该任务的职责。
• 其次，任务只在从待办事项移到第一个阶段时进行一次优先级排序。此刻，诸如潜在收益、所需资源、急迫性以及许多其他参数都可以并且也应该加以评估。值得注意的是，决定优先事项的方法很多，并非所有方法都意味着对列出的参数进行详细分析。管理队列的最有趣的方法之一将在4.10节中进行讨论。
  因此，一旦决定接受一项任务，就不能在接下来的阶段中忽略它，所有开始沿着价值流前行的任务，都必须移动直至终点。取消一项任务以便增加另一项任务，是不能接受的，因为在进行中的工作是应当被消除的浪费之一。这样的结果是，除第一个人以外的价值流上所有的参与者，都不需要花时间来设定已接受任务的优先级，因为优先级已经定义，不应改变。
• 再其次，细心的读者可能已经发现，上一个阶段的输出是下一个阶段的输入。也就是说，在每一个阶段之前都会建立一个队列，这样就可以可视化评估每个阶段的任务数。
• 最后，通过使用看板，可以构建一个所谓的拉动式系统。通常情况下，谁完成了上一个阶段，就将任务推到价值流的下一个阶段，并且尝试影响相关人员接受任务，并且快速处理任务，事实上，是在用责任驱动接受任务。与此相反，在拉动式系统中，当团队完成当前的任务后，负责相应工作的成员从队列中拿取下一个任务并开始工作。这让流动更加顺畅，资源利用更加有效，并且消除了协调的需要，同时最大程度地减少了主管与其他流程管理者的角色。

我们应该注意到看板另一个预想不到的应用。从看板可以观察到哪些地方以不正确的方式采用了DevOps方法。例如，如果优先级排序是错误的，进入价值流的待办事项马上就会超载，造成其他部分的混乱。在这种情况下，明显应该优化的不是价值的流动，而是理解排序的原则和队列的管理，理解任务管理的基本方式是拉动式系统，还是与看板和精益原则相违背的推动式系统。再比如，尝试将看板应用在支持和运营部门，却没有改变他们的工作原则。在这种情况下，混乱同样会出现，因为有大量的任务需要显示和追踪，从而让看板变得不可读。通常，此时只是以一种有点刻板的方式在看板上移动任务，即修改任务的状态，让任务移到下一列，但事实上，下一位操作者并未真正接受任务。所有这些，与价值流动及价值管理的关系都不大。

可视化的效果
对于可视化的好处，我们总结出以下几点。

• 可以构建拉动系统，从而改善工作流、减少停滞时间和减少协调的需要。
• 改善正在进行中任务的透明度。
• 改善对剩余工作以及当前状态的了解。
• 改善优先级排序。
• 低交接次数。
• 有助于识别效率低下的环节。

4.4 限制在制品（WIP）

在传统的工作实践中，任务是从多个来源异步涌入团队的。一般而言，一个专业人员会参与到多个流程中，将他的工作时间切分到每一个流程上。除了可以预测的工作之外，任务还随机来自于管理者、不满意的业务部门以及同僚，每个人都会说“只需要十分钟”。如图4.5所示，在很多公司，自动化工具可以为所有分配给专业人员的任务创建一个相当不错的列表。

在以下几个方面，这个列表表现得相当“不错”。

• 它总是不完整，有些任务记录在报事贴上、笔记本里、短期记忆中或好像就在某个地方。
• 有些任务是计划中的，有些就是随机的。
• 出于一百万种不同的理由，所有这个列表上的工作从来都不会按时完成，更别说是按照约定好的优先级和截止时间。
• 很多任务会在列表上停留长达几个月甚至几年，导致这个列表从未被适度缩减。

长长的任务列表是导致混乱的根源。混乱产生于专业人员频繁评审优先级（“我现在应该做什么”）、频繁在不同任务间切换（“我没有时间做这个，我要做那个”）、频繁由于外部因素而变更优先级（“更加紧急的任务出现了，我现在要暂缓这个”）等诸如此类的情况。在有些公司，常见的优先级排序方法最终归结为HiPPO（Highest Paid Person’s Opinion），即工资最高的那个人的意见。

导致这些问题的根源在于多任务处理。有一种说法，一个普通人是可以同时做多个脑力任务的，但最近几十年的研究和实践证明并非这样。在大部分情况下，IT员工一次只能做一项工作。如果有人尝试同时做多项任务，那么他将花费大部分时间在不同任务间切换。任务切换需要时间，至少需要增加额外的时间重新排列优先级以及切换内容上下文。测量数据表明，比起单任务模式，多任务模式极大增加了任务的持续时间。

与这种工作方式相对的，是限制手头在进行的工作数量。一方面，这听上去有点奇怪，这是否意味着一个专业人员不再接受属于他职责范围的新任务？另一方面，这是一种非常有效的机制，可以保障任务平滑流动以及在可预测的时间范围内交付结果。这个实践的精髓是，在价值流的每个阶段，基于并行任务的数量或基于已接受任务的总数来进行人为限制，这称为“WIP限制”（即Work in Progress/Process，在制品限制）。在极端的情况下，在任意时间，每个工作阶段都限制到只有一项任务。基于同样的方法，对整个价值流上的任务总数进行限制。

这一实践完美地支持拉动式原则，这在前面已经介绍过。事实上，有了WIP限制，上一阶段的负责人没有办法再将任务推给下一个阶段，他们只能是告知下游的同事他们已经完成自己负责的部分。当价值流的下游完成自己当前的任务后，也告知再下一个阶段，同时他们可以接受一个新的任务。

这个实践可能导致在价值流上某个独立阶段无事可做的情况，因为要等待上一个阶段的任务完成。在通常的IT部门会决定取而代之去做其他的一些事情，用一些新的工作来填充，只是因为员工不能闲着！他们拿了工资，也就意味着应该百分之百地在工作，最好是百分之一百二。对每一个管理者而言，每天最重要的目标之一是最大化利用资源，包括人力资源。但是在DevOps中，却不是这样。

“至少做些什么比什么都不做强”，这一规则在DevOps中并不适用，更有甚者，这个说法极端有害。去做没有客户要的工作，是一种浪费；仅仅因为新的版本可用，就给服务器升级，是一种浪费；在空闲时间捡起一个任务，稍后再搁置，也是一种浪费。相反，应该将一个阶段的空闲视为另一个阶段在超载，并且应该立即采取相应的措施。这些措施既包含操作性的（比如帮助超载的同事），也可以包含系统性的（比如消除价值流中的瓶颈）。我们核心的关注点是保证流动，在此可以类比河流的顺畅流动：当一切稳定且良好，流速也同样是稳定的；当源头的水位过高，将无法流过河道，河流将决堤从而不可避免地导致河水流失，并且对堤岸地区造成破坏。另一方面，如果水位变浅，说明在上游的某个地方存在障碍，必须发现并移除，以便恢复稳定且可预测的流动状态。

Jez Humble等专家建议设置限制，以刻意创造一些不便。当价值流上有人没任务可做，资源便会释放出来，此时难免会有放宽上游限制的冲动，让一部分工作可以流到下游来。要克制这种冲动，专注于消除瓶颈，专家建议设置的限制能让你感到有点儿痛苦，但这可以让系统显性受控。

回到资源利用率这个话题，设置合理的WIP限制并定期调整，是平衡工作强度与生产效率极好的工具。事实上，在WIP与平均前置时间之间存在着如图4.6所示的关联。

图4.6 累积流图

另一个重要的方面是对输出的可预测性。在很多情况下，除了评估任务的复杂度以外，很难评估完成这项任务到底需要花多少时间，也就是说，很难预测发布时间。这里有两个非常好的工具：累积统计团队速率以及管理WIP。通过严格的限制，既有可能实现更短的前置时间，又降低了人力资源利用率，反之亦然。因此，管理者的工作内容通过DevOps得以显著改变。

WIP产生的影响归纳在图4.7中。

4.5 减小批次大小

假设我们需要开发并随后测试一系列相互独立的产品。第一种组织工作方式是，我们开发第一个产品后交接给测试，然后我们开始做第二个产品，然后再交接给测试，以此往复。第二种方式是，我们一次性开发完所有的产品，然后一起交付给测试。通常会错误地认为第二种方式比第一种更高效。但是，实践证明，效率依赖于总体批量的大小、产品的可变性、产品开发所需要的速度、设备所需要的调试时间等因素，因此没有一个普遍适用的正确回答。

但是在IT领域，基于以下原因，更小的批次选择呈现出更好的结果，如图4.8所示。

• 首先，大的批次很少是同样大小的，与小的批次相反，甚至小到所谓的单件流。拥有同样体量的小的批次改善了工作的节奏，使其变得更稳定并且在各方面都更可预测。
• 其次，由于小的批次降低了价值流中的等待时间，首次交付的时间以及总体的前置时间都会得以缩短。
• 第三，小的批次减少了进行中任务的总数。
• 第四，小的批次降低了缺陷数量，如果出现错误，整个批次都要重新做。批次越小，返工引起的浪费也就越少。

以上所有这些因素，都从正面影响着DevOps关键指标：前置时间、工作负载以及产品质量。

图4.8 减小批次大小的效果

在IT部门的日常工作中，大的批次很难被检测到。一个突出的示例是，程序员历经几天做完成了几个大的任务，然后仅仅是在最后时刻，一次性地将结果保存在版本控制系统中。DevOps建议的方式是，在整个工作过程中，自始至终保存独立的中间结果，至少每天一次。在配置良好的流水线中，每一次保存都将触发测试等步骤，以提供早期的反馈并防范缺陷。因为每一次变更的量都很小，所以很容易更正发现的问题。

4.6 留意运维需求

在开发与运维分离的IT部门，对于如何提供客户所需功能的问题，往往倾向于在内部寻求答案。开发者想知道所描述的想要什么，并且随时准备满足这些需求。而运维部门则对维护正常可工作的用户关系更感兴趣，而这只有当用户可以使用所提供的功能完成工作时才可能达成。

如图4.9所示，传统工作中最容易出问题的是被称为“功能性需求（NFR）”领域：可用性、可靠性、可扩展性、可维护性和安全性等。主要受影响的是IT运维部门，解决事件，调查根因，处理增长的用户基数和不满意的消费者等……处理所有这些都基于受限的资源进行，资源的投入落后于对IT运维要求的增长。也就是说，开发部门可以主要关注于功能性需求，而在某种程度上忽略对非功能性（NFR）的需求。

在传统采用瀑布式模型的组织中，解决这个问题的方案是尝试在软件开发的早期阶段让IT运维参与进来。“尝试”一词，并不是偶然出现在这里的，因为只有极少企业能够在这一点上有显著的进展。敏捷开发中的方案是将非功能性需求与功能性需求一起进行排序：遵循同样的流程、同样的重视程度以及拥有同样的级别。这一实践当然比传统的方式要好。

DevOps往前更进了一小步。

• 首先，产品负责人的角色扩展了。在Scrum中，他是对产品最为关注的人，或是产品的代表，但他会偏向或局限于产品的功能。DevOps专家建议产品负责人要关注整个IT运维系统，包括功能性的需求以及其他需求。这从根本上改变了非功能性需求（NFR）的重要性，并将团队的关注度牵引到可工作的产品上，这里的“可工作”不只是承诺的功能。
• 其次，一些DevOps具有远见卓识的人士，坚持抛弃常用的“非功能性需求”这个名字，因为这个名字暗示着次要或不那么重要，取而代之以运维需求（OR，Operation Requirement）。
• 再其次，建议彻底改善IT系统的可用性和性能。在遗留系统中，关注点在于设计并构建高可用系统，故障应该尽可能少地发生。为达成这一要求，采用了昂贵的专用软件以及硬件方案，例如冗余、备份以及热切换等。这些方案由知名的厂商提供，他们采用专利技术，附带着长期而且昂贵的支持和维护合同。在DevOps中，主要关注点由可用性转移到可恢复性或反脆弱性：系统应该有能力检测到并更正故障、恢复正常运营，而不会显著地降低性能，同时不会给用户造成影响。系统自身构建于大量的相对便宜并且容易更换的组件基础之上，采用分布式数据存储、并行计算以及类似的技术，并倾向于开源。故意并持续不断地在生产环境中引入混乱和破坏的实践，这在1.3.3节中有过描述。

因此，DevOps对运维工作的需求显然采用了截然不同的方式管理。更有甚者，还有一种非常有趣并且相当流行的实践，采用一种终端客户容易理解的方式来呈现持续运营以及系统的状态，如图4.10所示。

图4.10 公开的网页显示Basecamp当前系统状态的示例
这种类型的页面增强了DevOps团队与用户之间的信任，并且展示了服务之整个生命周期的成就，而不只是开发阶段的。并且，当系统发生故障时，一个单一的系统状态信息来源，可以有效防止用户打来大量的电话、发来大量电子邮件以及其他信息。最后，正常运行的时间信息，直接类比于生产环境中著名的“146天无事故”板，也提升了员工的士气，让他们有安全感和集体责任感。

4.7 尽早检测并修正缺陷

与IT相关的最大损失发生在缺陷影响到生产环境时，比如系统不可用、系统间歇性中断或部分功能不可用，导致用户无法执行其工作。正如我们在3.2节中讨论过的，DevOps投入了大量关注，以防范缺陷进入生产环境。进一步的分析揭示：除了商业上的损失以外，随着交付流水线阶段向后移动，识别和消除缺陷的成本也随之增加，参见图4.11。

图4.11 缺陷发现滞后而引发的损失与成本

事实上，为了在第四个阶段检测缺陷，我们应该早在左边前三个阶段投入资源，例如，创建需要的测试环境并执行测试。这些资源和时间都是无法返还的，这当然会负面影响到前置时间。当流水线上并非所有环境都是自动化时，问题会变得尤其严重，例如，如果其中的一个阶段需要手工测试，则这类的测试成本将急剧上升。这说明缺陷越快的被发现就越好，对于流水线的成本以及性能，均如此。这就要求及早反馈，尽可能返回到接近流水线起始位置的地方。其中一种实践被称为“左移”：更有效的组织测试，以最大化在早期阶段发现最常见的错误。需要增加在流水线前几个阶段的测试，与此同时也会延缓这些阶段的执行，所以需要遵循一定的平衡。

注意，当测试尽可能自动化时，会收获最大的收益。可以说在绝对的DevOps流水线中，测试人员的角色和工作发生了变化：他们主要的工作不是去执行测试，而是进行开发。这一变化也印证了那个古老但依旧适用的原则：智力的工作属于人类，而重复性的日常操作应该交给机器。

需要进一步补充的是，测试环境与生产环境应该尽可能准确地保持一致，以快速发现缺陷。流水线上的测试环境完美无瑕，但是到了生产环境，应用却无法正常工作，这样的情况非常危险，并且会造成损失。这意味着我们应该尽可能保证测试环境，不只是完整再现生产环境，而且是以同样的方式进行创建。正如在“自动化配置管理”小节中展示的，如今它已经是可能的了。

4.8 管理的而不是受控的改善和创新

1.3.2节讨论过对DevOps的需求，我们接触到了持续累积非优化方案这个重要的问题。在正常情况下，除非我们采取特殊的举措，否则技术债务就会有增加的趋势。这同样适用于工作和管理方法，如流程、过程、协议等。流程有自我恶化的趋势，员工不只是在技术方案上抄捷径，也会在工作方式上这样做。更有甚者，如今外部因素变化频繁，昨天还工作的好好的软件或流程，今天就有可能不奏效了。

最后，信息技术自身也在快速进化。从2010年开始，ThoughtWorks这家在高效软件开发市场非常知名的公司，开始每六个月发布一次特别的报告《技术雷达》。它列出了上百个条目，分为四个领域：技术、平台、工具和语言&框架。例如在2017年，技术有产品化API、无服务框架和超越游戏的虚拟现实；平台有Apache Mesos、AWS Lambda和Platform IO；工具有Airflow、HashCorp Vault和Terraform；最后，语言和框架有Python 3、Elixir和Angular 2等。

这些条目的每一个，都被归入四个分级之一：勇敢采纳、尝试、为将来评估、暂缓并观望，并在很多点上给出相关的解释。由领域专家组成的小组进行耗费大量人力的工作，分析这些对消费者完全免费的技术。对最近几份报告的分析可以看出，一个新的技术如何动态的发展（或是消亡）。技术机会持续的诞生，其中很多可能会带来可观的回报。

因此，技术债务需要削减，工作需要改进，新的技术需要掌握。现代IT部门无法在核心的工作之外，私下做这些重要的任务：按这种方式，最好的结果也就是保持原地，而最差的（很有可能）情况则是退步。这也是DevOps建议持续改进与创新的原因。在不同的公司，这一实践完全不同，这里只列举其中的几个。

一些公司会设置一定比例的工作时间用于改善，“20%税”的说法越来越广泛地出现在公开的出版物中。显然，这个数字是拍脑子想出来的，这在不同的组织之间很难保持一致，当然，也有一些经过澄清的估算。例如，SAFe模型中，团队会实施持续8到12周的项目群增量，在增量的最后阶段，是一个专门用于创新和规划的迭代。需要说明的是，在这个迭代里，也包含前序迭代未结束工作的收尾、最终的集成和测试以及对下一个增量的规划；也就是说，在最初设定的两周时间里，只有几天保留下来，分配到创新的时间占整个增量整体时间的1.5%到15%。我们姑且认为这一估算是最低的合理程度。最高的合理程度可以从马蒂·卡根的说法中得到，20世纪90年代末期，他在易趣（eBay）经历了一场技术债务危机，由此将思考呈现在他的《启示录：打造用户喜爱的产品》一书中。按他的说法，在一些困难的情况下，有必要给改进工作分配30%甚至更多的时间，但由于不信任，团队往往分配少于20%的时间。很有意思的是，很多专家建议在改善工作期间禁止任何日常工作：不进行编码或测试，也不允许进行部署。

另一种实践称为“改善闪电战”（Kaizen Blitz）。在这种情况下，用于改善的时间未必是事先规划的，而是按需分配。此外也建议引入外部的参与者，比如其他团队的成员或外部专家。这一实践相信外部视角能够帮助将问题挪出死角，并发现内部无法看到的解决方案。真正的闪电战持续一天到几天不等，专注于消除识别出来的不足与瓶颈。由此，每一次的闪电战都期望能够产出明确定义和具体的结果：最差的情况是需要采取的行动列表，更理想的是问题已经解决。

有些公司会分配特定的时间，并同时引入外部资源。他们对公司内的知识和经验分享赋予了很高的期望。例如，Target公司会将团队集中到一个特别指定的区域（办公室）整整一个月，专职的导师参与到团队中，帮助他们重组工作方式，以同样的资源、更少的时间来完成更多的工作。公司会分配资源，最多同时对多达八个团队进行改进演练。预期在这个月里，团队不只完成所分配的工作，还要学会新的方式、方法和技术，并且可以在返回岗位时将他们的新知识教给其他员工。

最后，黑客马拉松这样的实践也越来越流行。黑客马拉松是分配一段特定的时间专门用来探索新的技术，并尝试创造出新的产品和工具。这一方式理解并且接受，并非所有的产出物都需要是完整的或是有商业潜能。然而，越来越多的例证显示，在黑客马拉松上开发的新的应用原型事后成为很成功的产品。在有的案例中，人们对内部采用的技术，进行大量的优化，简化了日益复杂的架构，移除了僵硬的链接，并消除了日益累积的依赖，等等。

作为持续改进和创新的总结，有必要提出以下两个重要的观点。

• 这一实践需要被管理，而不是听之任之。
• 贵公司的实践，很可能与其他的组织不同。

4.9 为创新提供资金

及时且充足的资金是任何举措的前提。传统的决策，是基于预算周期的中长期计划做出的。这种方式在十年前是有效的，但今天它成了企业努力成为创新领导者的阻碍。出了什么问题呢？

通常而言，投资是循环进行的，为预算计划及记账设置重复周期（常规是每年）。如图4.12所示，节奏的存在自然有它的道理，但问题是这一节奏与现代企业所需要的有所脱节。事实上，确切的预测一个还未进行开发的想法在12个月时间内造成的影响，有可能么？信心满满的计算这么长一段周期的成本，有可能么？正如在1.3.1节中描述的，在很多情况下，对所选方向的信心，只有在前行的过程中涌现，在途中不可避免会发生调整。如果公司的预算周期与税务报告周期绑定，那就太悲哀了，也许对负责记录并计税的部门会很方便，但要记住，这些部门并不会为企业创造太多价值；对于企业的目标、使命、客户、产品以及合伙伙伴而言，其重要性是次要的。我们发现对相关的外部资源遵从的需要决定着业务计划的方式。熟悉基本账务管理的读者会同意这种扭曲的现象应该终止。然而，这是现代企业广泛采纳的一种实践。

图4.12 资金周期与时间和方向没有对应，且彼此之间很少同步

第二个根本性的困难，来自于广泛使用的基于项目的投资：我们通常相信，在项目中，成本可以仔细计划并控制，并且回报是可以预期的。可是对很多现代事务，传统项目管理不再适用。

• 组织要交付的产品，无法在事先进行准确描述，并且在工作过程中通常会发生变化。
• 在项目正式结束时，产品才刚刚开始它的生命周期，需要基于使用中获得的新体验和客户反馈，持续进行改进和修正。
• DevOps专家并不建议（随项目周期）解散已经良好运作的DevOps团队，也不建议使用兼职（工作于多个团队）的员工。

因而，更加推崇的是基于产品而不是基于项目进行投资，这意味着截然不同的预算以及资源计划方式。

既然提到资源话题，我们就无法忽略另一个典型的问题：传统预算模式意味着在部门和团队之间激烈的竞争。很显然资源是有限的，而DevOps提倡协作的原则、部门与团队之间协同工作、知识自由共享、专业的特长，这些被视为是至关重要的。如果一个组织引入的投资规则（即资源分配）需要在同僚之间进行斗争和竞争，那么当你发现孤立团队这样的企业文化随处可见时，就不足为怪了。

早先，当系统的复杂性和变化较低时，传统的投资方式工作得还不错（把预算当做是限制而不是优先级排序的除外）。现在，这种投资方式成为创新的阻碍。另一种能够获得高投资回报的方式，是创建稳定的产品（或服务）团队，并持续对他们进行投资，在他们选择其战略、实现方式及负责领域内的优先排序时，给予一定的自由度。

当然，前述并不意味着没有限制，例如在开支上。与此相反，一些创业公司的开支显示，当严格进行财会以及支出控制时，独创性的奇迹会出现，新的技术方案会出现，而其他采用不同资源计划原则的团队就无法产生这些。生活一次次证明，不受限的资金以及期限，不足以产生有竞争力并让消费者趋之若鹜的产品。

另一种方式，一定程度上是DevOps从现代精益企业管理实践中借鉴来的，对于长期的目标进行高阶定义，而对立即要进行的行动进行详尽计划，并且持续的调整短期计划以保证方向正确。

前面已经提及，更简单的是将投资的原则从基于项目变为基于各个团队。

Jez Humble介绍的流程较为复杂，但也更有成效：

• 起始阶段：寻求并评估想法，但不要花时间和资源去开发一个精确并且复杂的业务模型。
• 探索阶段：分配固定的时间与预算，构建团队，开发一个最小可行产品（MVP）。
• 当前序阶段产品被证实有吸引力时，下一个阶段是拓展：保留团队，拓展投资，开发产品，寻求更多的机会点。

这种方式最主要的目的是，选择好的想法，将有限的资源投入其中，并且可以预料到并非所有的想法都会奏效，但某些一定会表现出显著的结果。注意，在很多商业技术孵化器中，创新被当作流水线处理，也遵循前面的原则。

前面描述的MVP概念经常被完全用错。很多人相信，MVP是某些快速并且劣质的成品、一些最小的功能、能够运行即没有明显察觉的缺陷，以便向投资者进行原型演示，是一种早期alpha版本的产品。

然而，Eric Ries（埃里克·赖斯），MVP一词的提出者，指出MVP描述的是一种以最小可能的资源，通过测试和训练，获得最大可能的新的信息，基于客观的数据进行投资战略决策：是继续沿着这个方向，还是改变航向甚至是放弃这个想法。

马蒂·卡根针对MVP又增加了以下明确的特征。

• 1．客户应该愿意买这个产品。
• 2．客户应该能够明白如何使用这个产品。
• 3．一旦下了决策，我们应该可以做出完整的产品。

很多人只关注最后一句，即功能。事实上，所有三句话都非常重要。

4.10 任务优先级

对进入价值流队列的任务进行排序，这个领域经常出问题。传统的方式包括分析任务、评估、比较并排序、获取审批或允许，所有这些都发生在了解目标工作之前。这些操作通常都需要大量的时间和资源。与此同时，它也有很多弊端。

• 首先，这种实践导致严重的延期。
• 其次，任务的信息会随着时间演进而趋于过时，所以决策耗时越长，基于的数据就越不可靠。
• 第三，这些步骤的重要性被严重夸大。
• 最后，也是最不愉快的是一个长时间的初始评估阶段，催化了图4.13所示的混合模式，被称为Water-Scrum-Fall，团队相信自己的模式很时髦和灵活，然而它的运作方式事实上还是非常传统。

图4.13 瀑布巧妙伪装成迭代
第一个步骤的困难之处在于，需要从通用的池子里选择哪个任务先完成。为完成此活动，通常需要遵循一系列的标准。

• 首先，需要评估一种或另一种方式的潜在收益，至少，将这个任务与其他的进行比较。收益的评估并不容易：类似Scrum的方法在这件事情上也帮不上多少忙，它们希望这一信息能够从客户或产品负责人那里获取。
• 然后，需要预估任务需要多少资源，而这也很困难，特别是首次做的任务。可以提一下计划扑克这样的技术，但我们将不会认真考虑它们，也不会进行细节讨论。
• 最后，把急迫性从考虑范围移除会非常危险；不应该仅从理论上进行收益以及资源的评估，而要在一定的上下文前提下进行，并且预期的回报通常也依赖于发布日期；仅仅描述为ASAP（越快越好）还不够。

在2009年，Don Reinertsen提出一种截然不同的排序方式，称之为“延期成本”（CoD，Cost of Delay）。这种方法相对简单，它的基础是对决策的重要性进行经济评估，在工作队列较大时更为有效。这种方法的第一步是选择指定价值流的关键指标。在很多情况下，可以用财务回报进行预测，但有些情况下也用其他更为关键的指标。定义度量单元之后，就要对每一个任务进行计算或估计：如果这个任务在队列中被延误，对所选取的指标会发生什么影响。Don Reinertsen的经验显示，许多团队成员并不理解这一指标的真正价值，并且所有对它的预估尝试通常都有巨大的错误。Reinertsen坚持可能的最准确的计算要考虑到价值随时间的动态变化。这一方式打开了一些让你不舒服的问题，但团队最终需要学着去回答。

得到CoD指标的数值，就很容易在不同任务之间进行比较。在最简单的情况下，对同样时长的任务，拥有较高CoD的任务应该进入队列。在复杂一些的情况下，也很容易用一个衍生的指标计算出来，即用CoD除以持续时长（CD3，Cost of Delay Divided by Duration）。将任务的持续时长纳入考虑的好处是，可以展示长的任务如何阻塞其他较小的任务从而延误了后者潜在的收益。因此，排序最基本的原则是，鼓励降低批次大小，保留价值，加速产品交付，并确保更均衡的工作负载。

CoD方法的一个好处是，它很容易对一个正处在价值流最初始阶段的任务进行计算，而通常时间最容易在此消耗，而减少这一阶段的时间消耗将带来巨大的效果。事实上，一旦我们对每一个任务都采用同样的指标进行决策，这样当团队成员空闲时，他们将很简单地从队列中选取下一个最高CoD的任务。价值流上其他的步骤也都采用同样的标准，并且对后续阶段的1～2周短迭代而言，可能不需要再进行排序，而相信早先的计算。

这种方法的第二个明显的优势在于，经济化的决策对所有人都保持透明。以往混合多个参数、等待上级审批或是采用HiPPO的方式（参见4.1节），都不再需要。

最后，这种方法的第三个（并不那么明显的）特性，是对限制在制品（WIP）这一实践的主动支持。事实上，如果并行执行多个任务，CoD指标将变得非常差，所以一旦完全遵循这种方式，没有人会同时进行多个任务。

同时应该牢记，CoD并不是对现有指标的补充参数。与此相反，它是被设计用于排除所有其他参数、简化决策过程并减少价值流起始阶段的浪费。

4.11 持续识别、发掘并评估约束

第3章里讨论过价值流，总存在约束，需要始终加以考虑。平稳流动而没有延迟的状态，并非一朝一夕就能达成，需要投入努力。这也意味着下一个实践：采用可视化工具来支撑WIP限制，从而能够识别出这个价值流的瓶颈。在所有已知的瓶颈中，有一个会造成最大的延迟，应该重点关注这一个。

事实上，对付瓶颈有两个步骤。

• 首先，有必要了解如何改变短期的工作规则来最大限度地利用（发掘）瓶颈资源。例如，限制价值流上的任务，从而不要让瓶颈过载，只让高优先级、重要的任务移动到瓶颈点。
• 其次，我们需要发现消除瓶颈的办法，摆脱它。也就是说，需要谨记在同样的地方让一个约束再次出现的危险性，因为系统的惰性以及流程的惯性很容易使其回归原有习惯的状态。

当消除了识别出来的约束，就可以取消先前建立的短期规则，开始寻找下一个最显著的瓶颈。

4.12 小结

任何书籍的篇幅都有自然的限制，而这本书刻意地进行了限制：当今的现实是，很少有人能够花一大堆时间去阅读大量的文字。同时，本书也不包含对其他的DevOps实践的检视，其他有太多有关DevOps实践的书籍。

正如第2章所揭示的，很多DevOps的实践是继承或者借鉴自诸如约束理论、精益生产、持续部署以及其他存在已久的管理领域。当然，这并不会降低它们在DevOps中解决问题的重要性。有趣的是，进一步研究已公开发行的书籍证实了这些实践对读者的重要性，因而，本书最后一章将聚焦于DevOps的实践应用。