DevOps-选择策略-全-

DevOps 选择策略（全）

原文：annas-archive.org/md5/d185a837cc2b571d10ab8052ccaf2eb5

译者：飞龙

协议：CC BY-NC-SA 4.0

序言

每个组织都希望采纳 DevOps，作为 IT 专业人士，理解 DevOps 的基本原则及其如何促进组织的成功至关重要。本书全面介绍了实施 DevOps 文化、人员和流程所需的步骤。

本书适合谁阅读

本书面向 IT 专业人员，如支持工程师、系统工程师和开发人员，尤其是那些希望学习 DevOps 或正在经历 DevOps 转型的人。具备一定的 IT 和业务流程的基础知识将会有帮助。如果你在 IT 领域担任业务或服务角色，如服务交付管理，本书对你也会有帮助。

本书涵盖了什么内容

第一章，介绍 DevOps 和敏捷，介绍了 DevOps 和敏捷的概念，解释了 DevOps 的目标以及敏捷如何在 DevOps 中发挥作用。

第二章，DevOps 的商业利益、团队拓扑结构和陷阱，展示了 DevOps 的好处，并探讨了用于 DevOps 采纳的团队拓扑结构。

第三章，衡量 DevOps 的成功，展示了如何使用度量标准来衡量 DevOps 的成功，并使用适当的度量标准来应对不同的场景。

第四章，构建 DevOps 文化和打破孤岛，更详细地探讨了 DevOps 的文化，并讨论了如何构建成功的文化并打破组织的孤岛。

第五章，避免 DevOps 中的文化反模式，讲解了构建 DevOps 文化的挑战。

第六章，通过价值流图推动流程变革，深入介绍了价值流图是什么，以及如何在组织中使用它们。

第七章，在组织中推动流程变革，讨论了如何管理和推动组织中的流程变革，以实现成功。

第八章，持续改进流程，介绍了持续反馈的技巧，以及如何迭代流程变更。

第九章，理解 DevOps 的技术栈，探讨了 DevOps 工具链的优缺点。

第十章，制定工具实施策略，展示了如何制定有效的工具实施策略，并解决组织的培训需求。

第十一章，跟上关键的 DevOps 趋势，探讨了最新的 XOps 趋势及其与 DevOps 的关系。

第十二章，在实际组织中实施 DevOps，汇总了我们所学的所有内容，以研究 DevOps 在现实世界中的实施。

下载彩色图片

我们还提供了一个 PDF 文件，包含本书中使用的截图/图表的彩色图片。你可以在这里下载：www.packtpub.com/sites/default/files/downloads/9781801076326_ColorImages.pdf。

使用的规范

本书中使用了以下文本规范。

提示或重要说明

以这种方式显示。

联系我们

我们始终欢迎读者的反馈。

一般反馈：如果你对本书的任何内容有疑问，请在邮件主题中提到书名，并通过电子邮件联系我们：customercare@packtpub.com。

勘误表：虽然我们已尽最大努力确保内容的准确性，但难免会有错误。如果你在本书中发现错误，我们将非常感激你向我们报告。请访问 www.packtpub.com/support/errata，选择你的书籍，点击“勘误提交表单”链接，并输入相关细节。

盗版：如果你在互联网上发现我们作品的任何非法复制品，我们将非常感激你提供其位置地址或网站名称。请通过电子邮件联系我们：copyright@packt.com，并附上相关材料的链接。

如果你有兴趣成为作者：如果你在某个主题上具有专长，并且有意写作或参与编写书籍，请访问 authors.packtpub.com。

评审

请留下评价。当你阅读并使用本书后，何不在你购买书籍的网站上留下评价？潜在的读者可以通过你的公正意见做出购买决策，我们 Packt 也能了解你对我们产品的看法，作者们也能看到你对他们书籍的反馈。谢谢！

欲了解有关 Packt 的更多信息，请访问 packt.com。

第一部分：DevOps 和敏捷方法的原则

在本节中，您将深入了解 DevOps 的基本知识，包括其益处、陷阱和工具。

本书的这一部分包括以下章节：

• 第一章，介绍 DevOps 和敏捷方法

• 第二章，DevOps 的商业益处、团队拓扑结构及其陷阱

• 第三章，衡量 DevOps 的成功

第一章：介绍 DevOps 和敏捷

在本章中，我们将介绍 DevOps 和敏捷。我们将探讨一些问题，包括 DevOps 想要实现什么？，以及 敏捷在 DevOps 中扮演什么角色？。我们还将探讨成功的 DevOps 转型的价值，以及 DevOps 为组织解决的挑战。我们还将学习如何构建 DevOps 成熟度的四个阶段。

在本章中，我们将讨论以下主要内容：

• 探索 DevOps 的目标

• 与 DevOps 相关的价值

• DevOps 解决的挑战

• DevOps 成熟度的阶段

• 敏捷在 DevOps 中扮演什么角色？

探索 DevOps 的目标

DevOps 是一个通常会引发许多不同意见的话题，关于它意味着什么，以及如何在你的组织中实施 DevOps。DevOps 的目标和它在组织中帮助实现的目标也是根据不同人的经验、他们所在的行业以及组织在采纳 DevOps 方面的成功与否，会得到不同答案的内容。

对于许多组织来说，你可以定义以下共同的 DevOps 目标。这些是适用于大多数组织的目标：

• 部署频率

• 更快的市场交付时间

• 更低的失败率

• 更短的交付周期

• 更好的恢复时间

当然，你的组织可能有不同的驱动因素，甚至对于相似的组织，我也预计他们的目标会略有不同。毕竟，虽然大多数组织面临相同的挑战，但这些挑战如何解决，以及哪些挑战会带来最大的价值增益，也会根据组织的不同而有所不同。

部署频率

提高你在组织中发布或部署软件的频率通常是推动 DevOps 采用的关键因素。我们必须开始改变我们在组织内部的协作和沟通方式，以便为最终用户提供价值。

当开发和运维团队开始专注于相同的共同目标时，他们开始更有效地合作并提供更好的价值。

更快的市场交付时间

大多数组织将与其他组织竞争其提供的服务。拥有更快的市场交付时间可以为你提供比竞争对手更大的竞争优势。通过 DevOps，你可以通过减少从构想到产品发布所需的时间来增加价值。

作为一个企业，你的价值会随着发布产品功能的时间延长而下降，而你的竞争对手能够更快地领先于你。因此，实现更快的市场交付时间不仅是 DevOps 的关键目标，也是业务的关键目标。

更低的失败率

每个组织都会遇到失败，但通过 DevOps，随着时间的推移，你可以预期通过团队之间的协作和更好的沟通来实现较低的失败率。

提示

DevOps 中的跨职能指的是来自不同领域的人们在一个团队中共同工作。

DevOps 使团队能够更紧密地合作并进行更有效的沟通。在成熟的组织中，它允许跨职能团队的协作。这些团队之间及其中个体之间共享的知识，以及对彼此角色的更大理解，有助于降低失败率。

更短的交付周期

交付时间是指从开始到完成特定任务所花费的时间。在 DevOps 中，这指的是从用户故事开始工作到该故事发布所需的时间。

与更快的市场响应时间和更短的交付周期紧密相连，缩短交付时间不仅仅是关于产品，还涉及整个生命周期中的各个方面。这可能包括从规划阶段有效捕获需求，到比以前更快地建设基础设施。

通过流畅的流程、有效的沟通与协作，以及高水平的自动化，整个生命周期的交付时间将会更短，从而带来团队的高效表现。

改进的恢复时间

当然，我们都知道大多数组织都有服务级别协议（SLAs）来衡量关键服务指标的表现，如可用性。然而，有多少组织能告诉你，平均需要多长时间才能恢复一个服务呢？并不多。

拥有能够讨论失败原因、理解原因并采取措施防止失败再次发生的协作水平，是成熟组织的标志。一个能够衡量这些指标并采取措施减少这些指标的组织，才是一个更加成熟的组织。

停机时间是组织收入的损失和声誉的损害，因此减少停机时间非常重要。

在本节中，我们探讨了 DevOps 的关键目标以及采用 DevOps 背后的商业价值。接下来，我们将更深入地讨论使 DevOps 成功的价值观。

与 DevOps 相关的价值观

当谈到转型时，DevOps 可以分为不同的支柱。也就是说，如果你想从一个高层次的角度而非更深层次的角度来了解 DevOps，你可以将 DevOps 视为四个具体的领域。

这些领域如下：

• 文化

• 人员

• 流程

• 技术

我坚信这些顺序是很重要的。虽然初衷可能是先处理工具问题，但遵循这里列出的顺序将确保你的组织能够从 DevOps 转型中获得更多的价值。

重要提示

文化是成功的 DevOps 转型中最重要的方面之一，甚至比技术的使用更为重要。

DevOps 中文化的重要性不可过分强调；在组织中建立正确的文化可以帮助你朝着正确的方向前进，并在转型后期获得更多价值。你也不应低估改变组织文化的挑战——这需要强大的推动力和高层领导的支持才能成功。

接下来是人员，任何企业和产品的命脉。你必须确保拥有合适的人才，建立起正确的文化，以实现组织设定的目标，而这些人必须具备实现这一目标所需的技能。就像高层管理支持对 DevOps 的重要性一样，拥有合适的人才来执行它同样至关重要。

现在，我们谈到流程。拥有正确思维的人将是那些能够正确引导和推动流程的人，他们会应用适当的技术确保你的流程在 DevOps 的环境中适用。为了实现协同工作，你需要采用一些持续协作的流程，比如计划、开发、发布和监控。最后，你需要具备按需重复这些流程的能力，以提供最大价值。

最后是技术。到这个阶段，你在 DevOps 转型过程中所做的工作应该已经为你的组织带来了极大的价值，但通过引入技术，你可以再增加更多的价值。通过自动化工具，你的流程现在可以按需运行，更频繁地执行，且更重要的是，具有幂等性。这意味着使用相同输入参数的结果随着时间的推移不应发生变化。这就是自动化相比人工执行带来的价值。

在本节中，我们探讨了让 DevOps 成功的价值观。现在我们理解了实施 DevOps 的含义，接下来我们将理解 DevOps 在我们组织中所能解决的挑战。

DevOps 解决的挑战

DevOps 确实解决了组织中的许多挑战。你需要注意的是，许多挑战已经存在了相当长的时间，并深深根植于人们的工作方式中，要解决这些问题将需要一些时间。

在采用 DevOps 之前，组织通常按职能团队进行划分，并向直线经理汇报，彼此之间以及与更广泛的业务常常是孤立的。如果所有部署条件都满足，代码会被移交给运营团队进行应用部署。这些团队与其他团队一样，各自独立工作，孤立操作，导致了时间消耗大的活动被重复执行，结果也不尽如人意。

DevOps 的挑战通常可以通过以下三句话来解释：

• 开发人员对质量保障和运营中的障碍不清楚。

• 质量保障和运营团队通常不了解产品的商业目的和价值。

• 当团队各自独立工作时，每个团队都有自己的目标，这些目标往往与其他团队的目标相冲突。这导致了低效率。

在前面列表中的最后一点，可以通过开发团队和运维团队的合作来举例。开发人员的优先任务是快速发布新特性，而运维团队的优先任务是保持应用程序的可用性和高性能。这两个目标是冲突的，导致了这两个团队之间的低效。

解决这些挑战

这些挑战通过在 DevOps 中将团队转变为跨职能团队来解决，团队成员之间相互协作并沟通彼此的工作及最终结果。总体而言，这种方法提高了反馈的质量，并解决了现有自动化中的问题。

在 DevOps 中，大多数过程是持续的。通过反馈周期来改进已有的内容，这使你能够不断地成熟和演变你的过程，从而从以往的情况中学习，成为一个更加成熟的团队。

重要提示

解决 DevOps 挑战是一个耗时的任务；你不应指望通过几天或几周的努力就能看到即时效果。要实现你设定的目标，可能需要几个月的时间。

现在我们已经了解了与 DevOps 相关的挑战，是时候看看 DevOps 中的成熟度阶段，并了解一个组织如何根据这些阶段进行进展。

DevOps 成熟度阶段

组织应该随着处理和采纳不同的 DevOps 最佳实践而逐步成熟。这被称为成熟度，四个阶段用于描述 DevOps 中的成熟度阶段。

这些阶段如下：

• 瀑布式

• 持续集成

• 持续交付

• 持续部署

在 DevOps 转型的过程中，组织应从瀑布式方法逐步向持续部署过渡，并在此过程中访问每个阶段。然而，值得注意的是，瀑布式方法并不总是起始点；一些组织在后期才开始进入这些阶段。

在转型过程中，你会发现不同的团队成熟的速度不同。造成这种差异的因素有很多，包括团队所做的工作类型、他们必须遵循的流程，以及一定程度上他们已有的自动化和工具的水平。

瀑布式

如果你以前在项目中工作过，“瀑布式”这个术语你一定会很熟悉。瀑布式是一种项目交付机制，任务按顺序完成，以实现特定目标。它也可以用来解释一种软件开发的方法。

开发团队在长时间内编写代码后，这些团队会将代码合并，以发布最新版本。在这种情况下，代码库已经进行了许多更改，集成新版本可能需要几个月的时间。这是因为代码与之前的版本差异太大。

瀑布模型已经在项目管理领域存在很长时间了，即使敏捷方法越来越流行，许多项目仍然使用瀑布方法成功执行。

使用瀑布交付方法的优势如下：

• 模型简单易用，易于理解。

• 由于其僵化性，管理起来较为简单；每个阶段都有明确的交付物。

• 在较小的项目中，由于需求已经非常明确，它能够很好地运作。

• 交付阶段被明确定义。

• 里程碑已被充分理解。

• 任务与资源的安排简单易行。

• 过程及其结果有详细的文档记录。

话虽如此，瀑布模型确实存在一些缺点，正如所有过程模型一样。以下是其中一些缺点：

• 没有时间进行修订或反思。

• 风险和不确定性很高。

• 对于复杂且面向对象的项目而言，这不是一个好的模型。

• 对于长期项目而言，模型效果不佳。

• 直到项目后期才会产生可工作的软件。

• 在各个阶段衡量成功是困难的。

• 集成在最后以大爆炸方式进行，使得识别瓶颈变得困难。

敏捷方法解决了这些挑战，并且与 DevOps 结合使用，可以解决许多在这里描述的挑战。

持续集成

持续集成（CI）是将新开发的代码快速与其余应用程序代码集成的实践，直到最终发布。这样可以在应用程序准备发布时节省时间。这个过程通常是自动化的，并在过程结束时生成构建工件。

持续集成（CI）过程包含多个步骤，这些步骤对于实现有意义且高效的持续集成至关重要。自动化测试是实现持续集成的第一步。持续集成中有四种主要类型的测试可以自动化。这些测试如下：

• 单元测试：测试的范围较窄，通常聚焦于特定的代码部分，例如函数的方法，用于测试给定参数集的行为。

• 集成测试：确保不同组件能够协同工作。这可能涉及到应用程序的多个部分，以及其他服务。

• 验收测试：在许多方面，这与集成测试相似。最大区别在于，验收测试聚焦于业务案例。

• 用户界面测试：专注于从用户的角度测试应用程序的性能。

  重要提示

  持续集成的一个至关重要的要素是，进行早期集成并频繁集成。

当你进行频繁且早期的集成时，你能够减少变更范围，从而更容易在发生冲突时识别和理解冲突。这个方法的另一个大优点是，随着变更变得更易于消化，知识共享变得更加容易，而不像大规模的代码变更那样难以处理。

另一个要注意的事项是，如果主分支由于代码提交而出现问题，那么优先级最高的是修复它。在构建失败时，越多的更改会使得理解问题的根源变得越难。

每一个新实现的工作都应该有一套独立的测试。养成编写细粒度测试并追求一定代码覆盖率的习惯非常重要，因为这样可以让你有足够的信心，确保你正在充分测试应用程序的功能。

持续集成的价值在于团队频繁地进行更改时得以体现。确保团队每天都进行这些更改集成非常重要。正如你所记得的那样，频繁集成是确保我们能够轻松识别问题所在的关键。

持续交付

持续交付（CD）是一种方法，团队通过自动化工具频繁且高质量地发布产品，并从源代码库到生产环境都具有可预测性。这是在持续集成（CI）工作的基础上，利用构建工件将构建成果交付到生产环境。

持续交付实际上是与敏捷方法相关的一系列最佳实践。它将你的组织聚焦于开发一个高度精简和自动化的软件发布流程。这个流程的核心是一个互动的反馈环。

这个反馈环路，有时称为持续反馈，着重于尽快将软件交付给最终用户，通过经验学习，然后将这些反馈纳入到下一次发布中。

持续交付是一个独立于持续集成的过程，但它们是相互关联的，在成熟的组织中，二者是一起使用的。这意味着，在你为实现自动化测试所做的持续集成工作之上，你现在可以在构建阶段之后，自动部署所有这些更改。

通过持续交付，你可以决定最适合组织的发布计划，无论是每日、每周还是每月——根据你的需求来定。如果你想获得持续交付的真正好处，那就应该尽快部署到生产环境，确保发布的小批量可以在出现问题时轻松解决。

持续部署

持续部署是持续交付的进一步发展。每一个通过生产流水线所有阶段的更改都会直接发布给客户。没有人工干预——在此阶段，测试失败会阻止新的版本发布到生产环境。

持续部署是加速反馈循环并减轻压力的好方法，因为没有发布日。开发人员可以专注于构建高质量的软件，同时在完成工作后的几分钟内看到自己的工作上线。持续集成是持续交付和持续部署的一部分。持续部署与持续交付非常相似；它们的区别在于，发布是自动进行的：

图 1.1 – 显示持续集成、持续交付和持续部署之间的差异

在本节中，我们已了解了 DevOps 成熟度的主要阶段。掌握了这些信息后，我们可以进一步探讨敏捷在 DevOps 中的作用。

敏捷在 DevOps 中扮演了什么角色？

常常会混淆“敏捷”（Agile）和“DevOps”这两个术语。它们经常一起使用，甚至可以互换使用，但它们是互斥的术语。DevOps 是将开发团队和运维团队结合起来的实践，而敏捷则是一种强调协作、反馈和小规模快速发布的迭代方法。

虽然两者是互斥的，但从前面的简短对比中，你会发现 DevOps 的目标和价值观也是敏捷的目标和价值观。敏捷是 DevOps 的关键部分。尽管敏捷专注于持续变化，并使开发人员和开发周期更加高效，DevOps 则引入了运维团队来实现持续集成和持续交付。

作为一个项目交付框架，敏捷帮助解决了瀑布模型的一些缺点。由于持续集成、持续部署和持续交付的实践，使用瀑布模型实现 DevOps 是非常困难的，甚至是不可能的。这也是为什么在那些成功实践 DevOps 的组织中，团队会选择使用敏捷作为交付方法的一个主要原因。

敏捷宣言

2001 年，17 位成员在犹他州雪鸟的 Wasatch 山脉中会面。 他们的目标是讨论软件开发的未来。接下来达成的是关于当前软件开发现状的沮丧，即使小组无法就如何解决这一问题达成一致。

小组一致认为，组织过于专注于规划和记录软件开发周期，这导致组织失去了关注的重点——客户满意度。

大多数组织讨论企业价值观，如卓越和诚信，但这些价值观并没有促使人们走向更好的工作方式，尤其是软件开发人员。这是一个需要改变的地方。被称为“雪鸟 17”的几位成员已经有了如何改革软件开发并开启新纪元的想法。这次前往雪鸟山的旅程是该小组定义新纪元的机会。

这次旅行的成果就是敏捷宣言。仅 68 个字，这份简洁的文件永远改变了软件开发。宣言中定义的 12 条原则的发布可以说是软件开发历史上最大的变革。在随后的二十年里，这 12 条原则被世界各地的个人、团队和组织广泛采用。

文化定义

敏捷领域充斥着许多看似将敏捷转化为实际场景的想法。然而，这并不新鲜；事实上，宣言的诞生源于寻找 Scrum、Crystal Clear、极限编程和其他框架之间的共同点。

Snowbird 17 的最大目标之一是看看这些框架的代表是否能达成一致——他们做到了。最终达成的协议形成了一套定义文化的价值观。

敏捷宣言定义了以下价值观：

• 个人和互动优于流程和工具

• 可工作的软件优于全面的软件

• 客户协作优于合同谈判

• 响应变化优于遵循计划

你可以访问在山上会议中产生的完整宣言，地址为 Agilemanifesto.org/。

另一个来自峰会的产物是 12 条原则（agilemanifesto.org/principles.html），它们遵循这些价值观。它们扩展了构成这些价值观的四个句子。

这 12 条原则如下：

• 我们的最高优先级是通过早期和持续交付有价值的软件来满足客户需求。

• 欢迎变更需求，即使在开发后期。敏捷流程利用变化为客户提供竞争优势。

• 经常交付可工作的软件，从几周到几个月不等，优先选择较短的时间周期。

• 商务人员和开发人员必须在项目期间每天合作。

• 围绕积极的个体构建项目。为他们提供所需的环境和支持，并信任他们完成工作。

• 向开发团队及其内部传递信息的最有效方法是面对面的交流。

• 可工作的软件是进展的主要衡量标准。

• 敏捷流程促进可持续发展。赞助商、开发人员和用户应能够保持稳定的工作节奏，持续不断地推进。

• 持续关注技术卓越和良好设计能够增强敏捷性。

• 简洁——最大化减少不必要工作的艺术至关重要。

• 最好的架构、需求和设计源自自组织团队。

• 定期反思团队如何变得更有效，然后根据情况调整和优化他们的行为。

即使你在阅读本书之前对敏捷和 DevOps 的了解很少，我希望你能在那 12 条原则中看到我们迄今为止探索的内容与敏捷宣言原则之间的联系。

敏捷和 DevOps 能否协同工作？

敏捷和 DevOps 听起来像是两个截然不同的概念。事实上，在转型初期，我与许多接触的人对这两个概念感到非常困惑。这种困惑也因为两者各自有自己的术语和口号而加剧。人们通常对 DevOps 众多的定义感到沮丧。

大多数人认为，当你提到“敏捷”时，你指的是 Scrum，而当你提到“DevOps”时，你实际上指的是持续交付。这种简化的理解导致了敏捷与 DevOps 之间的紧张关系，甚至让人误以为敏捷和 DevOps 是敌人。

早在 2008 年，在敏捷大会上，Patrick Debois 和 Andrew Clay Schafer 主持了一场关于敏捷基础设施的讲座，DevOps 与敏捷的关系由此诞生。Patrick 随后创造了“DevOps”这个术语，敏捷大会至今仍然设有 DevOps 主题。

但这不仅仅是历史的原因。现在，让我们深入了解敏捷和 DevOps 之间的实际联系，超越 Scrum 和持续交付的范畴。

敏捷不仅仅是 Scrum

当业务或工作本身的局限性要求做出改变时，一个灵活的团队会运用 Scrum 的基本原则，审视自己的实践，并对其进行调整以提高效率。尤其在 Scrum 应用于软件开发之外的领域时，这一点尤为重要。

处理未计划的工作

在 DevOps 社群中，那些有敏捷经验的人认识到，Scrum 对于跟踪计划中的工作是非常有帮助的。一些工作可以预先安排：比如交付一个重要的框架变更，迁移到不同的服务器，或进行系统升级。然而，很多任务的执行是自发的：如执行冲刺、系统故障、以及安全漏洞等。这些事件要求快速响应。此时，已没有时间等待任务的过度排队或等到下一个规划会议。因此，许多已经接受 DevOps 思想的团队，会把目光从 Scrum 转向 Kanban。这使他们能够同时跟踪两种工作，并理解它们之间的互动。另一方面，他们采用一种混合方法，通常被称为 Scrumban 或 Kanplan（Kanban 加积累）。

从多个角度来看，Scrum 广泛应用的关键可能在于它不提倡任何技术实践。Scrum 轻量级的管理实践通常对团队产生很大影响。在之前，团队中可能有来自不同专业的需求冲突，而现在，所有的需求都集中在额外任务中。而且，曾经开发中的工作量过大，现在的工作量则由时间实际能完成的任务所限制。通过这种方式，这些变化可以帮助团队提高效率。然而，由于缺乏技术实践，如代码审查、自动化验收测试和持续集成，团队可能会感到受限。

其他敏捷周期，例如极限编程，明确表达了技术实践如何支持团队保持高效流动并为管理者和相关方提供透明度和可见性。一些 Scrum 团队会把技术任务放入这些额外任务中。虽然这对于 Scrum 的指导是合理的，但它很快会面临产品负责人对功能的偏好这一实际问题。除非产品负责人具有非常强的技术背景，否则他们可能没有足够的技能来评估技术实践的成本/效益。当技术任务涉及到支持可靠性、性能和安全性的项目时，产品负责人面临的难度更大。

什么是 Scrum？

Scrum 是一个帮助团队合作的系统。Scrum 鼓励团队通过经验学习，在处理问题时自我协调，并回顾他们的成功与失败，以不断改进。

虽然我所讨论的 Scrum 最常被程序开发团队使用，但它的原则和实践可以应用于各种合作。这也是 Scrum 如此流行的原因之一。Scrum 通常被视为一种协作项目管理方法，描述了一组活动、工具和角色，它们共同协作以帮助团队构建和管理他们的工作。

在你的组织中应用 Scrum 不是一项简单的任务，你会遇到一整套全新的术语。这里有一个简短的清单，尽管它并不全面：

• Sprint

• Sprint 计划

• 仪式

• 待办事项

• 回顾

• 站会

虽然 Scrum 可能是敏捷中最常用的框架，但也有许多其他框架。比如看板和 Kanplan，正如我们接下来要讨论的，它们对新接触敏捷的组织非常有用。

看板

看板是一种常见的框架，用于执行敏捷和 DevOps 软件开发。它需要持续沟通工作限制，并提供一个清晰的视图，显示计划中的工作、进行中的工作和已完成的工作。

Kanban 通过将工作放置在物理或数字看板上来工作。这种可视化使你能够限制在制品的数量，并最大化你的工作效率，有时被称为团队的流动（flow）。

许多人在日常工作中使用某种形式的 Kanban 看板。事实上，我认识很多人，他们在家里做日常任务时也会用看板。这个看板被分成不同的列，每一列定义了任务的不同状态。

你的 Kanban 看板还将定义在制品（work in progress）、交付点和承诺点方面的限制。

Kanplan

你可能没听说过“Kanplan”这个词。它是一种方法论的混合，但也许正适合你的团队。

重要提示

当为团队选择敏捷框架时，并没有“灵丹妙药”。框架中不同的方法论根据许多不同的参数有其优缺点。每个团队都需要确定哪个框架最适合他们在规划、跟踪和发布软件时的需求。

Kanplan 结合了 Scrum 和 Kanban 的特点。它非常适合那些希望整理待办项但没有能力进行冲刺（sprint）的团队。它提供了一个很好的折中，因为团队并不总能完全应用 Scrum 的所有内容（包括冲刺），但可以很容易地使用 Kanplan 开始更好地管理他们的工作、在制品、待办项以及这些待办项的优先级。

在组织内混合方法论

不同的团队采用敏捷框架中的不同方法论，互相混合并使之适合自己，并没有什么不对。我从未与任何一个组织合作过，他们能够简单地从敏捷教科书中挑选某种方法并在他们的组织中实施。

想想那些无法使用传统 Scrum 的运营团队，主要是因为他们的工作中包含了许多不可预见的工作，如事故处理。对于他们来说，Kanban 非常适用，因为它不强调规划。再想想在你们组织中，负责产品的完整 DevOps 团队。在这种情况下，传统的 Scrum 方法对他们是有效的，因为一切都在他们的控制之内，并且他们不依赖于外部团队。

最后，想想那些希望更具敏捷性的工程团队，但又需要与其他不实践任何敏捷方法的团队合作。这是一个棘手的情况，因为虽然他们希望更具敏捷性以交付更高质量的工作，但组织内其他团队没有采纳敏捷方法论的意愿。在这种情况下，Kanplan 对他们来说是个不错的选择，它能让他们根据优先级整理工作待办项，并在 Kanban 风格的看板上进行工作，从而使他们能够直观地看到工作、在制品限制以及已完成的工作。

这种方法是适合这种描述的团队的一个很好的起点，它将使他们朝着更高质量的工作目标迈进，能够在不需要整个组织跟进的情况下，融入一些 DevOps 的技术方法。

扩展敏捷团队

通过我们到目前为止学到的内容，我们可以看到在组织中实施敏捷可以带来许多好处。然而，组织的规模远大于单个团队，你可能会有多个团队共同开发一个产品。此时我们需要理解如何将敏捷扩展到一个组织中的多个团队。与在单个团队层面实施敏捷相比，后者相对容易，企业级的实施才是真正的挑战。

在企业级别扩展敏捷要求我们采用敏捷概念，以及在职能层面采用精益敏捷。这包括财务、采购、人力资源和销售等领域。在企业级别，敏捷是跨多个团队和大量工程师以投资组合方式进行实施的实践。

重要说明

在企业中扩展敏捷要求你从职能角度思考。到目前为止，我们所探讨的内容仅限于团队层面。要扩展敏捷，你必须把它看作是一项全组织的工作。

Netflix 创造了“高度一致，松散耦合”这一短语，你仍然可以在他们的主要招聘页面看到这句话。它描述了一个高度成熟的组织，整个企业都使用敏捷开发。

当谈到在企业级别扩展敏捷时，两个非常受欢迎的模型是规模化敏捷框架（SAFe）(www.scaledagile.com/enterprise-solutions/what-is-safe/)和 Spotify 模型(www.atlassian.com/agile/agile-at-scale/spotify)。这两者都非常受欢迎，所以我们来更详细地了解它们。

规模化敏捷框架

直接引用自 SAFe 官网，这是 SAFe 的定义：

''规模化敏捷框架（SAFe）使复杂的组织能够在大规模上实现精益敏捷软件和系统开发的好处。''

该框架定义了四个核心价值：

• 一致性

• 内建质量

• 透明性

• 程序执行

SAFe 实际上涵盖了四个主要领域：敏捷开发、精益产品开发、系统思维和 DevOps。然而，它的核心更注重前述列表中描述的四个价值观。

一致性是确保你跟上快速变化、破坏性竞争力量和地域分散团队的步伐所必需的。在这些场景中，一致性至关重要，因为敏捷团队非常出色，但战略和一致性不能仅仅依赖所有敏捷团队的意见。一致性来自于企业级的商业目标。

系统越大，质量越高。关于质量的重要性，尤其是在大型系统中，是无可争议的。内建质量确保了整体解决方案中的每个元素都能够反映出在整个开发生命周期中所需的质量。你可以通过敏捷测试、行为驱动开发（BDD）和测试驱动开发（TDD）来理解这一点。

透明性源于开发解决方案的难度。随着问题的发生或计划未能如预期进行，如果没有高度的透明性，事实就会变得模糊，任何决策过程将无法基于实际数据做出最佳决策。建立信任需要时间，然而，透明性是信任的来源，它通过 SAFe 在多个层次提供。最重要的是，如果团队无法持续执行或交付价值，那么这一切都无关紧要。SAFe 强调工作系统和业务成果。我们知道，虽然许多组织开始时通过单个团队进行转型，但随着这些团队在可靠且高效地交付更多价值时遇到困难，他们会感到沮丧。

Spotify 模型用于扩展敏捷

对于全球分布的众多工程师而言，Spotify 成功的一个关键部分是公司确保工作的组织方式能够增强敏捷性的做法。在 Spotify 工程团队的历程中，这一做法已经被记录并与世界其他地方分享。

这个模型，现在被称为 Spotify 模型，是一种以人为中心的方法，专注于敏捷扩展中的自主性，且强烈关注网络和文化。多年来，这帮助了 Spotify 以及许多其他组织通过专注于自主性、沟通、协作、问责和质量来提升创新和生产力，但最重要的是交付。

重要提示

虽然通常被称为 Spotify 模型，但它并不是一个框架。这只是 Spotify 从文化和技术角度看待如何扩展敏捷的一种方式。它是如何在产品环境中组织多个团队的一个示例。

该模型首次在 2012 年引入（blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf），并且受到了领域专家的广泛审视。经过检查，它展现了 Spotify 在敏捷性方面的极简方法。从那时起，它引起了大量的关注并变得流行。

这个总体主题是提倡团队自主权，它通过几种方式描述了组织的结构。它通过以下术语来实现这一点：

• 小队

• 部落

• 章节

• 行会

小队是组成部落的团队，章节帮助主题专家相互保持联系，行会则帮助团队在整个组织内保持一致，而章节则使你能够在一个部落内保持团结。

重要说明

像其他敏捷模型一样，确保在组织内部实施时，有足够的反馈机制和透明度，以建立和维持信任与自主的文化，是非常重要的。

现在我们已经理解了敏捷在 DevOps 中的角色，我们知道它在许多方面是 DevOps 的核心，并且如果我们想要成功，它至关重要。

摘要

这就是第一章的内容。到目前为止，我们已经介绍了一些将在本书其余部分中使用的术语，并确保你对 DevOps 的主要概念有了良好的基础理解，包括它给组织带来的价值、它能够帮助你解决的挑战，以及敏捷方法在 DevOps 中的作用。

在下一章中，我们将探讨 DevOps 如何给业务带来好处，以及根据你的结构，如何使用不同的团队拓扑来取得伟大成就，并强调一些 DevOps 的陷阱以及如何避免它们。

第二章：DevOps 的业务收益、团队拓扑和陷阱

展示 DevOps 如何能为您的业务带来好处的能力，在推动成功所需的变革时非常重要。本章将探讨 DevOps 转型的业务利益，以及在 DevOps 转型过程中可以采用的团队拓扑结构。最后，本章还会讨论可能导致 DevOps 转型项目失败的陷阱和错误。

本章将涵盖以下主要主题：

• DevOps 的关键业务利益

• 转型拓扑

• 转型反模式

• 避免转型失败的项目

DevOps 的关键业务利益

在 DevOps 转型过程中，获得组织内高层领导和高级管理层的支持至关重要。如果没有这种支持，您的转型将面临严重的挑战，甚至可能在真正开始之前就失败。

确保获得必要支持的一种方法是确保高层领导和高级管理层了解 DevOps 的业务利益。您不能仅仅向单个团队或领导解释技术或局部的好处。他们想要了解的是，这种新工作方式为什么值得他们投入资金，如何帮助业务加速发展。

简而言之，如何确保 DevOps 能够解决您组织的关键绩效指标（KPIs）和业务目标？

重要提示

在开始 DevOps 转型时，尽早争取高层支持是非常关键的；这样，您可以根据与高层和高级领导的讨论，适时调整您的方法。

为了最好地准备与高级领导的会议，讨论 DevOps 转型，您首先需要了解业务目标。这不是在高层次上的目标，而是在绩效衡量层次上——业务具体希望通过哪些指标来推动其绩效仪表盘的变化？这些是您可以着眼于 DevOps 如何帮助推动这些关键绩效指标（KPIs）的领域，例如：

• 客户体验（CX）

• 业务增长

• 成本节省

• 提高生产力

• 提高员工保持率

• 更高质量的产品

• 提高客户满意度

• 提高操作和流程效率

现在，让我们更详细地了解这些元素，以便更好地理解它们。

客户体验

在任何业务中，客户推动着成功，而更好的客户体验（CX）最终推动着产品的续订和业务的增长。客户体验对任何企业的成功至关重要。提高整体客户体验可以促进客户忠诚度、保持率和利润，并且能缩短销售周期。

在 DevOps 中，改进的生产支持是关键，也是 DevOps 存在的基础支柱之一。开发团队和运维团队之间更好的协作，通常最终能提升产品质量。正是这些因素对客户体验（CX）产生直接影响。

单凭这一点，CX（客户体验）就能得到极大的提升，因为业务团队和技术团队都专注于最优的输出，或者说——相同的目标。

业务增长

随着销售和客户服务的增长，前景也在增长。特别是，随着公司增长的提升，可用于企业的资本也会增加。这些资金可以再投入到业务中，进一步发展流程和系统。此外，提高的生产力和绩效确保员工有更多的时间，并能被解放出来专注于更高效、更具收入潜力的项目。

降本增效

值得注意的是，这里列出的所有变化和改进都有助于减少整体成本。生产和绩效的提升带来更高的销售、降低的运营成本以及更高的客户满意度，这些都会进一步改善收入。DevOps 明确鼓励持续的变革和发展循环。

生产力提升

更多参与且忠诚的员工意味着更高的生产力，尤其是当他们相信自己所做的事情时。但不仅仅是这一因素能导致生产力的提升。

在信息技术（IT）领域，团队通常被要求用更少的资金做更多的事情，这时自动化工具就发挥了作用。它们能够自动化和优化那些重复且频繁轮换的内部流程。DevOps 认可这种做法，尽管它已扩展到市场的其他领域。自动化常见任务为员工释放了时间，使他们能够集中精力处理更有意义的工作，并花更多时间做自己擅长的事。

提高员工留存率

毫无疑问，员工参与度是组织成功的最关键因素之一。如果员工在工作中不满意、效率低下或不合规，无论是表现还是整体结果都会受到影响。

高性能和功能完善的 DevOps 工作环境已被证明能大大提升员工体验。这一趋势不仅鼓励更高的员工参与度和生产力，还增强了品牌忠诚度。当当前的员工感到满意时，这对于员工留存率是个好兆头，也能吸引新人才加入。

尽管现在稍显过时，Puppet 的 2016 年 DevOps 状态报告 (puppet.com/resources/whitepaper/2016-state-of-devops-report) 显示，在 DevOps 组织中运营的推广者，比低绩效 DevOps 公司的人推荐他们的公司给朋友的可能性要高出 2.2 倍。

更高质量的产品

