The Devops Handbook 读书笔记04 Chapter2

Chapter2 The first way. The principles of flow

通过技术价值流改善流程是Devops的目标。
我们通过使工作可见、限制工作、减少批处理大小和交接次数、不断识别和评估我们的约束以及消除日常工作中的困难来做到这一点。

1.使工作可视化（MAKE OUR WORK VISIBLE）

To help us see where work is flowing well and where work is queued or stalled,
we need to make our work as visible as possible.

办法就是使用sprint计划板。
我们team就是这样做的，我们使用JIRA来管理项目里的ticket，有TO DO/IN progress/Block/IN QA/DONE四栏，它帮助我们了解工作在哪里流动良好，在哪里阻塞或完成。
此外，还应该记录实际完成时间。（当然JIRA有足够强大的功能，做到这一点。）

当ticket流动到DONE的时候，并不代表任务完成，只有delpoy到production并交到客户手中，才算完成，因为这样才算创造了“价值”！

2.限制工作中的任务（LIMIT WORK IN PROCESS）

方法：排列优先级，限制多任务处理（一个dev处理多个项目里的不同任务，效率会显著降低）
它是工作可视化的升级，因为可视化，因此不允许在计划中随意新增任务。

3.减小批处理的大小（REDUCE BATCH SIZES）

小批量的好处：更少的ticket、更快的交货时间、更快的错误检测和更少的返工。
每次投入生产的更改越大，诊断和修复生产错误就越困难，纠正错误所需的时间也就越长。

因此我们team的release从三周一发改为两周一发，赞！

4.减少交接的次数（REDUCE THE NUMBER OF HANDOFFS）

一次发布从开始到完成，必然会经历以下过程，例如：
功能测试、集成测试、环境创建、服务器管理、存储管理、联网、负载平衡和信息安全。
那么必然会需要跟多个团队合作。发出请求，assign ticket、协调，通常还有优先级、测试和验证权限等等，这一切带来的就是等待。

解决方案：为了减轻这类问题，我们努力减少交接的次数，要么通过自动化工作的重要部分，要么通过这样重组团队。例如我们team是这样做的，拥有只负责自己团队的QA，automation test，将功能测试和集成测试直接加入到pipeline。

To transmit code through the value stream requires multiple
departments to work on a variety of tasks, including functional testing,
integration testing, environment creation, server administration, storage
administration, networking, load balancing, and information security.
Each time the work passes from team to team, we require all sorts of
communication: requesting, specifying, signaling, coordinating, and often
prioritizing, scheduling, deconflicting, testing, and verifying. This may require
using different ticketing or project management systems; writing technical
specification documents; communicating via meetings, emails, or phone calls;
and using file system shares, FTP servers, and Wiki pages.

书里提出的解决方案：

To mitigate these types of problems, we strive to reduce the number of handoffs,
either by automating significant portions of the work or by reorganizing teams so
they can deliver value to the customer themselves, instead of having to be
constantly dependent on others. As a result, we increase flow by reducing the
amount of time that our work spends waiting in queue, as well as the amount of
non–value-added time.

5.持续的识别和提高约束

这一节看的懵懵懂懂，不知道作者想表达啥。

Because our goal is to enable small teams
of developers to independently develop, test, and deploy value to customers
quickly and reliably, this is where we want our constraint to be.

6.消除困难和浪费（ELIMINATE HARDSHIPS AND WASTE IN THE VALUE STREAM）

我们的目标是让这些浪费和困难可见，并减轻或消除这些负担和困难，以实现我们的快速流动的目标。

哪些属于困难和浪费？
Partially done work: 未完成的工作会导致一部分已经完成的工作变得过时或无用，这就是一种浪费
Extra processes: 执行了一些额外的流程，花费了时间，但是却没有给客户带来任何价值
Extra features:增加了客户并不需要的额外功能，但是增加了测试量和复杂度
Task switching:一个dev被分配到不同的project，在其中切换，会浪费不少时间
Waiting:资源等待
Motion:信息在团队之间流动、交接时，会导致时间浪费
Defects:不正确、不清晰的信息，或造成困难和时间浪费
Nonstandard or manual work:应该是自动的
Heroics