DevOps流动原则的实践之--减小批量大小

建立平滑而快速的工作流的另一个关键点，是通过小批量的模式完成工作。在精益革命以前，大批量（或规模）生产的方式在制造业司空见惯，在作业配置或作业之间的切换相当耗时且昂贵尤其如此。

例如， 在生产大型汽车时，需要将巨大而沉重的模具放到金属冲压机上，这个过程可能需要好几天时间。鉴于成本如此高昂，通常会用大批量作业， 一次冲压出尽可能多的车身板，从而减少模具的更换次数。然而，大批量导致在制品的暴涨，并在整个制造工厂中产生流量级联的变化。最后导致前置时间长、产品质量差的后果——如果发现了一个车身板有问题，整个批次都必须报废。

在精益中，一个重要的经验是：为了缩短前置时间和提高交付物质量， 应当持续不断地追求小批量模式。理论上，最小的批量是单件流 ，也就是每次操作只执行一个单位产品的处理。

举个例子假设要邮寄出10本宣传册。邮寄之前，每本宣传册都必须经历 4个步骤：折叠，插入信封，给信封封口，盖戳。

如果采用大批量策略（即“大规模生产”），我们会对每本宣传册按顺序执行上述4个步骤。换句话说，首先要将10张纸全都折叠完，再将每张纸分别插入信封，然后给所有的信封封口，最后全部盖章。

另一种方式是小批量策略（即“单件流”），即对每本宣传册顺序地执行所需的所有步骤，然后再开始处理下一本宣传册。换句话说，先折叠一张纸，将其插入信封，再给信封封口，之后盖章；然后，取下一张纸，并重复以上过程。

56采用大批量和小批量策略之间的差异是巨大的（见图1）。假设对所有10个信封都必须采取如上4个步骤，并且每一步操作需要10秒。如果使用每批5个的大批量策略处理，则完成第一个盖戳的信封需要用310秒。

更糟糕的是，假设我们在信封封口操作中发现第一步的折叠做错了，在这种情况下，我们能发现错误的最早时间是在200秒之后，那样我们就不得不将这个批次的10个小册子再重新折叠并装回信封中。

相比之下，使用小批量策略时，仅用40秒就完成了第一封盖戳信的生产，比大批量策略快8倍。如果第一步出错了，只需要返工一本小册子。小批量生产的在制品更少，前置时间更短，错误检测更快，返工量更少。

对于技术价值流而言，大批量的副作用和制造业一样。我们制订了软件发布的年度计划，将一整年的开发成果一次性地都发布到生产环境中。

这种大批量的发布会造成突发的、大量的在制品，导致所有下游工作中心4大规模的混乱，其结果是流动性变差，质量下降。这和我们阐述的57经验是类似的，即对生产环境的变更越大，问题的定位和修复就越困难，修复时间也就越长。

Eric Ries在“创业经验教训”（Startup Lessons Learned）这篇文章中说：“在开发（或DevOps）流程中，批量大小是工作产品在不同阶段间移动的单位数。对于软件而言，最容易看到的是代码。当工程师签入代码时，他们就批量地处理了一定数量的工作。有许多控制批处理的方式，从持续部署要求的小批量，到相对传统的基于分支的大型模块开发，都是聚合多个开发人员几周或几个月所工作的代码。”

在技术价值流中，单件流可以通过持续部署实现。其中，每一个提交 到版本控制系统的变更都会集成、测试并部署到生产环境。具体的实现方法，将在下篇进行详细描述。

在福特汽车时代，大批量的生产方式占主导地位。自从20世纪50年代丰田生产方式的诞生，小批量的生产方式逐渐开始普遍发展。小批量生产方式，能够降低工厂堆积的在制品，缩短产品生产的交付周期时间。小批量做到极致是单件流生产，实现零库存。

小批量、单件流的理念是反直觉的。直觉告诉我们，攒一堆工件以大批量为单位再往下游环节才是最高效的，本文用实例证明，反而是小批量、单件流更加高效。

在生产制造业，零部件的批次是显性可见。而对于知识工作领域，比如研发，在制品的批次大小是隐形的，大批次的研发过程产生的浪费、低效不容易显现。因此我们需要通过看板可视化管理、CI-CD仪表盘等呈现研发的批次。

小批量、单件流的理念虽然来自于生产制造业，但是这个理念对于研发领域是通用的。对于软件价值流而言，单件流做到极致，是每一次代码提交到版本控制系统的变更都会触发集成、测试并部署到生产环境，并且这个过程是非常顺畅和快速的，而不是以积累很多代码提交后才开始集成，累计大量功能后才开始测试，全部测试完后才开始部署。要实现真正的单件流，需要对工具和工程能力有较高的要求。而这也是众多企业建设DevOps工程能力要提升的领域。