DevOps 提倡一种持续一致和优化的开发文化，这不可避免地导致应用程序和产品的改进。具体来说，在软件开发中，目标是减少产品中发生的错误或 bug 的数量。

更高的客户满意度

客户服务与满意度之间有着强烈的关联。体验越好、越乐观，满意度评分就越高。这意味着，当然，如果 DevOps 提升了客户体验（CX），它也会提升客户满意度，前提是部署得当。

提高运营和流程效率

由于 DevOps 呼吁重新评估和演化当前的流程和开发操作，出现了向更高性能提升的趋势。随着公司致力于提升整体运营，他们正在朝着能够提供更高性能的流程、方法和实践迈进。常识告诉我们，整体而言，整个公司将因而看到生产力的提升。

但也有数据支持这一举措。CA Technologies 的一项研究，通过敏捷和 DevOps 加速速度和客户价值（docs.broadcom.com/doc/accelerating-velocity-and-customer-value-with-agile-and-devops-research-paper），显示了实施 DevOps 的组织在他们监控的组织或流程绩效的 KPI 中看到 40% 的增长。

转型拓扑结构

每个组织都是不同的；即使是同一行业的组织也存在差异，原因有很多。为了使转型尽可能有效，有许多不同的拓扑结构可用于与组织中的其他团队合作，具体如下：

• 开发与运营协作

• 共享操作

• DevOps 作为服务

• DevOps 倡导

• 站点可靠性工程（SRE）

• 容器驱动

你可能会认识到其中一些，可能来自你自己的组织。不过，实际上还有更多，这些拓扑结构都有详细记录，海报形式可以在 DevOps Topologies（web.devopstopologies.com/）购买。

重要提示

对于你来说，开始转型之旅时，按照前述的拓扑结构之一进行调整是常见的做法，等到你足够成熟时再切换到另一种模型。这种方法没有问题，在大多数情况下，这会带来更高的成功率，而不是一开始就瞄准顶峰。

开发与运营协作

第一个模型可能是最受欢迎的，并且通常被视为 DevOps 的黄金模型或理想模型。这个模型使得组织内的开发团队和运营团队能够顺畅协作，如下图所示：

图 2.1 – 显示开发人员与运营团队协作的示意图

各团队会在必要时共享知识，但每个团队都会专注于特定的产品或产品的一部分。这通常会涉及多个不同的开发团队。

这种模型非常有效，特别适用于那些拥有强大技术领导力的组织。不过需要注意的是，要实现这种模型，你将需要经历一场重大的组织变革。

为了成功实现，你需要管理团队中更高层次的能力支持。同样重要的是，开发和运营团队必须有非常明确且可衡量的共同目标，无论是提高可靠性、增加部署频率，还是其他目标。

你的运营团队必须与开发团队紧密合作，并且熟悉他们的一些流程和工具；这包括测试驱动开发（TDD）和用于源代码控制的 Git。此外，开发人员还必须非常重视运营功能，并在功能实现方面寻求运营团队的意见。

总的来说，这需要在文化上进行高度变革，改变这些团队过去的合作方式，因此虽然这种模式非常有效，但实现起来非常困难。你可能会发现自己一开始实施的是另一种模式，并随着组织的成熟逐步朝这个目标努力。

共享运营

如果你在一个以产品团队为单位运作的环境中工作，而不是以单独的职能团队为单位，那么我们就能看到共享运营拓扑图。在这种拓扑图中，开发和运营团队之间几乎没有什么分隔，大家都专注于共同的责任。下图展示了这一点：

图 2.2 – 显示开发人员与运营团队之间分隔极少的示意图

与前述模型一样，这种模型也有很高的效果，非常适合任何拥有单一产品或服务的组织。从实际情况来看，它是我们之前讨论的模型的一种形式，但具有一些特殊的特征。

拥有单一产品的组织——例如 Netflix、Spotify、Facebook 和 Twitter——可以实现这种拓扑结构。然而，我认为，除了专注于单一产品的情况下，这种拓扑结构并不太适用。

在拥有多个产品线的组织中，预算约束和产品线之间的焦点切换通常会导致开发和运营团队进一步分离，很可能回到前述的模型。

另一种描述这种拓扑结构的方式是NoOps。在这种模型中，运营团队没有明显的独立性。

DevOps 作为一种服务

到目前为止，我们已经看过有利于初创企业的拓扑结构，因为它们可以从零开始以正确的方式构建，或者有利于大型企业组织，它们寻求改变自己的运营模式。对于那些可能没有足够预算、经验或员工来主导其产品运营方面的小型组织，开发团队可能会依赖外部服务提供商，示例如下图所示：

图 2.3 – 显示 DevOps 作为服务拓扑结构的图示

服务提供商的角色是帮助他们构建环境，自动化基础设施，并提供平台的监控。提供商还可以就开发周期中所需的运营功能提供建议。

重要提示

尽管我们称这种拓扑结构为DevOps 作为服务，但重要的是要强调，首先，这种模式不可扩展，客户必须与服务提供商以相同的方式工作才能使其顺利运作，但这并非总是可能的。

这种拓扑结构对于较小的组织来说，有助于学习与运营相关的方面，例如自动化、配置管理和监控。对于服务提供商来说，实施这种拓扑结构作为商业模式的问题在于，这些较小的组织在技能积累后，可能会转向第一个或第二个拓扑结构，因为他们会招聘更多的运营人员。

总体而言，这种模型对于那些经验有限的小型组织可能会有所成效，但如果尝试在大型组织中实施，可能会停滞不前。

DevOps 倡导

当组织倾向于在开发与运营之间存在较大差距时，我们可以引入倡导拓扑结构作为促进团队。这个拓扑结构可以帮助保持开发和运营之间的沟通与合作，具体示例如下图所示：

图 2.4 – 显示 DevOps 倡导拓扑结构的图示

这种拓扑结构适用于所有类型的组织，尤其是在存在漂移趋势的地方。采用这种拓扑结构的结果可能是多种多样的，但它可能会带来非常有效的结果。

重要提示

在使用 DevOps 倡导模型时，要注意 DevOps 团队孤岛反模式。

为了高效运作，倡导团队必须有特定的任务，即促进开发和运营团队之间的沟通与合作。团队成员通常被称为DevOps 倡导者，因为他们的目的是帮助传播 DevOps 实践，并促进团队之间的协作。

对这种拓扑结构的警告是，它可能会迅速出错。你必须确保将你的倡导团队与开发和运维团队的日常交付分开。他们不能被日常工作所吸引，否则他们会失去对目标的专注。

SRE

这种拓扑结构常被称为谷歌模型，与我们之前探讨的其他拓扑结构不同。DevOps 通常会说开发团队应加入值班轮换，但这并不是一个要求。包括谷歌在内的组织采用了一个稍微不同的模型，即开发团队将工作交接给负责运行软件的团队。这时，SRE 团队便发挥作用，如下图所示：

图 2.5 – 显示 SRE 拓扑结构的图示

然而，这种拓扑结构至关重要的一点是，SRE 团队在代码部署到生产环境时拥有最终决定权。团队可以拒绝不符合运营标准的发布，并要求开发人员解决问题。

开发人员需要通过日志、指标和测试结果向 SRE 团队证明发布版本达到了足够高的标准，以便 SRE 团队能够支持。

重要提示

使用 SRE 拓扑结构时，必须小心开发与运维之间的壁垒。单纯地将你的团队重命名为站点可靠性工程师并希望它能奏效是解决不了问题的。

这种拓扑结构很独特，虽然它听起来像是今天大多数组织中使用的常见模型，但它只在具备高水平工程能力和成熟度的地方才真正适用。否则，你将解决不了任何问题，且没有那种成熟度，SRE 团队也没有权力拒绝。

因此，这种拓扑结构可能要么非常低效，要么极其高效——最终结果完全取决于你的文化。

容器驱动

最后，我们来谈谈容器驱动的协作拓扑结构。容器可以消除开发与运维之间的一些协作需求。这是通过将应用的开发及任何运行时需求封装在容器中来实现的。容器充当开发与运维职责之间的边界，如下图所示：

图 2.6 – 显示容器驱动拓扑结构的图示

在良好的工程文化下，这种拓扑结构运行得很好，但如果开发人员开始忽视或没有妥善考虑运营方面的问题，那么这种拓扑结构可能会退化为典型的我们和他们的局面，就像 SRE 拓扑结构一样。

就像 SRE 拓扑结构一样，要注意开发与运维的反模式，即运维只是被期望去执行开发人员交给他们的任何任务。

转型反模式

在 转型拓扑 中，我们探讨了有助于 DevOps 转型的模型，并了解了它们旨在实现的目标。然而，在这里，我们关注的是反模式：这些是可能适得其反、阻碍 DevOps 转型进展的工作方式。

每个反模式都是具体的，我相信你们中的大多数人在职业生涯中至少遇到过以下一种：

• 开发与运维孤岛。

• DevOps 团队孤岛。

• 开发不需要运维。

• DevOps 作为工具团队。

• 过誉的系统管理员。

• 运维嵌入开发。

让我们在接下来的章节中详细分析每一种情况。

开发与运维孤岛

这是我知道每个人都经历过的反模式。这是典型的 把它扔过墙（或插入你可能用的任何其他说法）。在许多方面，这个反模式（如下面的图示所示）引发了很多问题：

图 2.7 – 展示开发与运维孤岛反模式的图示

从开发者的角度来看，功能可以标记为完成，当他们的工作完成时，他们可以为其申报故事点，但该功能可能还没有投入生产，甚至可能在生产环境中无法正常工作。

可操作性也会受到影响，因为开发人员无法获得足够的背景信息来理解运维中的功能，而运维团队则没有足够的时间或意愿与开发人员合作，在上线前修复问题。

大多数人都知道这不是我们希望的工作方式，尽管我们知道这种反模式很糟糕，知道问题出在哪里，但我认为有些拓扑更糟。

DevOps 团队孤岛

我能想到的唯一一个可以接受的情况是，当一个独立的 DevOps 团队在孤岛中运作时，那就是这个团队的存在是暂时性的。这可能与我们在上一节中讨论的倡导型拓扑相契合，即该团队有明确的任务，通过其努力将各团队紧密联系在一起，改善团队之间的协作和沟通，如下图所示：

图 2.8 – 展示 DevOps 团队孤岛反模式的图示

这个反模式出现在管理层或高层决定 他们需要做 DevOps 并启动一个 DevOps 团队 时。这个团队很可能由 DevOps 工程师 组成；问题在于，这个团队很快就会变成一个独立的孤岛。它会阻碍开发与运维的紧密合作，工具和技能将成为内部争斗的主题，每个人都会捍卫自己的立场。

开发不需要运维。

当你把开发人员及其管理者表现出的傲慢与天真混合在一起，尤其是在启动新项目时，通常会做出假设，认为运营已经是过去的事情，尤其是在使用云原生技术时。关于良好的操作技能的重要性和复杂性，常常会被大大低估，正如下面的图表所示：

图 2.9 – 显示“无需操作”反模式的图表

他们相信自己可以在没有运营的情况下进行操作，或者利用空闲时间来覆盖他们所执行的活动。如果团队意识到运营作为一种专长，和软件开发一样重要且有价值，那么他们就能避免许多痛苦和基本的操作错误。

DevOps 作为工具团队

尽管该团队的成果可能有益，但其影响是非常有限的。你可以从改进的工具链中受益，但根本问题在于缺乏早期的操作参与和整个开发生命周期中的协作，正如下图所示：

图 2.10 – 显示 DevOps 作为工具团队反模式的图表

一个 DevOps 团队被设立来处理部署所需的工具，如流水线、配置管理、机密管理等。这种情况发生在你设置一个团队，目的是为了不影响当前开发团队的工作速度（故事交付）。

运营团队继续孤立工作，继续像第一个反模式那样将发布抛给对方。

美化过的系统管理员

DevOps 工程的问题已经被讨论了很久。许多人认为它根本不是一个概念；但我认为它是的，而且已经被许多组织广泛采用。不过，理解基础设施工程师和 DevOps 工程师之间的区别是非常重要的。我曾就这个话题写过一篇博客文章：blog.m12d.com/hiring-the-ideal-devops-candidate。这种反模式在下图中得到了说明：

图 2.11 – 显示美化过的系统管理员反模式的图表

这种反模式在工程成熟度较低的组织中非常典型。虽然组织强烈渴望改进实践并减少开销，但他们往往忽视了 IT 是推动业务发展的核心因素。

在 DevOps 的行业成功并不明显；遗憾的是，这意味着一些组织仅仅因为他们的竞争对手在做DevOps，他们也想要做 DevOps。这些组织没有反思当前团队结构和团队间关系中的空白，而是决定为他们的运营团队招聘DevOps 工程师。

所有这些所能达到的，仅仅是对以前的基础设施工程师角色或系统管理员角色的重新命名。除了职位名称通常要求更高的薪资外，并没有发生任何文化或组织变革。

重要提示

是人际沟通和软技能使 DevOps 蓬勃发展，而非技术技能。

随着人们纷纷追随潮流，寻找具备工具、自动化和云技能的候选人，这种反模式越来越普遍。

嵌入开发中的操作

当一个组织——无论出于何种原因——不想维持独立的运维团队时，开发团队就承担了基础设施的责任。当这种情况发生在产品驱动型环境中时，运营责任项目往往受到资源限制，并且常常被降级优先级，导致次优的处理方式，如下图所示：

图 2.12 – 展示开发中嵌入操作反模式的图示

与我们讨论过的许多反模式一样，这个也显示了对有效操作技能重要性的缺乏认知。操作的价值大大降低，因为它被视为开发人员的一个烦恼。

避免失败的转型项目

现实是，项目会失败。DevOps 转型也不例外，和所有项目一样，你应该为此做好准备，并在可能的情况下从他人的错误中学习，采取控制措施，以便不仅从这些错误中学习，还能防止它们再次发生。

以下是 DevOps 转型项目未按计划进行并且常常被放弃的五大原因：

• 将 DevOps 举措植根于客户价值中

• 组织变革管理不善

• 未能进行协作

• 未能采用迭代方法

• 在 DevOps 举措中对期望管理不善

让我们更好地理解这些原因。

将 DevOps 举措植根于客户价值中

各行各业的许多公司都受到业务方面的建议，认为他们需要加速寻找新机会和应对威胁。你确实有这种迫切的需求，但是我们必须确保加速的需求是基于消费者的价值。仅仅需要变得更快是不够的，我们需要更快速地交付价值，或者也许根本不是速度的问题，而是需要创新。

在尝试解决业务问题时，如果出现混乱，DevOps 将帮助企业更快地进行实验，找到正确的答案。

仅仅因为 DevOps 的名义而决定推行 DevOps 的领导者面临失败的风险，因为员工与DevOps这个词并没有建立关联。相反，你需要将这些努力所带来的益处与员工和公司联系起来。这意味着要了解谁是消费者，他们认为重要的是什么，以及如何满足这些需求。

组织变革管理

我看到的一个主要问题，不幸的是，这个问题不断重复出现，那就是忽视组织中的变革。

当你试图一次性融入重大变革而没有足够的学习时间时，这会导致低成功率的改进。领导者应通过认识到并表达消费者的重要性来发起组织变革。DevOps 及其所需的改进不是可选的，员工必须理解这一点，并且明白为什么需要变革。

我们还需要专注于消费者满意度，因为客户与价值相关，而不是与DevOps这个词相关。我们需要进行迭代，确保我们有能力学习和发展。

未能协作

有效的 DevOps 项目需要与所有利益相关者合作，以解决出现的挑战。然而，许多 DevOps 项目仅限于单一领域，这限制了它们的有效性。

重要提醒

协作是 DevOps 的基石；如果不能促进团队之间的强大协作，将导致工作方式几乎没有变化，甚至可能使部门之间的孤岛问题更加严重。

组织也常常犯一个错误，那就是根据员工的技术能力而非他们的合作意愿来招聘。当我们组建一个 DevOps 团队时，我们希望团队成员能够相互协作——他们喜欢团队合作。他们聪明、有动力、技术熟练，能够保持自己和他人的责任感，并且享受学习，因为 DevOps 绝不是一成不变的。

我们仍然可以在技术技能上培训优秀人才，但要让态度差、动力不足的人改善是非常困难的。

未能采用迭代方法

在一个阶段内推出 DevOps，周五进行培训，周一开始执行这一过程，会导致更高的失败率，特别是对于大型组织来说。渐进的迭代方法使公司能够专注于质量改进，并通过给你学习的机会、纠正方向、改进每次尝试并向前迈进，去避免更快方法的风险。

我们需要创建一个学习居于前列和中间的环境，迭代将帮助我们做到这一点。

先行者战略是较好的方法之一。先行者是指通过反复操作和学习，企业能够在竞争中获得优势的单一价值流。先行者应该是政治上友好的，以便利益相关者愿意给予 DevOps 一个公平的尝试，理解错误是不可避免的，并且能够从中学习，通过创造适当的价值来建立信誉并增加支持，同时向公司呈现一个可接受的风险水平。

我们的目标不是将整个工具链和从开发到输出的端到端、全方位、一体化解决方案结合起来。我们的目标是改善工作流程，并随着时间的推移不断改进。

DevOps 项目的期望管理

利益相关者对 DevOps 的关注，往往会预期错误的结果，这其实是很正常的。例如，许多人期望工作流程能最小化成本，而它其实应该是一个价值导向的过程。另一个错误的期望是，DevOps 只是关于那些可以轻松应用的资源，而实际上它是一项涉及组织变革的艰巨任务。

重要提示

你能做的最重要的事情之一，就是设定合适的期望。成功转型为 DevOps 通常比你想象的要花费更多时间。

到头来，所有的一切都归结于确保你所交付的符合标准。这也是我为什么要提醒大家，对于自己承诺的事情要保持警觉的原因。无论他们是使用咨询机构的数字，还是市场调查中的数字等等，你无法准确知道这些数字会带给你什么样的具体结果。但请意识到你的期望。

解码失败的 DevOps 转型

在我们解开 DevOps 失败背后的原因之前，关键的部分是要理解 DevOps 的定义。这是我们在 第一章《引入 DevOps 和敏捷》中讨论过的内容，但让我们再总结一次，内容如下：

• DevOps 不仅仅是团队协作。

• DevOps 不仅仅是一个工具链。

• DevOps 不仅仅是一个软件开发模型。

• DevOps 不仅仅是敏捷性和质量。

• DevOps 不仅仅是开发和运维之间的一座桥梁。

可以说，关于 DevOps 的内容如此繁杂，导致了混乱，这也在实施过程中给组织带来了问题。一些拥有最好工具的大型组织在实施 DevOps 时也遇到困难，因为他们没有掌握基础。

文化对成功有着巨大的影响。

如果你回想一下第一章，介绍 DevOps 和敏捷方法，我曾经强调过，在做任何事情之前，首先要注重培养文化。文化是加强组织结构的传统、价值观和信念。DevOps 不仅仅是工具的集合；你需要在组织中建立一种 DevOps 文化，才能取得成效。

仅仅依靠工具无法奏效，那么如何建立正确的文化呢？

这实际上是对前面一点的延续。组织往往追求工具以实现目标，而不是文化的变革。仅仅这一点就是 DevOps 失败的最大原因之一。

事实是，文化是复杂且困难的。我们将在后续章节中对这一点进行更详细的讨论。

为你的组织定义 DevOps

在这个数字化时代，任何组织都是一个以技术为驱动的组织，无论其领域如何。从数字化转型到持续数字化之旅的过程，需要灵活性、敏捷性和一致性，这三者是最重要的方面。

DevOps 已经成为那些关注软件分发的公司，或者那些为了一致性和卓越性向客户发布升级或新功能的公司必不可少的一部分。

毫无疑问，DevOps 会使软件开发变得更加容易，但每个公司都有不同的需求。

自动化和速度可能不是你想的那样

Knight Capital，一家实时股票交易公司，使用自动化让交易对客户更快速、更简便。在为其应用程序编写新代码时，新的代码错误地与一个旧的、未删除但已停用的功能同名。

结果，Knight 的应用程序在几分钟内就进行了数十亿美元的购买，公司因此被罚款640 百万美元（USD），并因此破产。

经常，组织会误解自动化。DevOps 通过持续集成/持续交付（CI/CD）原则，自动化软件开发过程。市面上有大量的工具可用于源代码管理、测试、维护和存储。

重要提示

自动化是一个极其强大的组成部分，但你绝不应忘记机器与人类结合的力量来提高准确性。

DevOps 意味着赋能团队中的每个人

人员是 DevOps 失败的一个关键原因。不能只关注增长和运营团队。

DevOps 需要团队中所有认为团队合作是关键职能的成员的参与。为了使 DevOps 有效，你需要找到合适的人，给他们正确的技能，并给予他们时间去体验 DevOps 文化。

一位来自流行网站的软件工程师正在将数据库列重新组织到与数据库相关的工具中，以加深自己对数据库的理解。与此同时，他们没有意识到自己也在修改实际数据库中的列顺序，这导致许多用户无法访问服务器。

总结

这标志着第二章的结束。在这一章中，我们探讨了 DevOps 带给组织的关键业务收益，并讨论了可以帮助团队取得最大成功的拓扑结构。反过来，我们也了解了反模式，即在 DevOps 转型过程中需要避免的团队模式。最后，我们讨论了如何避免 DevOps 转型项目失败，并举了一个 DevOps 失败的例子。

在下一章中，我们将讨论如何在组织内衡量成功，以及设定适当目标的重要性。

问题

现在让我们回顾一下本章内容，并验证我们所学到的知识。看看你是否能回答以下问题：

1. 以下哪项不是 DevOps 的关键业务收益？

   a) CX

   b) 生产力提升

   c) 以更少的资源做更多的事

   d) 更高的客户满意度

2. 哪种转型拓扑被视为黄金标准？

   a) 共享运维

   b) DevOps 作为服务

   c) 容器驱动

   d) 开发与运维协作

3. 以下哪项是导致 DevOps 转型失败的原因？

   a) 未能协作

   b) 采用迭代方法

   c) 成本节约

   d) 更好的员工留存

第三章：测量 DevOps 成功的方法

您必须能够指出显示组织内 DevOps 成功的指标和测量方法。选择正确的指标对展示您的进展至关重要，确保团队与愿景保持一致并赋予人们权力。本章将探讨在 DevOps 中使用的各种指标以及如何衡量成功。

在本章中，我们将讨论以下主要主题：

• 用于衡量成功的常见指标

• 为您的团队设计指标

• 在组织层面创建汇总数据

用于衡量成功的常见指标

首先，了解为何要衡量您的绩效很重要。我与许多各类企业的领导人交流，一个令人担忧的趋势是，他们都认为衡量成功是一种可以用来帮助绩效管理的工具。

现实情况是，绩效追踪是改进的工具。持续改进（CI）是 DevOps 的关键支柱，因此，如果您不知道自己的表现如何，如何进行改进呢？改进应该是用于 DevOps 的指标的主要目标，这些指标可以推动实际结果，并突显增长领域。

在查看可以使用的度量标准之前，我喜欢将它们分为三个类别。随后您将在本章后面看到，根据您管理的团队类型，您可以从每个类别中选择适当的度量标准来评估您的表现，并生成有用的反馈方法。您从每个类别选择的度量标准数量取决于您的目标和团队的风格。请参考以下图表：

图 3.1 – 显示速度、质量和稳定性关系的维恩图

上述图表背后的理念是展示，在理想情况下，您可以从三个类别中平衡地选择度量标准，但可能出现某一类别占比更多的情况。在所有情况下，您会注意到稳定性始终存在。

在此模型中存在以下可能性：

• 速度 + 稳定性

• 质量 + 稳定性

• 速度 + 质量 + 稳定性

稳定性至关重要，因为无论我们在组织内做什么变更，稳定性都应该是我们所做一切的核心，并且在任何情况下都不应该影响这一点。

首先，让我们看看您可能与速度相关的指标。在 DevOps 中，当我们谈论速度时，我们指的是同时具备速度和方向性。

常见的速度指标

在 DevOps 中，速度非常重要，因为我们正在尝试打破组织内的隔离，并改善协作和沟通。具有考虑速度的指标在突显改进领域时非常有用。有了这个想法，让我们看看一些常见的速度指标，如下所示：

• 部署持续时间

• 部署频率

• 变更量

• 测试自动化覆盖率

• 交付时间

• 周期时间

• 部署失败率

• 环境准备时间

从高层次来看这些指标后，我们现在将更加详细地了解它们，以理解每个指标的含义。

部署持续时间

部署持续时间是执行持续部署（CD）流水线所需的时间。如果你在生成构建并同时运行部署，而不仅仅是使用最新的构建产物，那么需要记录 CI 和 CD 流水线的时间，但要确保你能够了解每条流水线执行所需的时间。大多数工具都可以让你查看每条流水线的开始和结束时间，以及执行的步骤。

部署频率

测量部署频率可以帮助你了解你部署了多少次。在成熟的组织中，目标是一天进行多次部署。是否达成这一目标取决于多个因素。

重要说明

随着部署次数的增加，绘制进度图可以展示你在 DevOps 转型中的实际进展。

变更量

在 DevOps 中，通常会存在一个误解，即你不遵循正常的变更管理程序。实际上，情况正好相反——透明性非常重要，而没有比变更管理更适合服务管理中的透明性工具。你可以测量每个迭代周期中的变更次数，甚至是每月的变更次数，以了解你发布了多少次版本。

测试自动化覆盖率

测试自动化也是 DevOps 中自动化的一项关键部分。谈到测量测试自动化的覆盖率时，我们指的是应用程序或代码库中被自动化测试覆盖的部分。

交付时间

在 DevOps 中，如果你希望快速交付功能，那么交付时间是一个重要的度量指标。交付时间是指从将某个任务加入待办事项到该任务交付发布之间的时间。通过这个指标，你可以测量从待办事项到生产环境平均需要多长时间。

周期时间

和交付时间非常相似的是周期时间。这个指标的细微差别在于，周期时间不是从某项任务加入待办事项到该任务交付，而是从开始处理该项任务到完成或交付这项任务的时间。

部署失败率

识别部署失败率有助于团队确定代码和测试的质量，从其他阶段迁移到生产阶段。这是代码和流水线成熟度的领先指标。部署失败显然是你需要了解的事项，监控有助于发现这个问题，但记录你的部署失败率百分比也是很重要的。这可以让你了解你的部署失败的频率。成熟的组织会寻找一个低于 5%的部署失败率，尤其是在大量部署的情况下。

环境准备时间

当使用基础设施即代码（IaC）来部署环境时，就像在衡量部署持续时间时一样，环境配置时间让你了解部署环境所需的时间。在拥有大量微服务的环境中，这是一个很好的指标，因为随着你部署更多的微服务，你将能够看到配置时间如何希望减少。

重要提示

随着你的组织在成熟度上不断进步，回顾你从何处出发非常有用。从一开始就追踪这个指标，以便你能够看到你的进展。

现在，让我们来看看与质量相关的一些指标。

常见质量指标

正如我们之前讨论的，衡量稳定性很重要；其次是质量。你可以拥有很高的开发速度，意味着你在快速工作，但由于此速度，质量可能会受到影响。这并不是你想要的情况，因为低质量会逐渐侵蚀对你所做工作的信任，以及你如何进行工作的信任。以下是你可以在组织中使用的一些常见质量指标：

• 缺陷密度

• 缺陷老化

• 代码质量

• 单元测试覆盖率

• 代码漏洞

• 标准违规

• 缺陷重新引入率

现在我们了解了可以使用的质量指标，让我们更详细地再看一遍，了解它们的含义。

缺陷密度

你可以通过多种方式来衡量缺陷密度。最常见的方式是计算每 1,000 行代码的缺陷数。使用这个指标有助于冲刺规划。随着时间的推移，你可以使用这个指标来估算每个冲刺中可能出现的缺陷数量。

随着集成开发环境（IDEs）和自动化工具的采用，识别代码行可能变得困难，但它仍然是一个重要的指标，而且大多数开发工具能够克服这一限制。

重要提示

缺陷密度的计算公式是缺陷数/代码行数（LOC）发布版本。请注意，这只是特定版本的情况，而非整个代码库。

缺陷老化

这是一个有价值的指标，简单来说，它是衡量缺陷从报告到积压列表到当前日期之间的时间，前提是该缺陷仍然未解决。在技术债务方面，追踪此指标非常重要。它让你了解平均而言，缺陷在解决前被保持开放的时间。

代码质量

当我们谈论代码质量时，很容易认为我们是在谈论标准违规的数量。我们将把这个指标作为另一种质量指标来讨论。在这个上下文中，当我们谈论代码质量时，我们指的是整个应用程序的质量。这可以通过整个应用程序的百分比来表示。这个指标的下降部分是违反代码质量的数量，这些标准由您编写代码的语言的许多规则集定义。

单元测试覆盖率

单元测试覆盖率以百分比表示。它覆盖了开发人员编写的单元测试所覆盖的应用程序部分。在测试驱动部署（TDD）环境中，测试在功能代码之前编写，组织通常将 80%的覆盖率视为最低要求。

代码漏洞

扫描您的代码以发现已知漏洞是良好安全实践的基本组成部分。因此，了解每个版本中的漏洞数量是一个关键指标。当您编写新功能或修复其他问题时，可能会在应用程序的其他区域引入漏洞。跟踪这个指标对于确保您遵循良好的安全实践至关重要。

标准违规

静态分析工具可以详细查看您的源代码，并突出显示不符合标准的代码区域。这些标准通常是社区驱动的或专业设定的标准。然而，某些工具允许组织设置自己的标准规则。这个指标为您提供有关开发人员如何遵循标准基准开发的相关信息和洞察。

缺陷重新引入率

尽管您可能会这样认为，但这个指标实际上跟踪的是开发人员本地测试的有效性。通过这个指标，我们衡量的是被报告为破坏其他功能并导致其他缺陷被提出的缺陷数量。您有时会看到这个指标被称为缺陷泄漏。

最后，让我们看看常见的稳定性指标。如果您有服务管理背景，您会认识到其中的一些指标。

常见的稳定性指标

稳定性至关重要——就像糟糕的质量可能会破坏内部和客户的信任，糟糕的稳定性也会如此。没有人愿意使用不稳定的产品或平台。监控工具旨在帮助您了解发生了什么以及它如何影响稳定性。以下指标帮助您衡量稳定性：

• 平均修复时间（MTTR）

• 部署停机时间

• 更改失败率

• 每次部署的事件数量

• 未批准的更改

• 热修复数量

• 平台可用性

现在让我们更详细地看一下这些常见的稳定性指标。

平均修复时间（MTTR）

我发现这个指标非常强大，比衡量可用性更有用，尤其是在云环境中，平台的可用性比传统数据中心环境更不容易控制。衡量 MTTR（平均修复时间）是指从系统或产品失败到重新可用的时间。随着时间的推移，这个平均值应当逐步减少。

部署停机时间

这个有趣的指标通过时间查看你的应用或产品在部署过程中不可用的平均时间。你可以将其衡量为一个月或冲刺中的整体可用性的百分比，或衡量特定的时间段。

变更失败率

正如我们之前讨论的那样，利用变更管理、对失败负责，并将变更失败率作为已实施变更的百分比来衡量非常重要。这可能是变更管理团队已经在衡量的内容，但建议为你的 DevOps 团队单独进行具体的衡量。

每次部署的事件数

没有什么比通过跟踪每次部署产生的事件数量更能理解发布对你的用户群体产生的影响了。像 ServiceNow 这样的系统能够将发布与事件关联，因此你可以轻松查看是哪次发布引发了该事件。这些事件可以回溯为 bug。

未经批准的变更

任何优秀的变更管理职能都会追踪平台上未经授权或未经批准的变更。其中一些可能是紧急发布，正在等待文档跟进，但有些可能是真正的变更，代表了学习的机会。

热修复的数量

衡量你部署的次数以及它们发生的速度固然重要，但你发布的 bug 修复或热修复的数量呢？采取措施减少这些数字也是判断一个 DevOps 组织是否成熟的重要标准之一。

平台可用性

这是一个典型的指标，衡量平台的可用时间，表示为百分比。最基本的形式是，百分比越高，平台的可用性就越好。一些组织有信用制度来补偿那些没有达到合同约定的可用性阈值的客户。

这就结束了我们对衡量 DevOps 成功的常见指标的探讨。那么，如何在实际场景中应用这些指标，应该设定哪些基准目标呢？

为你的团队设计指标

现在我们已经理解了 DevOps 中涉及的关键指标，接下来重要的是了解这些指标可以在什么场景中使用。你在组织中可以追踪过多的指标，这样反而会适得其反。

知道使用哪些指标取决于许多不同的参数。然而，我们现在将查看一些示例场景，描述它们的 DevOps 转型目标，并了解哪些指标可以帮助他们识别成功。

场景 1：拥有专门 DevOps 团队的小型组织

对于小型组织而言，它们之间的共同点之一是能够变得更加灵活，打破团队之间的壁垒。较小的团队可以更快速地获得反馈并缩短周期时间。事实上，大多数小型组织整体上壁垒更少，有些甚至没有壁垒。

在这个场景中，假设我们在组织内有一个专门的 DevOps 团队，由六个人组成。该组织只运营一个产品，该产品以软件即服务（SaaS）模式向客户销售。

在这个例子中，互动非常简单。由于组织规模适中，团队之间协作良好，角色和职责也得到了很好的定义。像大多数这种规模的组织一样，随着他们的成长，也出现了一些初期的问题，例如由于执行压力导致的质量下降。

对他们来说，专注于稳定性和质量同样重要，以确保高质量能带来更好的稳定性。接下来我们将查看他们可以使用的四个指标及其原因，如下所示：

• MTTR（平均恢复时间）——了解恢复应用平台所需的时间至关重要。组织需要考虑平台未来的发展方向。这一点尤为重要，因为随着平台的增长和扩展，这些发现可以促成架构上的改进，从而缩短平均恢复时间。

• 平台可用性（> 99%）——提供合同激励措施以保持平台的可用性可能有助于提高稳定性，但需要警惕：这也可能给团队带来不必要的压力，甚至使问题更加严重。进行简单的测量并讨论停机的原因及如何从长远解决这个问题，要比施加压力更具生产力。

• 单元测试覆盖率（> 80%）——确保良好的测试覆盖率非常重要。由于该组织存在较高的缺陷率，确保良好的单元测试覆盖率将确保进行更好的测试，并确保代码按预期运行。

• 缺陷密度（< 1/1,000 行）——该组织的发布曾经出现过问题。了解缺陷的密度将帮助他们做出更好的规划，并了解在开发过程中哪些问题会转化为缺陷。

现在我们来看一个不同的场景，适用于一个拥有宣传团队的中型组织。

场景 2：拥有宣传团队的中型组织

对于这种情况，我们的组织有独立的运营和开发团队，他们在倡导团队的帮助下，尝试更好地协作。其目标是通过使用不同的技术促进他们之间适当水平的协作和沟通，同时继续进行日常工作。

如前一章所述，倡导团队在冲刺团队中并不负责具体的交付任务，而是推动 DevOps 最佳实践，帮助团队实现设定的目标。

对于一个中等规模的团队来说，稳定性和质量在其成长过程中非常重要，但了解工作速度（velocity）同样重要。团队需要对其长期的表现有一个广泛的视角，以便随着团队的成熟，做出相应的调整。我们来看一下该团队可以用来跟踪表现的指标，如下所示：

• 提前期——跟踪提前期能够帮助团队了解时间的使用情况，从积压项的分配到交付完成。这有助于团队在未来做出更好的规划，提供合适的估算，并帮助识别可以简化流程的领域。

• 周期时间——同样，了解从开始工作到交付的平均时间，也为团队提供了帮助他们改进估算和计划会议的指标，随着时间的推移提升客户满意度。

• 单元测试覆盖率——作为一个新成立的 DevOps 团队，拥有高质量的代码非常重要，但了解当前的情况更为关键。这有助于突出因缺乏优质单元测试覆盖率而继承的技术债务。

• 代码质量——与单元测试覆盖率类似，这一指标将帮助团队了解开发人员的技能差距，并通过针对问题领域来改进。

• MTTR——记住：稳定性非常重要，了解恢复服务所需的时间也是如此。这些信息会反馈到团队的改进周期中，帮助他们再次改进。

• 部署停机时间——最后，任何新成立的 DevOps 团队都需要了解他们在发布期间工作的影响。衡量发布停机时间可以帮助你在未来改进自动化过程，甚至将手动部署转为自动化部署。

现在我们来看一个大型组织的场景，组织中有多个 DevOps 团队。

场景 3：拥有多个 DevOps 团队的大型组织

当你拥有一个包含多个不同规模的 DevOps 团队的大型组织时，确保每个团队专注于自己的优先事项非常重要，尤其是他们的目标是什么。然而，业务的整体目标必须始终牢记在心，指标可以帮助确保这一目标得到跟踪。

对于这个场景，我们的大型组织正在寻求提高整体开发和发布的速度。当然，正如我们在本章之前讨论的那样，这不能以牺牲稳定性为代价。

从 DevOps 角度来看，他们的挑战是改变已持续多年的传统工作方式，而且存在一些繁文缛节，使得流程变更变得困难且缓慢。

现在让我们看看他们可以使用的指标，以确保在保持稳定性的同时，实现提高速度的更广泛目标，具体如下：

• 交付时间——了解从积压工作中处理事务的速度非常重要，特别是在团队需要快速调整并改善结果的环境中。这可以帮助你了解在确保流程精简方面需要做什么。

• 部署频率——如果目标是提高发布节奏，那么这个指标是必不可少的。你可以了解你部署的频率，并与其他指标结合使用。确保这不仅仅是一个数字，而是多个高质量的发布。

• 变更失败率——错误在快速变化的环境中难以避免。我们可以通过这个指标帮助所有团队了解他们的发布是否高质量，不仅仅是功能层面，而是通过遵循现有的变更管理政策来确保他们在改变部署方式时的质量。

