DevOps三步工作法（一）—

DevOps三步工作法（一）——流动原则

编辑：008 时间：2020-02-22

在技术价值流中，工作通常是从开发人员流向运维人员。

接下来要介绍的第一步工作法，就是建立从开发到运维之间快速、平滑且能向用户交付价值的工作流。

我们要为这个目标进行全局优化，而不是局部优化，局部优化指的是关注功能开发的完成度、Bug 的发现率和修复率、运维维护的可用性等指标。

在这一步要持续加强工作内容的可视化，减小每个批次任务数量和各个任务的等待间隔，内建质量防止缺陷向下游流动。

这样可以缩短满足内部客户和外部客户需求的前置时间，进一步提高工作质量，让我们能比竞争对手更快速地推出符合客户需求的产品。

在这一步的目标是缩短代码从变更到生产环境上线所需时间、提高服务的质量和可靠性。

1.1 可视化

和制造业生产流程不一样，技术行业的工作内容一般是不可见的。

比如当测试人员抱怨自己“测不过来”时，到底多少功能需要测试的时候测试人员才会测不过来？有多少待测试的功能？这是不可见的。

不可见导致开发过程的的哪个环节受阻，发生了积压任务的情况，大家都不知道。

为了识别工作队列的流动、排队或停止的情况，就要把工作可视化。

而可视化的方式，可以用看板或 Sprint 计划板，用纸质或电子的形式把各项工作的进展展示出来，比如上图就是看板。

看板能把工作可视化，从任务的创建时间到完成时间，可以推算出工作的前置时间，通过提升管理任务的效率，加速任务从左到右的流动速度。

在看板中，工作通常从左侧的待办事项中拉取，然后从一个工作中心转移到下一个工作中心，最右侧也就是最后一个工作中心，通常标记为“已完成”。

通过把工作可视化，项目经理或产品经理能列出各项工作的优先级，每次迭代就从优先级最高的任务开始，依次完成所有功能。

1.2 限制在制品数量

制造业的日常工作，通常是由定期（如每天或每周）生成的生产计划决定的。

计划会根据客户订单、交货日期、零件库存等条件，确定执行哪些任务。

但技术工作动态是动态的，团队需要同时满足很多利益相关人员的需求。

紧急、临时安插的任务数量，可能比计划进行的任务数量还要多。

在制造业中，生产中断的代价很高而且很明显，当正在进行中的工作中断时，大多数半成品都会报废。

生产想要继续，只能重新启动一批新作业，因为代价高昂，制造业的人对于生产中断的现象更敏感。

但是在技术行业，技术工作者的工作经常会被打断，因为中断的代价是不可见的。

当一个软件工程师在多个任务之间来回切换时，需要不断切换编程的思路。

比如有个工程师为了开发一个计划中的功能，需要重构一段遗留代码，这段代码读了一半，还没理清逻辑。

这时测试人员说有需要紧急修复的 Bug ，工程师就需要停止读代码，为了调试和修复这个 Bug ，开始读另一段代码。

如果这时候产品经理又跑过来，说要加需求，然后开始描述，这时候该工程师又要切换思路，想一下这个需求能不能实现，实现要多久。

在这时，工程师手上有 3 个任务，3 个任务都没有完成，假如最初工程师读遗留代码的时间花了 10 分钟，再读 5 分钟，就知道怎么改了。

也就是在等 5 分钟，就有一项任务能被完成了，前置时间就变少了，而临时安插的 Bug 修复任务和新增的需求，则让前置时间变长了。

这时候回过头来，可能又要花多 15 分钟，也就是原本 15 分钟能完成的任务，现在需要 30 分钟，工作效率大大降低。

这就是为什么使用看板时要做到限制在制品数量，限制在制品数量是影响前置时间的重要因素之一。

限制在制品数量，一般的做法是在看板中每一列的标题都标记上该工作中心的数量限制，比如“开发中（5）”

在制品在技术价值流中，一般指的就是待实现的从需求或待修复的缺陷。

当某个工作队列的工作数量达到上限时，就要禁止添加新卡片。

还有为了强调所有任务都必须可视化，开始执行任务开始的前提，是任务已经添加到看板中了。

通过限制在制品数量，还能发现开发流程中存在的阻碍，比如有的团队会发现测试团队经常没事干，因为要等待开发人员开发完成。

又或者发现开发团队没事干，因为要等待产品经理把需求分析完成。

当我们查明并解决导致等待的原因后，我们就能够减少任务的前置时间。

1.3 减小批量大小

1. 单件流

建立平滑而快速的工作流的另一个关键，是通过小批量的模式完成工作。

在精益革命发起前，在制造业最常见的生产方式是大批量生产。

这是因为要把巨大儿沉重的模型放到金属冲压机上，换模的过程需要几天时间。

