如何持续识别和改善DevOps识别系统中的约束点，提高工作产能！

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

Goldratt博士在Beyond the Goal 一书中提到：“在任何价值流中，总是有一个流动方向、一个约束点，任何不针对此约束点而做的优化都是假象。”如果我们优化约束点之前的那个工作中心，那么工作必将在这个约束点上更快地积压起来。

反之，如果优化约束点之后的工作中心，那么它还会处于饥饿状态，等待约束点处工作的结束。

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

• 识别系统的约束点；
• 决定如何利用这个系统约束点；
• 基于上述决定，考虑全局工作；
• 改善系统的约束点；

如果约束点已经突破了，请回到第一步，但要杜绝惯性导致的系统约束。

在DevOps的转型过程中，如果希望前置时间从月或季度缩短为几分钟，那么一般需要依次优化下面的约束点。

• 环境搭建 ：如果生产或测试环境的搭建总是需要数周或数月，则按需部署就无法实现。解决措施是按需建立完全自服务的环境，保证团队在需要环境的时候，能通过自动化方式创建。
• 59代码部署 ：如果代码的部署需要花数周或更长时间（譬如每次部署需要1300个手动、易出错的操作，涉及多达300名工程师），那么就无法按需部署。解决措施是尽可能自动化部署的过程，以便让任何开发人员都可以按需自动化地部署。
• 测试的准备和执行 ：如果每次代码部署都需要两周的时间来完成测试环境的准备和数据集的配置，手动执行所有的回归测试还需要另外四周时间，那么就无法实现按需部署。解决措施是实现自动化测试，这样才能在安全、并行地执行部署的同时，使测试的速度能跟上代码开发的速度。
• 紧密耦合的架构 ：如果架构是紧密耦合的，那也无法实现按需部署，因为每次要做代码变更时，工程师都不得不从变更评审委员会里获得执行变更的许可。解决措施是创建松散耦合的架构，这样开发人员才能安全、自主地进行变更，提高生产力。

如果能突破以上的约束点，那么接下来的约束有可能是开发部门或产品经理。因为我们的目标是让小型开发团队可以独立、快速、可靠地开发、测试和部署，并持续为客户创造价值，所以这些环节应该是约束点集中的所在。对于高绩效者来说，不管工程师是处于开发、QA、运维还是信息安全岗位，他们的目标都是尽量提高生产力。

当约束点出现在开发阶段时，我们将仅受限于有多少创意精良的业务假设，以及能否开发出必要的代码来用真实客户来测试这些假设。

以上所述的约束点在DevOps转型中是相当普遍的——在价值流中识别约束点的技术，诸如如何使用值流映射和度量的方法，以后会详细描述。