• 热修复次数——发布热修复是可以的；它们是开发生命周期的重要组成部分。追踪热修复的次数可以帮助团队理解稳定性，同时也可以平行评估质量。这是一个在快速变化环境中寻找快速变更时非常有用的指标，但正如之前所讨论的，错误是难以避免的。

  重要提示

  在这些类型的组织中，团队可能会各自为战。要将它们紧密结合在整体目标上是困难的，但找到共同的指标可以帮助解释这一点。团队可能有相同的指标，但基于产品或能力的不同，领先和滞后指标可能会有所不同。

现在让我们看一下另一个小型组织场景，这次是与外包的 DevOps 团队合作的场景。

场景 4：与外包 DevOps 团队合作的小型组织

对于一些希望获得 DevOps 带来的好处的小型组织，外包可以用来让一个专业的第三方团队与组织合作，达成多个目标。

这可能包括交付的帮助、敏捷方法的执行，或是环境的支持和将自动化作为整体解决方案的一部分。第三方可以以多种方式使用，具体取决于组织的规模和需求，这将改变第三方参与的范围。

对于我们的小型组织来说，重点是提供更高水平的自动化，特别是在测试方面。这将帮助他们推进 DevOps 的进展。

现在我们来看一下我们可以为这个团队使用的指标，具体如下：

• 测试自动化覆盖率——由于团队的规模，他们将测试自动化外包了。使用这个指标来查看提供的自动化覆盖率，并随着时间的推移逐步增加这个数值。

• 部署失败率——部署失败率有很多关注点，但这个团队决定关注测试关卡的失败。使用这个指标将帮助团队了解失败的原因、频率，并通过探索找出为何发生失败。

• 部署停机时间——与前面的指标类似，跟踪部署中的停机时间可以帮助你与第三方进行互动。这能帮助你们共同改进组织内的 CI 和 CD 流水线，在你们不断发展时也能提升效率。

• 平台可用性——了解第三方如何在你的环境中运行至关重要。理解平台的可用性是必需的，当他们犯错导致故障时，你需要考虑如何追究责任。这个问题需要妥善处理，避免强硬语气，应该有合作改善而不是惩罚的态度。

在所有四个场景中，你都可以使用不同的指标来衡量自己；然而，这并不意味着某些指标比其他指标差。关键在于你想要衡量的是什么，你衡量的是你希望整体改善的内容。

现在我们已经看过了你可以在不同场景中使用的各种指标，那么当你有多个团队在实践时，比如在场景 3中，情况会怎样呢？你如何确保报告的层次适当？让我们在接下来的章节中看看答案。

在组织层面创建汇总

无论你的组织是否在实践 DevOps，清晰的沟通都是成功的关键之一。在沟通你的关键绩效指标（KPIs）时，这一点同样重要。

你必须确保向组织内的领导展示的数据清晰、简洁，并能准确反映组织的表现。

在 DevOps 中，特别是当你需要传达全组织的进展时，你首先需要解释这些指标对更广泛业务的意义。指标的含义和展示内容并不总是显而易见的。

重要说明

尽量使用清晰的措辞向高层领导展示，即使这意味着需要改变对指标的解释。将其与他们理解的内容关联会更容易，而不是在高层会议中面对关于如何衡量、为何衡量等问题。

DevOps 中的另一个关键因素，特别是在衡量速度时，是要理解并非所有团队都是平等的。即使从内部来看，当团队交付的内容看似非常相似时，团队的工作方式和运作方式意味着这两个团队的速度不太可能成为可比的度量标准。

因此，我永远不建议通过使用诸如故事点等简单的度量标准来比较团队。团队可以内部使用这个指标来查看他们在规划分配给他们的工作方面的有效性，并且在冲刺期间，利用前一个冲刺的输出，看看他们的表现如何以及在哪些方面能在规划上做得更好。

提示

如果你使用故事点来衡量已完成用户故事的速度，请务必不要将此指标公开显示在高层管理的仪表板上。

多个团队协作时的报告

如果你的组织有多个团队在一个产品上工作，并且每个团队负责产品的不同部分，那么创建汇总报告就非常简单。就像任何项目一样，你会报告整体进展与任何计划的对比。在这种情况下也是如此。

每个团队可能在不同的业务分析师的指导下，处理各自的功能和需求，但他们都将为同一个共同的目标而工作，并朝着这个目标协调一致。因此，你需要理解最终目标的样子，然后你可以创建衡量该目标的指标。

这种风格可能被称为高层管理得分卡，或者有时被称为业务得分卡。它列出了显示你是否在成功之路上的关键绩效指标，或者是否有障碍阻挡你的前进。

多个团队协作多个产品时的报告

当你有多个团队在多个产品上工作时，你可以采用类似之前提到的策略。将每个产品团队视为一个团队，并创建反映该团队在该产品上完成的工作的报告。

记住之前的讨论：没有两个团队是完全相同的，无论他们是同一产品组还是不同产品组。即使他们在不同的产品上工作，也要小心不要跨不同的产品比较团队，即使他们在不同的产品中工作着相同的交付物。

根据你的组织情况，多个产品之间可能完全不相关，这种情况下，创建将业绩汇总到更高层次的报告没有任何意义。

例如，如果你的组织拥有多个相关的产品，并且它们通过某个更高层的营销组合在一起（也许你的组织有一个实际由多个产品组成的总产品），那么尽可能地将你的报告对齐到这个最高层级。

它是跨业务领域都能理解的顶层指标，因此，当报告我们在本章前面讨论的速度、质量或稳定性指标时，确保它们与能够实际理解的最高层级相关联。

制定 S.M.A.R.T 目标

为你的产品制定目标，或从高层领导那里获取目标，并将其分解成更具操作性的任务，可能是一项困难的工作。

在你的部门中，你可能需要将一个更高层次的目标分解为不同团队之间更易管理的目标。这时与 DevOps 的协作和沟通就显得尤为重要。当一个更大的目标被拆分为多个小团队的目标时，相互协作和交流对确保完成根本任务至关重要。

在商业领域，一个常见的设定可衡量和可实现目标的工具是使用S.M.A.R.T方法。如果你之前没听说过，这就是它的含义：

• 具体

• 可衡量

• 可实现

• 现实可行

• 及时

S.M.A.R.T.目标有不同的版本，但这些是我偏好的定义。它真正意味着，要设定一个合适的目标，必须回答以下五个问题：

• 你到底想做什么？

• 你怎么知道自己已经达成了目标？

• 这个目标在你的能力范围内吗？

• 你认为自己能实现这个目标吗？

• 你什么时候希望完成这个目标？

我之前多次使用过这个方法，你可以在Mind Tools（www.mindtools.com/pages/article/smart-goals.htm）找到更多关于这个方法的详细信息。

一个简单的例子是，你想学习如何使用某个特定工具——例如：我想了解如何在 Azure DevOps 中创建管道。那么我们如何将这个目标变成 S.M.A.R.T.呢？下面是做法：

• 具体—我想学习如何在 Azure DevOps 中使用YAML Ain't Markup Language（YAML）创建管道。

• 可衡量—能够在没有我们主题专家（SMEs）帮助的情况下，创建用于部署应用程序 X的有效管道。

• 可实现—我需要学习如何构建基本的管道，然后理解我们的流程，以便我可以学习如何将合适的项目添加到管道中，完成构建。

• 现实可行—通过观看在线视频、与我们的专家合作以及参加在线课程，我能够实现这个目标。

• 及时—我将在 6 个月内实现这个目标。

使用这里展示的模型，你可以清楚地知道自己要实现什么目标，如何实现这些目标，需要什么资源，最后——你将在何时实现这些目标。

你可能在表格中有多行描述不同的目标，并且可以使用步骤来描述实现目标的方法。关键是将其写下来。

总结

在本章中，我们查看了衡量 DevOps 成功的最常见指标，并探讨了确保定义成功标准的重要性。我们通过不同团队的场景，突出了一些可以用来跟踪其成功的指标。最后，我们探讨了如何确保从组织层面进行跟踪，而不是过于关注单个团队。

DevOps 中最大的挑战之一是衡量成功。运用你在本章中学到的技能，你可以为你的组织实施有意义的目标和指标来衡量成功。

在下一章中，我们将探讨如何在 DevOps 中建立文化，以及如何打破组织中的隔阂以实现最大效率。

第四章：发展和建立成功的 DevOps 文化

文化是 DevOps 的关键，本节将探讨如何建立、培养和发展成功的文化。

本书的这一部分包括以下章节：

• 第四章，构建 DevOps 文化并打破孤岛

• 第五章，避免 DevOps 中的文化反模式

第五章：构建 DevOps 文化并打破部门墙

在本章中，我们将探讨 DevOps 中文化的含义，如何在组织内构建成功的 DevOps 文化，以及为什么文化是 DevOps 中一个重要的方面。我们还将看看 DevOps 文化的特征，如何在组织内维持强大的文化，以及如何打破现有的部门墙。

在本章中，我们将涵盖以下主题：

• 什么是 DevOps 文化？

• 为什么文化很重要？

• 维持强大的文化

• 打破组织中的部门墙

什么是 DevOps 文化？

在之前的章节中，我们稍微谈到了文化。现在是时候深入讨论了。文化有许多含义，但在 DevOps 中，我们谈论的文化实际上是开发与运维团队之间的共享理解，以及他们对所构建应用程序的共同责任。这大致可以转化为以下几点：

• 提高透明度

• 更好的沟通

• 跨团队合作

尽管有些人认为 DevOps 只是技术的演变，但实际上 DevOps 远不止于技术。DevOps 并不是对工具或平台的技术性演变，它并不会改变你在组织中使用的工具或平台。

DevOps 中的文化也不仅仅是让团队决定他们自己的命运；它是关于团队间的合作。实施这些措施可能让人感到害怕，但我希望带您走过四个可以帮助实践这一点并在组织中建立正确文化的步骤。

我们接下来要讨论的所有内容将帮助我们更好地理解之前提到的关键要点，并开始在您的组织中培养正确的文化。

角色和职责研讨会

为团队定义非常清晰的角色和职责有助于打造强大的文化。这样可以避免人们不清楚自己该做什么，并确保每个人都知道自己在做什么，同时意识到每个人的角色对整体团队的重要性。

将您的团队纳入本次会议；这是一个非常有意义的经验，并且通过大家共同参与角色和职责的制定，形成了团队之间的相互契约。

看看下面的图表。这是一个角色和职责研讨会输出的示例：

图 4.1 – 角色和职责矩阵示例

您可以利用前面的示例，借助团队的帮助，定义组织内的角色，然后完成其他团队成员认为该角色应承担的职责。

重要提示

如果您在远程工作，可以将此内容转化为 Word 文档并共享，以便团队协作编辑。

完成这一步后，与团队一起讨论你们的成果，并达成一致，明确责任分配。你可能会发现自己将某些成员调到其他角色，这没问题，只要确保团队达成一致。

一旦会议结束，确保首先与团队分享成果，确保不再需要任何反馈。所有人完成后，通知其他领导们这就是你团队将要采用的工作方式。

这种高度协作的方式在团队内部建立了牢固的关系，这种关系很难打破，并将为你的成功奠定基础。

协作规则

听起来可能像是军事术语，但这是一个严肃的练习，未来可能证明它非常有价值。将这次练习的产出视为与你团队的社会契约，应该每季度更新一次。

定义你的协作规则就是定义你们如何共同工作。如果你在一个跨职能团队中，那么在早期定义这些规则可以防止团队内部的紧张情绪积累。你也可以称之为你团队的工作协议。

从向团队提问一些简单的问题开始：

• 作为一个团队，对我们来说，什么是重要的？

• 我们如何避免过去的错误？

• 表现良好的团队都做了什么，我们可以借鉴？

首先，请团队成员私下写下他们的答案。这一反思时刻将帮助为会议定下基调。接下来，要求团队写下一个让团队合作成功的声明。

当你完成后，将所有答案汇总在一起，并将相似的声明合并。如果你有一个小团队（少于五人），可以让他们写下两条声明。

然后，你们作为团队对这些想法进行投票。投票的目的是为了协作，投票结果是书面协议中的承诺。如果一个想法被投反对票，只需询问将其转为支持票需要什么条件，并看看团队是否同意。

重要提示

定期与团队跟进你的协议；将它放在团队经常访问的地方，以便他们时刻提醒自己你们共同达成的协议。

关键是要促进与团队的开放讨论，使他们思考如何成功地合作。保持开放、诚实，最重要的是，保持尊重。

回顾会议

进行回顾会议是敏捷实践中的一部分，你可能已经习惯了这种方式。这种技术侧重于在每个迭代结束后召集团队，详细讨论上一个迭代的内容。与Scrum Master一起，团队将回顾上一个迭代的成果以及那些未能按计划完成的事情，看看哪些可以改进。

回顾会议的氛围应当促进持续的改进与学习。它被视为一个安全的空间，可以讨论什么是有效的，什么可能无效，以及什么可以改变。通常，每次冲刺后都会举行回顾会议。

对于大型组织，你可以由每个团队的领导每月主持一次回顾会议，讨论 DevOps 的采用情况。就像冲刺回顾一样，与领导讨论哪些有效，哪些无效，及他们希望如何改变你们的 DevOps 转型。

进行回顾的技巧很简单。通过快速搜索，你可以找到许多不同的回顾方式。你应当时不时地改变回顾的方式，以保持团队的参与感。我发现作为领导者进行回顾非常有价值，而且准备工作几乎不需要时间。你应该预留大约 1 小时来进行回顾会议。你甚至可以很轻松地在线上进行回顾。

如果你在办公室完成回顾会议，请确保你的会议空间准备好白板和一些马克笔，另外还要准备便签和一个能清晰显示的计时器。

如果你在进行远程回顾会议，你可以使用软件让大家将虚拟便签放到相应的标题下。对于面对面的会议，你可以设置四个不同的区域，供大家放置便签。

现在，要进行一次非常简单的回顾，你只需根据适当的时间安排做以下几点：

• 准备（15 分钟）：无论是数字化方式还是纸质方式，设置四个标题：做得好的地方，做得不好的地方，我们可以做得更好的地方？，最后还有一个是行动项。

• 基本规则（5 分钟）：花几分钟时间解释并设定基本规则。每次回顾最关键的是记住评论不是针对个人的；每个评论都是有效的，因此要以开放的心态倾听。设定你将讨论的时间段（上一个冲刺、上个月、上个季度等），并专注于改进，而不是指责。

• 什么做得好（15 分钟）：将你对上一时间段内做得好的内容写下来并放到相应的标题下，或者创建一张数字卡片，记录你个人的想法。

• 什么做得不好（15 分钟）：将你对上一时间段内做得不好的内容写下来并放到相应的标题下，或者创建一张数字卡片，记录你个人的想法。

• 我们能做得更好什么？（15 分钟）：将你对上一时间段内可以做得更好的内容写下来并放到相应的标题下，或者创建一张数字卡片，记录你个人的想法。

• 行动（10 分钟）：最后，记录下回顾中提出的任何行动项。如果你是远程工作，确保拍摄成果照片或截屏。讨论提出的想法并分配跟进责任。

  重要提示

  如果你面临大量的行动项，可以使用投票系统来帮助团队优先处理紧急事项。常见的投票系统示例包括 Lean Coffee 和 Scrum poker。

现在我们理解了 DevOps 文化是什么，接下来有必要了解这种文化为何如此重要。

为什么文化很重要？

我总是喜欢把文化描述为 DevOps 的支柱。可以把 DevOps 想象成一棵树，其中有人员、流程和技术作为树枝，但它们都由文化相互连接。

在我多年的 DevOps 工作经验中，服务于不同的组织，所有的工作都让我明白，即使拥有世界上最好的流程、最优秀的工程师以及最好的技术支持，但如果没有最好的文化，并且不去改进这种文化，那么一切努力都将是徒劳的。

在本章早些时候，我们列出了 DevOps 中文化的三个重要方面；我们来回顾一下这些内容：

• 增加透明度

• 更好的沟通

• 团队间的协作

为了理解文化为何重要，我们来更详细地看看这三个方面。通过这种方式，我们可以逐步构建出文化为何如此重要的全貌。

增加透明度

透明度在许多商业领域是基础，但随着层级的降低，透明度可能会稀释，这并非有意为之，而是因为团队的工作方式和历史积淀所致。这通常不是某个具体个人的过错，而是组织整体文化的漂移。

开发团队通常面临巨大的压力，要在组织内发布软件，这可能导致这些团队绕过运维团队所设定的控制措施。正是这一点根本上导致了团队之间的紧张关系，因为开发人员现在拥有非标准的基础设施，而且这种基础设施的使用方式无法被运维控制。这一切最终导致了我们所说的影子 IT。

你会发现，许多人将公共云服务视为缺乏透明度的原因；然而，这个问题早在公共云讨论之前就已经存在。事实上，正是自助服务时代使得这一问题更加严重，但即便在那之前，这一问题早已存在，无论是自助服务还是公共云的出现。

如果你把开发人员请求虚拟机的过程看作是通过自助门户进行的，运维团队将只部署操作系统的基础设施。此时，他们对该基础设施不再有任何洞察。

关于公共云，你也可以做同样的解释，当开发人员表达对运维工作拖慢其进度的不满时，他们会转向公共云服务提供商，并自己使用这些服务。

然而，这种方法的三个主要缺点是什么？

• 合规性标准的验证

• Infrastructure utilization and efficiency

• Cost control

Almost every organization I have spoken to at the start of their cloud journey has cited cost control as a problem. But what does this mean? Let's now look at some ways to improve transparency.

Verification of compliance with standards

With the delivery of a baseline operating system, or for cloud-native resources the baseline configuration of that resource, applications that are deployed and any database instances deployed on the virtual machines are all items that have standards in most organizations for compliance.

As an operations team, when you are blind to what is deployed on your servers and have limited control, you lose ground in your security posture and end up not knowing whether the applications and development tools are security patched.

The exact same scenario can be said when consumed directly from a cloud provider without the knowledge of the operations team.

Infrastructure utilization and efficiency

If your developers build 10 machines, with limited control, operations have no idea whether those resources are fully utilized, when they are utilized, whether they can be turned off outside of working hours, or whether they apply for a special licensing benefit.

These decisions, or lack of decisions, can have implications for capacity planning and the future ability to scale the platform and build critical services.

Cost control

Finally, developers are unlikely to realize the benefits of a cloud provider if they take that route on their own, the benefits of a scalable platform, and the benefits of overall spending a cloud platform can bring.

Spending outside of the main budget has an overall detrimental effect on the business and its ability to operate without distractions.

Better communication

Some of the things we have just discussed fall quite naturally into better communication as well. Imagine if developers and operations were able to communicate better with each other. From an infrastructure perspective, they could collaborate with operations to work on templates that match their requirements and operations could explain the controls in place for the security of the business.

That mutual understanding then becomes working practice and the developers get the infrastructure builds in a timely manner and operations keep control.

This isn't the only place where better communication helps you build culture though. Communication can be made more efficient in a number of different ways:

• Operations participation in sprint planning

• Developers performing releases

• Operations working in development sprints

• Developers working in operations

These examples may seem trivial, but they can have a real impact on the overall experience of those involved and can make them think about their interactions. Over time, this helps improve communication.

Operations participating in sprint planning

你经常会听到运维团队的经典反馈之一是，开发人员很少考虑到环境因素，且运维方面的挑战、问题和需求没有被充分考虑。

我们在《转型拓扑》一节中讨论的一个模型，在第二章《商业效益、团队拓扑与 DevOps 的陷阱》中提到，强调了将运维与开发更加紧密地结合。在第一章《引入 DevOps 与敏捷方法》中，我们也探讨了敏捷在 DevOps 中的作用。当你开始朝着敏捷工作模式转变，接近我们所探索的转型拓扑时，你会发现运维团队与开发人员的协作会更加密切。

重要提示

当运维团队在规划阶段参与，并在迭代开始前开展工作时，他们将有机会提出开发人员可能未考虑到的、属于其专业领域的问题和顾虑。

及早开始这一过程会带来实际好处。刚开始时，可能会很棘手，对于那些没有以这种方式工作过的人来说，也许会感到不自然，但只要坚持下去，结果会非常显著。

完全改变工作方式会给人带来挑战，而且你会面临一些阻力。

执行发布的开发人员

对于许多组织来说，通常是开发人员将编译好的应用程序发布到生产环境中。尝试让你的开发人员和运维团队合作，专门负责发布工作。

重要提示

我们希望运维和开发之间的对话能够真实和透明。如果两个团队都提前被通知到这一过程的变化，可能会导致事先准备好的声明和假设。将运维团队引入正常的站会，并允许他们实时反馈。

这样做的好处是，开发人员应该会开始理解并欣赏每次发布应用程序时需要完成的工作。

运维在开发迭代中的参与

类似于之前提到的，把这个过程反过来，让你的运维团队在迭代中与开发人员共同工作。不仅如此，他们将更加理解并欣赏开发过程，你还会发现他们在迭代中能为运维相关事项做出贡献。

重要提示

这样做意味着运维问题可以在开发迭代期间和发布前得到解决，而不是在发布后出现问题，导致团队之间的矛盾加剧。

大多数时候，你会发现运维团队无法编写软件，所以将一些通常由你来执行的运维任务纳入迭代中，不仅能提高沟通效果，还能促进协作。

从事运维工作的开发人员

正如之前提到的，颠覆这个想法，并让开发人员与运营人员一起工作。这将使开发人员了解理解运营元素的重要性。

这种工作模式可以增加协作和沟通，并达成共识。现在开发人员了解了故障期间发生的情况，监控如何工作，以及应用程序中的仪器化如何影响操作流程，这将对应用程序的开发产生积极影响。

跨团队协作

当我们说协作时，我们到底是什么意思？在 DevOps 的背景下，它是一起工作和创造。协作对任何企业都是至关重要的，但当您的团队既多样又全球化时，这一点尤为重要。

从技术角度来看，您会发现许多工具可以帮助团队更好地协作。但当我们谈论协作时，我们如何定义它，以及如何改进它？

重要提示

协作工具可以帮助，但它们并非整体解决方案。选择最适合您需求的协作工具。

DevOps 中协作的主要目标是减少存在的操作延迟，以及与地理分布的团队之间的沟通障碍。这是 DevOps 中需要文化性转变的部分，许多人都在谈论这一点。

您的团队需要共享的目标定义以及一种团队一体化的工作方法。确定一组共同的目标，为未来的工作关系奠定基础。经理和领导还应在团队中营造鼓舞人心、诚实、信任和尊重的文化。这使每个人都感觉像是团队的一部分，并创造出更强的联系和您试图实现的信息传递。

一个清晰的路线图同样至关重要，它定义了您成功的路径，并帮助实现您设定的目标。路线图应当清晰明了，避免任何歧义。随着进展，定期的跟进和与团队的讨论也有助于提供清晰度。

最后一点是关于多样性的问题，这是关键。一个紧密结合的团队要求您了解每个人以及他们的工作方式，甚至理解他们的文化和个人情况。在远程团队中，当人们在不同的时区工作，并拥有不同的文化和宗教信仰时，这一点尤为重要。

现在我们详细了解了为何 DevOps 中的文化对我们的组织至关重要。让我们看看如何保持和发展这种文化。

维护强大的文化

现在，你已经花时间在组织中建立了文化，你最不希望看到的就是所有的努力付诸东流。保持已经建立的文化非常重要，这样它才能继续促进你已经实施的良好实践。事实上，DZone 的调查（dzone.com/articles/top-10-barriers-to-devops）发现，14%的人表示文化是 DevOps 采用的障碍。

然而，像大多数事情一样，团队和企业的日常运营可能会带来一些威胁，影响你维持文化的强度。有些事情甚至可能产生负面效果。以下是其中的一些因素：

• 新人和离职者

• 为成功过度施压

• 缺乏创新

• 文化差异

• 缺乏认同感

我们如何避免这些文化障碍呢？让我们逐一看一下这些问题。

新人和离职者

在任何组织中，人们会离开，也会有新人加入。这是任何企业中最常见的现象之一。希望你所创建的文化意味着，当人们离开时，他们是为了更好的机会，而不是因为恶劣的原因离开。

如何处理高效敏捷团队中的新人和离职者，是敏捷领导者必须时刻处理的问题。确保以你希望的方式开始任何新成员的工作非常重要。

这始于确保你招募到合适的人，这说起来容易做起来难。既然你已经与团队保持开放的文化，寻求团队成员对新员工应该带给团队的想法。要做好以合作的方式倾听的准备，但也要准备好自己的想法，以便在必要时进行反驳。

重要提醒

在面试过程中，邀请团队成员参与，验证你对候选人特质的看法，以及他们能够为企业带来的价值。

对于离职者，遵循你已经制定的实践可以确保当团队成员离开时，他们不会对你的工作方式造成重大影响。当然，人们通常会和同事成为好朋友，某人离开可能会对团队产生情感上的影响，超过任何其他因素。

但要小心，这种情感影响可能开始影响生产力和质量。团队合作的时间越长，他们之间的节奏越好，而这种节奏一旦被打破，可能会对团队产生影响。

尽可能尽早替换团队成员，以减少任何影响。新成员往往能够为团队带来新的想法，并为团队注入新的活力。

当你面临重大变动时，可以先进行章节开头的角色和责任演练。在员工离开之前，进行一次回顾总结。如果仔细思考的话，那个人的离开是一个关键时刻，并且可以设定时间限制。可以从更广泛的角度总结什么有效、什么无效以及什么可以改进。

过度追求成功

当你在建立文化方面付出了很多努力并看到积极的结果时，你可能会进入一种心态，过度追求更多的成功。这种情况可能发生在团队中，也可能发生在个人身上。这两者都会对你迄今为止所做的工作产生不利影响，因此需要密切关注。

要警惕这一点的简单原因是，当你开始追求成功时，你可能会回到过去的老路上，采取捷径以获得更多的成功。然而，坚持自己的立场，不要过度承诺你无法完成的工作，继续保持你已经习惯的强劲成果。

重要提示

遵循持续反馈和持续改进的流程，随着进展会带来更多的成功。让这一切自然而然地发生，不要强求。

如果你这样做，你会发现成功会自然而然地降临到你身上，你无需过度逼迫自己或团队去追求更多的成功。

缺乏创新

高绩效团队的一个特征是他们的创新能力。习惯了拥有创新能力的团队将会持续渴望创新。实验和创新的能力对任何企业的成功至关重要。

注意创新步伐的减慢，或者更糟的是，其他团队设置障碍，阻止你的团队进行创新。这应被视为一个警示信号，促使你作为一个团队专注于解决阻碍创新的问题。

尝试不要被此事分心，作为领导者处理这种情况，让你的团队照常运作。但不要与团队互动并告诉他们他们不再能够进行创新。

许多 DevOps 专业人士因为能够快速创新并提出新想法而与他人不同。告诉他们不能做自己擅长的事情，将对整个团队和你所建立的文化造成损害。

文化差异

我们之前多次讨论过远程团队，特别是那些地理上分散的团队。我们之前也谈到了多样性及其所起的重要作用。

文化差异也包括你所合作的团队之间的差异。每个人都有自己对组织内工作方式的理解。正如我们讨论过的，查看反模式时，问题在于它们可能与你作为团队希望做的事情不一致。这正是 DevOps 诞生的原因。

你可以通过对齐目标来应对团队目标中的文化差异。这里的关键是一次又一次地执行这一点，确保团队紧密对齐。当团队目标开始分歧时，他们就会重新以旧方式运作。

缺乏支持

除了缺乏创新，保持文化的最大障碍之一仍然是缺乏支持。你可能会认为，到了这个阶段，你已经做了艰苦的工作，管理层已经支持你了。当然，你是对的，但就像在你自己的团队中一样，管理层会变动，业务优先级会变化，商业环境也可能发生变化。

这是一个常见的情况，你需要确保领导者仍然支持你正在做的事情，为什么要这么做，以及到目前为止你们取得的成果。

重要提示

在获得支持方面，千万不要自满。领导者会变，随着变化，可能会出现新的想法，关于事情应该如何进行。

为了应对这一点，记录下你们作为团队取得的成功，并确保你能够回顾你们在 DevOps 旅程中的过程，以展示这些成功是如何实现的。

如你所见，不仅要建立文化，还要保持它，需要付出努力。请确保参考本节中分享的一些技巧和练习，保持你们团队文化的强大。现在，让我们来看看如何打破组织中的孤岛。

打破组织中的孤岛

在 DevOps 中，文化的形成源自于打破组织内某些团队之间的孤岛。孤岛心态是行为驱动的，可以通过多种技术来解决。孤岛存在于团队独立运作，并且活动交叉或缺乏对他人工作的考虑时。

在商业世界中，孤岛的危险在于信任被摧毁，沟通被切断，且日常工作开始陷入自满。孤岛化的团队无法快速响应变化，或抓住出现的机会。

最糟糕的情况是缺乏透明度，当数据无法在团队之间自由共享时，这会影响你做出基于数据的决策，无论是关于团队还是关于业务。一些我们即将讨论的内容之前已经提到过：

• 为团队协作创造一个共同愿景

• 通过协作工具朝着共同目标努力

• 一起学习，一起工作，一起培训

• 经常沟通

• 评估团队的薪酬

让我们更详细地看一下每一个方面。

为团队协作创造一个共同愿景

我们之前讨论过为你的团队创建共同目标的重要性，以及它们应该共享一个愿景。如果一个团队的愿景与另一个团队完全不同，且他们没有朝着更大的成果前进，那么这样的愿景是适得其反的。

所有团队应当共享、认同并采纳这个共同愿景。当设置与其他团队相冲突的目标时，便会出现孤岛心态，这意味着管理层往往会创造出孤岛。

领导团队必须在将统一的愿景传递给各个团队之前，理解组织的长期目标、部门目标和关键举措。通过这种方式，统一的领导团队能够鼓励信任，创造赋能感，并将管理者从我的部门心态中解放出来，转变为我们的组织心态。

使用协作工具朝着共同目标努力

孤岛心态的最大缺点是人们只从自己的角度看问题。当然，这不总是坏事，但当这种情况发生时，人们会做出有利于自己团队的选择，而不是从公司整体的角度出发。

保持每个人朝着共同目标前进的最简单方法之一是使用仪表板来突出显示向共同目标迈进的进展。这是一种合作的形式。

当组织为员工提供高质量的协作工具时，人们自然会分享更多信息，因此彼此之间的沟通也会更顺畅。

最后，当整个组织努力理解每个部门（有时是每个团队）及其日常面临的具体问题时，部门目标就可以成为整个公司的共同目标。

一起学习、一起工作、一起培训

根据经验，打破孤岛思维的最简单方法之一是进行跨组织的练习和活动。这类培训可以真正帮助打破孤岛，因为员工能够与组织内的其他人建立联系。

一起工作也能产生很大的影响。考虑一下如果可行，将人们安排得更近一些的想法。当人们坐得更近时，他们会建立起融洽的关系；当工作中出现问题时，他们会寻求身边人的帮助。这能产生很大的影响。

特定的培训也是确保能够转变组织孤岛心态的关键方法。这些培训支持合作、团队合作和沟通的理念。

经常沟通

我坚信沟通永远不可能过多。不论何种情况，沟通的频率非常重要。经常沟通会引入一种信任和透明度的氛围。

当团队感受到这种信任和透明度时，数据会在团队之间流动，从而促进孤岛的打破，而不是仅通过一次沟通的行动来打破它们。

组织结构本身就是一种孤岛，一些组织试图通过去除这种结构来消除孤岛。然而，这并不总是有效。在这种情况下，更有效的方法是正确地进行沟通，而不是去除这一组织结构，因为组织结构对于职责的分配至关重要。

评估团队薪酬

团队之间的竞争可以是非常健康的，但不同团队之间的薪酬计划可能会产生孤岛效应，形成一种不健康的关系，使得竞争成为目标，而不是合作。

如果你的公司有奖金或薪酬计划，确保这些计划反映了你作为组织设定的目标，而不是让团队相互对立，妨碍他们的共同目标。

当薪酬计划与公司目标一致时，员工会被激励去合作、沟通，并共同达成目标。

总结

在本章中，我们了解了 DevOps 文化，并明白了文化在 DevOps 中的重要性。我们讨论了增加透明度和改善沟通的必要性，以及保持强大文化的需求。最后，我们讨论了打破组织内部孤岛的必要性及其在 DevOps 中的重要性。

在下一章中，我们将探讨 DevOps 中的反模式，并讨论如何避免它们。

问题

现在让我们回顾一下本章中学到的一些内容：

1. 文化的关键支柱是什么？

   a) 角色与责任、参与规则以及回顾会议。

   b) 团队合作与协作。

   c) 与同事们拥有良好的社交生活和回顾会议。

   d) 尽可能快速完成工作，并对其他团队施加压力。

2. 如何在组织中促进更好的沟通？

   a) 让开发人员休假。

   b) 带领大家参加团队建设课程。

   c) 让开发人员执行发布。

   d) 让你的运营团队阻止所有发布。

第六章：避免 DevOps 中的文化反模式

在学习了打破团队间壁垒的具体挑战，并理解了文化在 DevOps 中的重要性后，在本章中，我们将探讨在 DevOps 中建立文化的挑战——特别是那些可能成为文化阻碍的反模式。这不是一项容易的任务，需要仔细的规划和思考。

本章中，我们将讨论以下主要主题：

• 组织对齐

• 对变革的抵制

• 扩展困难

• 过度关注工具

• 遗留基础设施和系统

组织对齐

整个组织的对齐至关重要。在本章后面，我们将讨论对变革的抵制，以及我们应该在没有明确愿景或目标的情况下仅为了变革而推动变革。这将导致组织中出现高度的抵制。对齐有助于减少这种抵制。

重要说明

增强的竞争优势、增加的收入、提高的利润和降低的成本只是实现更好组织对齐后的一些预期成果。

在组织对齐中获得成功始于回答什么、为什么和如何。在每个步骤中采取适当的措施是帮助实现更好对齐的关键：

图 5.1 – 组织对齐以产生结果

实现对齐的基础是什么、为什么和如何这三大支柱。什么阶段围绕确保使命声明的明确性展开。战略也是应该在这里定义的内容。通过定义目标、任务和活动来完成此任务。公司的使命声明是定义什么的一个例子。

接下来是为什么。定义你的愿景和帮助组织实现愿景的支持结构。在这里，组织结构很重要，领导力的角色以及帮助我们实现为什么的流程同样至关重要。一个例子可能是“我们的愿景是为更多人创造更好的日常生活。”这可以是一个医疗组织的愿景声明。

在如何方面，这就是组织的文化。文化由定义的价值观、业务中的实践以及我们在业务中期望的行为组成。

将这些元素结合起来就能产生结果。愿景同样推动什么和如何。这个概念由西蒙·西内克（Simon Sinek）在他的演讲《从为什么开始》中讲解得非常清楚（www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action）。

这就是我们对失去对齐的影响及其如何影响 DevOps 转型的分析。现在，让我们看看对变革的抵制对组织意味着什么。

对变革的抵制

变革总会发生——这是任何业务中常见的现象。有时，这些变革是被迫进行的，而其他时候，变革是出于业务发展的需要。无论哪种情况，在大多数组织中，我们很可能会遇到对变革的抵制。如果这种抵制没有得到妥善处理，我们的 DevOps 转型可能会在开始之前就陷入困境。

因此，进行 DevOps 转型时，理解如何应对组织变革，理解各方角色以及实现成功所需的步骤是至关重要的。

理解组织变革的角色

在进行 DevOps 转型时，对员工来说，这是对组织的重大变革。当我们对组织的运作方式进行任何重大变革时，理解成功推动这些变革所需的两大关键角色是至关重要的。这些角色就是管理层和人力资源（HR）。

管理

在这种情况下，领导力至关重要。为了避免员工因对变革处理方式感到不满而离职，领导层和执行团队需要对提议的变革给予一致的支持。

管理者与团队之间的对话，从一对一的交流开始，将帮助团队统一方向，推动这些变革。这些对话至关重要。它应该是一个开放的环境，我们可以讨论这些变革如何影响他们，以及他们对这些提议的变革有什么看法。

作为管理者，我们应该提出为什么、什么和如何的问题。然而，不幸的是，许多管理者对组织变革管理并不熟悉。缺乏这些技能可能会使得实施所需的变革变得困难。

为了提升这方面的技能，人力资源应为管理者提供适当的培训，这不仅对这种情况有帮助，还能为管理者在职业生涯中进一步提升管理层提供有价值的知识。

人力资源

在任何组织中，人力资源在实施任何规模的变革中都扮演着关键角色。人力资源可以提供沟通、实施和跟踪等支持。人力资源的真正价值在于他们能够公正地与关注这些变革的员工对话，说明为什么业务需要进行这些变革，以及员工在这些变革中为何如此重要。

重要提示

无论我们做什么，我们都必须确保从一开始就让人力资源参与对话。当人力资源了解提案内容、我们为何提出变革以及这将如何为业务带来益处时，他们才能提供帮助。

人力资源可以通过支持变革并为各个受影响的团队提供所需的支持，帮助提高员工对组织变革的认同感。SHRM 在这个主题上有两个非常值得参考的资源。

第一个问题是HR 在变革管理中的角色是什么？（www.shrm.org/hr-today/trends-and-forecasting/special-reports-and-expert-views/pages/deb-cohen.aspx），接下来是HR 如何提升员工对组织变革的认同？（www.shrm.org/ResourcesAndTools/hr-topics/organizational-and-employee-development/Pages/ImproveBuyIn.aspx）。

组织变革过程步骤

在经历组织变革时，为了成功，我们应该遵循一个有条理的过程。确保我们与组织中的所有利益相关者从上到下合作是非常重要的，以确保成功。

让我们看看实现组织变革成功的六个关键步骤。

