[DEVOPS] 理论框架

[kaishen2018]

持续学习

发现新的瓶颈

 识别系统的约束点；
 决定如何利用这个系统约束点；
 基于上述决定，考虑全局工作；
 改善系统的约束点；
 如果约束点已经突破了，请回到第一步，但要杜绝惯性导致的系统约束。

实现自动化，提高生产力

在 DevOps 的转型过程中，如果希望前置时间从月或季度缩短为几分钟，那么一般需要依次
优化下面的约束点。
 环境搭建：如果生产或测试环境的搭建总是需要数周或数月，则按需部署就无法实现。
解决措施是按需建立完全自服务的环境，保证团队在需要环境的时候，能通过自动化方
式创建。
 代码部署：如果代码的部署需要花数周或更长时间（譬如每次部署需要 1300 个手动、易
出错的操作，涉及多达 300 名工程师），那么就无法按需部署。解决措施是尽可能自动化
部署的过程，以便让任何开发人员都可以按需自动化地部署。
 测试的准备和执行：如果每次代码部署都需要两周的时间来完成测试环境的准备和数据
集的配置，手动执行所有的回归测试还需要另外四周时间，那么就无法实现按需部署。
 紧密耦合的架构：如果架构是紧密耦合的，那也无法实现按需部署，因为每次要做代码
变更时，工程师都不得不从变更评审委员会里获得执行变更的许可。解决措施是创建松
散耦合的架构，这样开发人员才能安全、自主地进行变更，提高生产力。
如果能突破以上的约束点，那么接下来的约束有可能是开发部门或产品经理。因为我们的目
标是让小型开发团队可以独立、快速、可靠地开发、测试和部署，并持续为客户创造价值，所以
这些环节应该是约束点集中的所在。对于高绩效者来说，不管工程师是处于开发、QA、运维还
是信息安全岗位，他们的目标都是尽量提高生产力。
当约束点出现在开发阶段时，我们将仅受限于有多少创意精良的业务假设，以及能否开发出
必要的代码来用真实客户来测试这些假设。

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

持续学习分享