《DevOps实践指南》笔记：第2章

《DevOps实践指南》笔记：第2章

 第2章 第一步：流动原则

将工作可视化
为了能识别工作在哪里流动、排队或停滞，就需要将工作尽可能地可视化。如在看板或Sprint计划板上，使用纸质或电子卡片将各项工作展示出来。通过这种方式，不仅能将工作内容可视化，还能有效地管理工作，加速其从左至右的流动。

理想情况下，看板应该覆盖整个价值流；仅当工作到达看板最右侧时，才能算是已完成。开发完成某个功能不能算是“已完成”，只有应用程序在生产环境里成功地运行起来，并开始为客户提供价值的时候，才能算是“已完成”。

限制在制品数

1）技术工作通常是动态的，尤其是存在共享服务的情况下，团队必须要同时满足很多利益干系人的需求，有临时工作，日常工作，紧急工作。技术工作者很容易被打断，因为对所有人而言，这个中断的后果似乎是不可见的，即便它对生产效率的影响比制造业更甚。

2）控制队列的长度（即在制品数）是一个非常强大的管理工具，因为这是影响前置时间的重要因素之一，对于大多数的工作条目而言，在它们完成以前，其实并无法预测到底需要多长时间。

3）通过限制在制品数，还能更容易地发现工作中的阻碍。

减小批量大小

小批量：为了缩短前置时间和提高交付物质量，应当持续不断地追求小批量模式。理论上，最小的批量是单件流。小批量生产的在制品更少，前置时间更短，错误检测更快，返工量更少。

大批量：大批量的发布会造成突发的、大量的在制品，导致所有下游工作中心[插图]大规模的混乱，其结果是流动性变差，质量下降。

 减少交接次数

（1）开发到部署之间的浪费。在技术价值流中，如果部署的前置时间以月作为周期单位，通常是因为要将版本控制系统中的代码部署到生产环境需要经历功能测试、集成测试、环境搭建、配置服务器、存储管理、网络、负载均衡设备和信息安全加固等流程。

（2）团队之间交接的浪费。一项工作在团队之间交接时，需要大量的沟通——请求、委派、通知、协调，而且经常需要排优先级、调度、消除冲突、测试和验证。这些工作可能还需要使用不同的工单系统或项目管理系统，编写技术规范文档，用会议、电子邮件或电话的形式进行沟通，可能还涉及文件共享服务器、FTP服务器和Wiki页面的使用。

        为了减少这类问题的出现，要么努力减少交接次数，要么用自动化方式执行大部分操作，要么重新调整组织结构，让团队不必依赖其他人就可以独立地为客户提供价值。因此，要通过减少队列中的等待时间以及非增值工作的时间来增加流动性。

持续识别和改善约束点

在任何价值流中，总是有一个流动方向、一个约束点，任何不针对此约束点而做的优化都是假象。在DevOps的转型过程中，如果希望前置时间从月或季度缩短为几分钟，那么一般需要依次优化下面的约束点。

（1）环境搭建：按需建立完全自服务的环境。

（2）代码部署：任何开发人员都可以按需自动化地部署。

（3）测试的准备和执行：实现自动化测试，使测试的速度能跟上代码开发的速度。

（4）紧密耦合的架构：创建松散耦合的架构。

消除价值流中的困境和浪费

浪费是使用了超出客户需求和他们愿意支付范围的任何材料或资源的行为。7种主要的浪费类型：库存、过量生产、过度加工、运输、等待、移动和缺陷。

浪费和困境分类：半成品、额外工序、额外功能、任务切换、等待、移动、缺陷、非标准或手动操作、填坑侠。