清晰地定义变化并与业务目标对齐

这看起来可能很明显，但许多组织在这方面做得不好。阐明我们要进行的变革是一回事，但将其与组织目标和绩效目标进行比较则是另一回事。这一步很重要，因为与业务目标对齐的正确变革将把企业朝着正确的方向推进。毕竟，这就是我们首先要进行变革的原因。

这个步骤的另一个好处是，它使我们能够评估我们所提议的变革与其所带来的价值之间的关系。如果没有足够的价值，为什么要进行变革呢？

在这个阶段，我们应该提出以下关键问题，以确保我们能获得最大的价值：

• 为什么需要变革？

• 我们需要改变什么？

让我们学习如何确定变化对整个组织的影响。

确定组织变革的影响

当我们确定了想要进行的变化，并且知道它具有实际价值时，我们应该评估我们的组织并确定它将产生的影响。

需要理解的是，变革不仅仅影响组织内的一个业务单元——变化会在整个业务中产生连锁反应，并且对每个人都有影响。这里收集到的信息对于确定哪些地方需要培训，哪些地方员工需要支持，将是非常宝贵的。

在这个阶段，你应该回答的一些关键问题如下：

• 员工如何接受变化？

• 变化的影响是什么？

• 变革最会影响谁？

现在，让我们学习如何制定强有力的沟通策略，以传达我们的变革信息。

制定强有力的沟通策略

让每个人都参与到转型过程中是至关重要的。前两步已经告诉我们那些直接受到影响的员工，显然必须包括在任何沟通中。然而，透明度是关键，因此与整个业务的沟通应该是你沟通策略的重点。

你的沟通策略应包括活动的时间表、我们希望使用的沟通渠道、我们希望用于展示信息的媒介，以及如何逐步传达这些信息。

在我们转型的这一阶段，我们应该提出两个关键问题：

• 我们将如何管理反馈？

• 变革将如何进行沟通？

培训是变革过程中常常被忽视的一部分。现在，让我们来看一下如何提供有效的培训。

提供有效的培训

现在我们的转型信息已经公开，我们也了解了组织中的差距，员工需要知道培训将如何进行，以及我们将提供哪些培训。

这一点非常重要，因为员工会想知道他们需要什么技能才能在拟议的变革下履行新角色。培训可以通过在线学习模块、课堂培训、与主题专家的影子培训或导师制来进行。

为了提供有效的培训，请问以下问题：

• 哪些培训方法将是最有效的？

• 成功所需的技能和行为是什么？

在变革中支持员工至关重要。让我们来看一下如何为员工提供支持结构。

实施有效的支持结构

在任何组织变革中，为员工开发支持结构是非常重要的。变革可能会让员工感到不安，因此拥有一个有效的支持结构可以帮助克服这一点。

在组织变革中的有效支持结构将帮助员工在情感上和实践上适应角色变化所需的技能和行为。导师制度以及领导层的开放政策是员工在出现问题时提问所需的关键思维。

在实施有效的支持结构时，你应该问的一些关键问题如下：

• 哪些类型的支持将是最有效的？

• 最需要什么样的支持？

最后，让我们来看看如何衡量我们组织变革的进展。

衡量进展

最后，让我们来看一下衡量。整个组织变革过程中，应该建立一个结构来衡量我们在整个业务中所做变革的影响。这个衡量步骤可以在过程中提供持续的反馈和改进。

这也是一个评估你变革计划的机会，确定它在我们设定的目标中有多有效，并记录我们正在学习的任何经验教训。如果需要，我们也可以借此机会对计划进行调整和改进。没有什么比继续执行一个注定不会成功的缺陷计划更糟糕了。如果调整能带来成功，不要害怕在过程中做出改变。

在这个阶段，我们应该提出的关键问题如下：

• 这一过程是否成功？

• 变革是否有助于实现我们的业务目标？

• 我们应该做些什么不同？

现在我们理解了组织变革的步骤，让我们看看如何克服对变革的抵抗。

克服抵抗

我们已经讨论了在变革过程中应该采取的一些步骤。这些措施将帮助我们克服一些面临的抵抗。

尽管如此，这些对每个人都不会有所帮助，正如我们之前提到的，沟通对于做到这一点至关重要。通过持续的沟通来帮助我们对齐我们的目标，将有助于使人们感到放心。当人们感到对可能发生的变化感到威胁或担忧时，就会产生抵抗。

组织内抵抗变革的一些主要原因可能如下：

• 害怕失业

• 沟通不畅

• 缺乏信任

• 对未知的恐惧

• 时机不对

现在，让我们更详细地看看这些原因。

害怕失业

在每个企业中，为了保持竞争力和与客户保持相关性，都需要进行变革。有时，公司需要增加新角色，裁减人员，甚至改变角色以实现这些目标。对大多数人来说，这就是他们害怕失业的地方。

沟通不畅

我几乎记不住我们说沟通很重要的次数了，但实际上它确实重要，因为它将决定变革的成败。沟通可以解决变革中的所有问题，而缺乏沟通则会制造很多问题。

员工需要清楚地理解为什么需要变革以及它将帮助企业实现什么目标。如果员工被灌输的观念是“他们一直做的一切都错了，而且将完全改变”，那么预计会有很大的反弹。

缺乏信任

成功的企业建立在信任的基础上。如果领导和基层员工之间的信任水平很高，那么你们的抵抗力就会很低。然而，在领导和员工之间存在相互不信任的组织中，业务就不会朝着正确的方向发展，因此成功实施变革将非常困难。

对未知的恐惧

在商业中有一句话：“有未知的未知。”当人们不知道发生了什么时，这会产生恐惧，从而导致抵抗。通过良好的沟通可以轻松解决这个问题。我们沟通得越多，我们的沟通越开放，这会打破对未知的恐惧并建立信任。这两件事单独做到会减少组织中的抵抗。

时机不对

根据经验，传达变革信息的方式和时机是主要问题之一。通常并非变革行为本身会引起员工的抵抗，而是变革的传达方式和时机。

沟通中断

沟通是关键，没有任何商业活动可以过度沟通。当沟通中断时，它会对业务造成严重影响。这会在金钱和时间方面引发挫败感。

沟通崩溃发生在沟通者没有有效地传达他们要表达的内容时。这可能通过口头表达、这些话语的理解，甚至是书面文字。沟通崩溃不仅仅是一种方式，可能是沟通者说错了话，或者接收者未能正确解读沟通者的意思。

商业可以从航空业中学到很多东西，尤其是那里沟通至关重要。飞行员和空中交通管制员之间未能清晰沟通可能会导致巨大的生命损失。在航空史上，行业从错误中吸取了教训，确保了天空更加安全。我们也应该如此。

避免商业中沟通崩溃的关键在于五个要素。让我们来看一下这些要素：

• 承认错误

• 放慢节奏

• 人们的聚集

• 赢得人心

• 耐心

让我们详细看看每一个要素。

承认错误

人类通常害怕犯错，这种恐惧可能源自害怕失望、曾经犯过的错误或其他原因。承认自己的错误很重要，因为将责任推给无辜的一方只会让事情变得更糟。

如果我们误解了别人，我们应该直接告诉他们。这有助于在问题真正发生之前纠正问题。沟通者之后会明白哪里出错，下次可以改进他们的沟通策略。

放慢节奏

速度很重要，所以不要急于行动。我们匆忙做出决策只会加剧沟通崩溃的情况。调整节奏，慢下来；如果我们匆忙做事，人们可能认为这不重要，或者我们只是想赶紧结束。当我们放慢节奏时，这种情况会改变，因为我们会花时间去思考，所以解决问题变得至关重要。

人们的聚集

最重要的是，确保你的战略是围绕着将人们聚集在一起，而不是把他们推开。沟通崩溃会导致人们分裂并破坏信任。让每个人在同一页上——如果可能的话，在同一个房间里——并且集中于同一个目标，开始把人们聚集在一起。

赢得人心

通常，当沟通崩溃时，一些关键人物需要为此负责。显然，应该聚焦于解决问题，而不是进行责怪游戏。正如我们之前讨论的，责怪只会破坏信任。

耐心

“沮丧”是我们可能用来形容沟通崩溃的词语，解决这些问题也相当困难。然而，我们需要耐心：缺乏耐心只会让事情变得更糟。

缺乏耐心通常是沟通崩溃的一个原因，而解决这一问题的唯一办法是文化上承认并强化这一点。遗憾的是，抗拒改变是非常普遍的，但我们能够克服它！现在，让我们继续，看看扩展我们 DevOps 转型的难点。

扩展难度

DevOps 中的另一个反模式出现在我们能否扩展所做的事情上。当企业刚开始时，大多数企业会遇到扩展上的问题。随着增长，特别是快速增长，企业在扩展时会面临各种挑战。

扩展你的业务是困难的。需要进行许多变化，这些变化可能会使即便是最成功的企业也会脱轨。扩展过程中我们可能遇到的挑战如下：

• 必须在市场适配之前进行扩展

• 与不合适的人合作

• 过于关注销售和营销

• 价格竞争

• 随着发展进行管理结构调整

• 忽视问题

• 忘记精益化本身也是扩展的一部分

所列举的这些挑战大多来自业务角度，但专门针对 DevOps 的扩展呢？当我们谈到扩展时，我们需要坚持特定的步骤，专注于发展 DevOps 实践中的某些方面：

• 从小团队开始

• 鼓励技能发展

• 优先考虑文化

• 持续反馈

• 自动化

让我们详细看一下这五个方面，以便了解我们需要做什么。

从小团队开始

你是否听说过“创新者的窘境”？它讲述了在我们处于现实周期或日常运营中时，创新带来的挑战。如果我们希望扩展，消除这一障碍对于我们的成功至关重要。

我们必须决定我们想要交付的内容，组建一个敏捷团队进行推广，帮助扩展我们的运维并解决阻碍问题。我们必须在这个团队中获取所需技能，并朝着合乎逻辑的解决方案努力，然后再将团队转移到其他团队。

鼓励技能发展

这就是我们引入成长型思维或学习者思维的地方。我们必须愿意尝试新事物，并与不同的团队合作。这些团队成员的思维方式在起步阶段至关重要。

为了从开发和运维团队中获得最佳效果，鼓励他们不仅提升技术技能，还要发展软技能，因为软技能在 DevOps 中同样重要。

优先考虑文化

DevOps 的成功来自于开发和运维团队之间的积极文化。虽然很容易认为 DevOps 仅仅是关于产品开发，但发展正确的关系同样重要。文化与 DevOps 的其他方面同样重要。

最难的部分是让每个人都参与进来。因此，小团队是开始这一过程的基础。将这些事项做对了，将使你的团队在发展过程中能够承担更多的责任。跟随早期采用者的团队也能从他们那里学习。

持续反馈

持续反馈是根据实际情况和团队表现来调整 DevOps 文化的一个非常重要的步骤。获取反馈的过程使我们能够了解产品的现状以及需要改进的地方，从而让产品变得更好。

如果可能，我们应该尽量将发布和部署分开。我们可以朝着迭代部署的方向努力，从而获得来自用户群的反馈，并将这些变化融入未来的发布中。

自动化

使您的自动化能力成熟，将帮助您实现规模化。谈到自动化，找到流程中痛点并着手自动化这些痛点。然而，别过度关注这一点，否则我们会经历在过度关注工具部分中讨论的一些问题。

如果我们想实现持续交付，那么我们真的需要考虑自动化我们的测试。没有自动化测试的支持，我们将很难进行持续交付。

到目前为止，我们已经探讨了组织层面的 DevOps 反模式。现在，让我们来看看过度关注工具的影响。

过度关注工具

到目前为止，我已经谈到在关注工具之前，DevOps 中其他方面的重要性。从在线的诸多研究中可以看出，过度关注工具的危害是显而易见的。

然而，现实情况是，我们在文化、人员和流程方面相比过于关注工具的情况是存在的。即使在这一点之后，您仍然可能会过度关注工具。这会破坏您的转型努力。

DevOps 中最常见的技术领域之一是自动化。这可能是自动化您的 CI/CD 流水线或其他技术或业务流程。然而根据我的经验，许多组织把 DevOps 中的自动化信息推向了极端——这种做法往往是适得其反的，有时甚至对业务有害。这就引出了一个问题，多少自动化才算过多？让我们来看看。

多少自动化算过多？

了解组织如何达到这一点非常重要。假设大多数组织正从传统的瀑布式方法向敏捷方法转型，而这对于他们来说是全新的。常见的情况是，组织过度应用敏捷方法，从而导致敏捷和 DevOps 的过度使用。

重要提示

关键问题应该是，自动化是否服务于什么和为什么？

451 Research的研究（www.scriptrock.com/automation-enterprise-devops-doing-it-wrong）显示了一个支持这一点的趋势：

“我认为有一种倾向，认为大型企业组织，凭借它们的各个部门、团队和孤岛，能够像 Facebook 或 Netflix 那样使用前沿的配置管理工具。但实际上，所有的遗留技术和流程也必须加以考虑。”

– Jay Lyman，451 Research

工具链中充满了各种组织承诺将您的组织打造成下一个 Spotify 或 Netflix 的例子。虽然这是一种值得钦佩的目标，但从根本上讲，您的组织既不是 Spotify，也不是 Netflix，永远也不会是。

当我们尝试从任何角度，特别是从技术的角度，复制这些组织的成功时，我们很快就会发现自己走在一条下坡路上。此时我们所做的任何投资都将变得毫无价值，因为我们试图自动化太多，推动了太多的工具。

找到平衡

了解和理解何时该自动化或实施工具以实现特定目标是很重要的。事实上，我过去与一些组织合作时，根本没有在 DevOps 中进行自动化；有些做 CI/CD 自动化，而另一些则自动化了业务流程。

自动化是将手动流程并围绕其中的部分或整个流程应用技术，以便通过自动化进行复制。问题在于，并非所有的流程都能或应该被自动化。请注意，流程的不同部分可以被自动化；并不总是要么自动化整个流程，要么一部分都不自动化。

当我们决定是否应当自动化某些任务时，我们应该退后一步，遵循一个简单的过程。让我们把这个放在软件开发流程的背景下：

1. 思考在开发过程中，与团队其余成员共同进行的流程，审查它们并加以锁定。

2. 决定自动化的工具。

3. 一步一步地看自动化的价值。

   重要提示

   如果你的流程一开始就有缺陷，那么给它们加入自动化只会让不良流程发生得更快，而且没有监督。

你的组织也是独特的，供应商有一个习惯，用华丽的营销手法把我们吸引过去，告诉我们他们与不同软件供应商做了些什么。然而，我们的组织已经经营图书销售 100 年了。我们不是一个独角兽初创公司，混合旧系统和新系统将是一项挑战。

拆解流程

当涉及到我们的软件开发流程时，我们可以进一步将其拆解。我们可以对任何流程做这个，虽然我这里只是以软件开发作为工作示例。

在这个过程中，我们将组件拆解为子流程。这些就是我们自动化的候选项。当我们拥有子流程时，我们就能在细节上对其进行审视。此时，我们可以决定是否要保留、修复或创建新流程。

花时间去做是很重要的。创建流程看起来可能微不足道，但想一想公司未来的运作方式和现在的运作方式。流程必须具备随着组织变化而成长的能力。

与 DevOps 相关的启用任务，如 CI、CD 或持续测试，也应该在这一点上与任何固定流程结合起来。

最后，你必须选择合适的工具。这是大多数组织失败的地方，也是事情出错的地方。当我们定义了我们的流程并弄清楚哪些 DevOps 组件将被集成到这些流程中时，我们需要为这项工作选择合适的工具。

过度自动化的组织通常会将注意力集中在具体工具上，而不是流程本身。在这种情况下，技术通常基于情绪，比如其他组织使用类似工具，或者他们的同事在某次会议上使用这些工具。

这种情况最终会导致所有相关人员的混乱。结果是使用了太多工具和流程，这些工具必须调整以适应现有工具，而实际上，工具应该根据流程来进行调整。

当自动化引发问题时

我想谈谈我遇到的一个例子。我曾与一个组织合作，该组织希望从零开始，完全自动化整个生命周期。这样，开发人员可以在任何时间进行端到端的工作。宏伟的愿景是实现“随时随地构建”的场景。

然而，现实是开发人员每天会向平台发布新代码两次，有时更多。由于这种行为，最终的结果是终端用户对不断变化的代码感到沮丧。

对我来说，这个实验的“致命一击”是自动化测试不够全面。那些本可以通过人力进行的性能和回归测试中的质量问题，最终未能被发现。

最终，组织从工具链中去除了部分工具，限制了开发人员可以做出的更改类型，并加强了审查流程、部署过程，最重要的是测试。

这个故事的寓意是，不要让宏伟的计划和愿景，以及对自动化的无止境追求，压倒我们在自动化时应用理性思考的部分。

不做伤害

我希望在阅读了前面的部分后，你不会对敏捷或 DevOps 感到反感。那绝对不是我的本意。事实是，DevOps 所带来的价值远远超过了其缺点，但我们必须在实施时保持聪明和有条理。

总的来说，技术是一个促进者，当正确使用时，它能为你的组织带来巨大的价值，并且能使我们的工作更加轻松且可重复。

被称为 DevOps 的“黄金涅槃”是一个逐步实现的过程，源于我们如何在组织中执行敏捷和核心 DevOps 原则，而不是模仿他人的做法。许多组织最终可能会使用工具来满足他人的愿景，而非自身的需求。

在这一部分，我们已经探讨了过度关注工具的影响。现在，让我们继续讨论遗留基础设施和系统对 DevOps 的影响。

遗留基础设施和系统

当然，DevOps 不仅仅适用于云环境；它也适用于混合环境，当然，也适用于本地部署。可以说，在云环境中实施 DevOps 会更容易，但遗留的基础设施、系统和思维方式可能会成为 DevOps 的真正障碍。

遗留基础设施在 DevOps 采用过程中会带来许多问题，因为这些系统并非为 DevOps 所需的持续流程而设计。使用遗留基础设施进行迭代发布也非常困难，在某些情况下甚至是不可能的。这破坏了整个 DevOps 的精神，并开始引入我们需要克服的挑战。

遗留现代化

我们应对遗留基础设施的技术债务的一种方式是进行现代化改造。这是从传统基础设施到更现代化服务的一个过程，大部分是向公共云服务提供商迁移。

现代化对寻求扩展的企业有很多好处，它有助于降低成本、改善客户体验、加快市场发布速度，并促进企业的敏捷性等。

现代化的最常见途径之一是将现有的单体应用程序迁移到基于微服务的架构和设计模式。这种模式代表了一种基于领域的架构，服务之间解耦，可以多次用于不同的目的。

遗留应用和基础设施给我们带来了一些挑战：

• 安全性

• 单点故障

• 缺乏灵活性

向更现代的应用原则和实践的转变有助于解决和应对这些领域的关注点。涉及到流程和人员时，DevOps 在这里可以提供帮助。当然，这些是非技术性领域。在解决遗留基础设施问题时，这些领域和技术领域同样重要。

总结

在本章中，我们探讨了与 DevOps 文化相关的反模式，分析了这些挑战如何影响我们的 DevOps 转型，以及如何解决其中的一些问题，以防它们过度拖累我们的努力。最后，我们还探讨了过度使用工具对我们环境的影响以及这种做法给我们带来的风险。

在下一章中，我们将介绍价值流图，并学习如何利用它们推动流程变革。我们还将探讨价值流图与流程图的区别。

问题

现在，让我们回顾一下本章所学的内容：

1. 以下哪项不是抗拒变革的原因？

   a. 错误的时机

   b. 沟通不畅

   c. 关于加薪的担忧

   d. 错误的责任归属

2. 以下哪些措施可以改善沟通中的问题？

   a. 认领错误

   b. 让团队成员参加团队建设课程

   c. 持续反馈

   d. 团结团队

第三部分：推动变革并使流程成熟

流程让你的组织运转，是高效工作的重要组成部分。理解如何使其成熟是关键。

本书的这一部分包括以下章节：

• 第六章，通过价值流图推动流程变革

• 第七章，在你的组织中推动流程变革

• 第八章，流程的持续改进

第七章：通过价值流图推动流程变革

要完全理解流程，我们必须了解谁在执行这个流程，何时执行，以及为什么执行。这些信息可以帮助分解流程并消除冗余，以便可以自动化有用的流程。

本章将帮助你通过减少不必要的流程，使用价值流映射来改善组织内的流程流动。

在本章中，我们将涵盖以下主要主题：

• 理解价值流映射

• 价值流映射如何提供帮助？

• 流程图与价值流图的区别

• 解释一个示例价值流图

理解价值流映射

价值流映射的过程来源于价值流管理。而价值流管理本身是精益业务实践，旨在理解软件开发、交付和资源的价值。

这个过程还可以帮助组织内的价值流动，同时为软件交付提供生命周期管理。通过价值流映射，团队不再仅仅专注于功能，而是可以帮助你的团队关注有效的部分，并开始摆脱那些无效的部分。

到目前为止，我们已经重点讨论了 DevOps 的文化方面以及它对组织在向 DevOps 最佳实践转型过程中意味着什么。本章将开始关注组织内的流程。精益的流程是那些运作良好、浪费极少且高效的流程。一旦你达到了这种效率水平，你就可以开始自动化。

重要提示

自动化不良流程意味着你让不良流程发生得更快。首先对其应用精益实践，如价值流映射，以使其尽可能高效。

进行价值流映射练习可以从客户体验的角度提供一个简单明了的流程视图。这样做的结果是更好地与业务目标对齐，并能够扩展敏捷和 DevOps 转型。

这个过程的第一步是改变你的思维方式，使你把软件开发看作是与业务目标直接相关的环节。我们已经多次讨论过所需的变化。在我们试图让我们的流程更精简时，也可以说是同样的道理。

你在软件开发中执行的活动和业务目标往往是彼此分离的，软件团队的不同优先级使得他们始终专注于那些优先事项。在这种没有对齐的情况下，你必须退后一步，看看自己是否与业务目标保持一致。

所以，第一步是停下来稍作反思。评估一下业务中正在发生的事情，然后看看你在软件开发中所做的工作如何帮助并支持业务实现其目标。

在这个过程中，评估你与所涉及的人员、流程、工具以及任何存在的依赖关系的当前状态，以便领导层能完全了解事情的进展。

超越 DevOps 进行流程改进

的确，DevOps 在软件行业内推动了巨大的组织变革和转型。这一过程随着时间的推移不断发展，从最初对团队合作和共情的关注，到如何为组织创造真正的价值。

正如我们已经讨论的，要获得最佳的投资回报，你必须关注你正在生成的商业价值以及由此带来的客户满意度。这是我们在第二章中讨论的内容，DevOps 的商业收益、团队拓扑和陷阱。

对于许多组织来说，他们会同意 DevOps 带来了大量的转型。然而，你仍然会发现一些企业未能理解并解释从所需投资中获得的价值。

随着你的实践不断成熟，你需要更多地关注理解和创建度量标准和 KPI，以衡量成功。这些度量标准应进一步提高你交付的任何软件的质量，并加速交付，以满足客户体验，同时展示你所交付的商业价值。

这里的关键消息是，成功实施 DevOps 将大大有助于推进，但你必须在流程成熟度上走得更远。

查看价值流映射图示

以下图示来自 Plutora 的一篇关于价值流映射的文章（www.plutora.com/blog/value-stream-mapping）：

图 6.1 – 价值流映射练习中的示例图示

我们将在本章稍后的部分更详细地分析前面的图示。之前的例子是价值流映射练习中的一些输出。

价值流图是一个被分为三个主要领域的图示。这些领域是信息流、产品流和时间阶梯。

信息流

这个图示展示了与流程相关的任何信息是如何进行传递的，以及数据如何被传输。图示中显示了发布经理接收所有客户请求。只有经过批准的请求才会提交给开发队列，开发队列被视为一个供应商。

根据价值流映射练习的目标，SharePoint 和 Excel 中显示的收集和分配过程可以包括许多细节层次，以及许多其他集成系统。

产品流

本节旨在映射软件开发生命周期的各个步骤，从最初的概念到交付。根据你的需求，你可以专注于流程中的特定部分，以在特定环节提高效率。它可以是详细的，也可以是高层次的，视需要而定。

正在执行的任务显示在框中，执行任务的个人或团队也显示在框中。关键的过程数据接着显示在下方。前面示例中的两个项目分别为 C/T 和 S/T，C/T 指的是周期时间，S/T 指的是准备时间。

你可以在此处包括任何数量的细节，突出你希望展示的任何重要信息。三角形显示了在每个阶段等待的特性队列，随后是从一个阶段到另一个阶段的虚线箭头。这些被称为推送箭头。它们表明产品正从一个阶段移至另一个阶段，而不是被拉动。

时间梯子

时间梯子的目的是提供价值流中涉及的时间线的高级或简化视图。梯子的顶部部分代表你的特性在每个阶段的队列、门或等待的平均时间。

梯子的底部显示了参与主动工作的平均时间。更具体地说，它展示了在特定阶段，特性在此阶段已被添加的时间。

其他术语

让我们看看在价值流图中你可能遇到的其他术语：

• 周期时间：指的是特性生产的频率，或者是两个完成的特性之间的平均时间。

• 准备时间：指的是为任何给定步骤准备所需的时间。在软件工程中，这可能是理解需求所需的时间。

• 正常运行时间：以百分比衡量，提供了任何过程或系统处于活动状态的总时间。

• 交付时间：衡量从概念到交付，单个请求在整个周期中所需的平均时间。我们在第三章中讨论过这个概念，衡量 DevOps 的成功。

• 节拍时间：这是你需要的生产速率，以满足客户需求。这是一个计算公式，将工作日的小时数乘以一个月的工作天数，再除以可用的工作小时数，最终转换为每月分钟数。基于每月 9,000 分钟和 150 个客户需求的特性，计算结果表明你每个特性需要在 60 分钟或更少的时间内完成，以保持生产的速度。

现在让我们来看一下在价值流图中使用的符号。

价值流符号

你会注意到在图 6.1中有一些特定的符号。就像流程图一样，这些符号代表了特定的事物。让我们来看一下你可以在价值流图中使用的符号：

图 6.2 – 价值流图中的符号

当然，实际中存在更多符号，但图中包含的符号是常见的，且你在自己的价值流图中一定会用到它们。你还可以将它们分成不同的类别。最上面一行包括所有的物料流符号，第二行包括信息流符号，底部一行包括一般符号。

现在，让我们详细讨论涉及物料流、信息流和过程流图中的关键术语。

物料流

以下术语通常用于物料流图中：

• 过程：表示一个个人或团队执行特定任务。

• 共享过程：与常规过程相同，但该过程是多个方共同参与的。

• 供应商/客户：通常，当这个符号位于价值流图的左上角时，它表示流程的起点，并指示供应商。当它位于右上角时，表示客户。

• 库存：如果你想在两个过程之间添加库存计数，请使用此符号。如我们的示例所示，我们在那个时间点记录了未完成的特性数量。

信息流

以下术语通常用于信息流图中：

• 手动流：表示传递对话或笔记的位置，以及流动的信息类型。

• 电子流：与手动流相同，但它表示电子信息资产。

• 信号看板：当库存降到最小值时使用，用来提示生产多个零件。可以类比为超市的库存水平。

• 看板柱：通常表示一个收集信号的位置。它也可以用于看板中提取和生产的交换。

通用

你可能还需要在图中使用以下内容：

• 操作员：表示在特定步骤中需要多少操作员来处理价值流图。

• 改善冲刺：有时也叫做改善闪电战，这是一次集中的团队活动，专注于解决特定的挑战。其目的是解决问题并使团队集中在一个问题上。

• 质量冲刺：表示质量问题，可以在价值流映射链中的任何节点使用。

• 安全库存：表示一种临时的安全库存，用以防止在发生故障或其他问题时出现问题。

现在我们已经理解了价值流图的一些基础知识，让我们来看看价值流图如何帮助你的组织。到目前为止，我们使用的一些术语比较通用，所以让我们举些更具体的软件工程方面的例子。

价值流图如何提供帮助？

值流图极为重要。它不仅帮助你理解你的流程，还帮助你将这种理解转化为改进流程的方法。它对业务的可持续性至关重要。

这其中有三个原因：

• 消除浪费可以改善组织的底线。你还可以通过这个过程发现浪费的根本原因和来源。

• 团队将抛弃个人假设，并根据客户的视角进行优先排序。

• 通过值流图创建的可视化可以轻松识别浪费的交接。团队可以识别并采取措施改善他们的协作、沟通和文化。

虽然创建值流图的过程对你的组织来说极其有用，但它也可能带来一些挑战。我们来更详细地看看这些挑战。

值流图的挑战

如果不小心执行，值流图可能变成一种浪费的活动。你需要意识到其中的一些常见陷阱，包括创建值流图并确保你所产生的内容对你的业务本身有价值。

投资回报率在值流图中至关重要。你需要监控投入到值流图绘制过程中的努力，并将其与可能获得的价值进行平衡。从一开始就关注投资回报率。

确定浪费的过程可能是密集的。当员工知道正在进行值流图绘制时，通常会产生恐惧和不确定感。他们错误地认为该过程是为了从员工角度识别浪费。

许多过程涉及跨职能团队和其他复杂性。在进行值流图绘制时，确保有来自各方经验的人员参与。

虽然逐步改进是开始通过改善每个环节来节省成本的绝佳起点，但这些改进可能不会影响整体的盈利，直到完成从上到下的变革。

重要提示

记住，值流图的目标是减少浪费，而不是制造更多浪费。

本章早些时候我们讨论了可以在值流图练习中使用的符号。我建议不要急于寻找专业的解决方案来创建它们。先从纸张或白板开始，结果是一样的，你可以勾画出你的想法。之后可以使用软件来正式化值流图。

值流图的应用场景

基于本章早些时候提到的一些符号描述，你应该已经猜到，像许多来自制造业的精益流程一样，值流图的根源并不在软件工程，也不在技术领域，而是在制造业。

价值流图可以为多个行业带来价值。精益原则同样适用于每个行业，你可以根据需要像在任何框架中一样进行调整。根本上，你所在的行业或领域决定了价值流图中的项目流。

例如，在供应链中，价值流图对于发现并消除导致成本延误的因素至关重要，从而最终导致完成产品。在服务行业中，流程将促进为客户提供及时且有效的服务。

在医疗保健行业，价值流图将确保患者获得高质量的护理，同时减少可能威胁生命的延误。最后，在制造业中，价值流图通过分析物料和信息流的每个步骤，帮助识别浪费。通过价值流图流动的过程项目被称为物料。

识别和减少浪费

正如我们在上一节中提到的，价值流图起源于制造业，就像精益原则本身一样。精益的起源可以追溯到日本的汽车工业。这使得日本汽车工业通过精益原则和自动化蓬勃发展，而世界其他地方则还在追赶。

将这种精益思想应用到你的日常流程中，比你想象的要困难。在制造业中，以下八种是浪费：

• 缺陷

• 过度生产

• 等待

• 未充分利用的人才

• 运输

• 库存

• 动作

• 额外处理

在应用精益思想时，尝试思考前面列表中的八个方面，看看你在哪些地方可以改进你的流程。我们来看看一些软件开发中的例子，帮助你识别浪费。

运输

在制造业中，我们将运输视为一种物理行为：从一个地方移动到另一个地方。在软件开发中，运输可能是最难发现的浪费类型之一。毕竟，产品不是你可以移动的物理物体——它是虚拟的。

不要从物理角度思考，想想你的任务是如何从一个开发者传递到下一个开发者的。这可以是从架构师到开发者，或者从设计师到开发者。

这个的一个实际例子可以是开发者到测试员的流程。假设你的测试员已经准备好进行任务工作，并且他们刚刚完成了另一个任务，这样任务可以立即开始。首先，测试员会查看任务，了解他们需要做什么。接下来，你必须启动应用程序，并到达你希望他们测试的步骤。测试员可能需要一些时间才能到达那个步骤。这就是所谓的准备时间，在这个例子中，准备时间是由任务交接产生的。

等待

等待方面的浪费可以在在制品（WIP）中找到，以及等待流程中的下一步。如果你在等待，那么这项工作没有得到高效处理。等待某人或某事的任务会产生非增值时间。这会延迟交付，不仅是这项任务，所有任务都会受到影响。

在软件工程领域的一个好例子就是质量控制步骤，如测试，以及技术债务和漏洞修复。

过度生产

在软件开发中，这表现为两种明显的形式。第一种对你来说非常熟悉，那就是范围蔓延。具体来说，范围蔓延是指当你开始时有一组初步的需求，但在开始工作后，这些需求发生了变化。

第二种过度生产类型与帕累托原则一起发挥作用。该原则的应用是，你的目标受众中 80%的人只会使用约 20%的功能。因此，这个原则意味着你将花费大量时间开发那些几乎不会被使用的功能。

现在我们已经理解了为什么价值流图如此重要，并且理解了如何识别浪费，让我们来看看流程图和价值流图之间的差异。

分析流程图与价值流图之间的差异

价值流图显示了大量信息，并采用了更线性的格式。它与只显示流程步骤的流程图截然不同。同样的差异也适用于流程图，如下图所示：

图 6.3 – 显示流程图一些元素的高级示意图

如你所见，流程图或过程图非常有效地展示了流程的各个部分，包括整个过程中做出决策的节点。然而，它并没有像价值流图那样进一步深入。

价值流图尝试识别流程中的浪费以及流程步骤之间的浪费。另一方面，流程图则呈现了更详细的业务流程。

请看下面这个来自Creately的示意图（creately.com/blog/diagrams/process-mapping-guide/）。下面的流程图清楚地展示了流程的不同部分：

图 6.4 – 带泳道的流程图示例

上面的示意图显示了所谓的泳道。这些是你可以看到的垂直列。在前面的示例中，它们将流程的不同部分划分给了与流程互动的不同人员。你可以看到客户、前台和技术员出现在上面的示意图中。

这对于突出显示在您正在记录的过程中处理各部分的人非常有用；它可以在不同的泳道之间移动，您图表中的泳道数量完全取决于流程。

以下图表，来自 Creately，是一个更简单的流程图示例。它是从左到右读取的，沿着箭头进行：

图 6.5 – 流程图的简单示例

普通的矩形框表示流程中的步骤，其中会发生某些事情，而圆角的药丸形状表示启动和终止节点——换句话说，就是流程的开始和结束。

何时使用流程图或价值流图显然是您需要理解的关键内容。如果您不小心，可能会花费大量时间创建流程图和价值流图，最终得到错误的结果。

我应该使用哪一个？

您可以充分利用流程图和价值流图，显然是由于它们产生的细节层级的差异，因此您需要确保为正确的原因创建正确的内容。每种类型的图表用于识别过程中的不同变量，但将价值流的组件与流程图的详细元素结合使用是有价值的。

如果您仔细思考，详细的流程图确实包含了价值流图的所有元素——它也可以进一步细分为更详细的内容。

重要提示

当您的价值流图识别出浪费时，可以考虑使用流程图来包括更详细的内容。

在下一部分，我们将理解流程映射和价值流映射之间的区别。让我们通过查看一个价值流图示例来结束本章，并看看我们可以做些什么来改进我们的流程。

解释一个示例价值流图

到目前为止，在本章中，我们已经了解了价值流图是什么，它们如何帮助您的业务，以及价值流图中涉及的各个组件。现在，我们将开始探讨如何构建价值流图，同时也会审视 DevOps 流程的前后状态。

创建一个有意义的价值流图的过程可能是漫长的，这取决于流程的大小。正如我们之前讨论的那样，请确保通过监控价值流图活动的投资回报率，从过程中获得一些成果。

创建价值流图

当您开始创建价值流图时，应该遵循以下步骤，以确保成功。首次创建价值流图可能是一项艰巨的任务。按照这些步骤和提示操作，您将能够制作出具有实际价值的价值流图。

确定待解决的问题

首先，你需要确定你要解决的问题。不要仅仅因为想要绘制一个图表就去绘制价值流图——请从一个存在问题的地方开始创建你的价值流图。

为了让你更清楚这一点，可以从客户的角度思考问题解决方案。他们是否觉得你交付新功能的时间太长？每个人都需要达成共识，所以确保你发布了问题陈述。

最后，设定一些目标。说你想将某个指标减少一定百分比并不现实；这是一个值得称赞的目标，但要确保它是现实可行的。

确保团队有足够的授权

在进行价值流图绘制时，你需要一个经验丰富且成熟的团队。这将帮助他们顺利完成当前的任务，最重要的是按时完成。领导层也应预留必要的预算，以确保执行符合预期。

限定过程

一旦完成并发布了问题陈述，重要的是要限制你的价值流图绘制的范围。你可能不需要绘制整个过程的端到端流程；你可能只需要专注于过程中的某一部分。

将复杂的过程分解成更小的部分，然后继续将其分解，直到复杂性变得易于理解，并呈现为离散的组成部分，这一过程被称为过程分解。

总体来说，我推荐这种方法；通过专注于问题的一部分，而不是从上到下全部处理，你会从经验中获得更好的结果。分阶段地处理整个过程，而不是一开始就试图从头到尾解决。

一旦你将工作范围限定在过程的一部分，确保通过进行审查来绘制它。经验不能被偏见、不完整或不准确的文档或他人的叙述所替代。

定义过程的步骤；这一过程需要多次完成。有时候，事情会在第二次甚至第三次尝试时显现出来。确保至少进行两次，以确保你获得完整的图景。

收集过程数据并创建时间线

在进行价值流图绘制时，记下任何你希望收集的适用的过程数据。这些数据可能包括但不限于以下信息：

• 涉及的人数

• 平均工作时长

• 循环时间

• 等待时间

• 正常运行时间

同时，确保在底部包含你的过程时间和交付时间。还记得我之前解释过时间阶梯的用途吗？这时它派上用场了。

评估当前的价值流图