由于换模成本过高，导致大多数工厂都会用大批量生产的方式，每次作业都尽可能生产出很多的车身板，这样就能减少换模次数。

大批量生产会导致在制品暴涨，最终的结果就是生产的前置时间长、产品质量差。

如果发现了一个车身板有问题，整个批次都将报废。

而在精益生产得出的一个重要经验是，为了缩短前置时间和提升交付产品的质量，要持续不断追求小批量生产模式。

而最小的批量生产方式就是单件流，也就是每次只执行一个单位产品的处理。

小批量生产的在制品更少，前置时间更短，错误检测速度更快，返工时的次品数量也更少。

大批量生产模式，对技术行业造成的负面影响和对制造业造成的负面影响是一样的。

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

2. 请客

假如我们现在请朋友来我们家吃饭，要做 10 道菜，每一道菜都要经历 3 个步骤：

清洗食材（5 分钟）—烹饪（10 分钟）—上菜（3 分钟）。

如果用大批量生产的策略，生产流程是这样的：

清理 10 道菜的食材
烹调 10 道菜
上 10 道菜

那上第一道菜的时间就是：

5 * 10 + 10 * 10 + 3 = 153（分钟）≈ 3（小时）

3 个小时后客人才可以吃到你第一个菜，如果吃的是午饭，那你最晚也要 9 点就开始做，而且你等你把第一个菜端出来时，前面的 9 个菜也已经凉了。

如果我们把菜都烹调完毕后才发现，洗菜用的水被污染，脏了，那我们之前洗的菜白费了，要重新洗一遍，甚至是用新的食材来洗。

如果是重新洗的话，重新做的话，那上第一道菜的时间延迟了 3 个小时，那朋友不得饿死了。

如果我们是用单件流的形式，这也是一般我们是做菜的方式，那上第一道菜的时间就是：

5 + 20 + 3 = 28 分钟

和大批量生产比起来，前置时间缩短了约 80% 。

如果我们在上菜前发现洗菜的水脏了，那我们找到干净的水，然后再洗一遍。

也就是我们也只浪费了半个小时，和大批量生产的错误情况比起来，失误的成本也降低了 80%。

1.4.4 减少交接次数

在技术价值流中，如果一个软件的部署前置时间，以月作为周期单位，一般是因为要把版本控制系统中的代码部署到生产环境中，需要几百甚至上千个手动操作。

代码在技术价值流流转的过程中，需要各个部门的协同才能完成，包括功能测试、集成测试、环境搭建、配置服务器、存储管理、网络、负债均衡设备和信息安全加固等工作。

一项工作在团队之间交接时，需要大量的沟通、请求、委派、通知、协调，而且需要安排优先级、调度、消除冲突、测试和验证。

这些工作可能还需要用不同的工单系统或项目管理系统，编写技术规范文档，用会议、电子邮件或电话等形式进行沟通。

可能还涉及文件共享服务器和 Wiki 页面的使用。

上面提到的流程中的每个环节，就算我们不把这些环节中的工作可视化，它也有自己潜在的队列。

当某个任务依赖不同价值流共享的资源时（比如集中式操作），该任务就只能进入等待状态，结果就是工作的前置时间变长、延期。

即使在最好的情况下，有些信息或知识也会不可避免地在交接过程中丢失。

在经历了多次交接后，问题的上下文和支持的组织目标可能会完全丢失。

比如服务器管理员可能会收到一个关于创建用户账号的新工单，但是他并不知道什么应用或服务将使用这个账号。

也不知道为什么要新建账号，不知道这个工作是不是与另一个类似的工作重叠了。

想减少这类问题的出现，可以减少交接次数，或用自动化的方式执行大部分类似的操作。

又或者调整组织结构，让团队不必依赖其他人，就可以独立地为客户提供价值。

比如测试人员可以通过 Jenkins 自动打包，不需要等待开发人员手动打包。

我们要减少工作在队列中的等待时间，减少非增值工作的时间，以增加工作的流动性。

1.4 约束点

为了缩短前置时间、提高生产系统的吞吐量，我们要不断识别系统中的约束点，才能提高产能。

在 Goldratt 博士的《目标》一书中提到：在任何价值流中，总有一个流动方向、一个约束点（瓶颈），任何不针对该约束点做的优化都是徒劳的。

如果我们对约束点前的工作中心的产能进行优化，那将有更多的工作积压在在约束点上。

比如当测试部门的工作过量时，再对开发效率进行优化时，就会有更多的功能需要测试，导致优化的结果让总的产出效率下降了。

对于这种现象，Goldratt 博士给出了解决方案，定义了下面 5 个关键步骤：

识别瓶颈

找出系统中的约束点（瓶颈）；
找出措施

找出提升约束点利用率的措施；
协力解决

