DevOps 文字培训

应如何让 DevOps 工作流顺畅运行？

在 DevOps 中，工作流指软件的端到端生产链，从产生想法到代码在生产系统中运行。你和 DevOps 团队负责建立并保持可靠、稳定、快速的工作流，以达到并超越组织目标，并在所在市场胜过其他产品与服务。

为 DevOps 转型确定使命

DevOps 团队就位后，下一步是确定使命。团队只有具备共同使命，才能正常运作。没有使命，就无法为关键工作确定优先级，也无法区分阻碍进展的大问题与日常杂务。使命应具有挑战性、令人振奋，同时要能在规定时间内实现。

使命应按你自己的 DevOps 团队量身制定。应根据组织特点、面临的挑战和目标来确定，为与你的团队打交道的内部和外部客户服务。

以下是一些可以用来启动 DevOps 转型的使命宣言示例：

• 在 3 个月内将从提交代码到上线生产系统的平均前置时间缩短 75%。
• 在 6 个月内将从提出请求到上线生产系统的平均前置时间缩短 33%。
• 在 12 个月内将生产事件的数量减少 50%。

什么是价值流？谁参与价值流？

要改进工作，就需要了解价值流。信息技术系统中的价值流是一系列活动，用于设计、构建和运维特定的软件产品和服务。价值流也界定了确保其顺畅流转所需的人员、专业知识、设施和材料。

在复杂的组织架构中，没有人可以独立识别完整的端到端价值流。因此，DevOps 团队全体成员、利益相关方、供应商、客户代表，以及可能的情况下客户本人，都应参与识别价值流。

绘制价值流图，发现改进机会

价值流图让你和 DevOps 团队能够直观地看到软件开发与交付组织中的典型工作是如何完成的。绘制价值流图的目的并非详尽记录完成工作所需的每一步，而是充分理解典型工作流程，找出主要的低效环节、制约因素、问题，以及浪费时间和资源的地方。

软件开发和运维工程师第一次坐在一起绘制价值流图时，运维工程师往往才意识到，配置有误且缺少表空间的数据库服务器会给开发团队带来什么负面影响。同样，软件开发工程师往往才看到，交付没有内置监控、可用性、可测试性和配置功能的软件会带来什么后果。

尽可能消除交接、制约因素和浪费

交接、浪费和制约因素对效率影响很大，却往往被忽视。活动从一个团队移交到另一个团队时，需要通知、请求、排期、确定或降低优先级，以及解决冲突。

工作从一个团队传到另一个团队时，每次交接不仅会导致信息丢失，还会延长价值流的整体前置时间。

要解决这些问题：

• 质疑每次交接所需的时间。 例如，上面的价值流图显示，代码成功通过测试后，要等 80 小时才会由部署团队接手。为什么会这样？能否自动化这一步？当然可以。
• 消除重复交接造成的浪费。 根据上面的价值流图示例，测试团队把 65% 的功能退回给开发团队。有些缺陷需要交付多达 3 次修复，测试人员才会批准。能否改善开发和测试团队之间的协作，加快这些迭代？大量缺陷也表明开发团队的某些环节没有达到最佳效果，需要找出并解决这些质量问题的原因。
• 质疑交接的必要性，并尽可能取消交接。 根据上面的价值流图，请求细化完成后，要等 320 小时才会由审批人员处理。为什么组织需要这样的审批人员？他们为价值流带来什么价值？他们掌握的信息和见解足以作出正确决定吗？为什么不让审批人员加入请求细化团队？这样，他们会更了解自己在批准什么，还能减少一次耗时 320 小时的交接。如果不消除拖慢工作流的制约因素和障碍，就不能指望 DevOps 带来多少改善。

DevOps 要求你提出这类问题来打破现状。当然，组织内并非人人都乐意听到这些问题，但你已经为此做好了准备。

让所有人都看得见工作流

为确保工作从左向右顺畅流转、DevOps 组织达成目标，需要使用让工作流可见的工具和机制。在信息技术行业，把价值流中的工作从一个团队派给另一个团队，只需点一下鼠标。然而，由于工作未完成、依赖关系不一致或出现误解，工作经常在团队间来回传递，正所谓“前进一步，后退两步”，即使还能流转，速度也很慢。

因此，工作流应对所有人可见，包括团队内外。DevOps 使用产品待办列表、Sprint 规划待办列表和看板呈现工作流。这些看板除了列出你自己的 DevOps 团队负责的工作，还应让产品和服务从构思到运维、维护和退役的整个流程清晰可见。这样一来，只要工作受阻，所有人都能迅速发现。消除障碍、确保工作持续顺畅流转，是所有人的共同责任。

限制批次大小和在制工作量

一项由 Stanford University 开展的研究发现，同时处理多项任务的效率低于一次只做一件事。研究人员还发现，经常受到多股电子信息流冲击的人，在集中注意力、回忆信息或切换任务方面，都不如一次完成一项任务的人。

这对 DevOps 团队意味着什么？你需要减少在制工作，限制代码交付的批次大小。例如，团队可将同时开发的任务限制为最多 6 项，以免频繁切换任务，能够专注于手头工作。也可以根据斐波那契数列（0、1、2、3、5、8、13、21、34……）估算每项任务的故事点数，由 DevOps 团队在给定时间段（Sprint）内完成不超过一定总点数的工作，这一数值就是团队速率。

限制交付批次大小除了提升质量与生产力，也能让你更快找出问题根因并加以解决。任务完成后，将代码提交到共用存储库，用持续集成平台验证，然后部署到生产环境。批次较小，就更容易识别代码交付导致的生产问题，需要时也更容易回滚。此外，通过持续向生产环境交付，团队会持续为自己对组织使命的贡献感到自豪。你可以将这种工作方式与另一种情况对比：团队花 8 个月编写代码，却没有一行上线到生产系统，想想他们的士气、积极性和面临的技术挑战。

拿出 20% 的时间减少技术债务

如果组织不留出时间减少技术债务，却不断叠加临时解决办法，最终所有工程师的全部时间都会用来修复问题。用财务债务打个比方，组织就只能一直付利息。

总结

本章介绍了 DevOps 中的价值流和工作流、它们的重要性，以及如何让工作沿价值流顺畅推进。