当你开始评估当前的价值流图时，在此阶段的过程中需要寻找一些特定的内容。请提出以下问题：

• 团队是否有多个依赖关系？

• 你的等待时间或交付时间是否过长？

• 这可能是因为你的测试没有并行运行吗？

• 你的环境是否稳定？

所有这些问题都可以用来评估你的价值流图。甚至可能你的过程中的某些步骤是有价值的，但它们并没有转化为对客户有意义的成果。你还应该寻找过程中的任何阻力或信息流中的停滞。记下这是否是推动式（push）还是拉动式（pull）。

设计你的未来状态

在这个阶段，你的价值流图可能尚未完成或还不是最终版本，但这没关系。这里重要的是确保你未来状态的价值流图与组织对未来的愿景保持一致。

确保没有任何东西是固定不变的。在 DevOps 的精神下，确保你可以将持续反馈融入这个过程中，并做出任何合理的调整。

实施你的未来状态

你必须验证你的未来状态是否会带来你预期的变化。监控你的目标和关键结果（OKRs）以及关键绩效指标（KPIs），从你看到的趋势中学习。我们在第三章《衡量 DevOps 的成功》中讨论了可以用来制定 KPIs 的度量标准。

重要提示

成功的价值流映射练习的目标是确保每个人现在都在指向并朝着同一个方向工作：即客户的方向。

当然，所有这些应该已经解决了你在最初定义的问题陈述中设定的问题。如果你不能说它解决了问题，那就回去看看还可以做些什么来改善情况。

当前状态的价值流图

现在，让我们看一个真实的例子，看看 DevOps 世界中的价值流图是什么样子的。请看下面的图表，这是来自Lucidchart的模板（www.lucidchart.com/pages/examples/value-stream-mapping-software），它完美地展示了你能从中获得的价值：

图 6.6 – 我们 DevOps 流程的当前价值流图

我想花点时间解释一下这个图表中发生了什么。首先，让我们简要讨论一下这个过程。你可以看到我们的客户部分是主要的入口点。

它从客户通过电子邮件发送功能请求开始。这个请求由两位服务工程师中的一位接收。此时，他们将该请求记录到 Confluence 中。团队中的唯一一位产品经理然后在 Jira 中批准并优先处理该功能请求。

然后，我们的两人软件工程团队将使用Jira中的需求详细信息来处理该项任务的 Java 代码。该代码随后由一名部署工程师通过Jenkins和Circle CI部署到预生产环境中。接着，QA 专家和客户使用Selenium进行质量保证测试。最后，一名部署工程师负责将所有开发工作整合起来并发布到生产环境。

这个过程的总交付周期为 243 小时，而总的增值时间（用于完成任务的时间）为 26.08 小时。%C&A指的是已完成且准确的输出，而Rolled %C&A（24%）则指的是不需要返工的时间。最后，活动比率为 11%，即实际工作时间。

总体来说，虽然这个流程定义清晰且已很好地进行了映射，但你仍然可以看到几个改进的领域。让我们来看看这些领域。

未来状态价值流图

未来状态并不总是意味着要从你的流程中删除步骤。记住，未来状态是为了提高流程效率的节省。请看下面的未来状态价值流图：

图 6.7 – 我们的 DevOps 流程的未来状态价值流图

在我详细说明我们的未来状态发生了什么变化之前，请看流程框上方右侧的点，这些点表示该流程是新的。正如我刚才提到的，这并不是为了减少流程步骤，而是如果添加新步骤能够增加价值的话，就应该添加。

接下来，在每个流程下，所显示的时间数据包括指向右的箭头，表示没有变化。如果引入新的流程，你将添加这些箭头。指向下的箭头表示相较于之前的价值流图或当前流程，时间有所减少，而指向上的箭头表示时间有所增加。

那么，让我们来看看发生了什么变化。首先，让我们看看新的流程。在这里，你可以看到，客户不再通过发送电子邮件来传达他们的新需求，而是直接在Confluence中进行更新。产品经理将会审查并批准/优先处理这个需求，从而节省了时间。

这也导致开发人员完成开发工作的交付周期缩短，现在的交付周期为 96 小时，完成实际任务所需时间为 11 分钟。

事实上，你可以看到在整个过程中的多个任务都节省了时间，同时还引入了新的测试流程，并且对代码进行了监控。这一切意味着总交付周期现在缩短为 188 小时，相比之前的 243 小时有所减少。

增值时间现在为 19.54 小时，相较于之前的 26.08 小时有所减少。我们减少了员工在增值工作上的时间，这并不是坏事。这意味着他们可以在有限的时间内交付更多的工作。引入测试和监控使交付过程更加成熟，但最重要的是，它增加了客户与我们之间的互动。

总结

在本章中，我们探讨了价值流图绘制的过程，了解了它是什么、如何帮助我们以及如何构建价值流图。我们还看到了价值流图和流程图之间的区别，讨论了可以在流程中识别的不同类型的浪费，最后通过一个例子展示了如何创建价值流图。

在下一章中，我们将探讨如何将本章中学到的内容应用到组织中的流程变革中。我们将通过了解变革的八个步骤、流程变革的影响以及流程变革中的常见挑战来实现这一目标。

问题

现在，让我们回顾一下我们在本章中学到的一些内容：

1. 以下哪项在价值流图中不会出现？

   a. 信息流

   b. 产品流

   c. 游泳道

   d. 时间阶梯

2. 以下哪项不是一种浪费类型？

   a. 运输

   b. 生产不足

   c. 运动

   d. 过度生产

第八章：在您的组织中实施流程变革

现在您已经理解了您的流程以及需要变革的地方，本章将探讨如何在整个组织中管理流程变革。请记住，有时流程会影响多个团队和部门。这可能是一个挑战，需要精心管理，以确保成功。

到本章结束时，您将能够理解有效流程变革的八个步骤、不同的商业变革模型以及流程变革中的常见挑战。

本章我们将覆盖以下主要内容：

• 有效变革的八个步骤

• 商业变革模型

• 流程变革对人员的影响

• 流程变革的常见挑战

有效变革的八个步骤

在商业中，变革的需求几乎是持续不断的。能够有效适应变革的企业，通常会在长期竞争中脱颖而出并战胜对手。当您已经绘制出流程并完成了价值流图后，接下来要做的就是有效地在组织中推动这一变革。

这从一个八步变革计划开始，具体步骤可以描述如下：

1. 确定可以改进的内容

2. 向利益相关者展示商业案例

3. 变革规划

4. 确定评估所需的资源和数据

5. 沟通

6. 评估阻力、依赖关系和风险

7. 庆祝成功

8. 持续改进

其中一些步骤您可能已经熟悉，因为我们之前讨论过其中的一些内容，但现在让我们详细了解一下所有步骤。

确定需要改进的内容

我将此步骤包括在此，纯粹是为了完整性。为了明确，我们在前一章中讨论了价值流图，并详细探讨了如何识别需要改进的地方以及什么时候应该进行改进。

了解需要改变的内容将为成功实施流程变革打下坚实的基础。

向利益相关者展示商业案例

向您的利益相关者展示商业案例是下一步。然而，根据您迄今为止收集流程变革支持的方式，这一步可能不需要。

如果您已经与利益相关者互动，并带他们了解问题陈述以及如何解决，那么您实际上已经向他们展示了您的商业案例。

根据变革的类型和对整个业务的影响，如果您发现需要向更广泛的利益相关者展示您的想法以获得更广泛的支持，也不必感到惊讶。

变革规划

很多人认为，当您完成了价值流图后，就可以开始行动了。实际上，在做任何事之前，您需要先规划如何实施变革。如果您先进行规划，那么成功的机会会更大。

可能你所做的变革很小，但仍应为成功的实现设定明确的目标。显然，如果你的变革很大并涉及到组织的多个部分，那么规划至关重要。

确定用于评估的资源和数据

这个步骤是你规划的一部分。确保你有足够的资源来高效执行。在考虑资源时，不仅仅是考虑人员。这也可能包括额外的软件、培训、工具或文档的变更，等等。

数据的关键在于你如何评估进展和成功。拥有适当的数据意味着你可以提供基于数据的进展更新和希望的成功，而不是依赖感觉或直觉。

沟通

沟通是成功的真正关键。它是大多数变革管理框架所共同具备的金钥匙。它贯穿于变革管理的整个实践中，重要性不言而喻。

清晰和开放的沟通渠道是你成功交付流程变革的基础。沟通方法使你有渠道来倾诉挫折，庆祝有效的部分，并审视哪些做得不好。最后，沟通是透明度的重要推动力，它能确保大家始终保持一致。

评估抵抗、依赖关系和风险

对于变革成功的最大风险之一就是抵抗。抵抗是正常的，并且在每个组织中都会发生。大多数抵抗源自对未知的恐惧。更广泛地说，每一次变革都伴随着一定的风险。也许它不会产生预期的效果。

你可以通过为你的团队和领导层提供工具和知识，帮助他们顺利过渡，从而应对抵抗。

庆祝成功

识别过程中小的渐进变化以及最终的成功。你在正确方向上迈出的每一步都是积极的，每一步都应该得到庆祝。你的团队将会为成功付出艰辛的努力，庆祝他们的成功并认可他们的付出将激励大家，特别是当变革需要很长时间时。

持续改进

变革管理可能非常困难，因为它是一个持续的过程，需要在适当的时候进行调整，以帮助确保成功。持续改进应贯穿整个过程，就像沟通一样。这可以帮助你识别并解决过程中遇到的障碍。

现在我们已经更详细地探讨了这八个步骤，让我们来看一下你可以在组织中使用的一些变革管理模型。

商业变革的模型

有许多框架可供在你的企业中执行变革，像所有框架一样，有些框架会比其他的更适合你的企业。有些框架是针对特定场景的。你不应该试图让你的企业去适应框架；而是应将框架适应你的企业。

在这一部分，我们将仔细研究四个商业变革模型，它们如何使用以及我们能从中学到什么。你甚至可以将多个框架的元素结合在一起，融入自己的模型中。这些框架如下：

• 科特的变革管理模型

• 罗杰斯的技术采纳曲线

• 认知、欲望、知识、能力、强化 (ADKAR) 模型

• 展望、激活、支持、实施、确保、认可 (EASIER)

让我们更详细地看一下这些模型。

科特的变革管理模型

第一个模型是科特的变革管理模型。这是约翰·科特博士（www.kotterinc.com/team/john-kotter）的创意，约翰·科特是一位作者和管理顾问；他是商业、领导力和变革方面的思想领袖，也是科特国际（Kotter International）的创始人，该公司应用科特的领导力研究帮助组织执行大规模的变革。和本章前面讨论的模型一样，科特的模型也是一个八步模型，分为三个阶段。具体阶段如下：

• 为变革创造气候

• 吸引和赋能组织

• 实施并维持变革

第一步到第三步是第一阶段，第四步到第六步是第二阶段，最后，第七步和第八步是最终阶段。科特模型的步骤如下：

1. 创造紧迫感。

2. 形成一个强大的联盟。

3. 为变革创造愿景。

4. 沟通愿景。

5. 授权行动。

6. 创造快速胜利。

7. 基于变化进行构建。

8. 让它成为常态。

科特（Kotter）于 1995 年提出了这个八步模型。科特指出，即使前面的某一步骤失败，整个变革计划也会失败。下图是该模型的视觉展示：

图 7.1 – 科特模型的视觉展示

科特模型的一个主要优点是，其步骤是可操作的，呈现为一个检查清单。这是一个逐步的模型，清晰易懂，并提供了详细的步骤描述。

然而，它有一个局限性，即缺乏任何测量步骤，并且实施过程耗时。学者们也指出，随着时间的推移，它是一个流动的过程，并不遵循线性路径。

罗杰斯的技术采纳曲线

对变革管理模型的一个略有不同的解读是技术采纳曲线。该模型用于定义采纳时间框架，并在流行文化中有所应用。

西蒙·西内克（Simon Sinek）在他那场著名的 TED 演讲《从“为什么”开始》(www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action)中谈到了技术采纳曲线。西内克称之为创新扩散法则。

由乔治·比尔（George Beal）、埃弗雷特·罗杰斯（Everett Rogers）和乔·博伦（Joe Bohlen）于 1957 年开发，最初应用于农业，但后来扩展到技术领域。技术采用曲线旨在通过五个不同的阶段突出社会对新思想的接受度：

1. 创新者

2. 早期采纳者

3. 早期大多数

4. 晚期大多数

5. 落后者

该曲线解释了你的想法在采纳方面的成功可能性。如果你试图说服晚期大多数人接受你的想法，它不会成功。创新的扩散讨论了早期采纳者与早期大多数人之间的差距，弥合这一差距是实现成功的关键。

提示

在采用 DevOps 时，针对组织中的创新者和早期采纳者获取支持，并将他们带入变革过程中。然后，与早期大多数人合作，取得更多支持。

在应用 DevOps 方法时，使用这个相同的变革原则。当你试图推动 DevOps 变革战略的采纳时，确保先关注组织中的创新者和早期采纳者，再关注早期大多数人。

我非常喜欢这个模型，并且在多个不同的场景中成功地使用过它。也就是说，如果你在寻找一个传统的框架，这个模型可能并不是你的最佳选择。

ADKAR 模型

ADKAR 模型（www.prosci.com/adkar/adkar-model）是一个以目标为导向的模型。该模型由Prosci创始人 Jeff Hiatt 创建。该公司专注于客户成功，全球范围内都有其代表。

ADKAR 是一个首字母缩略词，代表了在组织内实现持久变化需要达成的五个具体成果。这五个成果如下：

• 意识

• 渴望

• 知识

• 能力

• 强化

该模型在自己的方式中紧密地遵循了科特尔模型的步骤。同样，ADKAR 模型也分为三个阶段：当前、过渡和未来。

该模型奖励组织变革框架中的个体变革。然而，模型的缺点是，在较大的组织中，它可能显得繁琐。

EASIER 模型

EASIER 模型遵循六个广泛的步骤。它是由 David Hussey 提出的。你可以在他所描述的步骤中看到与其他框架的相似之处。

EASIER 模型的六个步骤如下：

1. 展望

2. 激活

3. 支持

4. 实施

5. 确保

6. 认识

该框架的一个限制是高度依赖领导力的有效性和反应。不过，其一个显著的优点是变革管理的清单式方法，这使得它在许多人中非常受欢迎，类似于科特尔模型。

现在，我们已经看过了业务变革模型以及如何在组织中使用它们。接下来，我们来看一下流程变革的影响。

流程变革对人的影响

人员是你组织的核心。确保人员参与其中。与那些人心涣散的组织变革相比，你的变革更有可能成功。

当你经历任何组织变革，特别是那些可能改变涉及人员角色和职责的变革时，考虑这一变革对你组织内人员的影响是很重要的，不仅仅是那些直接受影响的人，还包括那些间接受影响的人。

直接影响

当我们谈论直接影响时，我们指的是那些直接受你提出的变革影响的员工。这包括那些因为你的提议而发生角色和/或职责变化的人。

当然，最大的影响无疑是直接来自于抗拒。我们在第五章，《避免 DevOps 中的文化反模式》中讨论了抗拒的原因，具体如下：

• 担心失去工作

• 沟通不畅

• 缺乏信任

• 对未知的恐惧

• 时机不当

这些理由很好，当然在我的经验中非常常见，但还有其他直接影响的后果吗？考虑以下这些影响：

• 让人们走出舒适区

• 社交安排的干扰

• 降低身份地位

现在让我们更详细地分析这三个原因。

让人们走出舒适区

在你的职业生涯中，你开始对自己所做的事情感到舒适。有些人很喜欢走出舒适区的想法，但其他人完全不喜欢。不要以为你组织中的每个人都迫不及待地想走出舒适区，实际上大多数人并不愿意。

因此，直接影响变革的后果之一是人们感觉他们被推到了舒适区外。对于那些不喜欢这种安排的人来说，这将会让他们感到不安。你需要在这种情况导致员工离开组织之前加以解决。

我们已经讨论了沟通和透明度的重要性。两者在这里至关重要——你可能无法解决这一领域中的每一个冲突，但良好的沟通和透明度将使解决变得更加容易。

社交安排的干扰

历史以及大多数管理文章告诉我们，工作与生活的平衡对员工的心理健康至关重要。这个平衡的一部分是员工与办公室内外社交圈子的社交安排。

任何看起来会打破这一点的行为都会让人感到不安，并质疑变革的有效性。是的，这也是一种抗拒，和我们正在探讨的另外两个原因一样，但你会惊讶地发现这有时会被忽视。

如果你在一个跨多个地区的大型组织中工作，别忘了文化因素。你的变革可能会对某些文化日历中的重要日期产生负面影响，而对你自己的文化却没有什么影响。

降低职位

大多数人会告诉你，职位头衔和在公司中的地位并不重要。然而，正如在Glassdoor上的这篇文章所指出的（www.glassdoor.com/blog/the-importance-of-title-in-the-job-search-process），职位头衔随着时间的推移帮助展示职业发展，反映薪资，并可能决定未来的角色。因此，任何能够通过反映地位降低来抑制这一发展的变化，都是潜在雇主会质疑的地方。

因此，当你在处理影响角色和职责的变更时要小心。你可能会让某人看起来像是降职了，单凭职位的变化就可能让人产生这种印象；希望这不是你的意图。

现在我们了解了直接影响，让我们看看间接影响及其对人们的影响。

间接影响

与直接影响相对，间接影响可以被看作是这样一种情况：某个直接受到变更影响的团队为另一个团队做了一些关键工作；另一个团队现在受到了你所做变更的间接影响。

重要提示

组织通常会考虑直接影响并妥善处理，但忽视间接影响。这个间接影响可能导致你的变更失败，因此要仔细考虑后果。

处理间接影响可能会很棘手，因为你可能在问题变得严重之前并不知道它的存在，而你需要在问题发生后再去修复它。尽早识别此类影响对整体成功至关重要。

间接影响的一些例子可能如下：

• 员工健康

• 影子 IT

• 过程依赖

让我们更详细地看一下这三个原因，以便更好地理解它们。

员工健康

我们简要讨论了心理健康与工作生活平衡之间的关系，但这远不止于此。这关乎员工的整体健康。工作条件、环境等因素的突变可能对员工健康产生不利影响。

仔细考虑你所做变更对员工健康的影响。可能并不会产生影响，但考虑这一点仍然很重要。员工也会感激你考虑过并讨论过这一点。

影子 IT

我们都知道并经历过影子 IT。就是不同的团队在没有中央 IT 团队控制的情况下，自己提供服务并运行自己的工具。对此要格外小心。

企业关键服务由影子 IT 负责并不罕见，且变更可能导致该服务的稳定性问题，因为团队的职责被打乱。

管理 Shadow IT 而不干扰组织中的创新是一项微妙的平衡。关于如何管理这一点，可以参考这篇来自TechRepublic的文章 (www.techrepublic.com/article/5-tips-for-managing-shadow-it-without-destroying-innovation)，该文章介绍了如何管理 Shadow IT。

Shadow IT 对你组织中的人员有着巨大的影响。Shadow IT 通常指的是未被追踪和记录的工作，因此这些工作往往是与人们日常职责并行进行的。

流程依赖关系

即使你走上了创建价值流图或在组织内运行流程图的道路，你也可能会忽略流程之间的依赖关系。如果这些依赖关系是人工交接的，你就会错过它们。

因此，在创建价值流或流程图时，重要的是与合适的人交谈。进行多次检查，以确保你捕捉到所有的人工交接，从而减少遗漏流程依赖关系的风险。

这里的风险是，如果你错过了某个依赖关系，当你改变主流程时，可能会破坏下游的其他环节。这样会对下游的人员产生不利影响：可能会增加他们的工作负担，或者会给他们施加不必要的压力，让他们去解决一个可能无法修复的问题，因为你已经改变了某些内容。

现在让我们看看组织内流程变革的一些常见挑战。

流程变革中的常见挑战

实施变更管理框架，例如我们之前在商业变革模型中讨论过的框架，伴随而来的是一系列挑战，有时这些挑战可能相当复杂。

这里列出了一些常见的、阻碍流程变革的挑战：

• 组织抗拒

• 缺乏明确的目标

• 战略对齐差

• 从工具开始

• 低估变革框架的必要性

• 多米诺效应

让我们更详细地看看这些内容，以便了解它们的影响。我们不会讨论组织抗拒，因为我们之前已经讨论过这个话题。

缺乏明确的目标

目标至关重要。你必须有明确的目标，这样你才能知道如何衡量成功，并知道自己所朝的方向。当你没有设定目标时，很难知道自己正在朝哪个方向走，可能会很快迷失方向。

当你建立了明确且定义清晰的目标时，每个人都会知道自己该朝哪个方向前进；每个人都知道成功的标准是什么。

战略对齐差

战略对齐，或者缺乏战略对齐，往往会导致变革管理的失败。你必须与所有相关方获得明确的战略对齐。如果没有清晰的战略对齐，转型项目将会失败。

实现强大战略对齐的一种方法是遵循以下步骤：

1. 从高层开始——目标设定必须从高管团队开始。

2. 创建目标层级。

3. 推动一致性和问责制。

4. 鼓励持续沟通。

这意味着什么？战略对齐确保流程变更与业务目标一致。当两者不匹配时，后续会出现问题。当你们达成一致时，变革过程会更加顺利。

从工具开始

我坚信，当你从与 DevOps 相关的任何工具开始时，你注定会失败。你必须首先考虑文化、人员和流程。

在你还没有理解问题时就实施工具，注定会带来灾难。涉及工具和流程，特别是自动化时，你是在加速运行糟糕的流程。首先要解决流程问题，再去实施工具。

企业架构的良好对齐和战略也很重要。随着工具的种类繁多，很容易迷失方向，部署那些看似能解决问题的工具。不久后，你的环境中可能会充满各种工具。企业架构旨在实施标准和流程，并为新软件对齐标准化的需求集。

这些要求在实施新工具时对你的组织至关重要。

低估变革框架的必要性

一般来说，当组织忽视变革举措对员工的影响时，障碍就会出现，期望的结果也无法实现。在流程管理方面，许多组织的员工参与度有限。那些不了解、关心，甚至不同意这些流程的员工，其承诺度也是有限的。员工的参与度可以建立员工的支持，并克服公司内部的抵抗。

多米诺效应

报告称其流程管理工作没有预先设定目标的组织，可能会面临进一步的挑战，例如缺乏战略对齐、沟通不足和缺乏 IT 工具。这些挑战会导致管理变革过程中出现一系列问题，包括组织抵抗和变革管理的需求。

总结

在本章中，我们探讨了如何在组织内有效实施变革。作为其中的一部分，我们研究了八个简单步骤，帮助实现这一目标，以及四个在组织中用于有效推动变革的变革模型。我们还分析了流程变更对组织内部人员的直接和间接影响。最后，我们讨论了在组织中实施变革时可能遇到的常见挑战。

接下来，我们将讨论如何持续改进流程——当你已经经历过改进过程后，如何进一步提升你的流程？我们将探讨一些持续改进的技巧，如何迭代流程的变更，以及如何跟上变革的步伐。

问题

现在让我们回顾一下在本章中学到的一些内容：

1. 哪种模型有助于定义时间线而非实施框架？

   a. 罗杰斯的技术采纳曲线

   b. ADKAR 模型

   c. 科特尔变革管理模型

   d. EASIER 模型

2. 有效变革中通常最重要的步骤是什么？

   a. 确定需要改进的内容

   b. 改进

   c. 沟通

   d. 庆祝成功

第九章：流程的持续改进

连续反馈和改进是 DevOps 的关键要素。保持学习和对 DevOps 各个方面提供反馈以进一步改进您所做的事情，并为业务提供更多价值，这是 DevOps 的基本支柱。本章探讨了连续反馈的技术，如何迭代过程变更以及确保每个人都跟上变化。

在本章中，我们将涵盖以下主要主题：

• 什么是连续改进和反馈？

• 连续改进和反馈技术

• 迭代流程变更

• 跟上变化的步伐

什么是连续改进和反馈？

连续改进是持续努力改善服务、产品或流程的过程。这个过程可以在一段时间内迭代进行，也可以一次性完成。如何进行这一过程取决于我们希望做出的变化程度。

连续反馈有许多不同的用途，包括向员工提供关于其表现的反馈。您还可以在产品开发中使用连续反馈，以获得关于产品表现的宝贵见解。在产品世界和 DevOps 中，讨论员工表现的优势和劣势的系统方式同样适用。

现在让我们更详细地看看连续改进。

建立连续改进的文化

DevOps 的概念主要围绕“连续一切”构建。DevOps 中的许多术语都包含“连续”，比如持续集成和持续部署等。连续一切是一个很高的目标水平，而像持续集成、测试和部署这样的工作则旨在消除软件交付流程和工具中的瓶颈。

然而，连续改进关注的是 DevOps 系统和流程中的瓶颈移除。创建连续改进文化并非仅限于技术或 DevOps。

建立成功的连续改进文化关键在于确保在每个领导层面灌输这些原则。随着时间的推移，您应该宣传您的成功；您必须抵制惯性和对改变流程和例行程序的抵制，即使是不好的流程也是如此。

现在让我们更详细地看看连续反馈。许多行业已经在连续改进方面有了成熟的实践和方法论。我们可以从制造业中汲取很多经验，精益生产中就诞生了连续改进，也称为Kaizen。让我们更详细地讨论一下这个。

理解和实施改善的“Kaizen”原则

Kaizen 诞生于 30 多年前，得益于 Kaizen 研究所创始人今井正明（Masaaki Imai），今天，Kaizen 被认为是竞争优势的关键支柱。

Kaizen 建立在五个原则上：

• 了解你的客户 – 确定他们的兴趣，以便你能改善他们的体验。

• 让它流动 – 你组织中的每个人都应该努力增加价值，同时减少浪费。

• 去现场 – 价值在实际发生的地方创造。

• 赋能团队 – 性能和改进应该是可触及和可见的。

• 保持透明 – 为你的团队设定相同的目标，并提供达成这些目标的系统和工具。

Kaizen 最著名的实施之一是丰田生产系统，简称TPS（en.wikipedia.org/wiki/Toyota_Production_System）。期望是，当检测到异常时，所有生产人员应立即停止手头工作，提出改进建议以解决问题。这样可能会触发 Kaizen。

Kaizen 的循环，通常被称为 blitz、burst 或事件，基于PDCA，也就是戴明循环，定义了四个步骤：

1. 计划

2. 执行

3. 检查

4. 行动

这一概念的核心是识别系统中的任何浪费并迅速消除它。在第七章《在组织中推动流程变革》中，关于通过价值流图推动流程变革的部分，我们讨论的符号之一就是 Kaizen burst 的启动。如果你回顾那一章，并且思考我们在这里讨论的内容，你会发现两者之间的联系。

价值流图用于描绘和识别活动及浪费，接着 Kaizen burst 被用来消除这些浪费。正是这种 burst，即为了解决浪费并实施新流程而进行的活动。

另一个常见的持续改进模型是六西格玛（en.wikipedia.org/wiki/Six_Sigma）。Kaizen 和六西格玛是你在 DevOps 中常见的两个模型，用于持续改进流程。

主要区别在于，Kaizen 通过建立标准化的工作方式、提高效率并消除业务浪费，力求整体改善业务。

六西格玛更关注输出质量（最终产品）。这通过识别并消除缺陷源实现。

精益（Lean）专注于消除浪费，通过减少流程中的浪费来提高流程速度和质量。

现在让我们来看一下如何在你的组织中建立持续反馈的文化。

构建持续反馈文化

延续我们在 DevOps 中关于“持续一切”的主题，如果持续改进是用来改善你的流程和系统的方法论，那么持续反馈则是突显这种变革机会的机制。

像持续改进一样，持续反馈并不是 DevOps 独有的概念或模型，它也从员工管理领域汲取灵感。持续反馈可以被认为是非正式的，但确实存在一些工具和流程来定义反馈的收集、处理，甚至采取行动的方式：

• 清晰传达愿景和目标

• 理解持续反馈的目的

• 提供分享反馈的渠道和工具

• 确保对所给与接收的反馈负责

• 教育团队理解持续反馈的重要性

现在让我们更详细地看看持续反馈文化中的五个关键要素。

清晰传达愿景和目标

如果没有清晰传达组织的愿景和目标，团队很难提供关于如何改进的反馈。当你的团队清楚地理解了愿景和目标时，他们就能轻松提供有价值的反馈，指出需要改变的地方。

当你理解了愿景和目标的背景后，反馈能够让团队直接思考哪些过程、系统和工具需要改变，以便组织有更大的机会实现其目标。

理解持续反馈的目的

提供有效的反馈不仅仅是说“做得好”或“你执行得不够好”。好的反馈应该提供具体的例子，并进行详细的解释。反馈应该尽可能具描述性，并且尽量做到实时。

反馈有助于管理绩效。这无论是针对个人，还是像产品或服务这样的资产都适用。反馈有助于识别需要改进和加强的领域，通过反馈，能够分别使这些领域变得更好或更强。

提示

持续反馈不仅仅应该来自领导者，它应该来自每个人，并且无论来源如何，都应当被平等对待。

从团队的角度来看，这也为他们提供了一种以建设性的方式表达意见和关注点的途径，尤其是在你开始进行 DevOps 转型时。这是一个有效的方式来吸引每个人的参与。

提供分享反馈的渠道和工具

提供多个反馈渠道非常重要。每个人都喜欢以不同的方式参与，你会发现有些人使用一个渠道，而其他人使用另一个。

个人反馈会议和小组反馈会议能提供很好的平衡，你会发现从这两种会议中都能获得宝贵的反馈。小组反馈会议的一个好处是，你会发现一个人的反馈可能激发其他人给出相似的反馈或对反馈进行验证。这可能是一个强有力的练习。

不要低估匿名反馈的力量。虽然将每条好的反馈都归因于个人是很好的做法，但即使在文化成熟的环境中，事实是人们有时希望匿名提供反馈。对此没有问题，匿名反馈应该受到欢迎，并以同样的方式付诸行动。

确保对所提供和所接收的反馈负责

无论你的反馈是匿名的还是非匿名的，关键是要有人对该反馈负责，无论你是提供反馈还是接收反馈。你需要对这个反馈负责。每个人都需要致力于持续反馈的文化。

为了改变文化，反馈的持续性是必不可少的。它有助于推动横向和纵向的问责制与透明度。确保反馈是公开的。你采取的行动，以及在可能的情况下，决定采取哪些适当行动的决策，都应该是公开的。

教育团队理解持续反馈的重要性

你不能做的或者不能期待的是，实施持续反馈系统并让团队和员工在一夜之间就能理解它。培训和沟通在这里非常重要，因为两者结合可以帮助你突出为什么要实施这个方案，它的好处是什么，以及它是如何运作的。

向员工强调正面反馈和负面反馈是平等的。无论是员工表现、产品表现还是服务表现，正面和负面反馈都能帮助你提升。

现在我们了解了什么是持续反馈和持续改进。接下来，让我们看看我们可以采用哪些技术来在组织内实施这些措施。

持续改进和反馈的技术

当我们在本章开始时讨论什么是持续改进和反馈？时，我们简要提到了 Kaizen（改善）和快速提及了六西格玛（Six Sigma），这两者都是你可以用来迈向持续改进的工作方法。那么，在你达到这一阶段之前呢？

现在让我们来看一下你可以用来进行持续改进的技术。

持续改进流程

如我们在上一节中讨论的，PDSA 循环代表计划（Plan）、执行（Do）、研究（Study）和行动（Act）。这一模型背后是一个六步流程，它是一种利用数据进行规划、排序和改进工作的系统性方法，也是 PDSA 模型的扩展。

使用的六个步骤如下：

1. 识别机会

2. 分析根本原因

3. 采取行动

4. 研究结果

5. 标准化解决方案

6. 为未来做规划

这些独立的步骤是顺序进行的，并且是持续改进过程的重要组成部分。你的持续改进计划应始终与组织的愿景、目标和优先事项相连接。

让我们更详细地看一下这六个步骤。

识别机会

你可以通过几种不同方式识别流程改进的机会。一个机会可能来自持续反馈，在其中某个问题被突出显示，而这个问题的结果就是改进的机会。

这也可以来自团队成员对该过程的个人反馈，或者在一些较不成熟的环境中，虽然持续反馈循环尚未完全建立，但运营问题或投诉已经触发了这一审查。

分析根本原因

在你开始修复问题之前，你需要了解问题的本质。确保你找出问题的根本原因。记住，有时候问题是由于一连串事件引起的，因此不要止步于你发现的第一个问题，要继续向后追溯，找到可能引发一系列反应的最早问题。

但分析并不仅仅止步于此。当你知道根本原因是什么时，要验证这些发现，并查看你可以做些什么来证明这确实是根本原因。根据流程的不同，当然也取决于输入，你甚至可能能够重现这些结果。

采取行动

当你准备采取行动时，这是一个两步走的过程。首先，你需要能够规划出纠正根本原因的行动。记住，解决问题可能需要多个行动。

第二步是实施那些已规划的行动。实施这个计划需要采取若干行动。在这里，沟通你的计划至关重要。确保有合适的人选也非常重要，他们能够帮助使变更成功。

研究结果

确认你所采取和实施的行动也同样重要。你需要监控与所更改的过程相关的指标，以及任何相关的输出和工具，以确保你的变更已成功实施且没有产生不良影响。

通过规划提前做好准备，确保在变更失败时有回退的路线，并在必要时做出小的渐进性调整，以确保变更成功。

标准化解决方案

通过定期监控，你可以查看你所看到的结果是否一致且已建立。在这一点上，你必须确保提升后的性能水平能够持续维持。

有时你需要做进一步的改动，以确保这种标准化方法能够在整个组织内落地。你应该确保也为这些事情做好规划。

为未来做规划

当你完成实施后，稍微后退一步，进行一次简单的回顾。与团队一起识别哪些方面做得好。这是一种持续反馈的形式，你从中学到的经验可以在下次进行过程变更时应用。

任何由于变更带来的残留问题也需要在此进行记录和规划。

现在我们已经看过了持续改进的六个步骤，接下来我们来看一下你可以在组织中使用的其他持续改进技术。

额外的连续改进技巧

我们刚刚介绍了一个连续改进流程的例子，你可以在你的组织中使用它来帮助开始。当然，还有许多其他框架和技巧。让我们来看看其中的一些。

每日会议

几乎所有组织都会实践的最常见敏捷实践之一是每日会议，有时也被称为每日站立会议。你的每日会议可以成为识别改进机会的灵感来源。

让整个团队参与简短的电话会议，讨论阻碍因素，将为大家提供机会，提出可以解决这些阻碍因素的办法，这甚至可能是一个改善爆发（Kaizen burst）来解决瓶颈问题。

接球法

这是一种精益技巧，涉及将想法从一个人或一个团队传递到另一个人或团队以获取反馈。严格来说，这也可以视为一种持续反馈技巧。

这种方法意味着组织中不同层级的人可以提供反馈并为该想法的发展做出贡献。它也可以是任何东西——在 DevOps 中，这通常是一个产品或服务。

现地走访

你可能没有听说过“现地走访”，但你很可能见过这种做法。该实践包括领导者四处走访、提问，并与现场执行工作的人员一起识别改进机会。

在这个阶段，发现的改进尚未实施。只有在分析完成后，才会进行实施。

现在我们已经看过了一些你可以在组织中使用的其他连续改进技巧，接下来我们将详细探讨连续反馈过程。

连续反馈过程

用最简单的话来说，连续反馈或持续反馈循环可以简化为四个简单的步骤。这四个步骤如下：

1. 评估

2. 修改

3. 计划

4. 实施

上述四个步骤与你之前所讨论的连续改进过程有着非常密切的关系。你可以将这两个过程结合在一起。

上述概述的连续反馈过程确保你有适当的流程来捕捉反馈，评估这些反馈的含义，规划如何执行这些反馈，然后实施这个计划。这就是连续改进的作用所在。

现在，让我们来看一下在你的组织中可以使用的其他连续反馈技巧。

额外的持续反馈技巧

大多数连续反馈技巧来自员工绩效管理领域和人力资源领域。不过，你可以将其中的一些技巧应用于产品和服务反馈。

让我们来看看其中的一些。

EDGE 框架

Zoomly 的创始人Dawn Sillett（https://www.zoomly.co.uk/people）概述了EDGE反馈框架。它是解释、描述、提供和积极结束的首字母缩写，这为反馈提供了一个清晰的结构，旨在提高清晰度，并提供可操作的结果。

框架的每个组件都旨在以持续的方式提高性能。

360 度反馈

你在过去的工作中一定遇到过 360 度反馈。这是从多个来源收集反馈，以建立更全面的绩效图景。从人类角度来看，这些反馈来自领导者、经理、同事和同行。

在 DevOps 世界中，这可以来自不同的产品经理、工程师、安全团队、客户和其他来源。想想你是否希望你的 360 度反馈是匿名的。这在质量上是一个重要因素。

跨团队反馈非常好，但请记住，并不是所有团队都有相同的文化。如果没有提供匿名反馈的机制，有些人可能不会像他们可以那样诚实。

反馈比例

不同的研究表明，正面反馈与负面反馈的比例应在 3:1 到 5:1 之间。当然，这是在人与人之间进行工作时，但对于流程、产品或服务的反馈也是类似的。

无论你使用哪种比例，确保正面反馈占比大于负面反馈。强调正面反馈有助于创造一种改进和提升绩效的文化。

现在我们已经了解了在业务中可用的持续反馈技术，接下来让我们看看如何对流程进行迭代改进。

流程的迭代更改

就像在应用代码中一样，改变流程时采用迭代方法也非常重要。对于应用代码，我们采用这种方法是为了在出现问题时，能够轻松地知道哪些更改已被做出，谁做的更改，为什么要做这些更改。这提供了对发生事件的完整可追溯性。