根据第二步找到的措施，让企业的其他活动为该措施服务；
突破瓶颈
重复执行

突破一个约束点后，回到第一步，并在后续杜绝惯性导致的系统约束；

在我们转型到 DevOps 的过程中，如果想把前置时间从月或季度缩短为几分钟，一般需要一次优化下面 3 个约束点。

环境搭建

如果生产或测试环境的搭建需要几个星期或几个月，那就无法实现按需部署。

解决办法就是按需建立完全自服务的环境，保证团队成员能通过自动化的方式创建环境。
代码部署

如果代码的部署需要几个星期或更长时间，比如每次部署需要 1300 个手动、容易出错的操作，并且涉及的人员多达 300 多个，那就无法实现按需部署。

解决办法是尽量自动化代码部署的过程，让每个开发人员，都可以按需自动化部署代码。
准备和执行测试

如果每次代码部署，都要两个星期的时间完成测试环境的准备和数据集的配置，手动执行所有回归测试也要 4 个星期的时间，那就无法实现按需部署。

解决办法是实现自动化测试，以便在安全、并行地执行部署的同时，让测试的速度跟上开发的速度。

如果能突破上面 3 个约束点，那接下来还可能遇到开发部门或产品部门成为约束点。

因为 DevOps 的目标是让小型开发团队能独立、快速且可靠地进行开发、测试和不熟，持续为客户创造价值。

这些环节是约束点集中的地方，不管是开发、QA、运维还是信息安全工程师，大家的目标都应该是尽量提高生产力。

当约束点出现在开发阶段时，我们可以用真实客户，验证产品经理对需求分析的结果和技术风险较高的代码，从而突破开发阶段的约束点。

以上提到的约束点，在 DevOps 转型中遇到是很正常的，在价值流中识别约束点的技术，比如使用价值流映射和度量的方法。

1.5 常见的困境类型

丰田生产系统的先驱之一新乡重夫认为，浪费是企业增长的最大威胁，精益中对浪费的常用定义是：使用超出客户需求和客户愿意支付的范围内的任何材料或资源的行为。

新乡重夫定义了制造业中 7 种主要的浪费类型：库存、过量生产、过度加工、运输、等待、移动和缺陷。

浪费有一点主动的含义，但是这并不一定是工人主动造成浪费的，所以在 DevOps 中，把浪费称为困境。

DevOps 的目标，则是通过持续学习打破日常工作中的困境，从而更好地实现组织的目标。

下面是常见的困境的类型：

半成品

半成品指的是价值流中没有彻底完成的工作，比如未实现的需求、未测试的代码。

半成品往往会随着时间的推移而过期，最终失去价值。
额外工序

在交付过程中执行但未带来客户价值的额外工作、下游工作中心从没使用过的文档、对输出结果做的不带来客户价值的评审。

额外工序不仅增加了处理的工作量，还会增加工作的前置时间。
额外功能

额外功能增加了功能测试、管理复杂度和工作量，额外功能包括在交付过程中构建的，组织或客户不需要的功能。

比如需求文档上写的是需要一个登陆功能，然后你自己花了 1 个星期搞了个酷炫的登录动画。
任务切换

把人员分配到多个项目和价值流中，会导致耗费额外的工作量和时间。

因为被分配的人员需要对于不同的任务，要进行上下文切换、管理工作之间的依赖关系。
等待

由于资源的竞争，在工作之间产生了等待，增加了周期时间，减慢了向客户交付价值的速度。
移动

移动指的是信息或数据，在工作重心之间移动的工作量。

比如在一个需要频繁沟通的项目中，团队成员没有坐在一起办公，无法进行紧密协作，这时人员移动的浪费就产生了。

此外工作交接也会产生移动的浪费，需要额外的沟通澄清有歧义的部分。

比如产品经理在需求文档上写的某些需求你不理解，你要跑到隔壁的隔壁的办公室去找他，这就造成了浪费。
缺陷

缺陷型浪费，指的是由于信息、材料和产品的错误、残缺或模糊，需要一定的工作量来确认。

缺陷的产生和被检测出来的时间间隔越长，往往解决问题也就变得越困难。

比如你上一个月写的代码，这个月发现了 Bug ，这时候你就要去回想之前是怎么写的，怎么想的。

但是如果是刚刚写的代码，那回想的时间就会变得很短。
非标准/手动操作

当某项工作需要依赖某个人的非标准的或手动的操作，比如没有自动化的环境搭建步骤、没有自动化的测试数据填充操作、没有自动化的手工测试、不标准的编码规范。

理想的情况下，任何依赖运维团队手动完成的操作，都应该配置为能自动化且按需提供的，也就是自助服务。
填坑侠

有时为了实现组织的目标，不得不把一些人和团队放在不合理的处境。

比如半夜两点生产环境出问题了，连夜给软件版本提了上百个工单。