在对流程进行迭代更改时，我们需要相同级别的可追溯性和透明度。这样，如果在任何时候我们需要查看发生了什么以及为什么，我们就能轻松地识别相关信息。其次，在继续下一个变更之前，我们可以看到一个变更的影响。

这一点实际上适用于所有类型的变化，从技术流程到业务流程。最大的影响并不是来自于对这些流程的单个变化，而是来自于大规模的变革计划，这些计划涉及对同一组流程或同一流程的多个变化。

当我们在迭代中工作时，或者像我们在敏捷方法中常常称之为的冲刺，结果是清晰的、有影响力的，并且在多个领域都有广泛的应用。事实上，迭代设计通常被作为一种设计方法学广泛应用于产品的原型设计、测试、分析和改进。为什么不把它也应用到流程设计中呢？

迭代设计流程

在设计新流程时，就像产品设计一样，请记住在开发周期的最早阶段进行更改更加容易且成本更低。

在迭代设计中，第一步是创建一个原型。您也可以对流程采取同样的方式。利用您拥有的所有需求和可用工具，制定一个流程原型，并通过场景来工作，记录结果，这是您的流程运行如何的宝贵反馈。

聚焦小组在迭代设计过程中也被使用。就像获取 360 度反馈或者某些凯泽元素一样，它们旨在从特定群体中获取关于具体问题的反馈。

迭代设计通常是一个持续的过程。本章我们讨论的技术已经教会我们这个持续过程的要素。

使用迭代设计

迭代设计是面对不可预测的用户需求和行为现实的一种方式，这可能导致设计上的重大变化。用户测试通常显示，即使是经过仔细评估的想法也是不够的。因此，迭代设计方法的灵活性尽可能地延伸到系统中非常重要。设计师还必须意识到，用户测试结果可能导致需要放弃旧想法，转而采用更用户友好的新想法。

迭代设计的好处

当正确应用时，迭代设计是确保采用最佳解决方案的一种方式。当迭代设计方法在开发周期的早期应用时，也可能实现显著的成本节约。

还有一些其他关键好处包括以下内容：

• 在流程早期就能看出误解

• 它鼓励用户反馈

• 开发聚焦于项目中最关键的问题

• 设计与需求之间的不一致性可以早期检测出来

我们在本节中探讨了一些持续改进和反馈的技术。接下来，我们将看看如何在您的组织中跟上变化的步伐。

跟上变化的步伐

除了个人日常角色外，在他们领域的技术变化以及他们当前冲刺中的所有工作和未来工作的思考，可能会很难跟上。因此，在这些变更之上添加流程变更会使情况变得非常困难。

你需要能够在组织内管理变革步伐，特别是在处理流程变更时。当然，流程变更非常重要——这是组织进步的方式，但人们可能最快忘记的也许就是这些变更。

流程变更通常失败是因为这些变更没有在组织中生根。在大多数组织中有大量竞争性优先事项和大量信息需要掌握，很多人遗憾地首先忘记流程信息。

以下方法可以帮助你简化这一过程，让员工更容易理解，并使流程变更得以落实：

• 有效沟通

• 知识传递

• 访问领域专家

现在我们来更详细地看看这三个方面。

有效沟通

拥有有效的沟通方法是确保组织内流程变更得以落地的一部分。

工作小组

作为实施流程变更的工作小组，你可以在整个流程中设立会议，确保你所做的变更是简明扼要的，并且频繁地进行沟通。

在工作负载较大的情况下，人们更倾向于接受较小的信息块。考虑设立面对面和虚拟的工作小组，以最大化参与人数。

协作工具

微软 Teams 或 Slack 等协作工具对于将重要话题的沟通集中在一起非常有效。你可以使用频道或小组的概念来创建一个流程小组，让每个人定期查看并发布更广泛的公告。

这种方法的一个好处是，你分享的沟通信息和内容可以供人们回顾。参加会议的缺点是，人们并不总是做笔记。协作工具可以解决这个问题，通过确保你拥有可查看的历史信息。

全员邮件

根据经验，面向全员的大范围通用邮件效果不佳。这类沟通缺乏足够的个性化，无法吸引人们并促使他们认真查看内容。

如果你采取这种方法，考虑一些方法使其更加针对性，而非泛泛的沟通，从而保持人们的参与感。

知识传递

知识传递非常重要。我们刚才讨论了使用协作工具。利用它们帮助知识传递，并将文档集中存储，以确保所有流程文档和流程图只有一个权威版本。

每个人接受信息的方式不同，重要的是你要考虑到这些情况，但要确保最重要的是这些知识被集中存储。Wiki 是一个非常好的工具，可以帮助实现这一点，并且它们是开放的，适用于所有人编辑。

访问领域专家

拥有适当的文档、沟通方法和知识传递方式当然很重要，正如我们刚才所讨论的。然而，你可以做的最简单的事情之一就是确保你的领域专家有时间与需要帮助的人一起工作。

我曾经实施过一种有效的常见方法，那就是让领域专家与受影响的团队坐在一起，这样如果他们有问题，可以直接提问——无需提交正式工单并等待邮件回复。

这一过程的额外好处是，它能增加组织内部人员之间的合作，随着更多人共同工作，长期来看，这将带来更多的益处。它有助于建立开放的文化，进而建立信任。

总结

在本章中，我们讨论了持续改进和持续反馈的主题。我们了解了 Kaizen 原则以及如何在组织中建立有效的持续改进和反馈文化。我们还讨论了如何通过迭代设计过程来逐步改进流程，以及如何跟上组织内变化的步伐。

本章所学的技能将帮助你和你的团队在 DevOps 之旅中不断改进，不仅仅是在最初的转型阶段，而是如我们所讨论的，在你们组织内部 DevOps 持续发展的过程中。

在下一章中，我们将研究 DevOps 的技术栈。我们将了解 DevOps 工具的各个类别，理解工具在 DevOps 中的作用，以及 DevOps 工具的优缺点。

问题

现在让我们回顾一下本章中所学的内容：

1. 持续改进和反馈有何不同？

   a. 持续反馈是关于收集而不是采取行动

   b. 持续改进就是根据反馈采取行动

   c. 模型是相同的

   d. 模型完全不同

2. 哪种设计过程与流程变更高度契合？

   a. 单元测试

   b. 迭代设计

   c. 持续部署

   d. 持续集成

第四部分：实施和部署 DevOps 工具

工具为你迄今为止取得的成果增添了价值，但确保以战略性方式实施并理解其中的步骤非常重要。

本书的这一部分包含以下章节：

• 第九章，理解 DevOps 的技术栈

• 第十章，制定工具实施策略

• 第十一章，跟上关键的 DevOps 趋势

• 第十二章，在真实世界组织中实施 DevOps

第十章：理解 DevOps 的技术栈

将工具加入到你的 DevOps 投资中是确保你的采纳从好变得更好的关键。如今市面上有许多 DevOps 工具。理解今天和明天应实施哪些工具集可能是一个挑战。在本章中，我们将探讨 DevOps 中主要工具的优缺点。

到本章结束时，你可以期待理解不同的 DevOps 工具家族，并了解工具如何在 DevOps 中发挥作用。你还将理解 DevOps 工具的好处和障碍。

在本章中，我们将讨论以下主要内容：

• DevOps 工具的家族有哪些？

• 工具如何帮助推动 DevOps 的采纳？

• 理解 DevOps 工具的好处

• 理解 DevOps 工具的障碍

DevOps 工具的家族有哪些？

我们所说的 DevOps 生态系统有许多不同的类别，工具被划分到这些类别中。一些工具是为了非常特定的目的设计、开发和营销的。也有一些行业特定的工具解决了独特的问题。

当然，你还会遇到一些工具，虽然它们特定于某一类别，但也适用于许多行业，有些工具是提供跨整个生态系统服务的工具套件。

我们可以使用一个传统的图表来描述 DevOps 循环，以讨论不同的类别。我喜欢使用以下这些类别，它们与传统图表中的类别非常接近，但有一些细微的差异：

• 协作

• 构建

• 测试

• 部署

• 运行

你可以在下面的图表中看到这一点的可视化表示：

图 9.1 – 工具链阶段的可视化表示

让我们更详细地看一下这些，了解哪些类型的工具属于生态系统中的每个部分。

协作

我将协作加入到这个列表中，这个内容实际上在大多数传统列表中找不到，因为协作在 DevOps 中的重要性。所以到目前为止，我们已经从文化视角以及人员和流程的角度看过协作，但工具在协作中也非常重要。

你可以在组织内部围绕协作建立出色的流程、人员和文化，但最终，如果没有合适的工具，你仍然无法走得很远，规模化也会成为一个真正的问题。

当你想到协作时，很容易想到 Zoom、Microsoft Teams、Skype 等大型平台，但工具集远比这要广泛。协作也涉及到知识共享。

像 Read the Docs、GitHub Pages 和 Apiary 这样的工具都是文档工具；它们也被归类为协作工具。

知识共享在任何组织中都很重要，尤其是在那些高度协作并朝着 DevOps 实践努力的团队中，知识尤为重要。关于你产品的每一条知识都应该被记录下来并集中存储，以便在任何人需要时能够找到。

提示

可以将知识管理视为避免知识孤岛的一种方式。没有这些孤岛的情况下，你能够更好地扩展，并确保每个人都有平等的机会学习新技能，并了解更多关于产品的信息。

知识还包括文档。在我看来，如果没有相关的文档，不能认为某个工作已完成。这些文档可以是面向公众的，也可以仅供内部团队使用。不管哪种方式，文档都非常重要。

构建

构建工具使你能够将你开发的内容转化为可以在其他地方部署的成果。这从源代码控制工具开始。目前最常见的工具是Git。它有多种版本，其中最流行的是 GitHub，尽管 Git 技术也存在于其他不同的源代码控制产品中。

工具还支持持续集成。这一实践涉及将你的工件从源代码控制库提取，并通过一个叫做管道的自动化工作流进行处理。在管道中，许多任务会被完成，管道的结果是一个具体的工件，之后你可以将其部署到其他地方。

构建工具不仅与软件相关，你还可以使用一些工具来构建基础设施，这就是所谓的“基础设施即代码”。如果你使用的是容器，也会找到一些帮助你构建它们的工具。

如果你的应用程序涉及使用数据库，你还会找到数据库工具，帮助你管理数据库的架构和结构。

测试

测试是 DevOps 工具中最广泛的术语之一。在这里，你可以找到用于执行各种测试要求的工具。测试过程可以包括从开发者进行代码单元测试到用户验收测试，再到自动化浏览器测试的工具，这些都可以用于 Web 应用程序。

此外，测试还可以包括针对 OWASP Top 10 基准的安全扫描、静态和动态代码分析以发现漏洞，以及负载测试，以确保你的应用程序在负载下表现良好。

部署

部署的过程是将你构建和测试过的应用程序工件部署到需要去的地方。这可能是一个云平台，如 Microsoft Azure、Amazon Web Services 或 Google Cloud，也可能是一个移动应用商店，甚至是一个本地数据中心。

如果你将应用部署到云平台或应用商店，那么你很可能会使用本地工具来部署到这些环境。这些工具可能仅仅会将部署执行到这些特定的环境，而不会做其他操作。

如果你正在为其他开发人员编写可共享的应用程序库并部署到包管理库，你也可能会使用支持这种场景的工具。

如果你正在使用容器，那么你也很可能在使用制品管理工具；这些工具也属于部署范畴。此时，可以访问让你将容器指向公共或私有容器注册表的工具。

最后，即便你正在配置和部署虚拟机或其他类型的传统基础设施，你可能也会使用负责基线配置管理或基础设施配置的工具。这些工具在管理企业级基础设施时能够节省大量时间。

运行

一旦你部署了应用程序，就进入了所谓的运行阶段。在这一阶段，运营团队使用工具来管理应用程序。开发人员可能在此阶段也会使用一些工具来帮助监控应用程序性能和捕获异常。

运行阶段中的一些工具可能是你所使用平台中本地内建的；也有可能是额外的产品和工具。例如，你可能会使用云平台中的本地监控功能，然后使用应用性能监控工具来同时监控基础设施性能和应用程序性能。

根据经验，这是许多组织在工具使用上存在不足的一个领域；然而，正确的运行工具对于确保你拥有关于基础设施和应用程序性能的正确技术反馈至关重要，这样你才能做出基于数据的决策。

现在我们了解了 DevOps 工具链中不同类型的工具家庭，接下来让我们看看工具如何帮助 DevOps 的采纳。

工具如何帮助 DevOps 的采纳？

DevOps 利用其与敏捷开发的关系，进而创造一种促进协作和价值流的文化。这是通过将精益、约束理论和丰田生产系统等经过验证的原则与实践与敏捷开发结合实现的。

为了实现这一目标，DevOps 要求组织在团队内采纳文化变革，并采纳诸如自动化、版本控制和持续集成与交付等技术原则。与制造业类似，正确工具的整合对于充分实现 DevOps 内部技术实践的好处至关重要。

但是，有一点需要提醒：DevOps 不仅仅是使用工具——它是关于我们迄今为止学到的所有知识的结合，以及与工具的互动，从而充分实现 DevOps 的好处。

这里有一套可以帮助选择适合你组织工具的指导原则：

• 选择促进协作的工具。

• 使用能增强沟通的工具。

• 偏向有 API 的工具。

• 始终鼓励学习。

• 避免使用环境特定的工具。

现在让我们更详细地看一下这些指导原则，帮助更好地理解如何应用它们。

选择能促进协作的工具。

团队之间能够有效协作对于 DevOps 的成功至关重要。虽然有很多专门用于协作的工具，可能让你认为应该为此购买一个专用工具，但在 DevOps 工具链中，你可以使用许多不同的工具来增强团队之间的协作。

一个很好的例子是版本控制，它实际上是 DevOps 方法中的关键元素。当你在组织中鼓励更多人使用版本控制工具时，要考虑你的工具选择的影响。你和你信任的基础团队成员可能习惯了仅使用命令行工具，但其他人呢？对于那些更习惯使用用户界面的人来说，使用仅支持命令行的工具可能会成为一种障碍。

重要提示

在这个例子中，命令行工具用于版本控制，虽然是 DevOps 工具链的一部分，但对人们来说，尤其是非开发人员来说，它是陌生的。

在这种情况下，命令行工具的受众有限，因此协作机会非常少。然而，如果你采用像 GitLab、GitHub、BitBucket 或 Azure DevOps 这样的版本控制平台，你就可以利用关于文件更改和提交的讨论；这也是一种协作形式。

这有助于与拥有不同技能的人进行协作，并鼓励更多人学习如何根据自己的需求使用平台，从而促进协作。

我们在这里讨论的方法同样适用于工具链中的其他部分，而不仅仅是版本控制。它不仅仅影响新的工具；这也可以应用于你组织中现有的工具。

考虑权限对协作的影响。多次我曾与运维团队合作，他们拒绝向开发人员提供他们认为是自己工具的访问权限，认为其他人不应该有访问权限。如果你想提高协作，就应该向开发人员开放这些工具——结果会是两个团队之间的更好协作。工具本身没有改变，但权限改变了。

使用能增强沟通的工具。

根据我的经验，使用 DevOps 方法构建现代软件平台的组织中，最常见也是最大的问题之一，是团队职责与其工具之间的不匹配。

有时，组织会使用多个工具来完成一项任务，而实际上一个工具就足够了。反之亦然：有时组织只有一个工具，但当团队需要使用独立工具时，反而会产生问题。

团队间互动和沟通效果的最大影响因素之一，就是共享工具的使用。共享工具有助于团队之间的协作，但如果你需要明确责任边界，使用不同的工具可能是最好的选择。在第二章《业务效益、团队拓扑和 DevOps 的陷阱》中，我们讨论了业务效益、团队拓扑结构和 DevOps 的陷阱。可以利用此章节来帮助你了解哪种模型适合你的组织。

如果你希望开发与运营团队之间建立紧密的合作关系，那么使用独立的工单系统只会导致这两个团队之间的沟通不畅。为了帮助这两个团队更加高效，你应该选择一个能满足这两个团队需求的工具。

提示

在考虑选择工具时，首先要考虑团队关系，然后再为整个组织选择工具。

关键是要确保你查看整个组织，部署共享工具以便团队协作，并且在需要时，不要害怕使用独立的工具。

倾向选择具有 API 的工具

基于服务的架构和 API 驱动的应用程序是云原生或云就绪系统的基石。能够自定义且高度自动化的工具是一个重要的优势。具备全面功能的 API，尤其是基于 HTTP 的 API，是必须具备的。

从 DevOps 角度来看，使用 API 可以将你正在使用的多种工具连接在一起，作为你流程的一部分。符合这些标准的工具非常重要，因为当你需要将现有工具更换为新工具时，更换将一切连接在一起的“管道”会变得非常容易。

使用这种方法将工具链接在一起非常简单，但你需要小心这个过程中未记录的脚本。驱动软件交付和运营过程的工具应该像生产工具一样对待，这意味着要具备正确的文档编写和发布这些工具的能力。

在成熟度较低的组织中，常常犯下没有提供必要的操作支持就实施新工具的错误，导致这些工具无法发挥作用并有效地运作。

总结来说，你应该通过结合多个 API 驱动的工具来获得新能力。

始终鼓励学习

当你查看 DevOps 工具链中的工具时，你会发现其中一些相当复杂，尤其是在新人使用这些工具时。工具越复杂，你不应期待每个人都能迅速采用它们。

也可能发生相反的情况，当一个工具复杂且难以使用时，人们可能会固守己见，不愿使用它。这就是为什么你需要考虑为人们提供新的工具培训机会的原因。

引入新工具需要你评估组织内的广泛技能，然后为团队制定一条通往更高效工作方式的路线图。给人们提供按自己节奏学习的机会至关重要，因此，考虑拥有多种界面的工具，例如用户界面、命令行和 API，可以让每个人都能学习。

采用 DevOps 的过程是从手动操作到自动化的过渡；不是每个人都会在同一时间处于相同的位置，所以给人们提供能力，尤其是学习的空间，将使你有更大的机会让人们成功采用新的工具和方法。

把这看作是一个逐步演化的过程：通过引入令人害怕的工具来避免恐惧，并让人们有机会按照自己的节奏学习。就像敏捷方法通过短周期迭代实现渐进式改进一样，也应该以同样的方式对待你的工具，偏好那些小幅度的进步，而非未来状态和大爆炸式的方法。

避免使用特定环境的工具

随着 DevOps 的采用，交付的速度和频率会增加。这意味着，要想取得成功，你需要增加交付和运营过程中的反馈循环。尽可能多的技术人员应该学习尽可能多的生产工作原理，以便反过来构建更可靠、更具韧性的产品。系统的变更也应在部署到生产环境之前进行测试。

任何仅在生产环境中运行的工具都会引发问题，因为这会阻止人们学习，因为生产环境被视为一个特殊案例，而不是你应用程序运行的另一个环境。

为了尽可能提高效率，你应该选择能够在所有环境中工作的工具；在某些情况下，这甚至包括开发人员的本地环境。要留心那些按环境收费的部署或安装工具，尽量寻找提供站点范围许可证的工具，以便在可能的情况下降低成本。

也要考虑 DevOps 的自动化方法；优秀的 DevOps 工具应该能够在每个环境中自动设置。避免使用那些需要手动部署的工具——这些工具在 DevOps 中不是好的选择。

当你在每个环境中使用相同的工具时，你实际上在增加团队之间的互动，并增加学习的机会。将工具限制在生产环境中会将人们排除在学习机会之外。

总结来说，涉及特定环境工具时，必须避免使用它们。这会破坏学习的反馈循环，并使得你的持续集成和交付变得困难。

现在我们了解了工具如何帮助你采用 DevOps 方法，让我们来看看 DevOps 工具的好处。

了解 DevOps 工具的好处

根据 Puppet 发布的 《DevOps 状态报告（2017）》 (puppet.com/blog/2017-state-devops-report-here)，“高效且准确地开发和交付软件是所有组织的关键差异化因素和价值驱动因素。” 尽管这份报告可能已经有几年历史，但其中的内容在我们谈论为什么实施 DevOps 时依然非常贴切。

报告发现，DevOps 组织在效率、满意度、质量以及组织目标实现方面，超过目标的可能性是其他组织的两倍以上。这些目标为成功的 DevOps 组织提供了重要的洞察力。那么它们是如何做到的呢？

以这些关键点为基准，整合正确的工具以成功应用 DevOps 技术实践，将使你实现以下好处：

• 增加代码和部署速度

• 缩短新产品和功能的上市时间

• 降低新版本发布的失败率

• 改进恢复平均时间

• 提高可靠性指标

• 提高协作与生产力

• 消除高水平的进行中工作和技术债务

我们已经通过本章前面的一些例子探讨了增强协作和生产力的好处；这些好处之间的一个共同主题是协作和沟通，但现在让我们用工具作为例子，更详细地看看这些好处。

提高代码和部署的速度

如果没有合适的工具，是无法准确衡量部署和代码速度的。你需要结合版本控制软件、任务管理工具和管道环境中的信息，才能获得关于这些数据的洞察。

拥有这些工具并能够准确报告速度是很重要的：它有助于你更好地进行团队规划，并理解你在一个迭代中能够完成多少工作。

从长期来看，理解这一点也有助于你做出关于何时增聘团队成员的决策，尤其是当你将这些信息与技术债务和进行中的工作相结合时。

缩短新产品和功能的上市时间

沟通和协作确实是这个过程的核心，尤其是在开始阶段。当你拥有能够促进团队间良好协作和沟通的好工具时，你可以更快地将你的创意从构想到生产。

再加上持续集成和部署工具的使用，一旦你的想法被开发并测试完成，它就可以在短时间内部署，经过各种测试周期。

仅这一点就成为许多组织，尤其是软件行业中的大企业，巨大的业务驱动因素。如果你能比竞争对手更快地将你的想法推向市场，这将给你带来竞争优势，最终让你的客户有更多理由选择你的产品而非他们的。

新发布版本故障率的降低

当你对管道进行投资，并使其能够一致地处理部署时，便需要关注反馈循环的必要性。在这种情况下，反馈循环是围绕提高构建和发布管道的质量展开的。

通过引入对管道的监控，并利用现有的 CI 和 CD 工具中内置的报告，你可以提取出显示管道执行成功的指标。

当故障发生时，将其视为一个学习机会，提取为什么会发生故障的信息，并找出你可以做些什么来提高质量，以确保问题不再发生。通过收集的信息，这个循环有助于降低发布的故障率，帮助你开发出更高质量的管道。

改进平均恢复时间

没有人喜欢应用程序停机，无论基础设施设计得多么优秀，应用程序开发得多么出色。你很可能在某个时刻会遇到停机问题。

单体环境或遗留工作环境通常对应用程序停机及其影响有着严苛的看法。今天，许多实践 DevOps 的组织不再仅仅关注服务水平协议（SLAs），而是转向衡量平均恢复时间（MTTR），即衡量从故障中恢复服务的平均时间。

在这个领域，站点可靠性工具至关重要，它能够帮助你尽可能多地获取有关停机的信息。这包括对你的基础设施和应用程序的 360 度监控，包括性能和异常；用户旅程；以及合成事务监控应用程序性能、可用性和安全性的方方面面。

重要提示

你还应该不要低估日志文件的重要性，虽然它们经常被忽视。

日志文件为你的故障排除能力提供了另一个维度。我经常看到开发人员和运维团队抓耳挠腮，因为他们没有适当的日志来诊断应用程序停机。

当你拥有所有这些信息，并且具备良好的沟通、协作和文档时，你更有可能尽快找出问题的根源。

测量应用程序端点的可用性同样让你能够衡量 MTTR。你可以测量从故障到恢复服务之间的时间。在每次故障之后，重要的是回顾收集到的信息，不仅要看看如何避免再次发生故障，还要思考如何进行流程或其他方面的变更，以减少下次恢复服务所需的时间。

可靠性指标的改进

紧随 MTTR 之后的是可靠性指标的改进。使用我们之前讨论过的许多相同原则，你还可以提高你应用程序各个方面的可靠性。

大多数站点可靠性和仪表工具都能够生成一个仪表板或评分卡，帮助你展示你的可靠性水平。如前所述，使用这些数据实际推进并提高可靠性是将组织在成熟度上区分开来的关键。

消除高水平的进行中任务和技术债务

在 DevOps 环境中，生产力的最大杀手之一是工作中的任务数量和某些组织中存在的高水平技术债务。我使用过的所有待办事项管理工具都可以让你通过仪表板或看板等方式标出每个团队成员的进行中的任务数量。

确保这里的工作量在可接受范围内。当然，什么是可接受的，通常因团队而异，当然也因个人、他们的技能以及他们能够完成的工作而异。

找到平衡点可能很难，但当人们有太多“进行中”项目时，生产力就会受到影响。我的经验告诉我，每个个体在进行中项目不超过三个时，保持高效。当数量超过这个点时，他们的生产力将开始下滑。

另一个生产力杀手是组织中的技术债务水平。技术债务，有时也叫设计债务，反映了应用程序中额外返工的成本。

例如，如果你今天用一种简单的方法设计了应用程序的某个部分，而不是采用更好的但更耗时的方法，那就是技术债务。我们通常会将技术债务加入待办事项中，稍后再回顾并解决。

为了了解你的技术债务水平，你需要一种可靠的方式来记录它。在一些工具中，你可以创建一个特定的待办事项模板来记录它，或者简单地为用户故事或缺陷添加标签——你可以决定如何记录它。

然后，你可以运行查询并将数据添加到仪表板中，以突出显示你的技术债务。当它达到你认为不可接受的水平时，你可以启动一个技术债务冲刺，旨在减少技术债务的数量。

在本节中，我们探讨了 DevOps 工具链中工具的好处，并看到不同的工具如何为我们的 DevOps 价值带来益处。接下来，我们将看看在成功部署工具时存在的一些障碍。

理解 DevOps 工具的障碍

到目前为止，我们已经讨论了 DevOps 工具链中工具的所有优点。那么，使用这么多不同工具带来的障碍是什么呢？以下是一些阻碍这些工具采用的障碍：

• DevOps 定义的缺乏

• 缺乏对工具的知识

• 工具评估

• 市场上工具的数量

• 工具集成的缺乏

现在让我们更详细地探讨这些问题，更好地理解采用工具时面临的障碍。

DevOps 结果定义的缺乏

不用多说，如果没有对 DevOps 的清晰定义以及它对你组织的意义，你将面临工具选型的困难。这会导致组织因竞争对手部署了工具或其他原始原因而部署工具。

拥有这些定义也能帮助你了解工具发展路线图可能是什么样子，并且如何使用我们在本章中讨论的所有建议，合理地弥补现有的工具空缺。

不仅你的组织需要对 DevOps 有明确的定义，而且这一点需要在整个组织内保持一致。从高层到基层的每个人都需要认同这一点，才能确保你在 DevOps 采用过程中每个环节的成功；这其中包括工具的使用。

工具知识不足

缺乏对可用工具的知识也是成功的障碍之一。这个问题可能以几种方式表现出来；然而，其中一些对整体进展的危害更大。

首先，知识的缺乏可能会妨碍你选择适合任务的正确工具。虽然没有人能在整个工具链中，甚至在某个特定领域成为专家，但拥有广泛的知识将帮助你根据从供应商那里获得的信息做出合适的评估。

其次，知识的缺乏可能会让你陷入困境——没有对工具的广泛了解，你可能会发现自己无法理解这些工具如何满足你的具体需求。这种延迟会影响你的实施进度。

第三，最后，当你缺乏工具知识时，最糟糕的后果就是让你的决策陷入瘫痪。与第一点中做出错误决策，或第二点中缺乏理解不同，这更多的是误解工具的真正目标。

工具评估

就像从任何供应商购买软件一样，你的组织肯定希望确保你能从任何演示或试用中获得最大收益。这是一个重大投资，你需要确保选择一个能满足需求、符合要求的工具。

考虑工具的成本与其提供的价值之间的关系。你必须确保购买的投资回报符合预期。

如果你正在评估多个工具，确保对它们的评估是公平的。对做相同事情的工具进行不同的评估是没有意义的。这不仅无法给每个候选工具展示其优点，还能确保决策过程中没有偏见。

每个人对不同的技术栈和工具都有偏好，但你需要确保选择适合组织的工具，而不是仅仅因为你过去使用过某个工具就继续使用它。

市场上工具的数量

当然，在你开始评估工具之前，你必须穿越各种 DevOps 工具链类别中庞大的工具海洋。

工具的数量庞大，Cloud Native Computing Foundation (CNCF) 甚至创建了一个网站工具，详细列出了其领域内的工具，并提供了多个过滤器帮助你限制搜索范围。这就是 CNCF Cloud Native Landscape (landscape.cncf.io)。不要误会：这非常有用，但它也突显了我们在选择工具时面临的问题。

除了 CNCF 列出的工具外，当然还有一些不在 CNCF 生态系统中的其他工具。这份庞大的工具清单进一步加剧了你在选择可用工具时可能感受到的选择困难。

你可以通过查看独立的工具信息来源来突破厂商提供的营销内容。查看使用过这些产品的社区帖子，看看他们的使用案例，并利用这些信息帮助你筛选工具。

工具集成不足

在本章前面，我们讨论了 DevOps 工具中集成的重要性。使用缺乏足够集成的工具会限制你的能力，而这种限制的影响取决于其限制程度。

例如，如果持续集成和部署工具缺乏足够的集成，而平台又没有提供广泛的其他服务，这将成为一个问题。在查看这些工具时，我们应该寻找与待办事项管理工具、部署平台和票务系统（如果这是一个需求）的集成机会。

我们还必须考虑与提供安全服务的工具的集成，以便它们能为我们的整体目标提供价值。

缺乏集成会为你的工具创建一个黑盒，你无法与其交互，也无法从中提取可能有价值的数据。

摘要

在本章中，我们探讨了 DevOps 工具链中的工具。我们了解了不同类型的 DevOps 工具，并研究了工具如何帮助您的组织采用 DevOps。接着，我们分析了 DevOps 工具的好处，并试图理解可能阻碍高质量工具采用的障碍。

接下来，我们将探讨如何制定工具实施的策略。我们将讨论工具的架构和安全要求，以及如何制定培训计划来帮助团队，并将其与定义 DevOps 工具的负责人和流程结合起来。

问题

现在让我们回顾一下本章中所学到的一些内容：

1. 哪些工具会对整个 DevOps 工具链产生影响？

   a. 构建工具

   b. 测试工具

   c. 协作工具

   d. 运行工具

2. 为什么在采用工具时 API 如此重要？

   a. 其实不重要——我们不需要 API。

   b. 它们提供了自动化和集成的机会。

   c. DevOps 工程师需要了解 API。

   d. 所有优秀的工具本身都会配备 API。

第十一章：制定实施工具的策略

仅仅选择工具并在你的环境中实现它并不会让你成功，反而会拖慢你的 DevOps 转型进程。你应该与他人合作，倾听他们的顾虑，并制定一个实施工具的策略。在本章中，我们将探讨制定工具实施策略时需要考虑的因素。

到本章结束时，你将理解始终遵循架构最佳实践以及安全需求的重要性，学习如何制定培训计划帮助团队使用新的工具，并了解拥有工具的所有者和流程的重要性。

在本章中，我们将涵盖以下主要内容：

• 理解架构和安全需求

• 制定帮助团队的培训计划

• 定义工具的所有者和流程

理解架构和安全需求

当你在组织中实施任何东西时，无论是新工具，还是技术流程，或者现有工具的更新，都必须考虑这些对企业架构和信息安全的影响。这两者是 IT 组织的基石，朝着它们定义的目标努力，而这些目标与业务目标紧密对接，将有助于你寻找合适的工具。

为了进一步探讨这个问题，了解以下内容非常重要：

• 为什么企业架构很重要？

• 为什么信息安全很重要？

• 理解架构需求

• 理解安全需求

让我们更详细地看一下这四个要点，以便更好地理解。

为什么企业架构很重要？

企业架构在组织中有许多好处。最显著的一点是它提供了对企业内部系统的自上而下的视图。仅凭这一点，企业架构在管理许多业务所涉及的复杂性方面就具有不可估量的价值。

过去，许多人认为企业架构是 IT 的单一职能，并且是在象牙塔里运作的。近年来，这一看法发生了巨大变化。如今，企业架构不再仅仅被视为 IT 的职能，而是发挥着至关重要的作用，架起了业务与 IT 之间的桥梁。

企业架构的实践在多年来已经发生了演变。从最初的基础性和支持性角色，现在它更加注重进步和结果，能够识别变革和增长的机会。

企业架构之所以重要，是因为它决定了服务和应用程序的整体策略。企业架构的策略和路线图将定义服务部署的蓝图，列出在服务被考虑之前必须具备的条件。同时，它还定义了组织在短期、中期和长期将使用的平台。

因此，在考虑与 DevOps 相关的工具时，需要考虑所有这些信息。你的工具是否符合为你的组织使用的应用程序设定的要求？

当我想到企业架构时，我想到它为组织提供的三个主要好处：

• 管理复杂性

• 创建可操作的可交付成果

• 提高敏捷性并减少实现价值的时间

让我们更详细地看一下这三个领域。

管理复杂性

大多数组织，尤其是企业，是由一系列系统和应用程序交织而成的。这些系统和应用程序在组织内部有着不同的重要性和显著性。这些重要性或显著性的定义没有明确的规则。这正是它复杂的一部分。

一些应用程序对业务的成功至关重要，但在 IT 以外的人可能不知道这个应用程序叫什么。

重要提示

企业架构采用的自上而下的视角意味着组织在评估诸如应用程序等资产时更加高效和自信。

企业架构带来的整体视角旨在建立的不仅仅是一个领域，而是整个组织各个领域。这提供了诸如可能识别多个应用程序在处理相同流程的领域等视角。

另一种观点可能会得出一个看似不那么显眼的应用程序实际上是至关重要的结论。这种观点帮助我们避免领导层可能认为应该将某个应用程序从架构中淘汰的情境。

创建可操作的可交付成果

之前，我们讨论了评估我们当前能力以及管理许多组织中的复杂景观。通过我们讨论的整体视角，这也帮助企业架构团队识别任何空白点。

对组织内部架构的全面理解意味着组织能够做出更明智的决策，包括未来应该投资于哪些领域。

重要的是，它还帮助组织理解何时可以创建路线图，以便他们能够反思组织的关键优先事项，并且整个组织的紧迫问题可能会影响这一点。

总的来说，这种方法将帮助组织满足当前的需求以及当前的机会。这一切发生的同时，也尽量减少服务中断。确保这能够在组织的长期愿景下完成。

提高敏捷性并减少实现价值的时间

今天，在技术快速发展的时代，以及常常高度颠覆性的数字化转型中，对帮助企业架构的工具需求非常明显。

工具将有助于加快优化、替代投资、合理化、以及对风险、变化和组织整体影响的规划决策支持。能够将这些转化为实际成果的组织，更能高效地评估并实施新技术。

简而言之，一个运作良好的企业架构将帮助企业捕捉并理解，以及阐明现存的机会、风险和挑战。这其中也包括安全性。让我们来看看信息安全的重要性。

为什么信息安全重要？

在这个数据为王的现代世界中，我们的大部分数据都存储在系统中，信息安全变得异常重要。数据处理失误和安全事件可能会让公司陷入困境，并对组织的声誉造成不可挽回的损害。

可悲的是，许多人仍然不知道信息安全对企业的重要性，当然，也影响到企业的成功。许多经理人仍然抱有令人恐惧的误解，认为由他们控制的信息是安全的，不会受到威胁。这种误解，当然是一个大错误。

作为今天的技术专家，我们享受着多年来技术进步带来的好处。正因如此，网络攻击的次数和危害也在增加。重复性的攻击不断增多，在你意识到之前，您的组织可能已经成为另一起网络攻击的目标，并已处于风险之中。

这就是为什么在处理和处理机密信息时必须非常小心的原因。

为什么我的组织需要担心安全问题？

考虑一下有关您组织内部信息的重要性。战略计划、财务信息、员工记录、并购信息——这份清单没有尽头。

如果信息泄露，这将产生严重的多米诺效应，迅速引发多个后果，如损害您的声誉、暴露您的战略，甚至泄露公司的机密或知识产权。

这些信息不仅可能对您的公司造成损害，那您的客户呢？您可能持有关于客户的信息，例如他们是谁、他们使用什么、他们花多少钱、花在哪里，甚至可能包括他们的未来计划，而这些信息现在都可以在互联网上自由获取。

在企业外部，许多较小的组织认为自己不是网络犯罪分子的目标，因此无需投资于数据安全和网络防御。

事实上，由于缺乏保护，许多成功的攻击瞄准了这种规模的公司；很多公司甚至不知道自己的系统已经被入侵，直到事后很久才发现，而那时已经为时已晚。

我建议观看这个关于信息安全重要性的YouTube视频（www.youtube.com/watch?v=7L9JerWIT3Y）。该视频探讨了敏感信息的存储位置以及我们处理的各种类型的信息，以解释信息安全的重要性。

我应该注意哪些常见威胁？

现在有工具可以应对常见威胁。特别是代码扫描工具，会检查应用程序源代码中的漏洞利用。信息安全专家每天都会处理这些威胁。根据我的经验，我认为以下五种威胁是专业人士最常处理的：

• 利用漏洞

• 恶意软件

• 网络钓鱼

• 系统离线

• 缺乏保密性

让我们更详细地看看这五种威胁。

利用漏洞

黑客和网络犯罪分子会寻找系统中的漏洞，以帮助他们实施攻击。通常，漏洞的存在是由于这些系统管理上的疏忽，例如未更改密码或未更新系统以包括最新的供应商更新。

有时，黑客会利用所谓的零日漏洞，这些漏洞尚未由供应商发布补丁修复。

恶意软件

一种最常见的攻击途径，从网络攻击的初期就存在，就是恶意软件。简而言之，恶意软件是一种攻击软件或应用程序部分的有害代码，它的目的是破坏数据或甚至损坏组织内部的设备。

一个更极端的例子是 2020 年的 SolarWinds Orion 攻击。这次攻击从根本上来说是一次供应链攻击，其中恶意代码在构建和发布过程中被插入。这种方式确保了如果未被发现，你的恶意软件就会出现在最终产品中，并且软件的二进制文件会被签名，看起来像是正式发布的版本。

然后，作为常规维护的一部分，更新应用于该产品，全球各地的组织在不知情的情况下将带有后门的软件安装到他们的网络中。

其他形式的供应链攻击恶意软件的例子包括 Target 公司的安全漏洞事件，以及 Stuxnet 病毒，该病毒瞄准了控制和数据采集系统，正如Business Insider所述（www.businessinsider.com/stuxnet-was-far-more-dangerous-than-previous-thought-2013-11），导致伊朗五分之一的核离心机受损。

网络钓鱼

网络钓鱼的增长非常迅速。网络钓鱼攻击的根本原因是电子欺诈。犯罪分子作案的一种方式是伪装成他人。这可能是通过伪造来自你组织内信任人员的电子邮件，诱使你点击实际上已经被感染的邮件中的链接。

在外部世界，钓鱼攻击的最大目标是窃取银行信息以及身份信息。然而，在企业世界中，钓鱼攻击的目标则包括你的公司信息以及你打算如何利用这些信息。

系统离线

在过去 10 年里，最常见的攻击之一就是拒绝服务攻击。大多数组织都有至关重要的业务系统，不能停机。拒绝服务攻击就是通过大量请求目标这些关键系统，导致应用无法处理这些请求的数量，从而崩溃。

这些事件极为严重，可能导致组织收入损失，甚至损害声誉和客户信任。

缺乏机密性

大多数组织都会处理一定程度的敏感信息，有些比其他的更为敏感。绝大多数组织都处理个人数据，即使这些数据仅限于员工信息。

某些数据，包括个人数据，应该受到保护，仅限授权且可信的人访问。许多组织在员工开始进行背景调查之前，会花费大量资金以确保他们是可信的个人。

信息保护的基本规则是，当访问和信任规则未被遵守时，数据的信任圈外的人可能会访问到该数据，并有可能滥用它。

总结来说，信息安全极为重要，而确保组织内每个人都清楚谁对安全负责也同样至关重要。其实很简单：每个人都对组织内的安全负责；安全专业人员的工作是寻找、检测并追踪那些试图破坏信任并渗透你们网络的个人。

现在，让我们来看一下，在制定工具战略时理解架构需求的重要性。

理解架构需求

既然我们已经对企业架构以及它在组织中的作用有了清晰的了解，那么接下来我们来看一下，如何利用这些知识帮助制定一个能够帮助我们后续工具选择的战略。

定义我们的架构需求

首先，让我们定义一些可以用来对齐 DevOps 工具选择的架构需求。我们的第一个需求是，在可能的情况下，我们会购买现成的软件，而不是自己开发。接下来的需求是，系统必须能够接受我们的联合企业身份。这意味着需要支持如 OAuth 或安全声明标记语言（SAML）等技术，以便我们可以使用单点登录。

OAuth 是一种用于访问委托的开放标准，通常用于互联网用户授予网站或应用程序访问其他网站信息的权限，而无需透露他们的密码。另一方面，SAML 是一种开放标准，允许身份提供者将授权凭证传递给服务提供者。

其他要求包括，软件必须能够部署到公共云提供商上，并且我们必须能够通过 API 与该工具进行接口。

总结一下，这是我们的需求清单：

• 购买软件，而不是自行开发。

• 接受联合身份认证。

• 支持部署到公共云提供商。

• 使用 API 进行接口。

在现实世界中，会定义更多的要求，并由企业架构部门设定。这些要求帮助我们在市场上的工具选择中导航，并自然地帮助我们缩小选择范围。

为架构评审做准备。

实践企业架构的成熟组织还会规定所有新项目必须提交给一个委员会审查。该委员会由来自不同业务部门的领导组成，并由企业架构部门主办。

这个委员会的目标，通常被称为架构评审委员会，是确保进入组织的新软件符合企业架构蓝图的标准，并能够解决可能出现的任何附加问题。

在评估工具选项的过程中，最好让企业架构团队的一名成员与你一起工作。这样，在评审委员会上将要问的许多问题，会在你评估工具时就提前得到解答。

总体而言，这可以节省大量的时间。现在我们已经了解了在组织内使用工具时，架构和安全要求的重要性，接下来让我们看看如何制定培训计划，帮助你的团队采用新工具。

制定帮助团队的培训计划。

通常，组织并没有充分重视对团队进行新工具培训的需求，尤其是当这些工具被引入组织时。培训有多种形式，如果多个团队使用同一工具，你需要确保为不同的团队量身定制培训，同时考虑到不同人的学习风格。

事先考虑这些问题，并围绕它们制定计划，通常会使你的工具实施比没有适当培训计划时更加成功。

现在，让我们来看看在组织内制定培训计划的重要性。

为什么培训计划很重要？

让我们以一位职业运动员为例。对他们来说，训练对成功至关重要。随着职业运动员训练过程的日益精细化，训练中会出现一些变化，例如从规划天气到为重大赛事做准备。需要一个计划来提供结构、方向和指导。训练计划也帮助你做好准备，应对各种因素，例如可能干扰计划的分心。

重要提示

训练计划帮助你提前规划，增加员工留存，提升参与度，并帮助你在竞争中保持领先。

培训计划对企业很重要，原因有很多，以下是我想到的一些：

• 提高员工参与度

• 提高员工留存率

• 保持在竞争对手前面

• 节省成本

让我们更详细地分析这些原因，看看为什么培训计划如此重要。

提高员工参与度

缺乏参与感最终会导致员工留存问题（接下来会详细讨论）。保持团队参与感，尤其是对于一群技术人员而言，涉及到的训练帮助他们在职业生涯中进一步发展。

如果你的组织在提供优质培训机会方面有良好的记录，那么你的员工会保持参与感。他们知道，当新事物出现时，他们将有机会学习。

提高员工留存率

任何有过团队管理经验的人都知道，随着时间的推移，你的团队成员中总会有人提出类似于“我不知道我的职业发展方向”或“我觉得公司不重视我所做的工作”这样的观点。虽然这些评论可能不会立即造成问题，但它们会导致员工开始寻找其他工作机会，从而引发面试，最终可能收到其他公司的 offer。

提前规划，并且将这些培训计划沟通给你的团队，让他们知道在这段时间内，他们的培训如何与组织的目标对接，这有助于他们将事情放在正确的视角下。

保持在竞争对手前面

目标通常围绕增长、市场份额、提供产品和服务或增加销售额来设定。你依然可以将培训目标与这些目标挂钩，并且你的培训计划应当反映这些目标。

提前设计团队需要掌握的知识，也就是能帮助他们和你取得成功的知识。当你达到那个关键时刻，需要这些知识或技能时，成功的培训计划意味着员工已经具备了这些技能。

节省成本

难道不是每个人都喜欢省钱吗？实际上，当你在招聘时，你可以招聘到具备所有所需知识的人，而不是招募一个需要在内部逐渐积累这些知识的人。从长远来看，让某人获取这些知识要比聘请一个已经具备知识的人更加节省成本。

规划将帮助您更有效地利用培训预算。您可以提前规划所需的内容、时间，并尽可能使用内部人员，但简而言之，涉及到团队发展时，规划始终是关键。

现在，让我们看看如何为您组织中的团队制定培训计划。

如何为您的团队制定培训计划

制定培训计划实际上是一个相当明确的过程。培训计划应该是您整个组织培训项目的一部分，而这个培训项目应该已经建立。

制定有效的计划包括以下步骤：

1. 确定培训需求

2. 审查成人学习原则

3. 为个人制定目标

4. 设计或寻找合适的培训

5. 规划培训的时间安排

6. 让员工确认培训计划

让我们更详细地看看这些步骤，了解如何制定培训计划。

确定培训需求

您应该考虑团队使用工具时的差异。如果多个团队在使用同一工具，并不是每个团队都会以相同的方式使用该工具。在制定计划之前，先对现有技能进行审计，然后再制定您和员工所需的内容。

如果您制定的计划没有提供任何价值，人们就不会投入其中，也看不到价值，无论您多么努力。

审查成人学习原则

听起来很明显，但请记住，成年人学习与儿童不同。您的培训计划需要反映这一点。您需要确保培训能够保持学员的参与度；不要安排仅仅是播放 PowerPoint 幻灯片的培训。

大多数成年人通过自我指导的方式学习，他们所做的选择与个人目标相关。成人学习也非常注重目标，因此确保您的培训与业务目标（无论是个人的还是职业的）一致。

成人在培训过程中获得的生活经验也很重要，因为这些经验可以帮助塑造他们未来的培训。这些先前的经验有助于确定您偏好的学习方式。

为个人制定目标

在制定培训计划时，制定目标是非常重要的，因为如果您没有目标，就无法确切知道自己想要去哪里，培训可能也不会有效。拥有最终目标是一个开始，但您需要沿途设立里程碑，以确保自己朝着正确的方向前进。

学习目标应该根本上定义您希望员工在培训结束时理解的内容，最重要的是能够做什么。在培训结束时，员工应该知道自己现在能做以前做不到的事情。

设计或寻找合适的培训

尝试在内部寻找可能帮助你提供培训的主题专家。如果找不到，你也许可以在互联网上找到可以使用的现成材料。在其他情况下，你可能需要邀请一位培训师来帮助培训你的员工。

在这一步骤中，要考虑员工的学习风格，以及这可能如何影响你认为合适的培训内容。

将培训内容区分开来，确保软技能和硬技能之间有明确的定义。硬技能指的是新产品或工具中的技术技能，而软技能则包括沟通、 多样性或骚扰培训等内容。

规划培训的时间

作为一名经理，确保你的团队充分了解，他们有专门的学习时间来参加必要的培训。你应该积极鼓励员工利用为他们安排的时间，并做出承诺，以确保一旦培训预约好，就不会被推迟。通常，培训是由于操作上的挑战而被推迟或调整的第一件事。尽你所能确保这种情况不发生。

你应该使用工具或甚至电子表格来跟踪员工已报名、已完成或计划参加的培训。

让员工确认培训计划

跟踪你的培训项目，确保所有员工都已完成必要的模块。你可以实施一个培训计划，从新员工入职开始，专注于健康与安全、公司文化和一般程序。关键是要获得已完成特定项目的员工的反馈，并让他们确认自己的培训。

现在你已经理解了培训计划的重要性，以及如何在你的组织中制定和实施这些计划，让我们来看看如何定义工具的所有者和流程。

定义工具的所有者和流程

为了让工具有效，它实际上需要两个基本条件。第一个是该工具的所有者，第二个是为该工具定义和记录流程。

工具的所有者负责定义如何使用该工具、该工具解决了哪些场景、如何使用工具的各个部分以及提供有关基础设施和任何相关费用的所有权。你可以将工具所有权分为业务所有权，以管理费用、所需的基础设施或许可费用，以及技术所有者，后者负责管理知识文章和如何使用该工具的流程。

此时还应考虑工具的生命周期。在讨论测试工具时，Cania Consulting（cania-consulting.com/2019/10/25/software-testing-tool-basics/#Testing_tool_life_cycle）的这篇文章很好地解释了工具的生命周期。

现在，让我们来看看如何识别组织中工具的所有者。

识别组织中工具的所有者

如果你的组织足够幸运，拥有资产管理团队，那么大多数工具的业务所有权可能归他们所有。许可所有权通常会归资产管理团队作为一个集中的团队来管理。

技术所有权并不像你想象的那么清晰。当然，如果某个团队使用一个工具，那么从日常使用的角度来看，工具的所有权就归该团队。但如果工具更加基础，并被多个不同的团队使用，则情况就不那么简单。

在这种情况下，你会发现工具的所有权通常掌握在中央 IT 团队手中。在许多组织中，传统上这一点是成立的，但随着 DevOps 工具的采用以及团队内部的转型，许多中央 IT 团队不愿意拥有和管理他们自己不使用的工具。

在这种情况下，中央 IT 团队将根据需要为工具提供基础支持，尽管在工具是 PaaS 或 SaaS 的情况下，不需要这种支持。使用该应用程序的团队将被授予应用程序的所有权，并承担相应的责任。

工具与流程的映射

考虑成功运行你的工具所需的流程。你需要思考传统流程，比如用户如何加入工具、如何管理他们的访问权限和许可，直到如何从工具中移除人员。

此外，思考工具试图解决什么问题，以及它将自动化哪些手动流程。这些内容需要详细记录，以便在自动化过程失败时，能够知道它替代了什么，并知道该从哪里查找解决问题的方法。

你还需要考虑的其他流程包括记录工具的重要性。这有助于建立工具支持的内容，以及它对业务的基础性作用。同时，考虑工具如何更新以及何时使用，这样当工具更新时，就不会影响到其他重要流程的服务。

让工具成为流程改进的一部分

我们已经多次谈到持续反馈和持续改进的重要性。工具不应当被排除在这一循环之外。将工具纳入流程改进活动中，与改进流程本身一样重要。

查看您使用价值流映射的流程；例如，可能是工具导致了您尝试解决的流程中的延迟或周期时间。在这种情况下，您可能需要对工具进行调整，以便其能够正常工作。

总结

在本章中，我们理解了在制定工具策略时需要考虑的架构和安全性要求。我们还讨论了为什么企业架构和信息安全很重要，如何为您的组织制定培训计划，以及如何确定工具的负责人和相关流程。

运用这些技能，您现在可以在您的组织中实施 DevOps 工具策略和流程，并制定扎实的培训计划，使您的团队能够迅速掌握新工具。

在下一章中，我们将探讨与 DevOps 密切相关的各种趋势，例如 DataOps、DevSecOps 和 GitOps。我们将了解它们是什么，以及在这些 XOps 场景中帮助传递价值的工具。

问题

现在，让我们回顾一下本章中所学的内容：

1. 以下哪一项不是企业架构重要性的原因？

   a. 管理复杂性

   b. 指定应使用哪些工具

   c. 创建可操作的交付成果

   d. 提高敏捷性

2. 以下哪一步不是制定培训计划的一部分？

   a. 制定目标

   b. 节省培训费用

   c. 规划培训的具体实施

   d. 让员工签署计划

第十二章：跟上关键 DevOps 趋势

现在存在多种不同的学科，旨在建立在 DevOps 的核心原则和实践之上，针对业务的不同领域，甚至特定部门。像 DataOps、GitOps 和 DevSecOps 这样的术语现在已经成为行业中的常用术语，并且每个领域都有相应的工具。在本章中，我们将更详细地了解这些趋势，理解它们是什么，目标是什么，以及可以使用哪些工具。

到本章结束时，你将理解与 DevOps 专业相关的一些关键趋势，了解它们是什么，如何在组织中应用，以及如何在其中使用工具。

在本章中，我们将讨论以下主题：

• 什么是 XOps？

• 理解 DataOps 生态系统

• 理解 DevSecOps 生态系统

• 理解 GitOps 生态系统

什么是 XOps？

XOps是一个通用术语，描述了在技术内外采用其他形式的运营。在这个背景下，DevOps 实际上只是冰山一角。

DevOps 只是一个开始。你还可以包括 BizOps、FinOps、AIOps 和 MarketingOps 作为起点，但XOps的概念不仅仅包括这些。它们都是跨职能的努力，像 DevOps 一样，但组织是否真的需要所有这些，甚至其中的一部分，还是这一运动仅仅是炒作？

我们都能达成的共识是，所有组织都处于各自不同的成熟阶段。影响这一点的因素包括它们的规模、年龄、行业、技术采用、预算，当然，还有文化。

组织越来越需要这些不同类型的运营模型所提供的好处。有些组织会尽可能多地实施这些模型，而有些组织则会根据需要实施，并且调整过程和采用的程度，以最适合他们的组织。

这并不意味着结果会因为之前提到的因素而有所不同。与 DevOps 一样，这些模型共同的关键要素是关注价值，而这正是每个组织的独特之处。

XOps 是从哪里开始的？

有些人认为 XOps 只是炒作，一种会消失的炒作，认为许多提议的内容不过是对现有事物的重新标签化。你也可以对 DevOps 说同样的话，但正是将 DevOps 中的实践整合在一起，而不是将其割裂开来，才给组织带来了真正的价值。

像 DevOps 一样，大多数运营模型类型将关注过程加速和交付质量的改进。例如，在 DataOps 中，这将是数据，以及对 AIOps 运营性能的分析洞察。

那些认为 XOps 被过度炒作的人认为，风险在于不同的参与群体可能会导致碎片化。这种碎片化进一步稀释了更快创造的价值，并且产生了额外的官僚主义。

重要提示

敏捷性自千禧年初以来一直是 XOps 的核心。自那时以来，商业领袖已经意识到，他们的组织需要更加敏捷，以便在行业中保持竞争力。

作为 XOps 一部分的敏捷实践已经存在了一段时间，并且在商业领域中的地位逐渐上升。不幸的是，一些领导者认为敏捷就等于用更少的资源做更多的事。

事实上，从根本上说，背靠扎实流程的敏捷性为您的组织提供了在需要时进行扩展的能力，能够为终端用户提供更多价值，改进您的流程，并提高效率。

XOps 和 DevOps 之间的联系不仅仅体现在名称的相似性、实现黄金标准的方法或相关流程上。文化是 DevOps 的重要组成部分，特别是在改善组织内沟通与协作的能力方面。

XOps 从 DevOps 借鉴的其他重要方面包括关注持续改进以及任务自动化。技术人员常常忽略，流程自动化不仅仅局限于技术层面的流程。毕竟，业务流程自动化早在 DevOps 诞生之前就已经存在了。

了解 XOps 格局

为了进一步了解 XOps 格局，让我们来看一下 XOps 中的两个常见倡议：FinOps 和 CloudOps。我们将在本章稍后详细了解 DataOps、DevSecOps 和 GitOps。

FinOps

FinOps 也被称为云财务管理，它是组织内部财务和运营团队的融合。具体而言，FinOps 专注于管理财务运营的过程，同时将相关人员、流程以及技术相结合。

FinOps 的需求来源于传统的 IT 财务模型，该模型与其他团队分开运作，缺乏基于数据的决策制定和技术现代化来管理可扩展的、云支持的应用程序。

关于商业需求缺乏灵活性的问题只会使成本膨胀，这使得系统运作缓慢且更加昂贵。因此，组织需要提出一种方法，为其高度可扩展的云环境提供成本控制，了解这些成本是什么，如何发生，并跟踪云支出。

随着云计算的发展，对于组织内部其他部门能够对云环境中的服务进行费用分摊的需求也在增加。云计算涉及的细化成本在许多方面使得费用分摊的概念变得更加简便，但实际上，实施起来依然困难。

如何为共享服务（如网络和存储）计费的复杂性，使得很难意识到这些费用如何可以分摊到不同部门。这些基础设施级别的服务，或核心服务，通常由技术部门使用，而应用服务则按成本中心进行计费。

为了实现稳健的 FinOps 实践，重要的是遵循三个阶段的采用过程。这三个阶段是通知、优化和操作。第一阶段，通知，对资产、预算分配进行详细评估，并提供行业标准的理解，以便发现改进的领域。

第二阶段，优化，帮助设置警报和指标，以识别需要花费和重新分配资源的领域。这些操作能够生成决策能力，并在需要时提供架构变更的建议。

最后阶段，操作，帮助在资源级别追踪成本和成本控制机制。FinOps 在操作中提供了一定的灵活性，但仍保持对与云平台相关的可变成本的财务责任。

CloudOps

CloudOps 是定义和识别适用于优化云环境服务的操作程序的过程。CloudOps 是 DevOps 与传统操作的结合，能够为云平台、应用程序和数据提供进一步的技术增强，同时维持服务。

为了进一步加速敏捷性，组织必须密切关注预算限制，比如浪费和超支。这也是组织决定将工作负载迁移到云平台的原因之一。

CloudOps 提供可预测性和主动性，有助于增强可见性和治理。在维持本地部署的过程中，相关的电力、网络、存储和高可用性始终是一个挑战。尽管挑战依然存在，但在云中这更容易实现，虽然这些挑战与本地部署有所不同。

由于 CloudOps 是 DevOps 的扩展，它旨在建立负责云平台上迁移后应用程序的云操作团队。优化成本、增强安全性、提供容量规划的治理工具在 CloudOps 中至关重要。它还推动了持续监控的理念，并且通过较少的资源管理云应用程序。

自动化提供了提高云应用程序敏捷性、速度和性能的技术。CloudOps 中的自动化还促进了服务、事件和问题的顺畅处理。将 DevOps 中的元素（如持续集成和持续部署）与基础设施服务相结合，并引入基础设施即代码，提供了高水平的自动化，提升了 CloudOps 的价值，并为操作团队提供了以前未曾见过的可扩展性。

XOps 的方法

让我们看一下 XOps 的一种方法。目标是将当前的单体应用程序转化为微服务架构。此外，迁移过程应该是自动化的，并为生产、UAT（用户验收测试）和测试创建独立的环境。

主要身份应由 DevOps 团队进行管理。这使得您能够管理用户、群组以及第三方服务和应用程序。这种方法提倡协作文化。

此外，为了使资源模块化，团队为多个资源生成基于容器的模块，然后将堆栈拆分，使其可扩展，并确保部署更加容易。

这种方法使得开发团队的维护和调试变得更加简便，自动化流程有助于提升代码质量。基于角色的访问控制确保了安全的身份验证和授权。

集中化日志记录和监控系统的部署，可以在集中式仪表板上查看性能、可用性和安全性。这有助于提高成本效益并改善应用程序的性能。

在这里，我们已经讨论了多个学科，如 DevOps、CloudOps 和 FinOps，以使这一切得以实现。

现在我们已经了解了XOps这个术语。我们明白了 XOps 的来源和 XOps 的整体格局。接下来，让我们更详细地了解一下 DataOps 生态系统。

了解 DataOps 生态系统

关于 DataOps 的一个常见误解是，它在幕后仅仅是将 DevOps 应用于数据分析。尽管名称与 DevOps 和 DataOps 有相似之处，但它们并不相同。

看看下面的图表，它展示了 DevOps 循环：

图 11.1 – 显示 DevOps 各阶段的无限循环图形

DevOps 通常被描述为一个无限循环。正如你在前面的图表中看到的，DataOps 则有所不同。在展示 DataOps 时，它被呈现为价值和创新管道的交集，如下图所示：

图 11.2 – DataOps 展示，顶部为价值管道，底至顶为创新

DataOps 表示数据分析能够实现软件开发中的 DevOps 所取得的成就。也就是说，当数据团队使用新工具和方法论时，DataOps 可以带来质量和周期时间的数量级提升。DataOps 实现这些提升的具体方法反映了数据团队所特有的人员、流程和工具。

敏捷方法在需求快速发展和经常变化的环境中特别有用。数据专业人士对此会有深刻的理解。就像在 DevOps 中一样，DataOps 中的敏捷方法使组织能够快速响应需求，加速价值实现的时间。

DataOps 不仅仅是关于工具的管理，还涉及人员的管理。利益相关者的需求和偏好是 DataOps 与 DevOps 之间一个微妙的区别。

在 DevOps 中，我们的用户是熟悉编码的开发工程师和运维工程师，他们能处理一个环境中多种语言的复杂性，以及硬件和软件的相关问题。然而，在 DataOps 中，我们的用户是数据科学家、工程师和分析师，他们分析数据并构建复杂的数据模型。

DevOps 的开发是为了满足软件开发人员的需求。开发工程师喜欢编码，并且具备较强的技术能力。学习新语言或部署新工具对他们来说是机会，而非负担。他们对代码创建、集成和部署的各个方面都非常感兴趣。DevOps 欢迎复杂性。

DataOps 用户通常与此截然相反。他们是专门从事模型和可视化开发与部署的数据科学家或分析师。工程师通常比科学家和分析师更具技术敏锐度。他们专注于领域专业知识，致力于使模型更加具有预测性，或找出最适合的方式来直观展示数据。

用于创建这些模型和可视化的技术仅仅是工具。数据专业人士最喜欢的状态是只使用一两个工具，任何更多的工具都会增加不必要的复杂性。在最极端的情况下，复杂性超过了他们的管理能力。

DataOps 认识到数据专业人士生活在一个多工具、异构的世界中，并致力于让他们能够更好地管理这一局面。

了解 DataOps 相关过程

通过检查数据分析开发和生命周期过程，我们可以开始理解数据专业人士面临的独特复杂性。我们发现，数据分析专业人士面临的挑战既有与软件开发人员相似的，也有与其不同的。

在 DevOps 中，生命周期从规划阶段开始，并且会反馈到最初的代码阶段。因此，过程是无限迭代的。

DataOps 生命周期具有这些迭代特征，但有一个显著的区别：DataOps 由两个活跃且交叉的管道组成。之前提到的数据工厂是单一管道。另一个管道管理数据工厂的更新方式，包括创建和部署新分析到数据管道中。

将新分析思想引入价值管道的过程被称为创新管道。尽管创新管道在概念上类似于 DevOps 开发过程，但有几个因素使得 DataOps 开发过程比 DevOps 更加复杂。

了解 DataOps 中涉及的工具

为了交付一个可靠的数据管道，直接和间接支持 DataOps 需求的工具可以分为五个步骤，利用现有的分析工具以及旨在解决源代码管理、过程管理和小组之间高效沟通的工具链组件：

• 源代码管理

• 过程和工作流的自动化

• 添加数据和逻辑测试

• 在一致的部署中无畏地工作

• 实施沟通和过程管理

现在，让我们更详细地介绍这五个步骤。

源代码管理

数据管道不过是负责将原始数据转换为可用信息的源代码。我们可以自动化整个数据管道，从开始到结束，生成可复现的源代码。版本控制工具（如 GitHub）有助于存储和管理代码和配置的所有更改，从而减少不一致的部署。

过程和工作流的自动化

自动化对于 DataOps 方法的成功至关重要，这需要设计具有运行时灵活性的数据管道。自动化数据策划服务、元数据管理、数据治理、主数据管理和自助互动是实现这一目标的关键需求。

添加数据和逻辑测试

为确保数据管道正常工作，必须对输入、输出和业务逻辑进行测试。为了确保数据质量的一致性，数据管道在每个阶段都要进行准确性或潜在偏差的测试，以及错误或警告的检查。

在一致的部署中无畏地工作

数据分析专业人员害怕引入会破坏当前数据管道的更改。这个问题可以通过两个关键工作流来解决，这两个工作流将在生产中后期集成。首先，价值管道为组织生成持续的价值。其次，创新管道由处于开发阶段的新分析组成，后来这些分析会被添加到生产管道中。

实施沟通和过程管理

在 DataOps 实践中，高效且自动化的通知至关重要。当源代码发生更改，或数据管道被触发、失败、完成或部署时，相关利益相关者可以立即收到通知。工具链还包括促进跨利益相关者沟通的工具（如 Slack 或 Trello）。

我们现在已经了解了什么是 DataOps，实施正确时它所期望达成的目标，以及涉及的 DataOps 生命周期中的流程和工具。现在，让我们来看看 DevSecOps 生态系统。

理解 DevSecOps 生态系统

DevSecOps 是一种软件行业的文化变革，旨在将安全性融入现代应用开发和部署中典型的快速发布周期，这也被称为 DevOps 运动。拥抱这种“向左推进”的思维方式要求组织弥合开发团队和安全团队之间通常存在的差距，以至于许多安全流程可以自动化并由工程团队处理。

以下图表帮助说明安全性如何融入现有的 DevOps 循环：

图 11.3 – 显示 DevOps 与 DevSecOps 交互的图示

历史上，主要的软件开发商通常每几个月甚至几年发布一次其应用的新版本。这给代码足够的时间进行质量保证和安全测试，这些测试由独立的专业团队（无论是内部团队还是外包团队）处理。

然而，在过去的 10 年里，公共云、容器以及微服务模型的兴起，已经将单体应用程序拆分成可以独立运行的更小部分。这一分解也直接影响了软件开发方式，导致了滚动发布和敏捷开发实践，在这种模式下，新特性和代码以快速的速度不断推送到生产环境中。

DevSecOps 将 DevOps 和 SecOps 结合，形成一个软件开发、技术运营和网络安全的循环实践。

DevSecOps 的目标是推动安全代码库的快速发展。DevSecOps 方法论并不单纯强调开发速度或安全性，而是帮助开发人员和安全专家在两者之间找到一个健康的平衡点。使用敏捷框架使得开发和安全团队能够持续合作。

DevOps 和 DevSecOps 方法论在许多方面是相似的，包括利用自动化和持续流程来建立协作开发周期。虽然 DevOps 强调交付速度，DevSecOps 更加注重安全性。

DevSecOps 的实践可能会在初期增加开发时间，但它们将确保代码库从一开始就具备安全性。经过一些实践之后，一旦安全完全融入到开发过程中，团队将受益于更快的编写和交付安全代码库的速度。

理解 DevSecOps 中涉及的流程

DevSecOps 中的许多过程并不新颖。你的组织可能已经在实践它们了。主要的区别在于，目前的流程可能不适合在 DevSecOps 环境中使用。

要了解需要改变的流程，一个很好的起点是查看DevSecOps 宣言（www.devsecops.org）。与敏捷宣言类似，DevSecOps 宣言列出了九个要点，以帮助你成熟信息安全实践。它们如下：

• 积极参与，优于总是说“不”

• 数据与安全科学，优于恐惧、不确定性和怀疑

• 开放的贡献与协作，优于仅限安全的要求

• 可消费的安全服务与 API，优于强制性的安全控制

• 以业务驱动的安全评分，优于象征性的安全审核

• 红队与蓝队的漏洞测试，优于依赖扫描和理论漏洞

• 24 小时全天候的主动监控，优于事后反应

• 共享威胁情报，优于信息保密

• 合规操作通过剪贴板和检查表进行

你可以看到，大多数宣言中列出的内容涉及到你现有的信息安全投资的成熟度，并且在一定程度上有助于收回一些多年来与信息安全相关的负面观念。

DevSecOps 很难，但做得好的话，你可以显著提升你的安全态势，同时加深对组织内部安全的理解。要转变为 DevSecOps 的思维方式，应该遵循以下五个步骤：

1. DevSecOps 是一种文化变革。

2. 将实践与开发工作流程对齐。

3. 可证明的证据表明，安全性与速度同步发展。

4. 从预防转向检测。

5. 使用安全预算来支持开发工作流程。

让我们进一步了解接下来的五个步骤，以便理解实施过程。

DevSecOps 是一种文化变革

采用 DevSecOps 方法对于大多数企业来说将是一次巨大的任务，因此要意识到它是一次重要的文化转变。开始对话，要勇敢，并成为迈向改变的第一步。如果你以一种清晰简洁的方式进行交流，突出每个组织在业务、效率和安全方面的好处，找到共同点并达成协议会更容易。

将实践与开发工作流程对齐

与开发团队进行讨论时，至关重要的一点是不要将当前的安全实践带到桌面上，并期待他们改变开发代码的方式。

显然，你不应忽视监控、风险评估等方面的安全需求，但你必须愿意改变你的安全实践，以与开发工作流对接。如果你试图基于传统的安全方式来构建你的 DevSecOps 方法，那么生产发布的速度和节奏就会停滞。

显示安全与速度保持同步的可证明证据

你的开发、运维或 DevOps 团队很可能会对欢迎安全团队或专业人员加入他们的工作方式感到犹豫。你可以通过提供可见性和监控服务，以及与团队合作，绘制流程并识别支持敏捷性的机会，来克服这种犹豫。

在初期，你应该更少关注强制执行、阻止活动和减缓流水线速度，而应该更多关注展示安全性如何跟得上你的开发团队如此高效地构建大量产品，以确保流水线能够顺利运行。

从预防转向检测

一旦安全已经在开发工作流中建立了自己的位置，你可以考虑从监控和可见性角色转变为主动识别代码中的漏洞。在这种情况下，安全团队可以成为开发团队最好的朋友。

使用你的安全预算来支持开发工作流

最后，考虑一下你自己的安全预算。是否有某些领域，你可以将一些安全预算重新分配到工作流流水线中，以便在改变你的实践以与开发工作流对接时使用？这展示了你通过将更多资源投入到持续集成和持续部署流水线中，致力于每次发布的安全可持续性。

了解 DevSecOps 中涉及的工具

由于从流程角度来看，DevSecOps 与 DevOps 生命周期紧密对接，因此，DevSecOps 中使用的工具也紧密契合 DevOps 生命周期的流程。因此，DevSecOps 的工具与 DevOps 的八个不同阶段对接。以下是每个阶段及其常见的安全工具和流程：

• 计划：威胁建模

• 代码：静态分析和代码审查

• 构建：渗透测试

• 测试：合规性验证

• 发布：日志记录

• 部署：审计

• 操作：威胁情报

• 监控：检测、响应、恢复

接下来，让我们更详细地看一下这些内容，了解使用的工具的具体情况。

威胁建模

不幸的是，威胁建模长期以来一直被认为是一项耗时且劳动密集的活动。因此，随着组织采用 DevSecOps 方法，威胁建模常常被排除在安全实践之外。然而，威胁建模在开发中的重要性不容小觑。

根据2020 DevSecOps Insights Report (snyk.io/wp-content/uploads/dso_2020.pdf)，威胁建模对团队整体的代码安全信心具有显著的正面影响。

从本质上讲，威胁建模旨在检查计划中的软件，识别如果攻击者针对该软件可能发生的安全问题。这项分析的目的是让开发团队了解在其实现过程中应该考虑哪些安全控制。传统上，威胁建模通常涉及整个应用程序环境的广泛范围。在此过程中，常常使用数据流图、详细的威胁分析框架以及规定的威胁优先级方法。

静态分析

静态分析工具，或 静态应用程序安全测试 (SAST)，与几乎任何软件自动化工具链、任何开发方法论和流程都能很好地配合使用。这主要是因为它们可以由开发人员在本地桌面上使用，以便即时反馈并分析完整的构建，无论是每小时完成还是根据其他任何节奏进行构建。

此外，由于它们不需要与测试人员或开发人员互动，SAST 工具是完全自主的。每当需要检查代码中的漏洞和安全漏洞时，它们都非常有用。

虽然单独使用这些工具并非万能，但它们应与其他自动化工具一起使用。随着软件团队开始将安全性集成到他们的 DevOps 流程中，像SonarQube (www.sonarqube.org) 这样的工具既易于实现，又能轻松集成到自动化流水线中。通过尽早发现漏洞并防止其进入开发周期的后期，这条流水线在减少后期安全修复方面大有裨益。

渗透测试

虽然流水线中的自动化工具可以大大帮助检测许多不同的漏洞，但你可能仍然需要渗透测试工具。从传统角度来看，渗透测试在许多方面既是一门艺术，也是一门科学。如果你认为渗透测试与 DevOps 中对速度、频率和可重复性的关注意味着 DevOps 和渗透测试是对立的，这也是可以理解的。

BreachLock (www.breachlock.com)，例如，可以通过对您的产品进行端到端安全测试，完全集成到 DevOps 环境中，从而确保开发过程的速度、可靠性和一致性。

威胁情报

随着更多环境组件在代码中被定义和记录，威胁情报的可视性也在不断增长。许多组织在识别其 IT 资产时面临困难，无法有效地将威胁情报与环境中的资产关联。通过确保有适当的流程将 DevSecOps 管道中的元数据传递给威胁情报能力，组织可以确保收集到正确的情报并将其应用，同时以风险优先的方式进行响应。

我们现在已经了解了什么是 DevSecOps，了解了当正确实施时它试图实现的目标，以及涉及 DevSecOps 生命周期的流程和工具。现在，让我们来看看 GitOps 生态系统。

理解 GitOps 生态系统

GitOps 是一种在云原生应用程序中实施持续部署的技术。它通过利用开发人员已经熟悉的工具（如 Git 和持续部署工具）来专注于为开发人员提供操作基础设施的体验。

GitOps 的核心概念是拥有一个 Git 仓库，始终包含当前生产环境中所需基础设施的声明式描述，以及一个自动化过程来匹配仓库中描述的状态。如果你想部署一个新的应用程序或更新现有应用程序，你只需更新仓库；自动化过程将处理剩下的部分。这就像为管理你的生产应用程序提供了巡航控制。

提示

虽然我们专门谈论的是 Git，但你可以使用任何源代码控制仓库来实现相同的结果。

GitOps 提供了一个完整的历史记录，展示了你的环境随时间变化的情况。这使得错误恢复变得简单，只需运行 git revert 并观看你的环境自行恢复。

GitOps 使你能够完全在你的环境中管理部署。你的环境只需要访问你的仓库和镜像注册表即可完成这项任务。就是这么简单，你不需要授予开发人员直接访问环境的权限。

当你使用 Git 存储已部署基础设施的完整描述时，团队中的每个人都可以看到其随着时间的演变。通过优秀的提交信息，任何人都可以轻松地再现改变基础设施的思路，并找到如何设置新系统的示例。

GitOps 中的部署过程围绕着代码仓库作为核心元素进行组织。至少有两个仓库，一个用于应用程序，另一个用于环境配置。应用程序仓库包含应用程序的源代码以及用于部署应用程序的部署清单。

环境配置仓库包含了部署环境当前所需基础设施的所有部署清单。它指定了哪些应用程序和基础设施服务应该在部署环境中运行，并且指明了配置和版本。

GitOps 是一种高效的工作流模式，用于管理现代云基础设施。尽管它主要关注 Kubernetes 集群管理，DevOps 社区正在将 GitOps 解决方案应用并发布到非 Kubernetes 系统。GitOps 可以从多个方面惠及工程团队，包括改善沟通、可见性、稳定性和系统可靠性。

理解 GitOps 中涉及的流程

GitOps 的一个优点是，你不需要做任何不同的事情。如果你已经在以代码形式编写基础设施并将代码存储在仓库中，那么你几乎已经完成了。

最难的部分是从命令式部署方法转变为声明式部署方法。基础设施即代码提倡一种声明式的系统管理方法，这促进了像 Ansible、Terraform 和 Kubernetes 这样的工具的发展，这些工具都使用静态文件声明配置。

考虑以下命令式语句，它们是部署应用程序的步骤：

1. 安装操作系统。

2. 安装这些依赖项。

3. 从这个 URL 下载应用程序。

4. 将应用程序移动到这个目录。

5. 在另外三台服务器上重复此操作三次。

这种声明式版本的做法可能只是像 四台机器从这个 URL 安装应用程序，安装在这个目录中 这样的描述。与一系列命令不同，声明式软件遵循期望状态的声明。

完成完整 GitOps 安装需要一个管道平台。一些流行的管道工具，如 Jenkins、Azure DevOps 管道和 CircleCI，能够补充 GitOps。管道自动化并将 Git 拉取请求连接到编排系统。管道钩子建立并通过拉取请求触发后，命令被发送到编排系统。

因此，GitOps 中涉及的过程与软件开发生命周期中相同阶段的过程并没有太大区别。这些过程定义了代码应该如何存储、使用什么语言、谁应该进行审查、管道应该如何构建以及这些管道在哪里执行。

为了实现 GitOps，你可以扩展在 DevOps 中已做的工作，将其应用到基础设施领域。

理解 GitOps 中涉及的工具

正如我们在上一节提到的，开始使用 GitOps 需要两个工具。这些工具分别是 Git 形式的版本控制，以及构建和执行管道的工具。

Git 是 GitOps 管道模型中的设计中心。它作为系统中一切的权威来源，从代码到配置，再到整个堆栈。构建可部署的工件需要使用持续集成、构建和测试服务。然而，在 GitOps 管道中，整体交付编排由部署和发布自动化系统协调，这一过程由仓库更新触发。总结来说，持续部署而非持续集成掌控交付编排。这是软件开发生命周期中管道工作方式的一个微妙转变。任何持续集成提供商都应该能够采用这一模型。

总结

在本章中，我们详细了解了 XOps 及其各种可用的运营模型。我们进一步探讨了 DevSecOps、DataOps 和 GitOps，深入理解了它们的起源、优势、流程和工具，并比较了它们与 DevOps 的不同之处。

在下一章中，我们将汇总迄今为止学到的所有内容，回顾一些关键的学习点，并通过一个示例组织来讲解 DevOps 的实施，列出它们面临的挑战、如何解决这些挑战，最后如何实施这些变更。

问题

现在让我们回顾一下本章中学到的一些内容：

1. FinOps 的目标是什么？

   a) 管理云平台中的财务运营。

   b) 设置适当的预算。

   c) 确保消费的问责制。

   d) 增强敏捷性。

2. DevOps 和 DataOps 有什么区别？

   a) DataOps 专注于数据而非软件。

   b) DataOps 专注于数据库管理。

   c) DataOps 不像 DevOps 那样是一个迭代过程。

   d) 没有区别；两者相同。

第十三章：在现实世界组织中实施 DevOps

运用我们迄今为止学到的所有知识，在本章中我们将实践并看看如何在现实世界中的组织中实施 DevOps。通过一个虚构的组织，我们将提出问题陈述，定义他们的目标，并讨论如何帮助该公司适应和变革，开始走上 DevOps 转型的道路。

到本章结束时，您将学会如何结合我们在书中所涵盖的所有元素，并将其运用到实践中，进行一次真实的 DevOps 转型。

本章将涵盖以下主题：

• 理解为什么组织转向 DevOps

• 定义我们的虚构组织

• DevOps 转型示范

理解为什么组织转向 DevOps

在 第一章，介绍 DevOps 和敏捷 中，我们讨论了 DevOps 的目标，以及 DevOps 的一些价值观和 DevOps 可以帮助我们解决的挑战。那么，为什么组织会转向 DevOps 呢？这是我们现在要更详细探讨的问题。

根据 2019 DORA DevOps 状态报告（https://cloud.google.com/devops/state-of-devops），DevOps 的顶尖表现者能够更快速地交付代码，减少缺陷，并更快地解决事件。该报告的一些亮点包括以下统计数据，支持了前述观点：

• 代码部署频率提高了 208 倍

• 从提交到部署的领先时间提高了 106 倍

• 从事故中恢复的时间提高了 2,604 倍

• 更低的变更失败率，减少了 7 倍

采用 DevOps 实践的组织能够做得更多。通过利用一个由跨职能成员组成、协同工作的团队，DevOps 组织能够以最大的速度、功能性和创新交付成果。

在 第二章，DevOps 的商业利益、团队结构和陷阱 中，我们重点讨论了 DevOps 的关键商业利益。然而，您可以将与 DevOps 相关的利益分为三个明确的类别：

• 商业利益

• 技术利益

• 文化利益

当我们谈到商业利益时，我们讨论了推动企业发展的因素；例如生产力的提升、更高质量的产品以及改善员工留存率就是其中的三个原因。此外，还有一些因素直接影响企业的成功，如增长的改善、客户满意度和客户体验。

现在，让我们来看一下实施 DevOps 后，您的组织可以期待获得的一些技术和文化上的收益。

技术利益

你可以列举出与 DevOps 相关的众多技术收益。然而，在推动 DevOps 转型时，重要的是不要过分关注细节，保持关注更广泛的收益。这是因为通常这些较小的收益，尽管对你或你的团队有利，但对于其他团队、部门或整个组织可能并不是更广泛的好处。

保持这种组织视角将确保你获得最大的支持。组织内的各个团队将感受到对其团队特有的好处，这是很好的，但你必须关注更大的利益。

有三个关键收益对我来说是至关重要的，它们与前述的思考大局的情景一致。它们是持续的软件交付、更快的问题解决和更少的复杂性。这也为更积极主动和反应式的技术债务管理提供了机会。

持续集成和持续部署与交付是 DevOps 的基石，是明确的技术收益。正确实施时，它们不仅为你提供了在构建和部署应用程序时的明显好处，还为你提供了在开发过程中捕捉不良实践的手段，以及在过程中发现安全问题和威胁。

通过 DevOps 中采用的实践，你正在使你的环境变得更简单。这种复杂性减少对组织和各个团队都具有吸引力。最重要的是，复杂性的减少可以体现在多个领域，例如你的工作流程，这意味着你已经自动化了手动任务；它也可能体现在文档的生成上，例如。它还意味着去除流程中不必要的步骤。这通常以价值流映射练习的形式出现，用以识别并去除操作中的无效步骤。

最后，随着 DevOps 提升了你对应用程序和基础设施的监控，也引入了站点可靠性工程，这涉及快速从故障中恢复的能力。站点可靠性工程 (SRE) 是一种将软件工程的部分方法应用于基础设施和运营问题的学科。

提供的遥测数据水平和团队之间在应用程序和基础设施方面的共享理解支持了应用程序以及团队设定的目标。

文化收益

在各章节中，我们已经深入讨论了文化在 DevOps 中的影响。DevOps 中的文化是将我们的团队联系在一起的纽带。更快乐、更高效的团队；更大的职业发展机会；以及更高的员工参与度，是你通过成功实施 DevOps 可以实现的三大文化收益。

我刚才提到过 DevOps 带来的团队共享责任。这是文化利益的重要推动因素。当团队共同承担责任、追求共同目标并推动愿景时，这将创造一个文化上健康的工作环境，从而带来更快乐、更高效的团队。

这一点的进一步好处是，DevOps 培养的良好文化能够提高员工的参与感。在 DevOps 中，我们被教导“快速失败”和“成长心态”这两个理念。这意味着员工更可能表达自己的想法，并相互开放沟通，因为焦点不在于归咎，而在于改进和分享想法，以实现共同目标。

最后，当你将所有这些因素结合起来时，你会自然而然地拓宽团队成员的技能。你为团队提供了扩展知识和进一步发展职业生涯的工具和能力。具有真正职业成长机会的组织是新员工寻找的最大亮点之一。DevOps 可以帮助你的组织在新员工中具备吸引力。

平衡稳定性与新功能的推出

在非 DevOps 环境中，通常会在发布新功能与保持系统稳定性之间产生冲突。开发团队的评估标准是向用户交付的更新数量，而运维团队的评估标准则是系统的整体健康状况。

在 DevOps 环境中，团队中的每个人都负责交付新功能以及确保稳定性。由于代码不会在开发结束后被扔给运维，基于共享代码库、持续集成、测试驱动技术以及自动化部署等方式的结合，使得应用程序代码、基础设施或配置中的问题能够在流程早期就暴露出来。

由于变更集较小，问题通常较为简单。DevOps 工程师可以使用实时系统性能数据，快速了解应用程序变更的影响。解决时间也得到缩短，因为团队成员无需等待其他团队进行故障排除和问题解决。

提高工作效率

在典型的 IT 环境中，人们常常浪费大量时间等待其他人或其他机器，或者反复解决相同的问题。员工更愿意提高工作效率，而浪费在无意义工作上的时间会导致沮丧和不满。当人们能够减少在无聊任务上的时间，更多地把时间花在为组织创造价值的事情上时，每个人都能受益。

DevOps 模型中的关键 IT 运维方面包括自动化部署和标准化的生产环境，这使得部署可预测，并使员工从日常重复任务中解放出来，去做更具价值的工作。例如，一家拥有超过 4000 名 IT 员工的大型金融服务公司，通过实施 DevOps 节省了超过 800 万美元，减少了 MTTR，并消除了遗留工具的维护。

现在我们已经更广泛地了解了组织为何转向 DevOps。接下来，让我们定义一下我们的虚构组织，以便更好地了解 DevOps 转型的实施。

定义我们的虚构组织

在我们开始讨论转型之旅之前，首先让我们定义一下我们合作的组织。我想向大家介绍Travelics。通过与 Travelics 的早期讨论，我们得知了一些他们的常见情况：

• 总部位于欧洲和北美的全球性组织。

• 拥有大约 4000 名员工。

• 为航空行业生产两款产品，一款专注于行李追踪，另一款则聚焦于运营洞察。

• 两个产品的团队规模大约有 15 名开发人员。

• 运维是一个共享实体，隶属于中央 IT 部门。

现在我们已经建立了一些关于 Travelics 的基础知识，接下来让我们深入了解一些更具体的信息以及他们试图实现的目标。

当前的运营模型

Travelics 目前的运营模型是由客户推动功能需求的提交到软件工程团队。这一过程通过与客户经理的互动以及工程师团队的行业经验来进行。所有需求都集中管理，并分配给负责该功能的团队。工作开始进行，并排队等待发布。

运维团队是一个共享实体，隶属于中央 IT 团队。他们依赖开发团队的文档来排查应用程序的问题。该应用程序目前正在进行转型，从一个部署在公共云环境中的单体应用程序，转变为一个更加云原生的架构，依赖微服务和多租户软件即服务模型。

目前，每个新客户都会部署虚拟机，如果客户购买了两个软件包，它们将分别部署在不同的实例中。

目前模型中存在的挑战

目前的工作方式为 Travelics 带来了许多挑战，其中最大的问题是它们在交付应用程序时的敏捷性不足。发布周期仅为每年两次；这通常导致部署失败并回滚应用程序，直到问题解决为止。此停机时间通常会持续约四小时。

另一个问题是代码质量：虽然开发人员技术精湛，但缺乏对彼此工作进行审核和监督的常规做法。这导致了 bug 的产生，并且工程团队背负着大量需要解决的技术债务。

缺乏可扩展性和云原生方法也是一个限制因素。这带来了严重的运营挑战，并且导致不同客户有不同的配置方式；应用程序的版本在所有客户中并不一致，一些客户甚至部署了不受支持的版本，因为他们不愿意允许公司进行升级，担心会发生停机故障。

DevOps 的理解在工程组织中各不相同，且在工程部门之外，很多员工可能对 DevOps 并不了解。虽然有一些人明白 DevOps 的概念，但普遍存在对转向这种新模式的犹豫。

未来目标

变革的驱动力是引入了一家提供类似服务的新组织。这个颠覆者规模较小，但能迅速交付新功能，并提供完全的“软件即服务”解决方案。Travelics 已经失去了三位大客户给这位竞争者。他们相信，通过变革，可以解决这些问题，并重新获得竞争力。

Travelics 的 DevOps 转型目标如下：

• 对产品发展的清晰愿景。

• 使团队能够独立工作，但共享实践的敏捷性

• 专注于更快的发布和提升质量

• 提高客户满意度

• 更快地实现新功能

• 降低故障发生率

• 转向一个更现代的、具有扩展能力的平台

总结而言，针对 Travelics 的 DevOps 转型需要从组织层面进行全面审视。这包括团队的结构以及运营方式。这些变革将是 Travelics 运作的根本，如果成功，将大大改变他们的工作方式。

现在，让我们开始 Travelics 的 DevOps 转型之旅。

DevOps 转型流程讲解

现在我们已经了解了 Travelics 组织的概况，以及他们的当前状况、未来的愿景和目标。我们可以开始与他们合作，帮助他们实现这些目标。

成功转型需要经过多个步骤；这是一个漫长的过程。转型大型企业的复杂性要求在最高层获得支持，以确保变革成功并实施所需的变革步骤。你在转型过程中应采取的步骤如下：

1. 举办初步规划研讨会。

2. 建立 DevOps 卓越中心。

3. 设置转型治理结构。

4. 建立一个信息采集流程。

5. 确定并启动试点项目。

6. 评估当前能力。

7. 执行转型练习。

8. 扩展 DevOps 转型。

现在，让我们更详细地了解这些步骤，并讨论与 Travelics 合作实现其目标的具体措施。

举办初步规划研讨会。

参与者必须包括所有涉及解决方案交付的团队。除了运营、安全和开发，还需要有业务参与。我总是建议这一阶段的研讨会由经验丰富的外部顾问或教练主导。关键在于获得高层的支持，并建立共同的目标和对 DevOps 计划的理解：

图 12.1 – 显示初步规划输入和输出的图示

对于 Travelics 来说，初步规划非常重要。记住我们之前提到过，除了少数几个人，许多人并不了解 DevOps，这也导致了他们对转向新工作方式的犹豫。

通常，多个小型的 DevOps 项目存在于孤岛中，并缺乏扩展到企业级的成熟度。设计思维是一种很好的方法，因为它利用了所有利益相关者的专业知识，使他们能够达成共识，并建立必要的支持。

现在我们将查看建立 DevOps 卓越中心所需的元素，这是 DevOps 采纳中的一个关键步骤。

建立 DevOps 卓越中心

创建卓越中心（CoE）是不充分的，如果它没有在适当的组织层级和企业权威下进行。必须由一位业务领导者来主导，且此领导者必须获得所有领域的支持和认同。所有交付领域的代表，以及供应商组织的代表，都是 CoE 的积极参与者。参与者必须慎重选择。

在图 12.1的基础上，我们现在可以添加一些其他元素，进一步定义所需的利益相关者，并更紧密地定义输出。

你应该注意图表中的时间线是自上而下的，这意味着从顶部开始进行对话。对于 Travelics 面临的转型挑战，我的建议是让首席执行官（CEO）或首席运营官（COO）从赞助角度负责这次转型。

提示

虽然时间线是自上而下的，但也没有问题从底向上获得支持。这只是建立正式卓越中心（CoE）的正式方式。

从转型的第一天开始，软件工程团队的高管、运营、开发部门的高级领导以及 CTO 或 CIO 等高层管理人员应该参与这些早期的讨论。

此阶段的输出是建立一个共同的心态，以推动 DevOps 转型。这将包括为需要完成的工作建立共同的目标、宗旨和优先事项。

进入流程的第三到第五天，我们的讨论需要发展到更高的细节层面，并包括项目的负责人，该负责人也是该项目的赞助人。这需要包括以下领域的代表：

• 应用程序负责人

• 企业架构

• 解决方案架构师

• 开发负责人

• 运营负责人

在接下来的两周内，将与 Travelics 公司进行工作坊，执行软件开发生命周期的价值流图绘制。其目标是更详细地了解组织的当前状态、开发状态、详细的交付流程以及目前与绩效相关的关键绩效指标。

在这个阶段，这些工作坊还着眼于从影响的角度扩展出需要优先考虑的领域。鉴于 Travelics 的需求，你认为哪个领域是他们的优先事项？

提示

Travelics 正面临客户流失和质量问题。这意味着，客户满意度和发布质量是需要立即改进的领域。

最后，在初步规划过程大约进行到 20 天时，之前的同一群人将重新聚集在一起，深入探讨工程在整个过程结束时将会呈现的样子。

考虑到我们对 Travelics 以及其高层目标和雄心的了解，这应当推动这些研讨会的进行，并帮助提供所需的细节，从而形成一个计划和前进的方向。

从这些最终规划研讨会中期望的输出将包括未来状态映射和 DevOps 的参考架构。此时，我们应该至少拥有一份实施路线图的草案，并且引入了高层目标。

在这一阶段，显而易见的是，当前的团队结构不适合目标，也与 Travelics 的目标不一致。因此，输出还包括提出的未来团队结构，以及明确任何角色和职责。

本节的最后部分包括制定推动转型的商业案例以及执行摘要，内容包括提案所涉及的内容。

我强烈建议最初阶段的 CoE 由外部经验丰富的合作伙伴领导，并逐步过渡给内部团队。初期阶段有助于巩固 CoE 的愿景和战略，以及建立支持这些战略的最佳实践。通常，从业务合作伙伴到内部利益相关者的过渡需要 12 到 24 个月的时间。

设置转型治理

这是改变组织文化最重要的一步。由于敏捷和 DevOps 的实施，实践者的角色和职责将发生变化。为了成功，他们需要意识、赋能和授权。至关重要的是，他们必须理解历史上有敌对关系的组织之间的协作，以打破这些组织之间的壁垒。KPI 必须从个人指标转向整体客户商业成果。

建立治理并不像外界所说的那样困难。您的项目治理由三大部分组成：沟通计划、赋能计划和已建立的 KPI。

您的沟通计划涉及定期公开您的项目目标、里程碑和成功。从赋能的角度来看，这需要帮助您的商业领导者理解敏捷的基本要素。赋能还包括开始为这些团队提供平台和工具链教育，以及深入培训 DevOps 方法，如持续集成、持续部署、持续测试、持续反馈和持续改进。

最后，您的 KPI 必须来自扎实的关键指标、衡量的良好策略以及频繁且详细的报告节奏以及转型的里程碑。

建立接入过程

第一个加入项目的迭代阶段为后续迭代设置了基调。这与工具和流程并不完全相关，更多的是关于工具和流程的适当规模化。加速器、工具链和开发方法的选择必须符合目的。一旦确定，接入过程必须在整个组织内进行沟通。收集反馈并在持续基础上进行演进和成熟。

可重用资产对于具有有效接入过程至关重要。架构模式、自动化脚本、操作手册以及基础设施资产都是可以定义和一次性在多种不同场景中重复使用的关键资产。

迭代的成功归结为最佳实践。这些最佳实践有助于强化一致性，并在不仅限于试点团队而且在转型扩展时提供可重复的结果。确保您已定义了基于主干的开发模式、源代码控制的分支和合并策略，以及围绕测试驱动开发的测试自动化模式和流程，这是此阶段成功的关键。

识别和启动试点

当应用于特定的应用程序组合或领域解决方案时，此步骤具有最佳成功机会。在此研讨会之前，我强烈建议开设一些工作会议，以确定一个开发工作领域，代表一个可以扩展到企业的投资组合。

此步骤的目标是与来自所有领域塔的参与者一起进行特定应用程序的价值流映射练习。这必须详细进行，以识别当前的端到端流程、工具、手动和自动化流程，以及涉及的技能和人员。

来自 CoE 的主题专家（SMEs）与项目团队的协作是项目接入过程的下一步。其目标是就“未来”过程提供建议，包括必要的工具、可重用资产、自动化以及来自运营、安全和其他相关领域的 SMEs。应用 Scrum 团队将由这些 SMEs 组成。程序的已确定 KPI 将在应用程序通过其开发/测试周期时进行捕获。这对与现有 KPI 进行比较绝对必要。

评估当前能力

理解您组织中存在的 DevOps 领域非常重要。您可能会发现某些领域比您意识到的成熟得多，您可以利用已经存在的一些良好实践，并在转型的其他部分中使用它们。

这些评估可以通过多种方式进行，但必须是可重复的，因为在整个转型过程中，你需要重复使用这些评估，以检查你的进展并在需要时进行调整。评估需要广泛且详细。

随着时间的推移，目标应是与团队一起进行评估，让他们使用一套卡片为每个问题打分，并在团队内讨论分数，以达成改进措施。

我发现的最佳评估之一来自 Marc Hornbeek，他是 Engineering DevOps（https://img1.wsimg.com/blobby/go/1c453e6b-8ce5-4e3d-a110-bba77def37c3/downloads/DevOps Practices Maturity Assessment v2.xlsx?ver=1619731527627） 的创始人。这个评估非常全面并且免费使用。它详细覆盖了 DevOps 实践的九个支柱，包括以下内容：

• 协作文化实践

• 持续安全实践

• 持续监控实践

• 为 DevOps 设计的实践

• 持续交付实践

• 弹性基础设施实践

• 持续测试实践

• 持续集成实践

• 协作式领导力实践

这些综合性问题提供了一个全面的性能视图。使用相同的评估可以清晰地看到性能的改进，并且你可以回顾跟踪这些改进：

图 12.2 – 成熟度评估的示例输出

正如你从前面的图示中看到的，输出为我们提供了一个全面的快照。每个问题都可以设定该问题对你组织的重要性，并评估当前得分。小组中的顶部条形图表示该领域的成熟度得分：

图 12.3 – 成熟度评估的示例详细输出

输出还提供了每个支柱的成熟度视图。这能让你通过计算每个领域的重要性与当前得分的差异，了解优先改进的区域，即得分最低的领域就是改进的重点。

定期我们也应该进行更详细的评估。这个变化要求提出不同的问题，并在其他某些重点领域进行挑战。更详细的评估关注以下领域：

• DevOps 培训实践

• DevOps 治理实践

• DevOps 价值流管理实践

• DevOps 应用性能监控实践

• DevOps SRE 实践

• DevOps 服务目录实践

• DevOps 应用发布自动化实践

• DevOps 多云实践

• DevOps 基础设施即代码实践

• DevOps 混合云实践

• DevOps 版本管理实践

这个高度详细的评估需要一些时间来完成。以往在与团队一起进行此评估时，我会安排一个早晨来完成讨论，并留出时间休息，以保持大家的精力。

与九大支柱输出类似，详细评估的输出在提供成熟度样本图表和表格概览方面是相同的，并突出优先关注的领域：

图 12.4 – 详细成熟度评估的示例输出

其他针对特定角色的评估也可以在 Engineering DevOps（engineeringdevops.com/documents#bf990569-1a3f-4eb4-bb3b-73073abf8a31）网站上找到。这些是非常有用的资源，可以帮助你的转型和改进之旅。

执行转型练习

执行推动转型前进所需的行动任务显然取决于计划研讨会的输出。回顾我们在 Travelics 的例子，现在让我们看看我们可以做哪些任务来帮助他们的 DevOps 转型。

• 巧克力、LEGO 和 Scrum 游戏

• 敏捷简介

• 向敏捷工作方式转型

• 重组团队结构

• 看看流程改进

• 实施 DevOps 实践

• 进入反馈循环

现在让我们特别看看这些领域，看看如何帮助 Travelics 实现他们的目标。

巧克力、LEGO 和 Scrum 游戏

初始的研讨会为与更广泛的受众共同设定 DevOps 的基础提供了机会，并且能够获得与你合作的人的信任。考虑使用模拟研讨会，而不是简单地通过幻灯片来推广 DevOps 的好处。

为了做到这一点，我会考虑 Dana Pylayeva（https://www.slideshare.net/danapylayeva/introduction-to-devops-with-lego-and-choco）提出的 巧克力、LEGO 和 Scrum 游戏。这个模拟游戏为参与者提供了听取他们在现实世界中面临的相同困境的机会，然后通过模拟情景来移除这些障碍，帮助他们看到移除这些障碍后的结果。

这是一个强大的练习，根据我的经验，它比简单的幻灯片演示更具说服力。游戏的目的是让人们分组坐下，然后通过一套角色卡片来确定具体活动，参与者可以在时间限制的练习中运行我们称之为冲刺的环节。

目标是将 LEGO 动物销售到市场上，并尽可能多地生产符合要求的 LEGO 动物。每当开始一个新的冲刺时，角色会发生变化，障碍会被移除，从而提高交付更多成果的机会。

敏捷简介

在本次会议中，面向 Travelics 的运营团队，我们直接面向那些通常对敏捷较为反感的人群。根据我的经验，开发团队更有可能接受敏捷工作方式。虽然敏捷原则来源于软件工程，但这并不意味着你不能与运营团队合作。

一个常见的误解是运营团队不能以敏捷的方式运作。在我个人的观点和经验中，这根本不正确。我将很快解释为什么以及如何解决一些运营团队在采用敏捷方法时常见的顾虑。我们从提出三个简单的问题开始（每个参与者都发放了一叠便签纸）：

• 为什么这样做是值得的？

• 有什么困难？

• 什么是敏捷？

每个参与者接着会有大约五分钟时间写下答案，并将其放在适当的标题下。然后我们会和团队进行讨论，谈论他们写下的笔记，并尝试开始一个开放的对话。在合适的时候，任何主持工作坊的人都可以运用自己在该领域的经验，提供示例来支持或反驳讨论内容。

如果可能的话，邀请一位来自已经进行敏捷转型的团队成员，或者是已经在实践我们试图强调的某些特质的团队成员。尽量邀请这个团队信任的人；在这个阶段，他们会比信任你的意见更有价值。幸运的是，我们在 Travelics 有一位符合这个条件的人。这个团队在开发后存在关闭工作的问题，而且他们的工作是基于票证的。正因如此，我们的 CoE 请求另一团队的成员来参与讨论。

这种方法有效的原因有几个，主要是因为我们举办工作坊的团队中有一位来自另一个正在进行敏捷转型的团队的成员，他能够证明我们所说的内容。大多数情况下，这位成员能够证明这个过程有效，并且值得付出实际的努力，而不仅仅是口头上的承诺。

转型为敏捷工作方式

团队转型的计划分为三个步骤。单独来看，每个步骤都很小，但合起来它们构成了整个旅程：

1. 引入每日站会。

2. 引入工作管理工具，如故事和 Scrumban。

3. 引入规划、冲刺和回顾。

在与 Travelics 进行的初始工作坊中，我们举办了团队的首次站会。每日站会的概念旨在回答三个问题：

• 我昨天做了什么工作？

• 我今天在做什么工作？

• 哪些问题阻碍了我？

在运动中，战术会议具有战略意义，确保每个人在比赛中保持信息畅通并紧密联系。对于技术团队来说，站会就是一个战术会议；它旨在强化我们和一个团队的文化与心态。

向团队突出问题通常会导致团队中的其他成员帮助解决问题。你的站会不应超过 15 分钟。不要进入你一天工作的细节。保持高层次，确保内容相关。突出问题，但不要详细讨论。

第二天，CoE 团队的某位成员参加了该团队举行的第二次日常站会。这个团队是前一天才开始的，会议大约持续了五分钟。大家都保持简洁，重点讨论了他们正在做的工作以及下一步的工作。阻碍因素在高层次上进行了讨论，并决定将对话移到线下。所以，在前一周的一次会议中，在不到 30 分钟的会议时间内，团队成员已经开始比之前更好地同步。

到现在为止，我们已经有了一些工作进展，敏捷的一个重要方面是引入回顾会议。事实上，大多数团队，无论其是否采用敏捷工作方式，都已经在进行某种形式的回顾，通常是团队会议。回顾会议或简称 retro 就是将注意力集中在上一个冲刺上。我们会根据 Scrum Master 进行的回顾类型，提出不同的问题。你可以运行多种类型的回顾，例如 4 Ls、速赛车、星星回顾等。

4 Ls 回顾法要求参与者在四个类别下添加卡片：喜欢、学到、缺乏、渴望。这要求团队讨论并突出正面和负面的方面。

速赛车回顾法，与以下示例相似，旨在突出加快团队进展的因素和减缓进展的因素。

星星回顾法，像 4 Ls 方法一样，要求团队聚焦于应该做得更多或更少的事情，或是开始、停止或继续做的事情。其原则是鼓励团队思考从不同实践中获得的价值。星星回顾法在进行持续反馈循环时非常重要。

在第一次回顾时，CoE 团队决定运行最基础的回顾方法之一；那就是帆船回顾法。在此方法中，我们画一艘帆船，添加一个锚，要求团队将能帮助团队加速的因素放在帆旁边，而将拖慢团队进度的因素放在锚旁边，以下图所示：

图 12.5 – 示例图，展示了帆船回顾的概念

这个练习非常简单，团队的反馈是他们喜欢日常站会；他们也喜欢了解团队中其他成员的工作内容，以及看板工作方式，能够直观地展示工作进展。

团队不喜欢的是额外的会议时间，此外，有时感觉站会时间过长，且其价值可能没有预期的高。

重要说明

虽然我们在敏捷中使用了大量统计数据，但即便没有过多关注统计数据，你仍然可以在教学所需技能和工作方式的过程中取得良好的进展，并看到改进。指标的改进会随着时间的推移逐步实现。

听起来有些粗暴，但当你从根本上改变组织的工作方式时，宣传是非常重要的。考虑在办公室环境中张贴海报，并通过通信渠道发布它们。你可以使用来自Dandy People（dandypeople.com/posters）的免费海报，作为传播信息的工具。

重组团队结构

通过与 Travelics 的讨论以及我们对他们目标的理解，很明显他们当前的团队结构无法适应。根本性的变化之一是从项目视角转向以产品为导向的视角。

产品视角使我们能够引入产品管理角色，帮助管理和优先处理反馈，同时也帮助我们利用市场情报来驱动团队在优先事项上的决策：

图 12.6 – Spotify 模型用于扩展敏捷的图示

接下来是希望通过协作将人们聚集在一起，并具备扩展这些团队的能力。对于 Travelics 来说，一种适合解决这一挑战的方法可能是使用Spotify 模型（www.atlassian.com/agile/agile-at-scale/spotify）。这引入了小队、部落、章节和行会等术语的使用。

小队

通俗来说，小队就是一群开发人员。在许多方面，小队类似于 Scrum 团队，它的设立目的是让团队感觉像一个小型创业公司。这些团队通常会坐在一起，具备设计、开发、测试和发布生产所需的所有技能和工具。小队将决定他们的工作方式，这意味着有些会使用 Scrum 冲刺，有些会使用看板，还有些会使用称为 Scrumban 的组合方式。

每个小队都有一个特定的目标，比如开发应用程序的某个特定功能、管理公共网站、编写移动应用程序或其他任务。不同的小队甚至可能负责用户体验的不同方面。

小队还被鼓励使用诸如最小可行产品（MVP）等原则，这意味着要早发布、频繁发布。我记得在我第一次阅读相关主题的文章时，Arthur von Kriegenbergh（medium.com/agile-series/agile-series-how-we-work-think-it-build-it-ship-it-tweak-it-afrogleap-1afb080dedab）曾引用过一个口号：Think it, build it, ship it, tweak it。由于每个小队都专注于一个使命和一个产品组件，并且持续时间较长，因此他们发展成了关键领域的专家。

部落

部落是由多个小队组成的集合，而这些部落都是致力于产品相关部分的小队。例如，在 Spotify 的案例中，我们所有的小队可能会属于一个桌面应用程序、桌面 UI 或其他相关的部落；你能理解我的意思。每个部落也有一个部落领导者，负责确保部落拥有小队所需的一切资源。理想情况下，部落中的所有小队应该尽可能坐在同一个物理位置，公共区域也应鼓励小队之间的协作。

你听说过邓巴数字吗？理想情况下，部落的规模应该根据这一理论来设定。根据这一理论，大多数人无法维持与超过 100 人的社交关系。当团体规模超过这个数字时，限制性的规则、政治和额外的管理层会增加官僚主义和其他低效的领域。因此，部落的设计应确保成员少于 100 人。

规模化和高度自治所带来的其中一个挑战是经济损失。例如，一个小组中的开发人员可能正在处理一个问题，而这个问题上周已被另一个小组的开发人员解决。这正是章节和公会设计的目的所在。

章节

章节就像公会一样，是将公司凝聚在一起的“粘合剂”。毕竟，如果小队和部落之间没有任何沟通，你的公司或许就会被分割成多个小公司。章节和公会让你在不放弃太多自治权的情况下，享受到规模经济的好处。

因此，一个章节是由一群具有相似技能的人组成，他们在相同领域或同一个部落内工作。这意味着开发人员、测试人员、安全专家以及任何其他角色都能从与自己技能相似的其他人在同一部落中的协作中受益；这种“粘合剂”意味着在一个章节内，你能够在自己的领域中拥有深厚的专业知识，并能够分享技能并借助其他理解你所从事领域的人的力量。

公会

公会更类似于社区组织。公会是一个想要分享知识、工具、代码和实践的人的集合。公会遍布整个组织，而章节则是本地化于部落的。你可以在组织中拥有任意数量的公会；例如，考虑以下示例：

• 测试公会

• 云技术公会

• Scrum 公会

• 敏捷教练公会

这一切听起来不觉得像一个矩阵式组织吗？确实是，但并不是你熟悉的那种方式。具有相似技能的人通常被组织成职能团队，然后分配到不同的项目中，向团队经理报告，而团队经理再向该领域的高级领导汇报。我们所创建并在其中工作的矩阵是面向交付的。

从两个维度来考虑：水平维度用于共享知识、工具和代码，垂直维度用于共享代码。垂直维度最为重要，它是人们合作和组织的地方，用以创造出色的产品。这描述了人们如何被物理地安排，以及他们大部分时间都在哪里度过。可以把垂直维度看作是做什么，水平维度看作是怎么做。矩阵结构确保每个小组成员都能获得有关下一步做什么和如何做好的指导。

实施 DevOps 实践

现在，获得正确的实践并通过正确的指标支持已成为 Travelics 的焦点。运用我们在本章学到的知识，我们可以建立起相应的指标。

在我们讨论的第三章《衡量 DevOps 成功》中的许多指标，在这里得到了更加明确的体现。记住我们对 Travelics 目标的理解。简单来说，他们希望提高质量、增加开发速度，降低故障率或提高稳定性。

我们讨论的所有指标都可以归纳为这三大类。以下是我们可以提出的一些指标，帮助 Travelics 在开始实施 DevOps 实践时衡量其表现：

• 前置时间——Travelics 希望提高市场推出的速度。这个指标帮助他们理解从概念到完成在待办事项列表上的时间。我们为该指标设定的目标是 60 天；随着成熟度的提高，未来这一时间应该会减少。

• 部署失败率——还记得客户对过时软件和新发布版本导致停机的抱怨吗？这个指标将帮助直接跟踪这个问题，并随着时间的推移，通过专注于管道、代码质量以及更多增量发布来改进。我们为该指标设定的目标是 1%。

• 单元测试覆盖率——改进测试是提高质量的一种好方法，在发布过程中引入测试覆盖率和测试通过率的质量门槛是提升质量的关键。我们为该指标设定的目标是 95%。

• 缺陷老化——Travelics 也面临着大量技术债务的问题。设定一个关于缺陷年龄的指标对于减少这个数字至关重要，同时引入技术性冲刺来解决技术债务。我们为该指标设定的目标是 7 天。

• 平均恢复时间（MTTR）——为了解决停机问题，衡量 MTTR 将重点关注恢复时间并加以改进。它还有助于推动团队内自动化恢复的水平，并帮助关注导致更多停机的缺失要素。

• 每次部署的事件数 – 最后一个有助于 Travelics 的指标是查看每次部署所产生的支持事件数。这有助于跟踪客户的满意度，并与发布策略保持一致，同时也有助于确定可以进一步改进的地方。

这也是你引入工具来帮助确定流程自动化方向的阶段。当你有了指标的基准，引入工具有助于你进一步识别可以改进的领域。

进入反馈循环

最后，在这个阶段，你已经建立的持续改进和反馈循环应该更加严格地启动，并努力发展转型团队所创建的内容，将组织推向更广泛的成功。

在转型过程中，你会学到大量关于组织、其所使用的流程以及其中人员的知识。所有这些学习对于反馈 DevOps 的持续投资以及 Travelics 的持续成功至关重要。

扩展 DevOps 转型

倒数第二步是从试点指标中获取反馈，并通过运行多个发布列车来自不同的应用程序组合来扩展这些反馈。仅仅执行每日构建和自动化部署是不够的。持续的反馈和优化是 DevOps 拼图的最后一块。

注意，我提到这是倒数第二步。实际上，你永远不应该觉得完成了；仅仅因为你已经完成了转型的谈判，并不意味着一切就结束了。这是一个机会，可以将你从试点小组中学到的内容反馈给赞助商、产品负责人和利益相关者。

总结

在本章中，我们提供了本书的关键学习内容总结，并针对一家虚构的旅行公司提供了具体的实施指导。这些建议帮助 Travelics 朝着正确的方向前进，在经过 18 个月的努力后，他们现在已经能够稳定达成指标目标，并且计划进一步提升 CoE 在组织内开发的内容。

随着本章以及整本书的结束，我想感谢你与我一起踏上 DevOps 转型之旅。希望你觉得这本书的信息丰富，并能够将我们共同学到的内容带回到你的组织中，推动变革。