持续测试-质量-安全和反馈-全-

持续测试、质量、安全和反馈（全）

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

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

在快速发展的软件开发领域，持续测试、质量、安全性和反馈的整合对于希望实现成功数字化转型的组织来说，已成为关键因素。 持续测试、质量、安全性和反馈 是一本全面的指南，深入探讨了将这些实践嵌入 DevOps、DevSecOps 和 SRE 方法论核心所必需的核心策略。

本书首先为理解持续测试、质量、安全性和反馈在数字化转型中的关键角色奠定基础。 它提供了历史视角，展示了这些策略如何从传统方法发展成为敏捷、DevOps、DevSecOps 和 SRE 实践的重要组成部分。 这些基础知识对专业人士来说至关重要，有助于他们认识到将这些持续策略融入工作流程中，从而提升软件交付的速度、效率和可靠性。 软件交付。

本书的一个优势在于它对持续测试、质量、安全性和反馈的清晰、以结果为导向的定义。 这些定义帮助专业人士在其组织中有效地实施这些策略。 通过将这些实践与可衡量的业务结果对齐，尤其是与DevOps 研究协会 (DORA)所认可的结果对齐，本书确保您可以根据这些策略对关键绩效指标的影响评估并调整其方法论。 这种方法不仅提供了清晰性，还强调了关注结果的重要性，而不仅仅是 程序性操作。

本书的核心内容致力于探索支撑持续测试、质量、安全性和反馈的指导原则和支柱。 通过详细的阐述，您将获得将测试整合到软件开发生命周期的每个阶段、采取主动的质量和安全策略，并培养持续反馈与改进文化的知识。 这些章节极为宝贵，提供了实践性的见解和策略，帮助您克服常见挑战，利用最佳实践打造高质量、安全且以用户为中心的 软件产品。

本书不仅是一本理论指南；它是变革的催化剂。 它鼓励专业人士接受持续策略，确保数字化转型具有韧性、以用户为中心， 并且安全。

本书的适用人群

无论你是经验丰富的专家还是该领域的新手，本书都提供了宝贵的见解和技能，将提升你在持续软件开发、交付和运营方面的方法。 本书是任何希望在其 DevOps、DevSecOps 和 SRE 实践中实施或增强持续测试、质量、安全性和反馈的人的必备资源。 它提供了实现数字化转型中效率、可靠性和成功的实用指南和全面框架，使其成为致力于软件开发和运营卓越的专业人士的必读书籍。 并且，运营。

本书内容

第一章，持续测试、质量、安全性和反馈的原则，解释了这些策略如何对利用持续开发实践（如敏捷）、持续交付实践（如 DevOps 和 DevSecOps）以及持续运营实践（如 SRE）进行数字化转型至关重要。 如 SRE。

第二章，持续测试、质量、安全性和反馈的重要性，解释了为什么持续测试、质量、安全性和反馈策略对 DevOps、DevSecOps 和 SRE 至关重要。 它解释了 DevOps、DevSecOps 和 SRE 的原则和支柱如何依赖于持续测试、质量、安全性、 和反馈的原则和支柱。

第三章，持续测试、质量、安全性和反馈的经验与陷阱， 通过我自己的经验举例，解释了使用案例、经验教训和需要避免的陷阱，包括避免陷阱的策略。 避免陷阱的策略。

第四章，持续测试、质量、安全性和反馈的工程方法， 解释了一个系统化、规范化的工程方法，用于规划持续测试、质量、安全性和 反馈解决方案。

第五章，确定转型目标，解释了一种规范性的方法，用于确定适合特定组织、产品和服务的持续测试、质量、安全性和反馈转型的目标。 描述了帮助确定目标的工具 。

第六章, 发现与基准评估, 解释了发现与评估组织在转型过程中，涉及持续测试、质量、安全和 反馈的人员、流程和技术现状的方法论和工具。

第七章, 选择工具平台与工具, 为你提供了深刻的理解，帮助你了解如何利用每个平台和工具，在面对不断变化的 技术挑战时，促进持续改进和韧性文化。

第八章, 将人工智能/机器学习应用于持续测试、质量、安全和反馈, 深入探讨了人工智能 (AI) 和机器学习 (ML) 在软件开发生命周期中的变革性作用，特别关注如何增强持续测试、质量、安全和 反馈实践。

第九章, 与 DevOps、DevSecOps 和 SRE 集成的使用案例, 介绍了在这些框架中持续测试、持续质量、持续安全和持续反馈的实际应用，并通过使用案例展示了组织如何转型到更高水平的 运营成熟度。

第十章, 构建实施路线图, 解释了如何为组织内持续测试、质量、安全和反馈的实施创建有效的路线图，确保你的数字化转型之旅既具战略性，又与 组织目标对齐。

第十一章, 理解转型实施模式, 深入探讨了实施模式的世界，这些结构化方法已被证明能够增强组织在提升持续测试、质量、安全和 反馈能力方面的战略路线图的部署和成功。

第十二章, 衡量进展与成果，重点介绍了在组织实施和改进其持续测试、质量、安全和 反馈能力时，衡量进展和成果的重要方法和框架。

第十三章, 新兴趋势，描述了正在重塑软件开发中的持续测试、质量、安全和反馈的新兴趋势。

第十四章, 探索持续学习和改进，讲述了在软件开发和运营的关键领域：持续测试、质量、安全 和反馈方面，有效的持续学习和改进策略。

要充分利用本书

没有特定的代码文件、工具或软件应用程序是理解或使用本书所必需的。 然而，本书提供了一些示例、模板和工具，以补充书中的材料 位于 https://github.com/PacktPublishing/Continuous-Testing-Quality-Security-and-Feedback。

注意

对于对作者咨询服务感兴趣的人，请访问 www.engineeringdevops.com 以获取更多信息。

使用的约定

本书中使用了许多文本约定。

粗体：表示一个新术语、重要词汇或您在屏幕上看到的词汇。 例如，菜单或对话框中的词语会以 粗体显示。这里有一个例子：“从 管理 面板中选择 系统信息 。”

提示或重要说明

看起来像这样。

取得联系

我们的读者反馈 随时欢迎。

总体反馈：如果您对本书的任何方面有疑问，请发送电子邮件至 customercare@packtpub.com 并在主题中提到书名。 您的信息。

勘误：尽管我们已经尽力确保内容的准确性，但错误仍然可能发生。 如果你在本书中发现错误，我们将不胜感激，如果你能向我们报告。 请访问 www.packtpub.com/support/errata 并填写 表格。

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

如果你有兴趣成为作者：如果你在某个领域有专长，并且有兴趣撰写或为书籍贡献内容，请 访问 authors.packtpub.com。

分享你的想法

在你阅读完 持续测试、质量、安全性与反馈后，我们很想听听你的想法！ 请点击这里直接前往亚马逊书评页面并分享 你的反馈。

你的评价对我们和技术社区很重要，它将帮助我们确保我们提供的内容质量卓越。

下载本书的免费 PDF 版本

感谢你购买 本书！

你喜欢在路上阅读，但又无法随时携带印刷版书籍吗？

你的电子书购买是否无法在你选择的设备上使用？

别担心，现在购买每本 Packt 书籍，你都可以免费获得该书的无 DRM PDF 版本。

随时随地，任何设备上都可以阅读。 在你最喜欢的技术书籍中直接搜索、复制和粘贴代码到你的应用程序中。

福利不仅仅到此为止，你还可以每天在你的 收件箱中获得独家折扣、新闻通讯以及精彩的免费内容。

按照以下简单步骤获得 这些好处：

1. 扫描二维码或访问下面的 链接

https://packt.link/free-ebook/9781835462249

1. 提交你的购买证明

2. 就是这样！ 我们会将您的免费 PDF 和其他福利直接发送到您的 电子邮件。

第一部分：理解持续测试、质量、安全性和反馈

第一部分 本书深入探讨了将持续战略融入软件开发和运维所需的基础概念。 它首先解释了持续测试、质量、安全性和反馈的原则，强调它们在支持敏捷、DevOps、DevSecOps 和 SRE 实践中的关键作用。 本节通过概述这些策略的历史背景和演变，为读者奠定基础，突出它们如何在现代软件框架中成为提高效率、安全性和 用户响应能力的必要因素。

此外，本书讨论了这些持续战略在维护和提高软件开发过程中的质量、安全性和反馈机制中的重要性。 它通过真实的例子和从个人经验中学到的教训，说明了常见的陷阱以及避免这些陷阱的有效策略。 本部分帮助理解理论方面的内容，并提供了实施这些策略的实用见解，以实现强有力的 数字化转型。

这一部分包括以下章节： 以下章节：

• 第一章, 持续测试、质量、安全性和反馈的原则

• 第二章, 持续测试、质量、安全性和反馈的重要性

• 第三章, 持续测试、质量、安全性和反馈的经验与陷阱

第一章：持续测试、质量、安全性和反馈的原则

本章解释了持续战略对于利用持续开发实践（即敏捷）、持续交付实践（即 DevOps 和 DevSecOps）以及持续运维实践（即 站点可靠性工程（SRE））的数字化转型至关重要。

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

• 引入持续测试、持续质量、持续安全性和 持续反馈

• 定义持续测试、质量、安全性、 和反馈

• 持续测试的指导原则和支柱 持续测试的指导原则和支柱

• 持续质量的指导原则和支柱 持续质量的指导原则和支柱

• 持续安全的指导原则和支柱 持续安全的指导原则和支柱

• 持续反馈的指导原则和支柱 持续反馈的指导原则和支柱

让我们 开始吧！

引入持续测试、质量、安全性和反馈

本节介绍 现代持续测试、质量、安全性和反馈策略的关键基础概念 及历史背景。 它还解释了为什么 DevOps、DevSecOps 和 SRE 实践推动了持续测试、质量、安全性 和反馈的需求。

测试、质量、安全性和反馈的基础

测试、质量、安全性和 反馈一直是软件 开发、交付和 运维的核心组成部分，自 软件诞生以来便如此。 图 1**.1 及接下来的段落展示了一些历史实例， 突显了这一点。

图 1.1 – 测试、质量、安全性和反馈的早期示例

• 测试与质量 – ENIAC（1940 年代）：即便是第一台通用电子计算机 ENIAC，测试和调试也至关重要。 这台机器必须为每个新任务进行精心编程和测试，这一过程常常需要数天时间。 这一早期的示例强调了测试在软件质量保证中的重要性 。

• 安全性 – 莫里斯蠕虫（1988 年）：莫里斯蠕虫是影响世界初期互联网基础设施的首批已知蠕虫之一，突显了在软件设计中关注安全性的必要性。 它利用了已知的漏洞，强调了在网络和 软件开发中考虑安全性的重要性。

• 反馈 – IBM 早期的软件开发（1950 年代–1960 年代）：在商业软件的早期，像 IBM 这样的机构和公司意识到用户反馈在软件开发中的重要性。 用户的反馈帮助塑造了软件产品的演变，使其更加符合用户需求，并与 业务需求对接。

然而，传统方法也存在一些缺点。 接下来，我们来看一下 这些缺点。

传统的测试、质量、安全性和反馈策略的弱点

ENIAC、莫里斯蠕虫以及 IBM 早期的软件开发 的历史案例凸显了传统方法在测试、质量、安全性和 反馈方面的关键弱点：

• 测试与质量 – ENIAC（1940 年代）：在 ENIAC 时代，测试和调试是手工完成的，且耗时繁琐。 每项新任务都需要精细的编程和测试，展示了面对复杂任务时传统测试方法的低效。 缺乏自动化测试工具和集成测试实践意味着确保质量是一个劳动密集型的过程，显著拖慢了开发 和部署的速度。

• 安全性 – 莫里斯蠕虫（1988 年）：传统方法通常将安全性视为事后考虑。 莫里斯蠕虫利用已知的漏洞，突显了反应性安全措施的不足，相比之下，前瞻性安全实践显得尤为重要。 安全性并未纳入软件开发生命周期。 这一事件强调了在开发的每个阶段都要考虑安全性的重要性， 从设计到部署。

• 反馈 – IBM 早期的软件开发（1950 年代–1960 年代）：传统软件开发常常受到延迟反馈循环的困扰。 反馈通常是在发布后收集的，这限制了在开发阶段进行以用户为中心的改进的能力。 在开发过程中缺乏与 用户的持续互动。 反馈未能系统地融入到开发周期中，导致产品可能无法完全符合用户需求 或期望。

这些历史实例展示了传统方法的关键弱点：

• 测试和质量：手动、耗时的测试方法，缺乏自动化，以及未能将测试集成到开发 生命周期中。

• 安全：一种对安全的反应式方法，将其视为事后的思考，而非开发过程中的一个重要组成部分。 开发过程。

• 反馈：反馈机制的延迟以及缺乏持续的用户参与，导致软件开发与 用户需求之间的脱节。

现在，让我们来看一下，随着软件框架变得更加持续，测试、质量、安全和反馈是如何演变的。

测试、质量、安全和反馈的演变，朝着持续战略发展

软件开发、交付和运营向持续开发、交付和运营方法（如敏捷、DevOps、DevSecOps 和 SRE）演变的过程，受到多个关键因素和 行业趋势的推动：

• 对速度和敏捷性需求的增加：随着市场和技术的快速发展，企业面临着更大的压力，需要更快地交付产品和服务。 这种对速度的需求导致了敏捷方法论的采纳，敏捷方法注重迭代开发、灵活性和软件的快速交付。 软件。

• 从项目思维向产品思维的转变：传统的软件开发通常是基于项目的，有明确的开始和结束。 然而，行业逐渐转向产品思维，即软件持续开发、改进和维护。 软件产品的持续性要求采用敏捷 和 DevOps 等方法论。

• 现代软件系统的复杂性：随着软件系统复杂性的增加，分布式架构（如微服务）要求采用更多协作和集成的方法。 DevOps 作为一种回应应运而生，强调开发 （Dev） 、 质量 （QA） 、安全 （Sec） 和运维 （Ops）团队之间的协作。

• 对更快发布周期的需求：随着竞争加剧和技术进步，快速发布更新和功能的能力变成了一项竞争优势。 这导致了 对 持续集成/持续交付 （CI/CD）实践在 DevOps 框架中的应用。

• 云计算和自动化的兴起：云计算的出现以及自动化工具的日益普及，使得软件开发、交付和运维过程更加高效和可扩展。 这些技术是 DevOps、DevSecOps 和 SRE 实践的基础。

• 安全性日益重要：随着网络威胁和安全漏洞的增加，将安全性集成到软件开发生命周期中变得至关重要。 DevSecOps 通过在开发项目一开始就将安全（Sec）作为关键组成部分，演变自 DevOps。 开发项目。

• 关注可靠性与用户体验：随着用户对可靠性和性能的期望不断增加，关注点转向确保软件不仅能够快速交付，而且还要可靠。 这促使了 SRE 的出现，它将软件工程和 IT 运维的各个方面融合在一起，创建可扩展且高度可靠的 软件系统。

• 反馈与持续改进：从用户获取持续反馈并迅速适应这些反馈的需求变得至关重要。 敏捷、DevOps 和 SRE 方法论都强调持续监控、反馈和改进，以使软件产品更紧密地与用户需求和 业务目标对齐。

• 文化和组织的转变：这些方法论还代表了组织对软件开发、交付和运营的看法的文化转变。 它们推动了协作型跨职能团队的形成，倡导快速失败的思维方式，并强调持续学习 和改进。

向敏捷、DevOps、DevSecOps 和 SRE 的演变，源于在快速变化的技术环境中对更快、更高效、更可靠的软件交付的需求。 这些方法论应对了软件系统日益复杂化、对速度和可靠性的需求、将安全性集成到开发过程中的要求，以及持续反馈 和改进的重要性。

本节中展示的历史实例表明，从计算机的早期阶段开始，测试、质量、安全性和反馈策略一直是软件开发、交付和运营的关键组成部分。 这些策略随着技术的发展而演变，但始终是可靠、安全、以用户为中心的软件开发、交付和维护的不可或缺的一部分。

传统的测试、质量、安全性和反馈策略的不足，促使了更为集成、自动化和以用户为中心的软件开发方法的演变，如敏捷、DevOps 和 DevSecOps，它们通过将测试、质量保证、安全性和反馈深度 并持续地嵌入到软件 生命周期中来解决这些不足。

接下来的章节将解释最初的测试、质量、安全性和反馈策略是如何演变的，以跟上现代持续开发、交付、 以及运营的步伐。

向持续测试、质量、安全性和反馈的演变

敏捷、DevOps、DevSecOps 和 SRE 实践的出现，迫使测试、质量、安全性和反馈策略经历了重大的演变。 这种演变，如 图 1**.2所示，受到技术、业务需求和软件开发、交付、 以及运营的持续性方法驱动。

图 1.2 – 持续测试、质量、安全性和反馈

让我们来探讨那些需要演变成“持续性”的测试、质量、安全性和反馈策略的具体属性：

• 在 Agile、DevOps、DevSecOps 和 SRE 背景下的测试

  • 更快的发布周期：传统的 测试方法对于 DevOps 中快速部署的周期来说过于缓慢。 CI/CD 管道要求自动化、更频繁和更复杂的测试策略，以确保新功能和更新能够快速部署，而不 影响质量。

  • Shift-left 测试：DevOps 倡导在 软件开发生命周期中向左转移 ，意味着测试从一开始就早早开始。 这种转变确保了缺陷能够尽早被发现并解决，从而减少成本 和市场投入时间。

  • 可靠性和可用性：在 SRE 中，重点是服务的可靠性、可用性和性能。 这里的测试不仅包括功能测试，还包括负载、性能和弹性测试，以确保系统能够处理 现实世界的场景。

• 在 Agile、DevOps、DevSecOps 和 SRE 时代的质量

  • 以用户为中心的焦点：DevOps 的快速和迭代性特点要求采用以用户为中心的质量管理方式。 功能和更新不断推出，这些增量的质量直接影响到 用户体验。

  • 监控和性能指标：SRE 强调使用实时监控和性能指标 以维护和提升服务质量。 这些指标对于基于数据的决策至关重要， 尤其是在系统改进方面。

• 在 Agile、DevOps、DevSecOps 和 SRE 背景下的安全性

  • 持续的安全性：在快速变化的 DevOps 环境中，传统的在软件开发生命周期结束时处理安全性的模式已不再可行。 DevSecOps 将安全集成到开发过程的每个阶段，而 SecOps 在产品中集成安全保护；二者共同确保 持续的安全性。

  • 自动化安全测试：安全测试中的自动化对于 DevSecOps 和 SecOps 至关重要。 自动扫描原始代码和第三方代码中的漏洞的工具被集成到 CI/CD 流水线中，允许你立即发现并修复安全问题。 还包括渗透测试的自动化，以及监控和保护生产中操作软件的工具，以识别和缓解安全入侵，从而增强对已部署软件系统的防护。 在生产中。

  • 合规性即代码：在 DevSecOps 中，合规性要求被编码化，以便可以在整个开发和运营生命周期中自动且一致地执行。

• 敏捷、DevOps、DevSecOps 中的反馈 以及 SRE：

  • 持续反馈循环：DevOps、DevSecOps 和 SRE 实践依赖于开发、运营和用户之间的持续反馈循环 。 这种反馈对于软件交付和部署到生产运营的快速迭代至关重要。

  • 无责事后分析：SRE 实践 如在事件后进行无责事后分析，促进了学习和改进的文化。 这种方法使团队能够理解发生了什么问题，以及如何在未来避免，而不是聚焦于 个人的错误。

  • 跨职能协作：这些方法中的反馈不仅仅是用户输入，还包括 跨职能团队的协作。 在开发、运营、安全性及其他利益相关者之间共享见解和知识是改善流程 和结果的关键。

图 1**.3 展示了持续测试、质量、安全性和反馈相对于持续开发（敏捷）、持续交付（DevOps 和 DevSecOps）以及持续运营（SRE）之间的关系。 该图显示，持续测试、质量和安全性在开发、交付和运营阶段是活跃的。 它还显示，来自每个阶段的结果，这些策略所带来的结果，提供了持续的反馈数据，这些数据影响着每个阶段的持续迭代。

图 1.3 – 持续测试、质量、安全性和反馈关系

在 DevOps、DevSecOps 和 SRE 背景下，测试、质量、安全性和反馈的演变反映了软件开发和运维的更广泛转变。 这一转变是朝着更持续、集成、自动化和以用户为中心的实践方向发展，旨在以更快的速度和更高的可靠性交付高质量、安全的软件。

定义持续测试、质量、安全性和反馈

本节解释了定义持续测试、质量、安全性和反馈的重要性以及与此相关的挑战，随后提供了持续测试、质量、安全性、 和反馈的实际定义。

对测试、质量、安全性和反馈的定义需求

对于持续测试、质量、安全性和 反馈，并没有标准定义，就像对于 DevOps、DevOps 或 SRE 也没有标准定义一样。 然而，在组织向成熟的 DevOps、DevSecOps 和 SRE 实践转型的背景下，定义持续测试、质量、安全性和 反馈是至关重要的，原因有很多。 定义为衡量和评估数字化转型中人员、流程和技术维度的表现和进展提供了基础。 本节解释了拥有（或没有）这些清晰定义的重要性、潜在好处和后果。

定义的重要性

让我们 理解 为什么 定义 是 重要的：

• 衡量的基础：清晰的定义使组织能够建立具体、可衡量的标准来评估其实践的有效性。 这是 持续改进的基础。

• 共同理解：定义确保所有参与者对期望的内容有共同的理解，减少跨团队之间的模糊性和不一致。

• 目标对齐：明确的概念有助于对齐各个团队（开发、运维和安全）的目标，以统一的目标为方向，这对于像 DevOps 和 DevSecOps 这样的协作环境至关重要。

清晰定义的好处

让我们 来看一看 定义的 好处：

• 性能跟踪：通过明确的定义，组织可以跟踪其 DevOps、DevSecOps 或 SRE 项目的绩效，识别成功的领域和需要改进的地方。

• 改进的协作：定义有助于促进团队之间的更好沟通与协作，因为每个人都基于共同理解的关键概念进行工作。

• 聚焦的培训和发展：定义有助于有针对性地进行培训和发展，专注于通过这些定义和指标识别出的特定领域。

• 增强的流程优化：组织能够更有效地识别并实施流程优化，从而提高效率，降低成本， 并产生更高质量的产出。

缺乏明确定义的后果

接下来，我们将了解当目标没有明确界定时会发生什么：

• 测量挑战：没有明确的定义，就很难衡量和评估 DevOps、DevSecOps 和 SRE 实践的有效性，这可能导致效率低下和 未解决的问题。

• 目标不一致：模糊的定义可能导致团队之间目标和期望不一致，从而引发冲突和 降低协同效应。

• 资源分配无效：模糊的定义使得难以识别应将资源分配到哪里以获得最大影响，可能导致浪费的努力 和投资。

• 责任减少：在没有明确成功标准的情况下，很难追究团队和个人在其角色和职责中的责任。 这会导致责任不清。

清晰且明确的持续测试、质量、安全和反馈的定义为设定和衡量绩效指标提供了必要的基础，确保每个人都朝着共同的目标一致，促进持续改进。 缺乏这些定义可能会阻碍在这些领域实践成熟的进展。

定义持续测试、质量、安全和反馈的挑战

标准化连续测试、质量、安全性和反馈的定义对于任何组织来说都是一项具有挑战性的任务，因为软件开发和部署环境的动态性和多样性。 虽然这些过程可以被广泛定义，但它们的实施和影响并没有绝对的特征。 毕竟，根本没有所谓的 100%的测试、质量、安全性或反馈。 这些方面总是相对于特定的目标和背景。 以下是 这些挑战：

• 定义 连续测试的挑战：

  • 多样化的测试需求：软件测试的范围和方法差异很大，取决于软件类型、预期用途、用户群体以及采用的开发方法论。 例如，航空软件等安全关键系统的测试与消费者 移动应用的测试有很大的不同。

  • 不断发展的技术：随着技术的进步，测试方法也在不断发展。 新的范式，如人工智能和物联网，带来了新的测试挑战，而这些挑战在传统 的测试框架中并未被考虑到。

• 定义 连续质量的挑战：

  • 主观性：质量本质上是主观的，不同的利益相关者可能有不同的看法。 对于开发人员来说，质量可能意味着代码的可读性和可维护性，而对于最终用户来说，质量关乎可用性 和性能。

  • 依赖于上下文：快速开发的原型的质量标准可能与成熟的、面向客户的产品的质量标准不同。 开发和部署的背景在决定什么构成质量方面起着至关重要的作用。

• 定义 连续安全性的挑战：

  • 不断变化的威胁环境：网络安全威胁的环境在不断发展变化。 今天被认为安全的东西，明天可能就不再安全，因此无法实现 绝对的安全性。

  • 风险管理：安全性通常是关于管理风险，而非消除风险。 不同的应用程序根据其面临的威胁和处理的数据敏感性，需要不同级别的安全性。 它们所处理的数据的敏感性决定了所需的安全性。

• 定义持续反馈的挑战 ：持续反馈的挑战：

  • 多样化的来源和解释：反馈 可以来自不同的来源（用户、利益相关者和自动化系统），并且可以有多种解释。 在某种情境下有价值的反馈，在另一个情境中可能是无关的。 。

  • 持续适应：反馈机制必须适应用户和市场需求与期望的变化。 这意味着收集和实施反馈的过程永远不会完成，并且始终处于变化之中。 不断变化。

虽然可以定义持续交付和持续运营的测试、质量、安全和反馈流程，但它们并不具有绝对的特性。 它们高度依赖于具体的背景，并且必须与特定的目标、技术环境和用户期望对齐。 这种固有的变动性和不断适应的需求，使得在所有软件开发和 运营场景中标准化这些概念变得具有挑战性。

持续测试、质量、安全和反馈的定义

在动态变化的软件工程领域，特别是在持续交付（DevOps 和 DevSecOps）实践和持续运营（SRE）实践中，关键是关注结果，而不仅仅是过程行为。 许多现有的定义过于侧重于过程方面，忽视了与业务结果对齐的重要性。 一种更实用且有用的方法是，定义持续测试、持续质量、持续安全和持续反馈的策略，强调可衡量的业务成果。 这些结果，特别是与 DevOps 研究协会的 DORA (DORA)指标对齐，对评估软件开发实践的效率和成功至关重要。 考虑到这些因素，以下定义可以在 本文件中使用：

• 持续测试定义：持续测试是一种旨在减少持续交付管道和持续运营中的前置时间和故障率的策略，通过自动化和迭代测试过程，目标是减少从代码提交到生产部署的时间，并减少生产中的故障 ：

  • 指标：

    • 从代码提交到 生产部署的测试任务时间。

    • 逃逸到生产环境的缺陷百分比。

  • 原理：

    • 该定义将测试整合到开发、交付和运维的每个阶段，确保问题能够早期并持续地被发现和解决，这对于快速且可靠的软件交付 和运营至关重要。

• 持续质量定义：持续质量是一种战略，旨在通过在开发、交付和生产过程中整合质量指标，增强用户满意度并减少生产故障率，专注于稳定的发布和减少 用户问题：

  • 指标：

    • 批准发布的 部署率

    • 客户报告的每次发布问题 数量

    • 可用性级别 目标（SLOs）

  • 原理：

    • 通过在开发和运营的每个阶段优先考虑质量，这一战略确保交付稳定和可靠的软件，满足用户 期望和 业务需求。

• 持续安全定义：持续安全是一种战略，将安全措施整合到持续的开发、交付和运营中，以减少安全事件的频率和影响，通过安全事件及其 解决时间来衡量：

  • 指标：

    • （发布前和发布后） 安全事件的数量

    • 检测、响应和解决 安全事件的平均时间

  • 原理：

    • 这一战略强调主动的安全实践，将安全考虑因素嵌入整个软件生命周期，对于维护软件完整性 和信任至关重要。

• 持续反馈定义：持续反馈是一种策略，利用利益相关者和用户的反馈来加速发布频率并改善恢复时间，通过反馈的实施速度及其对 系统可靠性的影响来衡量：

  • 指标：

    • 实施反馈的时间（来源 到解决器）

    • 批准发布的 部署率

    • 客户报告的每次发布问题 数量

    • 可用性级别 目标 (SLOs)

  • 理由：

    • 系统化 的反馈收集和实施确保软件不断响应用户需求和市场变化，推动 持续改进。

图 1**.4 提供了用于本文件中的持续测试、质量、安全和反馈的实际定义。

图 1.4 – 持续测试、质量、安全和反馈定义

采用这些战略性聚焦的定义来界定持续测试、质量、安全和反馈，使组织能够将其持续开发、交付和运营实践与可衡量的业务结果对齐。 这种方法不仅为持续改进提供了明确的方向，还确保了这些方法论根据它们对关键绩效指标的影响进行评估和调整。 在软件开发不断发展的环境中，这种以结果为导向的战略对于实现效率、可靠性和数字化转型中的成功至关重要。

持续测试的指导原则和支柱

本 节描述了支持有效持续测试策略的重要指导原则和实践支柱。 它们对于确保持续测试有效缩短从代码提交到生产部署的时间，并减少生产环境中的故障 至关重要。

图 1**.5 展示了持续测试的支柱。

图 1.5 – 持续测试支柱

让我们详细看看它们：

• 测试自动化：

  • 原则：自动化 是实现 持续测试所需的速度和一致性的关键。 自动化测试可以频繁且一致地运行，确保对 软件健康状况的快速反馈。

  • 支柱：开发并维护一套自动化测试，涵盖多个方面，包括单元测试、集成测试、回归测试、性能测试、安全测试、系统测试和用户 验收测试。

• 与开发 生命周期的集成：

  • 原则: 测试应该从一开始就融入开发过程，而不是在 最后才加上。

  • 支柱: 实施左移策略，在开发周期早期开始进行测试。 这 包括诸如 测试驱动开发 (TDD) 和 行为驱动开发 BDD(BDD)。

• 测试反馈:

  • 原则: 测试的持续反馈对于及时发现和解决 问题至关重要。

  • 支柱: 建立实时报告和分析测试结果的机制，确保在发现问题时能立即采取行动。 例如，bug 和漏洞问题报告可以 自动化。

• 测试指标:

  • 原则: 指标 和测量是了解测试效果以及指导 持续改进的必要手段。

  • 支柱: 使用一套全面的质量指标，如缺陷密度、测试覆盖率和平均解决时间，来跟踪和改进 测试过程。

• 基于风险的测试:

  • 原则: 根据 风险评估，集中测试资源在应用程序的最关键部分。

  • 支柱: 优先分配测试资源到风险或影响最大的领域，如关键功能、性能瓶颈和 安全漏洞。

• 测试环境和测试 数据管理:

  • 原则: 可靠和一致的测试环境 及数据对于 准确测试是必要的。

  • 支柱: 确保测试环境的稳定性、可扩展性和类生产环境的可用性，以及适当的测试数据 管理策略。

• 协作 与沟通:

  • 原则：开发人员、测试人员和运营团队之间的有效协作与沟通对 持续测试的成功至关重要。

  • 支柱：培养一种协作文化，在这种文化下，团队紧密合作并共同承担 质量责任。

• 持续学习 与适应：

  • 原则：持续测试是一个 不断发展的实践，应适应变化的技术和 项目需求。

  • 支柱：定期回顾并调整测试策略、工具和流程，以满足软件和 业务的不断发展需求。

这些指导原则和实践支柱构成了强大持续测试策略的基础。 它们有助于确保测试的高效、有效，并与降低交付时间、最小化生产中的故障、最终及时交付高质量 软件的总体目标保持一致。

持续质量的指导原则和支柱

本 节描述了支持有效持续质量策略的重要指导原则和实践支柱。

图 1**.6 展示了持续质量的支柱。

图 1.6 – 持续质量支柱

让我们来看看它们：

• 以用户为中心的聚焦：

  • 原则：用户 满意度是衡量质量的关键指标。

  • 支柱：定期收集和分析用户反馈、可用性测试结果、客户满意度指标以及满意度调查的结果，以指导 质量改进。

• 集成的 质量指标：

  • 原则：质量 应可衡量，并应集成到软件 生命周期的每个阶段。

  • 支柱：在开发、交付和生产阶段实施并持续优化一组质量指标（如缺陷率、正常运行时间和性能基准）。

• 主动 质量保证：

  • 原则：质量不仅仅是修复缺陷；它还涉及预防缺陷。

  • 支柱：采用积极的质量保证实践，如静态代码分析、设计审查和架构评估，以便在生命周期的早期识别和解决潜在问题。

• 持续改进：

  • 原则：质量是一个不断发展的目标，需要持续改进。

  • 支柱：通过定期的回顾和过程、工具及实践的评审，培养持续改进的文化，以识别可提升的领域。

• 协作与沟通：

  • 原则：质量是一个集体责任，要求团队之间的协作。

  • 支柱：鼓励开发人员、QA、运营和业务利益相关者之间的跨职能合作，确保质量的统一方法。

• 稳定且可靠的发布：

  • 原则：发布的稳定性和可靠性至关重要。

  • 支柱：实施强大的发布管理和部署实践，确保稳定可靠的软件发布，并进行全面的测试和验证。

• 风险管理：

  • 原则：识别和管理风险对于维护质量至关重要。

  • 支柱：进行定期的风险评估，并根据对用户满意度和系统稳定性的潜在影响来优先安排工作。

• 质量保证（QA）自动化：

  • 原则：自动化是扩展质量保证实践的关键。

  • 支柱：利用自动化测试和质量保证工具提高覆盖面和效率，同时释放资源专注于复杂的质量挑战。

这些指导原则和实践支柱定义了一个全面的持续质量方法。 通过专注于集成质量度量，强调用户满意度，推动积极的质量保证，并促进持续改进，组织可以有效提升其软件产品的整体质量，从而减少生产故障并提高 用户满意度。

持续安全的指导原则和支柱

本节 描述了支持有效持续 安全战略的指导原则和实践支柱。

图 1**.7 展示了持续安全的支柱。

图 1.7 – 持续安全支柱

我们简要地来看一下它们：

• DevSecOps 文化：

  • 原则：开发、 安全和运维之间的合作有助于提升 安全结果。

  • 支柱：推广 DevSecOps 文化，将安全作为共享责任，融入 DevOps 实践中，鼓励跨团队的合作与沟通。

• 安全意识 与培训：

  • 原则：安全是共享的责任，所有层级都需要具备安全意识。

  • 支柱：为所有团队成员提供定期的安全培训和意识提升项目，以培养安全意识文化。 例如，针对 诸如 开放全球应用安全项目（OWASP） 培训、 安全编码和 API 安全的培训可能 非常重要。

• 安全集成在 生命周期中的：

  • 原则：安全是整个软件生命周期的 一个不可或缺的部分，而不是一个 孤立的阶段。

  • 支柱：将安全实践和工具嵌入到开发、交付和运营流程中，确保从开始到部署 和维护的整个过程都考虑到安全因素。

• 自动化 安全测试：

  • 原则：自动化是 维持持续 安全警觉性的关键。

  • 支柱：利用自动化安全测试工具（如静态和动态分析工具以及漏洞扫描器）定期扫描并识别在 开发过程的各个阶段中存在的安全威胁。

• 主动 风险管理：

  • 原则：主动识别和 缓解风险比 被动应对措施更为有效。

  • 支柱：定期进行安全风险评估和威胁建模，主动识别并解决潜在的 安全漏洞。

• 快速 事件响应：

  • 原则：快速且 有效地响应安全事件能够最小化 其影响。

  • 支柱：建立一个明确的事件响应计划，包括快速检测、调查和修复 安全事件的程序。

• 持续监控 与合规性：

  • 原则：持续监控和遵守合规标准对于 保持安全至关重要。

  • 支柱：实施持续监控解决方案，检测和警告可疑活动，并进行定期的合规检查，确保遵守相关的安全标准 和法规。

• 反馈与 持续改进：

  • 原则：反馈 对安全实践的发展和改进至关重要。

  • 支柱：实施反馈机制，从安全事件中学习，并根据经验教训和不断变化的 威胁 持续改进安全措施。

这些指导原则和支柱建立了一个强大的框架，确保持续的安全性。 它们确保安全是一个持续、集成的过程，强调主动的风险管理、快速的事件响应和持续的监控，同时促进安全意识和合作文化的形成。 通过遵循这些原则，组织可以有效地减少安全事件的发生频率和影响，从而增强整体的 安全态势。

持续反馈的指导原则和支柱

本节描述了有效的持续反馈策略所需的指导原则和实践支柱。

图 1.8 说明了持续反馈的支柱。

图 1.8 – 持续反馈支柱

让我们接下来讨论这些支柱：

• 利益相关者 和用户互动：

  • 原则：与利益相关者和用户的积极互动对于获得相关和可操作的反馈至关重要。

  • 支柱：建立常规渠道收集来自所有利益相关者的反馈，包括客户、最终用户、团队成员和商业伙伴。

• 反馈与开发的整合：

  • 原则：反馈应无缝地融入开发过程。

  • 支柱：开发机制，迅速将反馈整合进开发流程，确保其直接影响开发优先级和决策。

• 快速迭代 和实施：

  • 原则：反馈的价值在于迅速和有效地实施。

  • 支柱：专注于缩短从接收反馈到实施变更的周期时间，从而加速迭代和改进。

• 数据驱动 决策制定：

  • 原则：决策应基于从反馈中得出的数据，而不仅仅是直觉或假设。

  • 支柱：利用工具和技术对反馈进行定量和定性分析，确保决策基于实际用户和利益相关者的洞察。

• 反馈透明度 和沟通：

  • 原则：关于反馈的开放沟通能够促进信任并保持持续的互动。

  • 支柱: 与利益相关者透明沟通收到的反馈、采取的措施及决策背后的 理由。

• 持续学习 和适应:

  • 原则: 反馈 是持续学习 和适应的关键驱动力。

  • 支柱: 鼓励一种将反馈视为学习和改进机会的文化，基于 反馈见解调整流程和实践。

• 衡量影响 与有效性:

  • 原则: 反馈实施的有效性应该 持续进行衡量。

  • 支柱: 跟踪和评估反馈对发布频率、恢复时间和系统可靠性的影响，以衡量反馈实施的 有效性。

• 平衡速度 与质量:

  • 原则: 尽管 快速实施反馈非常重要，但保持质量同样是 至关重要的。

  • 支柱: 确保以平衡速度和维护或提高系统质量与可靠性的需求的方式实施反馈。

这些指导原则和支柱形成了一个全面的持续反馈框架，强调了利益相关者和用户参与的重要性、将反馈快速集成到开发中的必要性，以及基于数据的决策。 通过遵循这些原则，组织可以有效利用反馈推动更快的发布、改善恢复时间并增强系统的整体可靠性，从而与现代软件 开发方法的目标紧密对接。

总结

在快速发展的 DevOps、DevSecOps 和 SRE 领域，持续测试、质量、安全和反馈的策略已成为引导数字化转型成功实现持续开发、交付和运营的关键因素。 本章深入探讨了这些策略的核心，提供了实际的定义和支撑它们的指导原则。

旅程始于 介绍持续测试、质量、安全和反馈，为全面探讨铺平了道路。 本节奠定了基础，阐明了为何这些概念在现代软件开发中是不可或缺的。 这是一个邀请，通过优先考虑持续改进和适应来审视软件开发、交付和运营的镜头。 定义持续测试、质量、安全和反馈的随后部分提供了每个概念的明确、以结果为中心的定义。 这种清晰度至关重要，因为它为专业人士在实施这些策略的复杂性中提供了一盏明灯，这对数字转型至关重要。 。

本章的核心在于详细阐述了每个概念的指导原则和支柱。 持续测试的指导原则和支柱 解释了将测试整合到软件开发生命周期的每个阶段中，确保质量和功能不是事后的考虑，而是过程中固有的。 关于持续质量的部分强调了积极主动的方法来保持高标准，确保产品不仅符合而且超出用户的期望。 当涉及持续安全性时，本章强调了需要采取一种整合的、警觉的方法来应对不断演变的威胁。

在专门讨论持续反馈的部分中，本章强调了利益相关者和用户输入在塑造和优化软件产品中的重要性。 这种反馈循环被描绘为开发过程中的一个动态、不可或缺的组成部分，推动改进并促进用户满意度。 最后，本章为你提供了宝贵的技能——理解持续测试、质量、安全和反馈的本质，并学会有效实施它们的指导原则。 这些知识不仅仅是理论，它们是在现代软件开发领域蓬勃发展的工具。 开发。

总之，本章是一个实用指南，也是变革的催化剂。 它鼓励您采纳这些持续策略，确保数字转型是有弹性、以用户为中心和安全的。 无论您是经验丰富的专业人士还是刚刚开始，本章都提供了宝贵的见解和技能，将提升您对持续软件开发、交付和运营的方法。 和操作。

下一章解释了为什么持续测试、质量、安全性和反馈对于 DevOps、DevSecOps 和 SRE 至关重要。

第二章：持续测试、质量、安全和反馈的重要性

本 章节 解释了 为什么 持续测试、 质量、 安全和 反馈 策略对 DevOps 、 DevSecOps和 站点可靠性工程（SRE） (SRE) 至关重要。 为了理解这一点，首先需要了解 DevOps、DevSecOps 和 SRE 的原则和支柱如何依赖于持续测试、质量、安全和反馈的原则与支柱。 这一点在某种程度上得到了简化，因为 DevOps 和 DevSecOps 等 持续交付 (CD) 策略的支柱是相似的，因此可以将其组合在一起进行比较。 持续运营的原则和支柱等同于 SRE，因此它们会在一个 单独的章节中进行比较。

本章分为 三个部分：

• 为什么持续策略对 DevOps 和 DevSecOps 很重要

• 为什么持续策略对 SRE 很重要 对于 SRE

• 没有正确实施持续实践的情况下实施 DevOps、DevSecOps 和 SRE 的后果 持续实践

让我们 开始吧！

为什么持续策略对 DevOps 和 DevSecOps 很重要

本 部分 介绍 DevOps 和 DevSecOps CD 策略的原则与支柱。 这一部分解释了这些实践的原则和支柱为何依赖于持续测试、质量、安全和 反馈策略的原则和支柱。

DevOps 和 DevSecOps 的原则与支柱

DevOps 和 DevSecOps 是相关的策略，它们都促进了 CD，尽管它们强调软件开发和 交付过程的不同方面。

DevOps 实践的九大支柱

DevOps 主要关注改善软件 开发 (Dev)与 运维 (Ops)团队之间的协作。 其目标是简化开发 流水线，实施 自动化，并实现更快速、更高效的软件交付。 软件交付。

正如 Marc Hornbeek 在 《工程化 DevOps》 (2019 年与 Bookbaby 出版)中定义的那样，DevOps 的九大支柱代表了成功实施 DevOps 所必需的基本原则和实践。 每个支柱在支持和增强 DevOps 哲学中都扮演着独特的角色，DevOps 哲学专注于改善协作、自动化和软件开发及交付的整体效率。 以下是每个支柱的解释： 这些支柱：

• 领导力：有效的领导力 对于推动 DevOps 所需的文化和组织变革至关重要。 领导者必须倡导 DevOps 原则，促进部门间的协作，并确保团队配备必要的工具和培训。 他们在打破部门壁垒和营造支持持续改进 与创新的环境中发挥着关键作用。

• 协作文化：DevOps 强调软件开发人员、IT 运维人员及软件交付过程中其他相关方之间的协作和沟通文化。 协作文化涉及共享责任、透明度和开放的沟通，这对于快速高效地进行软件开发、测试和部署至关重要。 这些文化元素是推动软件开发和交付顺利进行的基础。

• 为 DevOps 设计：这涉及到 以支持 DevOps 实践的方式设计软件和系统。 它包括模块化、可扩展性和可维护性等方面的考虑。 设计应便于快速更新、快速部署和高效操作，符合自动化 和持续交付（CD）原则。

• 持续集成（CI）：CI 是 将代码更改频繁集成到共享代码库中的实践。 每次集成都通过自动构建和测试过程进行验证，以尽可能快速地检测集成错误，从而减少集成问题并提高 软件质量。

• 持续测试: 持续测试 包括作为软件交付管道一部分执行自动化测试。 这确保了软件质量在整个开发过程中得到保持，使团队能够及早识别和解决问题，从而实现更快和更可靠的 软件发布。

• 弹性基础设施: 弹性基础设施 指的是根据需求动态调整资源的能力。 在 DevOps 的背景下，这意味着使用虚拟化和基于云的服务 以及 基础设施即服务 技术，这些技术 支持计算资源的灵活分配，促进应用程序的快速和高效部署与运行。

• 持续安全: 持续安全，或 DevSecOps，将安全实践融入到每一个软件 开发 和部署过程中。 它包括对安全威胁的持续监控、定期的漏洞评估，并将安全控制集成到 CI/CD 管道中。

• 持续交付（CD）: CD 是 一种软件工程 方法，团队通过短周期地生产软件，确保随时可以可靠地发布。 其目标是以更快的速度和频率构建、测试和发布软件，从而降低交付变更的成本、时间和风险。

• 持续监控: 持续监控 包括持续收集、处理和分析来自软件应用程序和基础设施的数据（性能指标、日志等）。 这一实践有助于主动识别和解决问题，了解系统性能，并确保系统可靠 且高效地运行。

这九大支柱共同构成了一个全面的框架，用于实施和优化 DevOps 实践。 它们鼓励采取一种整体方法来进行软件开发和交付，侧重于协作、自动化、持续改进和高度 的运营效率。 通过整合这些实践，DevOps 旨在缩短开发周期，提高软件质量，并增加发布频率，从而更快速地响应市场需求和 用户需求。

DevSecOps 实践的九大支柱

DevSecOps 扩展了 DevOps 模型，通过将安全实践融入所有 DevOps 支柱中。 这一策略强调安全不应是事后的考虑，而应是开发过程中的核心组成部分。 DevSecOps 致力于在 CI/CD 流水线中嵌入自动化的安全检查和平衡机制，确保安全性持续被考虑，并且不会影响 交付过程。

正如 Marc Hornbeek 在 《工程化 DevOps》中定义的那样，DevOps 的九大支柱同样适用于 DevSecOps。 虽然这些支柱相同，但每个支柱下的具体实践是互为补充的。 DevSecOps 的九大支柱确保安全性不是一个独立的元素，而是无缝地嵌入到软件开发和交付流程的每一个阶段。 以下是对 DevSecOps 每个支柱的解释：

• 领导力：强有力的领导力 在推动将安全性成功融入 DevOps 实践所需的文化转变中至关重要。 领导者必须将安全性作为核心价值观，确保在组织的各个层级都将其优先考虑，并确保团队拥有实现 DevSecOps 的资源和支持。

• 协作文化：在 DevSecOps 中，协作文化至关重要，开发、运维和安全团队需要紧密合作。 这种协作确保了对安全的共同理解和责任，能够更快速、更有效地识别和解决 安全问题。 安全问题。

• 为 DevOps 设计：这意味着在设计系统和应用程序时，要同时考虑 DevOps 和 安全性因素。 这包括从一开始就以模块化、可扩展性和安全性为目标进行构建，确保系统既具有敏捷性 又是安全的。

• 持续集成（CI）： 在 DevSecOps 中，CI 包括频繁地集成代码更改，并且 确保每个更改都会自动进行安全性测试。 这种方法有助于在 开发过程中及早识别和解决安全漏洞。

• 持续测试：在 DevSecOps 中，持续测试不仅仅是功能性和 性能的测试， 还包括定期的自动化安全测试。 这确保了在软件开发的每个阶段，安全性都在持续验证。 生命周期中。

• 弹性基础设施：在 DevSecOps 中，弹性基础设施强调根据不同需求迅速扩展资源的能力，同时保持安全性。 它涉及使用云服务和虚拟化，配合版本控制和灵活的配置控制，以支持操作灵活性和 安全要求。

• 持续安全：持续安全 是 DevSecOps 的核心。 它涉及将安全实践融入软件开发和部署过程的每个阶段，从最初的设计到操作，确保持续的监控 和合规性。

• 持续交付（CD）：在 DevSecOps 的背景下，CD 是指一个过程，其中代码变更会自动 构建、测试（包括安全测试），并为发布到生产环境做准备，确保软件能够随时以 高度安全性进行部署。

• 持续监控：这 涉及不断 监控已部署的软件和基础设施中的安全威胁。 持续监控使得能够快速检测并响应安全事件、漏洞 和异常情况。

这些支柱中的每一项都在将安全嵌入 DevOps 流水线中发挥着至关重要的作用，确保安全考量成为开发和 部署过程中的一个不可或缺且持续的部分。 它们共同构成了一个全面的框架，旨在有效实施 DevSecOps，使安全与现代 软件开发的快速和敏捷特性相契合。

DevOps 与 DevSecOps 的对齐

DevOps 和 DevSecOps 都共享促进 CD 的共同目标，但它们的重点不同：DevOps 优先考虑效率和速度，而 DevSecOps 在快速的环境中更注重安全性。 这一点是其主要区别。

尽管实现 DevOps 而不实施 DevSecOps 是可行的（不幸的是，行业中有很多这样的例子），但这样做存在一些问题：

• 安全作为事后考虑：在纯 DevOps 方法中，过于关注速度和效率可能导致安全被忽视，或者在开发过程的最后才被补充进来。 这可能导致软件中出现漏洞，若漏洞在管道的后期被发现，则需要进行修复、集成， 并验证。

• 被动而非主动的安全：如果没有将安全整合到 CD 管道中，组织可能会发现自己在部署后才开始应对安全事件，这可能会导致高昂的成本并损害组织的 声誉。

• 合规风险：对安全的忽视可能导致不符合行业法规和标准，尤其是在数据保护和隐私 至关重要的领域。

• 增加对网络威胁的脆弱性：没有持续安全的 CD 可能会使软件产品更容易受到新兴网络威胁的攻击，因为安全措施可能无法跟上更新和 新功能快速部署的步伐。

• 碎片化的风险管理方法：将开发与安全工作分开，可能会导致风险管理方法的碎片化，在开发过程中，安全考虑因素无法充分融入决策过程中 。

总之，尽管 DevOps 和 DevSecOps 都旨在促进持续交付，但从一开始就将安全融入其中——正如 DevSecOps 所强调的——对确保 DevOps 的速度和效率提升不妥协软件的安全性和完整性至关重要。 因此，结合 DevOps 和 DevSecOps 的原则，采用九大支柱的共同框架来实现平衡、高效和安全的软件交付管道，是至关重要的。 。

图 2**.1 来自 《工程化 DevOps》 展示了 DevOps 和 DevSecOps 的九大支柱。 如图所示，九大支柱模型展示了所有支柱如何共享一个共同的基础，即编排、自动化和治理，并且有一个共同的“屋顶”，即 CI/CD 管道、应用发布自动化和价值 流管理。

图 2.1 – DevOps 和 DevSecOps 的九大支柱

下一个 子部分 将解释 DevOps 和 DevSecOps 的九大支柱如何依赖于持续测试、质量、安全和反馈。

DevOps 和 DevSecOps 对持续测试、质量、安全和反馈的依赖

DevOps 和 DevSecOps 的九大支柱以各种方式与持续测试、持续质量、持续安全和持续反馈的支柱相交织并相互支持。 每一组支柱都相互补充并强化对方，形成了一个全面的软件开发与运维方法。 它们是这样相互关联的：

• 领导力：通过为测试、质量、安全和反馈倡议提供战略方向、资源和支持，领导力支持所有支柱。

• 协作文化：这与持续测试、质量和安全中的协作与沟通，以及在持续反馈中的利益相关者和用户参与相一致，促进了对这些方面的共同责任。

• 为 DevOps 设计：这依赖于主动的质量保证、基于风险的测试以及生命周期中的安全集成，确保系统的设计有助于这些实践。

• 持续集成（CI）：这直接得到了测试自动化、与开发的集成以及自动化安全测试的支持，使得变更能够频繁且可靠地集成。

• 持续测试：这体现了持续测试支柱的原则，确保测试是自动化、集成的，并且不断改进。

• 弹性基础设施：这通过持续测试中的测试环境和测试数据管理，以及持续安全中的持续监控和合规性得到支持，确保基础设施在保持质量和安全标准的同时能够适应变化。

• 持续安全：这包括了持续安全的支柱，在 DevOps 流水线的每个步骤中都融入了安全实践。

• 持续交付（CD）：这依赖于持续质量的稳定和可靠的发布，以及与开发的反馈集成和持续安全的快速事件响应，确保软件能够快速 且安全地发布。

• 持续监控：这通过持续安全中的持续监控和合规性支持，并通过持续反馈中的影响和效果度量，提供有关 系统性能、质量和安全性的洞察。

这些 相互依赖性 表明 九大 DevOps 和 DevSecOps 支柱并不是孤立的元素，而是与持续测试、质量、安全性 和反馈的基础方面紧密相连。

图 2.2 – DevOps 和 DevSecOps 对持续测试、质量、安全性和反馈的依赖

每一组支柱相互增强和强化，形成一种整体且集成的软件开发与交付方法。 这种协同作用对于实现 DevOps 和 DevSecOps 的目标至关重要：快速、可靠、安全和高质量的 软件 交付 满足用户需求和 业务目标。

为什么持续策略对于 SRE 至关重要

本节 介绍了 针对持续运营 SRE 策略的实践原则和支柱。 本节解释了这些实践原则和支柱如何依赖于持续测试、质量、安全性和 反馈策略的原则和支柱。

SRE 的原则和支柱

SRE 是一门 融合了软件工程方面的学科，并将其应用于基础设施和运营问题。 目标是创建可扩展且高度可靠的 软件系统。

图 2.3 – SRE 的原则和支柱

以下是 在图 2**.3中说明的 SRE 九大支柱的解释：

• 文化 – 向左转的生产智慧：这一支柱强调在软件开发生命周期的早期阶段融入运营知识的重要性。向左转意味着从开发过程一开始就考虑可靠性、可扩展性和运营方面的问题，而不仅仅是在结束或部署之后才考虑。这有助于形成一种文化，让生产经验能够影响开发决策。

• 减少繁琐工作和自动化：繁琐工作指的是可以自动化的重复性、手动且非战略性的工作。通过自动化减少繁琐工作，使 SRE（站点可靠性工程师）能够专注于更有影响力的工作，从而提高系统的可靠性和效率。这一支柱强调识别并自动化日常任务的重要性。

• SLAs / SLOs / SLIs 和错误预算：服务级别协议（SLAs）、服务级别目标（SLOs）和服务级别指标（SLIs）对于衡量服务的可靠性至关重要。SLAs 是对客户的承诺，SLOs 是服务级别的目标，SLIs 是用于衡量这些级别的指标。错误预算定义了可接受的错误阈值，并帮助平衡可靠性需求与创新进程。

• 度量与可观测性：这一支柱关注的是能够衡量和观察系统及基础设施的内部状态。有效的可观测性对于理解系统的性能和行为至关重要，进而为可靠性和效率的决策提供依据。

• 反脆弱性、演习、混沌工程与安全防御：反脆弱性不仅仅是抗压能力，它通过应对压力源和挑战来提升系统的韧性。像演习和混沌工程（故意注入故障以测试系统）这样的实践用于使系统更加稳健。该支柱还强调主动的安全防御措施的重要性。

• 工作共享和渐进的技术债务：这一支柱倡导开发和运维团队之间的协作工作共享 以便传播知识和责任。 它还强调了渐进管理技术债务的重要性 ，防止其积累到 无法管理的程度。

• 使用蓝绿部署、A/B 测试和金丝雀发布：这些部署策略用于 降低发布新版本软件时的风险。 蓝绿部署、A/B 测试和金丝雀发布允许对新变化进行受控曝光，支持在生产环境中测试，并在必要时进行快速回滚。 。

• 应用和基础设施的性能管理：这涉及监控和优化 应用程序及其底层基础设施的性能。 这意味着确保软件和其运行的硬件都经过优化，以提高效率、可扩展性和可靠性。 这一支柱包括容量规划，SRE 会确定系统是否能承受峰值负载，并实施应对需求激增的缓解策略 。

• 事件管理、值班、紧急情况和事后回顾：有效的事件管理 和在紧急情况下拥有结构化的值班响应对于 SRE 至关重要。 这一支柱还强调了在事件发生后进行回顾的重要性，以便学习和改进。 这关乎于创建一个应对、学习和预防 未来事件的过程。 。

这些 SRE 支柱为构建和维护可靠的系统提供了框架。 它们强调主动和预防性措施、持续改进以及在创新与稳定之间保持平衡的方法。 。

SRE 依赖于持续测试、质量、安全性和反馈

SRE 的九大支柱 与持续测试、持续质量、持续安全和 持续反馈的原则和支柱紧密相连。

图 2.4 – SRE 对持续测试、质量、安全性和反馈的依赖

图 2**.4 和 以下 解释 展示了它们是如何相互关联的：

• 文化 – 向左迁移的智慧 生产：

  • 持续测试：与开发和持续学习适应的集成对于左移至关重要。

  • 持续质量：主动的质量保证确保质量考虑在早期就已提出。

  • 持续安全：生命周期中的安全集成与开发过程中的安全考虑向左迁移保持一致。

• 减少繁重工作 和自动化：

  • 持续测试：测试自动化是减少人工测试工作量的关键。

  • 持续质量：质量保证自动化有助于自动化质量检查。

  • 持续安全：自动化安全测试减少了人工安全检查。

• 服务级别协议（SLA）/ 服务级别目标（SLO）/ 服务级别指标（SLI）和 错误预算：

  • 持续反馈：数据驱动的决策和衡量影响与效果的度量与定义和监控 SLA、SLO 以及 SLI 保持一致。

  • 持续质量：集成质量度量支持有效 SLO 的建立。

• 度量 和可观察性：

  • 持续测试：测试度量提供了可观察性所需的关键信息。

  • 持续质量：持续改进依赖于有效的度量。

  • 持续安全：持续监控和合规性是可观察性的核心组成部分。

• 反脆弱性、应急演练、混沌工程和 安全防护：

  • 持续测试：基于风险的测试与为最坏情况做好准备相一致。

  • 持续安全：主动的风险管理和快速的事件响应在这里至关重要。

  • 持续反馈：持续学习和适应对于从 这些活动中发展至关重要。

• 工作共享与增量 技术债务：

  • 持续测试：协作和沟通促进了 工作共享。

  • 持续质量：管理技术债务是持续改进和 风险管理的一部分。

• 蓝绿部署、A/B 测试 和金丝雀部署：

  • 持续测试：测试环境和测试数据管理支持这些 部署策略。

  • 持续质量：稳定 和可靠的发布对于成功的 蓝绿部署、A/B 测试和 金丝雀部署至关重要。

• 应用与基础设施的性能管理 ：：

  • 持续测试：测试自动化和测试指标有助于 性能管理。

  • 持续质量：以用户为中心的焦点和集成的质量指标对于确保性能与 用户期望一致至关重要。

• 事件管理、值班、紧急情况 和回顾：

  • 持续反馈：反馈的透明度和沟通，以及持续学习和适应，对于有效的事件管理和从 回顾中学习至关重要。

  • 持续安全：快速响应事件、持续监控和合规性是 这一支柱的基础。

这些 相互依赖关系 表明 SRE 的 支柱并不是独立的元素，而是与持续测试、质量、安全性和反馈深度关联。 每组支柱都相互补充，形成了可靠、安全和高效软件开发 与运维的全面方法。

实施 DevOps、DevSecOps 和 SRE 时，如果没有正确实施持续实践，将带来哪些后果

如果在实施 DevOps、DevSecOps 和 SRE 时未正确整合持续测试、质量、安全和反馈的支柱，可能会导致一系列负面后果。 这些方法论旨在与持续实践协同工作，忽视任何一个方面都可能削弱其效果。 以下是每种方法论可能出现的后果示例：

• 没有适当的 DevOps 持续实践：

  • 测试不足：如果在 DevOps 中未正确实施持续测试，可能会导致频繁的生产故障，原因是漏洞和性能问题，从而破坏了快速可靠的软件交付目标。

  • 质量差：忽视持续的质量保障可能导致软件未能满足用户期望或可用性差，从而降低客户满意度并可能导致信任丧失。

  • 安全漏洞：没有持续的安全保障，DevOps 可能会加速部署不安全的软件，从而增加数据泄露和网络攻击的风险。

  • 与用户需求不匹配：缺乏持续的反馈会导致开发出的产品与用户实际需求之间存在脱节，从而导致产品未能有效满足市场需求。

• 没有适当的 DevSecOps 持续实践：

  • 安全漏洞：如果在 DevSecOps 中未有效实施持续的安全实践，可能会导致漏洞未被检查，暴露组织面临安全风险和合规性问题。

  • 对安全事件的响应延迟：没有持续的反馈和监控，可能导致对安全事件的响应较慢，从而加剧泄漏事件的影响。

  • 忽视质量与测试：如果未将持续测试和质量集成，即使是以安全为重点的流水线也可能部署存在功能缺陷或性能问题的软件，影响用户满意度和系统可靠性。

• 没有适当的 SRE 持续实践：

  • 系统不稳定：未将持续测试和质量集成到 SRE 中，可能导致系统不够健壮或可扩展，从而导致频繁的停机或性能下降。

  • 运营效率低下：没有持续反馈和通过自动化减少劳累，SRE 团队可能会花费过多时间应对运营火灾，而不是进行战略性改进，导致精疲力竭 和低效。

  • 安全措施不足：忽视 SRE 实践中的持续安全，可能会使系统易受安全威胁，危及系统的可靠性和 用户信任。

  • 事故管理不当：缺乏持续反馈机制会阻碍有效的事故管理，导致系统停机时间延长和 恢复速度减慢 从故障中恢复。

总之，缺乏强有力的持续测试、质量、安全和反馈实践，可能会显著削弱 DevOps、DevSecOps 和 SRE 的实施效果。 这可能导致部署不可靠、不安全且质量低劣的软件，增加运营挑战，并无法有效满足用户和业务需求。 因此，全面集成这些持续实践是实现 DevOps、DevSecOps 和 SRE 方法论最大效益的关键。

总结

本章阐明了 DevOps、DevSecOps、SRE 与持续测试、质量、安全和反馈实践之间的内在联系，展示了它们在实现高效、安全、可靠的软件交付中的相互依赖性。 软件交付。

DevOps 通过协作和自动化来桥接开发和运维，天然依赖于持续集成（CI）来进行测试和质量保证，以确保软件的快速高效交付。 在 DevOps 工作流中集成持续测试和质量实践，使组织能够在加速开发周期的同时，保持高标准的软件性能和可靠性。 开发周期。

DevSecOps 通过将安全性融入 DevOps 实践的核心，扩展了这一模型。 持续安全的原则，如主动风险管理和自动化安全测试，是 DevSecOps 的关键，确保在追求速度和效率的过程中不妥协安全措施。 持续安全为在软件开发生命周期的每个阶段嵌入安全提供了框架，使其成为 DevOps 实践的基本组成部分，而不是 事后的补充。

SRE 专注于软件系统的可靠性和可扩展性，广泛利用持续实践来实现其目标。 持续测试和质量在设定和维持系统性能和稳定性的高标准方面至关重要。 此外，SRE 通过自动化减少机械工作，并通过持续反馈实践强调性能管理。 这些实践确保 SRE 不仅仅是维持现状，而且不断学习和适应新的挑战和用户需求。 用户需求。

本章强调，尽管 DevOps、DevSecOps 和 SRE 有各自不同的关注点和方法论，但它们的成功基本上取决于持续实践的整合。 持续测试、质量、安全性和反馈并非孤立的策略，而是纳入了软件开发和运营生命周期中这些方法的重要组成部分。 它们为组织提供了开发和维护软件所需的工具、流程和文化心态，这些软件不仅快速高效，而且健壮、安全，并与用户期望保持一致。 用户期望。

总之，本章明确指出，软件开发和运营的未来在于将 DevOps、DevSecOps 和 SRE 与持续测试、质量、安全性和反馈和谐整合起来。 这些策略和实践一旦共同实施，将形成强大的协同效应，推动创新，增强运营效率，并确保交付高质量、可靠和安全的软件产品。 它们代表了现代软件工程的综合方法，具有适应性、韧性，并且以用户为中心。

下一章将解释我个人对持续测试、质量、安全性和反馈策略的终身经验和陷阱。 反馈策略。

第三章：持续测试、质量、安全和反馈的经验与陷阱。

回顾我超过 48 年的职业生涯，我认为我注定要专注于现在被称为的持续测试、DevOps、DevSecOps、SRE，但这些标签直到最近才出现。 在这段时间里，我主要专注于为软件开发、交付和运营设计、开发和实施测试、质量、安全和反馈策略，以及自动化平台和工具。 在这段时间里，我的职业发展与从软件瀑布模型到持续交付和运营方法论的演变相一致。 我能够使用并贡献于这些策略、平台和工具的发展，最终因为我的终身工作而被 IEEE 授予 2016 年 IEEE 6 区杰出工程师奖。 在自动化方面的贡献。

本章通过我一生的经验、案例、经验教训和需要避免的陷阱，解释了如何避免这些陷阱的策略。

本章的前几节按照时间顺序组织，解释了我的学习路径。 后面的部分总结了我在职业生涯中学到的实践和陷阱，这些将对正在经历数字化转型的其他人有用。

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

• 一生致力于测试、质量、安全和反馈的研究，专注于 DevOps、DevSecOps， 和 SRE。

• Bell-Northern – 世界一流的大学

• 作为 商业企业的测试

• 咨询 和教学

• 经验教训、陷阱和克服陷阱的策略

让我们 开始吧！

一生致力于测试、质量、安全和反馈的研究，专注于 DevOps、DevSecOps 和 SRE。

回到 1960 年代，我是一个在加拿大安大略省金斯顿的工人家庭中长大的小男孩。 我们并不富裕，但我们有彼此。 我的父母都很努力工作，为我和我的两个姐妹提供食物和房子。 我是家里的小宝贝，我和我两个姐姐相差七岁。 基本上，我有三个妈妈，因为我的姐妹从一开始就把我看作“婴儿马克”，这个昵称一直伴随我到成年。 我也一直带着这个名字。

这种情况给了我大量的时间来玩耍和弄坏东西。 这个事实为我提供了实验的机会，因为我被宠坏了，而这也很好，因为我天生有些懒散——这是一个一直持续到今天的特质，也是我终身对 自动化 感兴趣的原因。

我喜欢拆解机械物品和家用电器，尝试理解它们是如何工作的。 这些早期的经验教会了我很多关于测试、质量、安全和反馈的重要性，因为我拆解的一些物品让我和我的猫 Puff 都受了轻伤和电击。 (那只猫有时是我的实验助手。）我还学到了遵循质量过程的重要性，因为我很少能在没有爸爸帮助的情况下把东西重新装好。 从爸爸那里得到帮助。

也许是因为我在家里弄坏了很多东西，我的父母给我买了一系列的 MECCANO 模型套件，这些套件是由机械金属零件组成的自制工具包——螺母、螺栓、预先打孔的支架和金属片、齿轮、轮子、皮带和滑轮，你可以用它们来创造各种东西。 图 3**.1 展示了它的样子。

图 3.1 – MECCANO

我特别有兴趣的是用 MECCANO 的上链马达，后来是 MECCANO 电动马达，来自动化我所做的玩具。 我记得我做了一个能自动行驶的装载机。 它会撞到家具上，因为它有运动功能，但没有传感器或反馈系统。 我对这个结果不满意，因为它与真正的装载机相比，实用性非常有限。 由于 MECCANO 没有传感器，所以我决心寻找另一些可以 实验的东西。

离我家几条街远有一家“神奇”的商店，名为爱好商店，里面有低价的玩具模型和许多吸引我的东西。 在我每周的小额零花钱支持下，我可以买到微型塑料比例模型飞机，这些飞机不仅能飞，而且还有控制元件，可以在用橡皮筋发射后操控飞机的飞行。 这种控制能力非常粗糙，因为发射后无法调整——这一点也导致了许多意外事故，但我可以根据之前飞行的反馈，在测试飞行之间调整飞行路径。 模型车赛道也在模型商店里提供。 这更加令人满意，因为我可以用手控调整速度，但从视觉角度来看，反馈非常有限，因此车子经常会被过度加速，跳出赛道并发生撞车。 这些早期的经历让我明白，及时的反馈是正确调整控制所必需的，反馈与控制的结合影响着即使是简单系统的结果质量和安全性。 简单系统也是如此。

虽然建造和操作模型很有趣，但这并没有满足我对更好控制系统的兴趣，而且它们没有日常实用性。 我的第一辆自行车让我更为满足，因为我可以同时控制和监控我的方向和速度，并用它去某个地方，尽管它需要花费很多力气踩踏板。 在青少年时期，我开始建造和操作摩托车、电动自行车和汽车，其中一些如图 3**.2*所示。由于资金紧张，我会花很少的钱买一辆不工作的自行车或汽车，然后与爸爸和机械师朋友一起修理，使其能够上路。 在这个过程中，我学到了很多关于机械和电气系统的知识，也了解了仪表盘指示器的重要性。 每一次转变都让我接触到越来越复杂的系统，这些系统需要多重控制和反馈机制才能可靠 且安全地运行。

图 3.2 - 摩托车和汽车

我注意到许多控制和反馈功能中都使用了电子元件。 对我来说，这些都是黑匣子。 于是，我决定在高中学习电子学，了解电子学是什么以及它是如何工作的。

我在 10 年级电子学课上的第一个项目是制作一个多用电表，用来测量电流、电压和电阻。 虽然它是一个粗糙的电表，但它足够准确，可以作为一些早期电气和电子项目的反馈电表，直到我有足够的钱购买一台专业的福禄克（Fluke）多用电表。 通过暑期工作赚的钱，以及卖掉我的摩托车和汽车的利润，我能够购买 Heathkits，这是一种用于复杂电子系统的自组装套件。 按照套件的说明，我制作了电子工具，包括可调电源、频率计、示波器和面包板，如 图 3**.3所示。这些工具足够可靠和准确，可以在我的工程学院岁月中以及之后使用。 (我仍然保留着那台多用电表和电源——它依然在工作，50 年后依然有效)。

图 3.3 – 电子工具和 Heathkits

我意识到，尽管电子技术可以执行许多功能，用于复杂系统的感应和控制，但无论是人类还是自动化都需要操作它们，以完成有用的任务。 这时，我对计算机和 编程产生了兴趣。

我第一次编程的经历是在高中 10 年级。 我们可以访问一个远程的共享主机计算机，用来执行用 A 编程语言 (APL) 编写的数学公式。 输入（控制）和输出（反馈）以电子终端的形式出现，看起来像一台打字机，如 图 3**.4所示。我喜欢终端的快速互动响应，但我了解到 APL 仅限于计算，并不适合一般用途的计算应用。 我们还可以本地访问一台大学的主机计算机，该计算机配有卡片读取器，可以接受以穿孔卡堆栈形式的 Fortran 程序。 共享的 IBM360 主机会按批处理作业顺序运行每个程序，输出（反馈）会通过行式打印机生成。 由于读取、运行和输出的序列是串行的并且具有变动性，反馈可能会根据程序的大小和排队的批处理作业数量而延迟数小时。 从程序创建到反馈的时间是令人沮丧的 且缓慢。

图 3.4 – 早期计算机与编程

几年前，我购买了一台 Radio Shack TRS-80 个人电脑和一台 Commodore 64，这台电脑直接通过键盘以 Basic 语言进行编程。 微处理器专门用于一个单一应用程序。 磁带提供了“大容量数据”存储和检索功能，因为内存电路非常昂贵且容量有限。 字符模式显示器可以实时输出字符，这对于实时反馈非常有用，但输出格式有限，尤其是在图表方面。 和图表。

这些个人电脑还配有声耦合器，可以连接到电话听筒进行数据传输，连接到其他远程计算机，这样我就可以实验 TRS80 和 Commodore 之间的数据通信。 这是我第一次体验自动化远程控制和实时远程反馈。 这为许多新应用开辟了可能性，如远程控制机器和互动视频游戏等的互动远程控制和反馈。 但通信速度受到调制解调器限制，只有 300 波特。 我很快意识到，精确的实时控制和反馈只有通过特殊的硬件和固件才能实现，这些硬件和固件可以构建更精确的机器级定时，以满足实时控制应用的需求。 我购买了一些微处理器评估工具包，并学习了汇编语言和集成电路逻辑设计，了解实时传输控制和 反馈方法。

在我的 皇后大学工程专业 学习期间，我学到了更多关于测试、质量、安全性和反馈对于 系统设计的重要性。

在我做的一个暑期工作中，我在 多伦多的一家 埃索石油 公司数据中心的输入/输出部门工作，那里有一台大型的 IBM360 大型计算机，用于加拿大范围内的石油物流计算。 输入是打孔卡片，输出是一个“高速”线路打印机，生成连续的多份复印纸，并由碳纸分隔。 打印生成后，碳纸和打印副本必须通过“分解器”机器分开，然后使用“爆破器”机器将各个页面分开并堆叠。 然后，分开的副本用金属针装订成书籍形式，便于分析人员阅读，他们每天早上都会在指定的邮箱槽中收到自己的副本。 每早。

从卡片输入到输出（印刷书籍）的反馈时间通常超过 16 小时，所有当天所需的输出都需要这么长时间。 如果分析员发现问题，问题就必须排队等到第二天才能重新测试。 物流问题意味着一些石油交货会因为每天的操作调度而迟到。 多次，尤其是在系统升级错误时，整个一天的测试运行失败，导致整个数据中心的物流操作中断。 这再次让我明白，加速测试、质量保证、安全性和反馈对于 确保操作至关重要。

在我大三的 暑假，我有幸在电信制造商 北方电信 (NT)工作，他们把我安排到 贝尔-北方研究院 Bell-Northern Research (BNR)，因为他们需要一种方法来测试 BNR 正在研究和开发的新一代分组交换系统。 在 BNR，我在专家科学家的指导下，开发了用于测试新分组交换机的干线卡的特殊电路、纳米代码、微代码和高级软件。 这将测试时间从几天缩短到了几分钟，大大提高了制造技术人员的质量检验精度，并减少了调试时间。 这是一个让我深刻认识到自动化在改善反馈方面具有改变游戏规则的力量的教训。

我的皇后大学 工程论文项目，名为 Intellicom，是我与两位工程专业同学的合作成果。 我们设计并构建了第一批空间交换式多功能私人办公室电话系统之一，如 图 3**.5所示。最终，这一项目 在一次区域大学工程活动中获得了认可。

图 3.5 – Intellicom 工程论文项目

我们构建了中央控制器，包含一个使用微处理器板的开关控制器、内存卡和带有混合模拟-数字转换器的电话线路卡，所有部件通过电线包裹的背板互联。 中央控制器和线路卡具有 LED 显示屏，用于提供实时操作反馈。 我们还设计并制造了四个多功能手持终端，配有用于输入数字和控制的按钮，以及用于终端用户反馈的 LED。 中央办公单元和手持终端之间的控制和反馈信息通过与语音线分开的控制线传输。 回顾起来，这是电话系统中常用信道信号的一个特别早期实现，这一信号技术后来成为电话系统发展的方向！ 鉴于学生预算非常有限，我们四处寻找零件，比如借自宿舍的手持终端，我的暑期学生老板也慷慨地从 BNR 的废料堆中捐赠了一些零件。 我们不得不使用 256 字节的 eROM 存储引导程序，和 1 Kbyte 的 2,102 RAM 来存储整个用 68 K 汇编语言编写的操作软件。 这要求我们进行一些 创意编程。

这是一个具有挑战性的项目，考虑到它必须在毕业前完成，尽管课程负担非常重！ 我们从一开始就意识到，按时完成的唯一希望是确保我们的进度始终朝前推进。 如果出现重大错误，恢复的时间不多。 因此，我们采用了增量设计、构建、测试、锁定的方法——这后来被称为敏捷和DevOps。 随着越来越多的部分被锁定，测试阶段的复杂性和时间大幅增加，因此我们自动化了测试。 这为我们节省了大量时间，并极大地提高了信心和质量。 通过破坏性测试，我们发现并解决了潜在的安全问题，例如串音和未经授权的监听。 最令人满意的时刻是，当我们的教授看到所有功能都正常工作，并且无法让我们的系统在最终的“演示日”崩溃时。

BNR——世界级大学

1978 年毕业后，我被 NT 聘用，位于加拿大安大略省贝尔维尔，并最初被 NT 指派到贝尔北方研究院（BNR），位于加拿大安大略省渥太华。 我的任务是继续我之前暑期工作的项目，即将实验性的 SL-10 分组交换系统技术从 BNR 实验室转移到 NT 制造部门。

在 1970 年代末，BNR 是一个完美的学习环境。 它汇聚了通信行业中的顶尖人才。 整个组织充满了创意、活力、创新和合作精神。 它的文化以电信系统的研究与开发为核心。 BNR 拥有真正令人惊叹的实验室能力，且许多项目都能轻松获得资金支持。 在这里工作提供了许多机会， 可以与三大公司——NT（后来更名为 NorTel）、BNR 和运营公司贝尔加拿大的优秀科学家和工程师合作。

我被分配到 BNR 分组交换组的系统测试团队，而我的 NT 角色是确保 SL-10 为 NT 制造做准备，负责在工厂中构建和测试 SL-10 节点和组件。 这个角色还包括开发一套切换驻留的测试程序，以验证各种系统组件，称为在线下测试（ISLOT），这一独特的职责让我学习到研究、技术开发和业务制造操作。 由于我是组织中为数不多的拥有这样系统级角色的人，我也有机会参与客户演示和互动。

SL-10 在现场实验中的早期成功获得了认可，NT 接到了来自德国德意志联邦邮政的订单，项目名称为柏林分组实验 一个名为柏林分组实验。

我被派往柏林安装交换机，如 图 3**.6所示。由于 NT 和 BNR 在德国没有支持办事处，我必须准备好处理所有问题，借助远程通话指导 BNR 的科学家和工程师，他们位于加拿大渥太华。 我工作的质量和向 BNR 提供的反馈对项目的成功至关重要，业务期望非常高。 如果柏林节点表现良好，客户将为德国的数据包网络购买大量 SL-10 节点，这对 NT 来说具有战略意义，他们希望扩展他们的业务 到欧洲。

我预料到会遇到一些问题，但事实证明这是一次真正的“磨炼”。在柏林现场，我们发现了许多 SL-10 节点的问题。 我们发现并解决了电源问题，连接器和电缆不匹配，软件性能问题，电源恢复程序，系统命令问题以控制系统配置，状态和故障指示器以及协议 通信问题。

此外，我们发现了关于传达失败信息、上传远程修复进行测试以及在现场测试验证修复困难的问题。 历时九周，但最终，交换机运行良好，足以满足实验的现场试验目标。 最终，德国确实继续了额外的订单，这成为了欧洲首个 大型数据包网络，名为 DatexP。在这个过程中，我们学到了很多关于如何使 SL-10 节点投入运营的经验，远程支持所需的反馈机制，以及需要改进以加速投入运营过程的内容。 和运营。

从测试的角度来看，使用 BNR 设计的微处理器协议测试仪进行数据协议仿真，以及 NT 设计的数据监控工具 DataSope 是最重要的。 这些工具在安装过程中替代了主机和终端，帮助诊断各协议层的连接问题。 测试结果可以打印出来，然后传递给开发人员，以便诊断问题并验证后续的修复。 其他反馈机制包括电路板上的 LED 指示灯和 SL-10 字符模式的视频显示管理终端。 这些工具提供了宝贵的线索。 它们没有互联，需要大量的人工协调，才能形成连贯的事件记录。 我意识到，如果这些工具能设计得与系统以及彼此更紧密集成，测试、诊断、修复和重新测试的周期将大大提高效率。

图 3.6 – SL-10 BERPEX

BERPEX 的成功经验向 BNR 和 NT 表明，SL-10 是一个重要的商业机会。 我们已经有来自比利时银行等客户的网络数据传输新业务前景， 例如法国巴黎银行， 他们希望在 1979 年安装一个网络。 但在我们交付之前， 质量需要改进。 我们才能交付。

1979 年初从柏林回来后，我被指派领导一个测试团队，验证 SL-10 的“通用 10 版”，该版本整合了柏林实验中确定的硬件和软件更改。 乐观估计，验证系统更改并达到我们的质量目标，包括客户要求的协议和网络配置，需要八周时间。 然而，测试是手动的，而且有成千上万的测试。 每个协议需要数百次测试来验证每次更新。 我们不断发现严重的问题，导致系统测试过程被重置。 我们发现许多柏林没有测试的协议问题，以及一些多节点测试拓扑问题，这些问题超出了柏林项目的范围。 实际上，我们达到 SL-10 通用 10 版质量目标的时间是八个月，比原计划多了 6 个月！ 最终，我们有了一个满足客户质量目标的交换机， 可以交付给 SGB。

我被指派到现场负责调试最初的三台 SL-10 节点——布鲁塞尔的主节点，以及安特卫普和根特的两个节点。 在 SL-10 通用 10 测试和质量改进上的投资获得了回报。 节点的安装比在柏林时快得多。 我能够在几天内完成每个节点和协议接口的调试，比在德国的 9 周大大缩短了时间。 节点之间的连接确实花了更长时间，但这并不是 NT 或 SL-10 的错。 比利时电话公司的干线连接延迟交付。 一旦干线连接可用，SL-10 分组网络在几天内便启动并正常运行。 SGB 成为 NT 的一个重要客户，SL-10 也成为全球许多其他客户的首选分组系统。 我将现场成功的一部分归功于我之前开发的自动化 ISOLT 测试软件和干线测试系统。

然而，回顾起来，有一件事并不好。 6 个月的“过度估计”是个问题。 虽然大家普遍称赞结果的质量，但管理层对于 验证发布所需的时间并不满意。 我接到了一个任务，要找出如何将 SL-10 的质量验证时间从 8 个月缩短到 2 个月。

答案显而易见——自动化那些费时的测试，并建立一个可配置的测试实验室，以适应不同客户所需的各种系统拓扑结构。 我被赋予了创建一个新团队来开发测试工具的角色。 考虑到之前的经验，我知道测试系统必须强大、可扩展，并且功能丰富。 它必须是开发人员、测试人员和现场工作人员都能轻松使用的工具，以便他们能够高效地沟通测试和测试结果。 它必须具备足够的容量和性能，能够测试高性能、高可扩展性的分组网络，支持多种协议、线路和 干线接口。

在几年内，我的团队 开发了一套名为 网络测试环境 (NTE). 我的论文， 集成化 SL-10 分组网络测试中心，于 1985 年发表在 ACM 期刊中，解释了它是如何运作的。 图 3**.7 展示了该工具集中的主要工具架构的部分插图。

图 3.7 – 网络测试环境

共有四种类型 的工具：

• 交互式协议测试仪 (IPT)：它模拟通信协议， 可以通过 CLI 进行交互操作或远程控制。

• 网络负载测试系统 (NLTS)：它 生成并测量 网络流量。

• 网络过程监控器 (NPM)：它 可以生成内部流量，并执行 网络监控。

• 网络测试系统 (NTS)：这是一种通用的自动化测试控制器 ，可以通过我们开发的测试语言 （测试语言 ，简称 TLAN）自动化执行操作并监控网络中其他工具和管理界面的结果。

除了 NTS 外，所有这些工具都在产品硬件上运行，这使得它们能够扩展到大型配置，同时也可以扩展到产品本身，并提供与现场节点集成的用例。 这种方法还确保了工具共享相同的管理和更新流程。 NTS 在一款基于 Unix 的商用微型计算机上运行，该计算机从微型计算机到大型机都有，能够根据测试需求进行扩展，并由供应商进行维护。 由于 NTS 计算机与 SL-10 数据控制中心使用的是相同的品牌，它可以按照与产品相同的程序进行集成和维护。

通过这些工具的配备，我们拥有了一整套完全整合的测试工具，能够自动化实验室、现场试验和本地测试中的所有测试。 与 竞争对手相比，这是一个重大优势。 这为 SL-10 以及下一代 数据包网络 (DPN)的实现做出了贡献，使其在 1980 年代和 90 年代初，成为全球连接导向包交换行业中效率、质量和销售水平最高的技术。

NTE 工具获得了业界认可，持续升级，并成为 全球电信网络 从电路交换向 信令系统 7 (SS7) 和 综合业务数字网 （ISDN） (ISDN)。

在此过程中，我对全球 国际标准化组织 (ISO)的标准化协议合规性测试的倡议作出了领导性贡献，并提出了一个名为 树形和表格组合符号 表示法 (TTCN) 的平台。

由于这一成功，我在网络测试技术方面的职业方向得到了巩固，并通过在 BNR、ECI Telecom 和 vPacket Communications 等一系列项目中得到提升，如 图 3**.8。

图 3.8 – 集成网络测试技术

在 BNR，我被提升为全球测试技术总监，负责为 所有 BNR 和 NT 网络及终端产品创建测试系统。 从 80 年代中期到 1991 年，我的团队为所有交换部门的产品以及为我司产品配套的第三方终端设备开发了一系列测试系统。 这些包括 测试与流量仿真 (TATS) 自动化平台，用于网络产品系统和回归测试，配有标准化测试套件的远程合规性测试平台用于第三方资格认证，以及用于测量 测试覆盖率的工具。

我们开发的一个 更为重要的工具平台，名为 测试执行管理器 (TEAM)，大大减少了设置和运行网络测试用例的时间，使得每季度节省了超过九千万美元——这一成果持续了多年！ 它是我们公司在开发、集成和系统测试过程中的关键平台。 TEAM 通过开发人员的 Unix 工作站窗口操作，并提供控制和反馈。 它确保每个用户会话都安全，并协调了成千上万的开发人员和实验室系统之间的测试环境预订，这些都是网络开发和 系统测试所必需的。

后来在 ECI Telecom 和 vPacket，我负责指导开发灵活的远程访问产品，这些产品提供了许多配置选项，需要进行测试。 为了减少测试时间，我们构建了可以快速重新配置的灵活测试设置，同时运行自动化测试用例，并设计了内建测试能力来监控网络产品的系统性能。 将测试能力无缝集成到产品和流程中这一想法，提供了快速的变更资格认证，并在开发、集成、 和生产过程中改进了协作。

作为商业企业的测试

由于我在职业生涯中花费了大量时间开发测试技术，因此参与测试系统作为商业业务对我来说是合乎逻辑的。 如图 3.9所示，在 1990 年代和 2000 年代初，我在Tekelec、VIEW Engineering 和 Spirent Communications等公司，担任过多个高级工程和商业职位，负责商业测试产品平台的开发。

图 3.9 – 商业测试产品

在这段时间里，我创办了一家名为EdenTree Technologies的公司，专注于为网络实验室开发智能测试自动化平台。这使我接触到了全球数百个客户在网络、企业、运营公司和政府机构中的测试和质量保证环境。我发现，测试是发布流程的瓶颈，并且对大多数行业实现质量构成了障碍。我清楚地看到，我在职业生涯中之前学到的许多关于测试、质量、反馈和安全的经验，能够帮助全球的许多组织。

咨询与教学

从 2008 年开始，我的职业生涯越来越多地集中在为客户的测试、质量、反馈和安全流程提供高级咨询专业知识，以支持他们的 DevOps、DevSecOps 和 SRE 数字化转型项目。

作为 Spirent Communications 的高级解决方案架构师，我为客户提供关于将测试工具和自动化与 DevOps 测试环境和流程整合的建议。我还为开发一个强大的测试环境自动化平台提供了建议，名为Velocity。

在Trace3，我帮助建立了一个名为Total DevOps的咨询实践，强调为企业客户自动化持续集成和持续交付（CI/CD）流程。

2019 年，我创办了一家精品咨询公司，名为Engineering DevOps Consulting，根据我的书籍Engineering DevOps（2019 年由Book Baby自费出版），提供关于 DevOps、DevSecOps 和 SRE 转型的规范化实践。

图 3.10 – 合作伙伴与客户

如图所示，今天我通过与其他咨询、培训和媒体公司（如 DevOps Institute、DevOps.com、Xellentro、Learning Tree International 和 Opus Technologies）合作，提供 DevOps、DevSecOps 和 SRE 咨询服务，服务对象涵盖了许多企业、制造商、服务提供商和机构。

经验教训、陷阱和克服陷阱的策略

回顾我职业生涯中的经验，本章前面已有描述，我确定了克服这些陷阱的常见策略。 以下章节重点介绍了从质量、测试、测试自动化、标准化、安全性 和反馈角度的一些经验教训。

质量的重要性

我对质量的主要体会是，太多组织对如何定义、衡量和实现适合其使命的质量水平有着过于狭隘的理解。 爱德华·戴明博士，一位著名的质量管理专家，将质量定义为一个连续的过程，而不是静态属性。 他强调，质量不仅仅是满足规格要求或拥有无缺陷的产品，而是要满足客户的需求并超越 他们的期望。

追求“零缺陷”并不是一个适当的目标，这样做是浪费的。 相反，需要定义对组织使命的所有客户和利益相关者重要的用例。 当这些用例完全满足时，就达到了足够好的质量。

建立持续质量评估和改进流程比实现任何一个质量里程碑更重要，因为利益相关者的需求会随产品或 服务的成熟而发展。

持续测试是实现成功的持续质量程序的关键部分，因为测试提供了符合利益相关者用例的证据。 然而，单靠测试还不够。 其他因素，如对支持请求的响应速度、易用性、集成、成本效益和创新的产品路线图，对满足客户质量期望同样重要，需要监测，以便组织能够持续 成功。

将测试工具集成到系统中

我了解到，测试是每个过程、产品和服务中必不可少且重要的一部分。 测试 活动包括测试规划、测试创建、测试环境搭建、协调、测试执行、结果报告、结果分析、故障报告和修复后重测。 测试通常占据价值流总成本和时间的 50%以上。 成功的产品和服务认识到这一点，并在其产品和流程中建立了测试和监控能力。 通过这种方式，测试能力在需要时可以随时使用，并能随着产品的规模扩展而扩展。 这也确保了测试数据和结果能够以所有利益相关者能够立即使用的形式反馈，从而促进协作， 减少浪费。

测试自动化提升效率和竞争力

在大多数情况下，最好完全自动化所有类型的测试。 测试需要在产品价值流的每个阶段和每次迭代中频繁重复。 如果没有自动化，每个阶段都将因为等待有人执行测试而被延迟。 此外，手动测试容易受到人为错误的影响，导致浪费、假阳性和假阴性结果。

最具竞争力的产品优先考虑测试自动化，因为自动化测试带来的时间效率和质量效益使得组织在竞争对手面前拥有战略优势 ，而那些没有进行自动化的竞争对手则处于劣势。

然而，必须小心确保测试自动化有强有力的标准，否则测试维护和结果分析会成为瓶颈， 导致过度返工。

AI/ML 的进展有助于提高测试自动化和维护各个方面的质量和速度。

标准加速了协作

没有 强有力的测试文档标准，自动化测试可能会失控，变得浪费。 标准有助于工具和团队成员之间的协作。 为质量、测试策略、测试计划、测试用例、测试脚本、测试环境、测试执行、测试结果、测试分析和 反馈报告制定标准是非常重要的。

此外， 定义 服务水平目标 (SLOs)也非常重要，它们决定了测试失败如何在组织中被优先处理，否则过程可能会导致 组织内部的摩擦。

理想的做法是 提供一个通用的测试工程平台，作为服务提供给开发、测试和运维团队，以促进测试文档的沟通，并确保组织中的每个人都能共享一个统一的“真理源” 来进行测试。

安全需要一种综合性的方法

随着系统变得更加分布式、通过多个管道交付并部署在分布式的短暂 基础设施上，网络安全问题持续演变和升级。 除非将安全控制措施内建到端到端 价值流中，否则安全问题会成为开发、集成、交付和生产过程中的主要瓶颈。

持续的安全思维模式和安全实践的实施需要结合 DevSecOps 实践和生产中的 SecOps 实践，以确保在生产部署前后最小化安全问题。 整个开发团队需要进行安全编码培训，并且安全实践需要通过针对每个应用程序的威胁建模来主导。 集成和交付过程中，代码、第三方库和镜像扫描器需要根据最 可能的威胁进行调整。

渗透测试和混沌安全工程需要作为交付过程的一部分，在发布到生产环境之前进行自动化处理。 所有的过程和资产都需要通过基于身份的零信任技术和防火墙进行保护，因为安全威胁可能来自组织的内部或外部。 部署最好使用不可变 技术，如 基础设施即代码 (IaC)，容器和容器编排工具，这些工具能够使基础设施快速响应变化的威胁条件。 安全事件和指标的监控需要在每个价值流中从构思阶段 一直延伸到生产阶段。

没有反馈，你就像是在盲目前进

反馈以质量指标、测试指标和安全性指标的组合形式进行，对于监控和管理开发、集成、交付和部署中的变化流动效率至关重要。 可以将阈值和目标定义为 SLO，并持续使用 服务级别指标 (SLIs)进行测量。 错误预算和错误预算政策是 SRE 实践中的概念，有助于管理这些活动，确保组织遵守这些指标。 组织。

总结

本章回顾了我的职业经验，提炼出关于质量、测试、安全性和反馈方面的常见陷阱和有效策略的见解。 它首先强调了质量的多维性质，呼应了德明的观点——质量不是静态的属性，而是一个持续的过程，需要与客户需求对齐，并超越他们的期望。 追求“零缺陷”被认为是浪费，强调了识别关键用例的重要性，并通过满足这些用例来实现令人满意的质量。 强调了持续评估和改进，认识到利益相关者需求的不断变化。 利益相关者的需求。

测试被视为一个关键方面，占用了价值流中大量的资源。 成功的产品将测试能力集成到产品本身，确保可扩展性，并且能够即时提供测试数据，以便利益相关者之间进行合作，从而 减少浪费。

测试自动化被突出为提升效率和竞争力的驱动力。 本章倡导全面自动化，以避免手动测试中固有的延迟和错误，但强调了强有力的标准对于维持测试维护和 结果分析的效率的必要性。

标准的建立被强调为在测试实践中实现协作和控制的关键。 从质量到反馈报告，标准被认为至关重要。 倡导建立一个通用的测试工程平台，它提升了沟通效率，并在整个组织内建立了共同的事实基础。 整个组织。

针对安全问题，本章强调了在整个价值流中采用全面方法的必要性。 从 DevSecOps 实践到生产中的 SecOps 实践，安全措施的整合得到了强调。 建议采用威胁建模、自动化安全测试和零信任方法，以应对内部和外部的安全威胁。 安全威胁。

最后，强调了反馈机制的重要性，结合了质量、测试和安全指标。 SLOs、SLIs 和错误预算政策被突出了作为持续监控和管理的实用工具，确保组织与已定义的指标保持一致。 已定义的指标。

下一章将解释一种工程方法，指导转型活动朝着成功的方向发展。 朝着成功发展。

第二部分：确定解决方案优先级

第二部分 聚焦于有效实施组织持续实践所需的战略规划和优先排序。 它从探索一种系统的工程方法开始，用于规划持续测试、质量、安全和反馈的解决方案。 这为组织提供了一个有纪律的框架，确保它们的转型努力既结构化又有效。 并且有效。

本节通过讨论如何确定符合不同组织、产品和服务具体需求的转型目标来推进。 它介绍了帮助设定这些目标的工具和方法，提供了一个清晰的路线图，供企业遵循。 此外，本节还讲解了通过发现和基准测试来了解组织当前能力状态的重要性，这对于识别需要改进的领域至关重要。 本节还讨论了如何选择合适的工具平台以及集成 AI 和 ML 技术，这些都能增强持续实践并促进持续改进和韧性文化的培育。 本书的这一部分对于那些希望通过持续实践战略性地优先考虑和简化数字转型方法的人来说至关重要。 持续实践。

本部分包括以下章节： 章节：

• 第四章**, 持续测试、质量、安全和反馈的工程方法

• 第五章**, 确定转型目标

• 第六章**，发现与基准测试

• 第七章**，选择工具平台和工具

• 第八章**，将 AL/ML 应用于持续测试、质量、安全性和反馈

第四章：持续测试、质量、安全性和反馈的工程方法

本章解释了一种系统化、规范化的工程方法，用于规划持续测试、质量、安全性和反馈解决方案。 这种方法是多年来根据前一章中描述的经验而发展出来的。 它包括七步转型工程蓝图，解释了专家转型顾问的重要性以及使用 AI 工具加速工作，并解释了能力成熟度模型 (CMMs)以及持续测试、质量、安全性、 反馈的能力成熟度等级。

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

• 为什么需要工程 方法？

• 七步转型 工程蓝图

• 能力成熟度模型 指导转型

• 能力成熟度等级 – 持续测试

• 能力成熟度等级 – 持续质量

• 能力成熟度等级 – 持续安全性

• 能力成熟度等级 – 持续反馈

让我们 开始吧！

为什么需要工程方法？

实施持续测试、质量、安全性和反馈需要一个精心设计的数字化转型方法，因为这不仅仅是采用新工具，而是从根本上改变组织的运作方式、交付方式和衡量价值的方式。 这涉及到重新定义流程、文化和思维方式，将这些元素无缝地整合到软件开发生命周期中。 这是一种全面的变化，需要在实践和部门间的协作上进行转变，并将这些努力与更广泛的商业目标对齐。 这种转型确保质量和安全性不再是事后考虑的因素，而是开发过程中的核心组成部分，是不断监控和持续改进的方面。 开发过程。

组织的数字化转型不仅影响技术，还会影响战略、运营和客户互动。 目标是提高效率、管理风险并发现新的 变现机会。

组织在数字化转型中常常面临挑战，原因在于以下几个 关键陷阱： 陷阱：

• 缺乏清晰的愿景和战略：如果没有明确的方向和对数字化转型内容的理解，组织可能会在有效地协调 各项努力上遇到困难。

• 抗拒变革：组织内的文化抗拒，特别是来自那些习惯于传统工作方式的员工，可能会阻碍新技术 和流程的采用。

• 领导承诺不足：转型需要强有力的领导来推动变革、克服抗拒并分配 必要的资源。

• 规划与执行不力：缺乏足够的规划、不切实际的时间表和不足的资源可能导致 实施失败。

• 技术挑战：过度依赖技术而忽视必要的流程和文化变革可能导致 不理想的结果。

• 扩展失败：将成功的试点项目扩展到更广泛的组织中存在困难，可能会妨碍 转型努力。

• 技能与专业知识不足：员工缺乏适应新数字工具和流程所需的技能，可能成为一个 重大障碍。

• 缺乏衡量标准：没有度量标准来监控进展、绩效和 投资回报率 (ROI)，可能 导致各项努力失去方向，无法准确衡量成功或 失败。

• 服务不足与可持续性：未能确保数字化解决方案能够在时间推移中保持可维护性和可持续性，可能导致系统在长期内无法持续，破坏 整个 转型努力。

对于成功的数字化转型来说，工程化方法至关重要，因为它为通常复杂而多方面的过程带来了结构化、纪律性的方法论。 这种方法确保数字化转型不仅仅是采用新技术，而是重新设计流程、工作流程和组织结构。 它有助于有条不紊地解决转型过程中的技术、流程和文化方面的问题，降低风险，提高效率，并增加实现期望结果的可能性。 通过应用工程原则，组织可以系统地规划、实施、衡量和迭代其转型工作，将其与业务目标对齐，并确保可持续、长期的成功。

理解七步转型工程蓝图

在 工程化 DevOps 中描述的 图 4**.1 中展示的 七步转型工程蓝图 *。该蓝图规定了一个无限循环的七步骤，用于有条不紊地实现您的转型目标，无论您当前的目标或成熟度水平如何。 相同的七个步骤适用于希望将其测试、质量、安全和反馈流程转型为 连续流程的组织。

图 4.1 – 七步转型工程蓝图

从一个成熟度级别转型到下一个更高级别，需要通过每个改进周期的七个步骤进行过渡，以实现在人员、流程和技术三个转型维度及持续测试、质量、安全和反馈实践支柱上的平衡，正如 第二章中所述。当维度和支柱失衡时，将会产生摩擦，影响流水线的高效运行和目标的实现。 对维度和支柱的变更必须逐步引入，并在连续的 改进循环中进行系统测试。

七步转型工程蓝图 包括以下 七个步骤：

1. 愿景制定：定义组织的战略需求，并确定在战略层面上主导转型的赞助人，以及需要与转型战略对齐的关键合作伙伴组织。

2. 对齐：对每个转型周期至关重要的领导者和关键利益相关者就选定应用的具体目标达成一致。

3. 评估：对于选定应用的当前状态，发现和评估成熟度，针对特定主题进行深入评估，并创建相对于组织目标的当前状态价值流图。

4. 解决方案：一个专家团队对评估数据进行分析，并制定未来状态的价值流路线图，包括主题、史诗和用户故事，并与关键利益相关者达成一致。

5. 实现：定义实施项目，包括用户故事和任务，进行概念验证（PoC）试验以验证解决方案选择，解决方案在选定的应用和用例中得到验证，随着解决方案部署到生产环境，进行培训，并启动新解决方案的治理实践。

6. 运营化：已部署的改进通过站点可靠性工程（SRE）实践进行监控和控制，监测 SLI、SLO 和 SLA 指标。进行回顾性评审，创建可操作的优先级排序的经验教训，以便持续改进。

7. 扩展：一旦为选定的应用实现解决方案，组织可以安全地将解决方案扩展到组织中的其他应用。进一步的转型周期将为每个应用带来更高的成熟度。

该工程蓝图对于旨在提升实践到更高能力成熟度的组织至关重要，确保对转型采取平衡、系统化和渐进的方式。

如果企业未能遵循这一转型蓝图，可能会出现若干风险和后果，削弱转型的效率、效果和整体成功。 以下是未遵循 蓝图步骤的风险和后果：

1. 愿景：

   • 风险：如果没有明确的愿景和完善的转型战略需求文档，组织可能在转型过程中缺乏方向和目标。 这可能导致目标不对齐， 资源浪费。

   • 后果：缺乏强有力的支持和与关键合作伙伴的战略对齐可能导致对变革的抵制、团队的低采纳率，并未能实现 转型的全部收益。

2. 对齐：

   • 风险：未能就转型目标达成一致，可能导致不同团队和部门之间在期望和交付物上的不一致。 这将影响整体协调。

   • 后果：这种不对齐可能导致团队之间的摩擦、低效的工作流程和缺乏协作，所有这些都可能拖延或破坏 转型计划。

3. 评估：

   • 风险：跳过对当前状态和能力成熟度的评估可能会导致在理解从何处进行改进的基准时出现空白。 这会留下理解上的漏洞。

   • 后果：没有明确的评估，进展很难衡量，也难以识别需要改进的领域，导致资源的低效使用，并可能错过关键问题，从而阻碍 转型 的成功。

4. 解决方案：

   • 风险：未能利用专家分析来制定未来状态的路线图，可能导致解决方案选择不当，且转型过程缺乏清晰性和方向。 转型旅程可能因此受阻。

   • 后果：组织可能实施与其具体需求不匹配的解决方案，导致无效的做法和成本增加，并可能未能实现 预期结果。

5. 实现：

   • 风险：忽视实现阶段，包括 POC 试验和验证，可能导致部署的解决方案未经过充分测试 或理解。

   • 后果：这可能导致运营中断、用户体验下降、生产力降低，以及团队成员对实践缺乏信心。

6. 操作化：

   • 风险：忽视对已部署改进的监控和控制可能导致无法看到实践的表现和效果。

   • 后果：没有适当的监控和回顾，组织错失了持续改进的机会，可能导致运营停滞和低效。

7. 扩展：

   • 风险：未能在组织内推广成功的实践可能会将转型的影响限制在少数特定的应用或团队中。

   • 后果：这一有限的范围可能会阻碍组织实现更广泛的运营效率，降低转型努力的整体投资回报率。

总结来说，未遵循七步转型工程蓝图会显著阻碍组织成功实施并从实践中受益的能力。这些风险凸显了转型过程需要结构化、战略性方法的重要性，强调需要明确的愿景、对齐、评估、解决方案开发、实现、操作化和扩展，以确保成功融入企业。

下一部分将解释如何加速七步转型过程。

专家和人工智能加速转型

如图 4.2所示，建议由经验丰富的转型专家顾问，或由人工智能工具支持的小型专家团队，引导转型过程，充当“专家转型顾问”，可以是个人，也可以是集体形式。

图 4**.2 说明了转型顾问作为转型过程的编排者的核心角色。 转型顾问提供工具和模板，帮助加速转型过程的每个步骤。 在转型过程的每个步骤中，这些工具和模板可以根据组织的需求、成熟度水平和偏好进行定制。 利用 AI 工具在每个步骤加速此过程，以根据 前几步骤的结果为每个步骤的模板建议定制。

图 4.2 – AI 加速转型过程

专家顾问在编排七步转型工程蓝图中的角色至关重要，以确保组织转型工作的成功。 这些顾问带来了专业的知识、经验和技能，指导和促进转型过程的每一步，确保战略目标高效 和有效地实现。

在专家顾问的指导下，AI 工具能显著提升转型过程中每个步骤的效率、速度和质量。 。

以下概述了专家顾问的需求和角色，以及在蓝图的每个步骤中使用 AI 工具：

1. 愿景:

   • 需求: 为 转型建立清晰而战略性的方向。

   • 顾问角色: 专家顾问帮助定义组织转型的愿景，确保其与整体战略目标对齐。 他们与领导者合作，确定转型赞助商并对齐关键合作伙伴组织，利用其经验预见和减轻 潜在挑战。

   • AI 的角色: AI 能分析来自各种来源的数据，识别可能并不明显的趋势、机会和威胁。 这些分析可以指导转型的战略方向。

   • 顾问的指导: 顾问们 可以解读 AI 生成的见解，将其与组织的战略目标对齐，确保转型愿景既雄心勃勃 又可实现。

2. 对齐:

   • 需求: 确保 所有利益相关者朝着 共同目标努力。

   • 顾问角色: 顾问通过促成领导者和关键团队成员之间的对齐会议，利用其专业知识弥合不同愿景和目标之间的差距。 他们帮助定义可实现的具体目标，确保每个人都致力于 相同的结果。

   • AI 的角色: AI 驱动的工具可以通过提供协作、设定目标和追踪的平台，促进利益相关者之间的对齐。 自然语言处理 (NLP)可以 分析沟通模式，以识别利益相关者之间的错位或混淆区域 。

   • 顾问的指导: 顾问可以利用这些洞察来调解讨论，澄清目标，并确保各方朝着 共同的目标前进。

3. 评估:

   • 需求: 了解 当前状态并识别出改进的领域。

   • 顾问角色: 通过评估，顾问诊断组织当前流程和技术的成熟度。 他们深入分析特定主题，并创建价值流图，提供对现状的详细理解，并识别出转型的关键领域 。

   • AI 的角色: AI 可以通过分析代码库、基础设施配置和工作流模式来自动评估当前系统和流程，从而识别瓶颈 或低效之处。

   • 顾问的指导: 顾问随后可以解读这些发现，优先考虑改进的领域，并调整转型策略，以首先解决 最关键 的差距。

4. 解决方案:

   • 需求: 设计一份 与组织目标对齐的未来状态路线图。

   • 顾问角色: 专家顾问分析评估数据，制定全面的未来状态路线图，涵盖主题、史诗和用户故事。 他们确保利益相关者对齐，并根据组织的独特需求完善计划，凭借经验提出 有效的解决方案。

   • AI 的角色：使用 AI，咨询顾问可以模拟不同的转型场景，以预测结果、识别潜在风险并优化转型路线图。

   • 咨询顾问的指导：这使得咨询顾问能够提出数据驱动的未来状态路线图，确保解决方案既具有创新性，又与组织的目标保持一致。

5. 实现：

   • 需求：有效地实施转型，并确保其与战略目标保持一致。

   • 咨询顾问的角色：咨询顾问监督实施项目的定义，进行 POC 试验，并验证解决方案选择。他们确保解决方案得到有效部署、进行培训并建立治理实践，运用专业知识预测并解决挑战。

   • AI 的角色：AI 工具可以通过自动化日常任务、优化资源分配以及预测变更的影响，简化转型项目的实施。

   • 咨询顾问的指导：咨询顾问可以利用 AI 确保解决方案的部署高效、有效且得到密切监控，主动解决任何问题。

6. 操作化：

   • 需求：确保改进是可持续的，并对其进行监控以实现持续优化。

   • 咨询顾问的角色：通过实施 SRE 实践，咨询顾问帮助监控关键绩效指标（SLIs、SLOs 和 SLAs），确保所部署的改进能够交付预期的价值。他们促进回顾总结，从中提取经验教训，并将其优先考虑，以便进行持续改进。

   • AI 的角色：AI 可以通过建议可观测性和高级监控能力、预测系统行为的分析以及自动化的事件响应来增强 SRE 实践。

   • 咨询顾问的指导：咨询顾问可以利用 AI 的洞察力来微调绩效指标，确保改进是可持续的，并且组织在不断优化其运营。

7. 扩展：

   • 需求：在组织中扩大转型规模，以最大化其影响力。

   • 顾问角色：专家顾问通过帮助组织将成功的实践扩展到其他应用或团队，指导组织完成这一过程。 他们帮助规划和执行进一步的转型周期，确保每个周期都能实现更高的成熟度 和效率。

   • AI 的作用：通过分析不同应用程序和团队的绩效数据，AI 可以帮助识别哪些实践最有效并且准备好进行扩展。 和团队。

   • 顾问的指导：顾问可以通过使用 AI 来指导成功实践的战略扩展，确保决策是基于数据驱动的，并且 组织为更广泛的转型做好准备。 广泛转型。

专家顾问在转型蓝图的每个步骤中都发挥着关键作用，提供必要的指导、专业知识和支持，以确保转型具有战略性、对齐性、有效实施并且可持续。 他们的参与帮助组织应对转型中的复杂性，避免常见的陷阱，并更高效 且有效地实现预期结果。

转型顾问可以使用 AI 工具加速创建来自每个转型步骤的精心定制的分析和文档。 转型过程。

在每一步中，AI 工具与专家顾问的结合创造了强大的协同效应。 AI 提供了基于数据的洞察和自动化能力，能够简化和提升决策过程，而顾问则带来战略监督、行业知识和必要的人类判断力，以解读 AI 的输出并有效引导转型过程。 这种协作方法确保转型不仅与组织目标对齐，而且还利用最新的技术进展来实现 卓越的成果。

能力成熟度模型引导转型

CMM 是一个框架 帮助组织评估其业务流程的有效性和成熟度。 组织转型需要成熟度模型，因为它提供了一个结构化的路径来指导改进。 CMM 帮助识别当前的流程成熟度水平，并指导组织通过更高的纪律性和质量水平。 这种结构化的方法确保变革是可持续的，流程是高效的，组织能够更好地实现目标并适应 新的挑战。

能力成熟度模型集成 (CMMI) 来源于原始的 CMM，该模型最初于 1980 年代末由 软件工程研究所 (SEI) 在卡内基梅隆大学开发。 CMM 最初专注于 软件开发过程。 随着时间的推移，对于更为集成的方案需求变得显而易见，最终促成了 2000 年代初期 CMMI 的发展。 CMMI 扩展了其范围，不仅包括软件领域，还涵盖了产品生命周期管理和服务交付等其他领域，提供了一个更为详细和灵活的框架。 这种更广泛的适用性和集成方法使 CMMI 区别于 原始的 CMM。

图 4**.3 展示了 CMMI 的五个成熟度等级。

图 4.3 – CMMI 成熟度等级

这些 等级如下：

• 第 1 级：初始 – 过程不可预测且反应性强，常常导致项目延期并超出预算。

• 第 2 级：管理 – 过程在项目级别上得到管理，项目被规划、执行、测量 并控制。

• 第 3 级：定义 – 组织采取主动方式运作，使用全组织范围的标准，为各项目、程序 和投资组合提供指导。

• 第 4 级：量化管理 – 组织以数据为驱动，拥有可预测的量化绩效改进目标，并与内部及 外部利益相关者的需求保持一致。

• 第 5 级：优化 – 组织稳定且灵活，专注于持续改进，能够应对变化和抓住机会。 它为敏捷性 和创新提供了平台。

修改后的 CMM 是软件交付能力所必需的，因为 CMMI 主要是为更可预测和稳定的环境设计的，而这些环境并不能完全应对现代软件开发的动态和迭代特性。 如今的软件交付需要快速 适应， 持续集成 (CI)和交付，以及快速响应市场需求变化的能力。 一个修改过的模型融入了这些方面，强调敏捷性、自动化、DevOps 持续交付实践和持续学习，涵盖了人员、流程和技术维度，这对于当前的软件交付格局至关重要。

图 4**.4 概述了一个软件 交付 CMM，其中包含 五个级别：

• 一级：手动与未测量（混乱） – 特征是混乱、沟通不畅、手动流程、工具不一致和缺乏 度量：

  • 人员: 团队成员之间沟通不畅。 指责文化。

  • 过程: 集成和交付过程的编排 是手动的。

  • 技术: 不同团队使用不同的工具。 没有 集成的工具链。

  • 度量: 很少，甚至没有，度量是自动化的。 发布不可预测且 容易出错。

• 二级：持续集成（CI） – 具有良好工程化的集成实践、团队内部的协作文化、编排的 CI 流程、一致的工具链和自动化的 CI 度量：

  • 人员: 开发和 QA 团队之间的集成实践已良好工程化。 CI 培训已到位。 团队内部有协作文化。

  • 过程: CI 流程已经编排和自动化。 代码在 CI 过程中被合并并测试到公共主干分支。

  • 技术: 为 CI 版本管理、构建和测试提供一致的工具链。 发布候选项托管在一个 构件仓库中。

  • 度量: CI 度量是自动化的，并用于管理 CI 活动。 开发人员每天提交 代码。

• 第 3 级：持续交付（CD1） – 涉及跨团队的协作交付实践、自动化交付流程和指标，以及包含自动化 测试工具的统一工具链：

  • 人员：已为开发、QA 和发布团队建立交付实践。 团队之间的协作文化 。

  • 流程：交付流程被协调并自动化。 回归测试、系统性能和用户验收 是自动化的。

  • 技术：已建立一致的工具链用于 CD，包括自动化工具 用于测试。

  • 指标：交付指标被自动化，并用于管理交付和发布 验收活动。

• 第 4 级：持续部署（CD2） – 涉及跨所有团队的部署实践，完全 自动化部署流程，并通过指标管理和推动 持续改进：

  • 人员：已为开发、QA、发布和运维团队建立了部署实践。 团队之间的协作文化 。

  • 流程：生产流程的部署由自动化协调 和自动化。

  • 技术：已建立一致的工具链用于部署，包括自动化工具来进行基础设施编排、生产环境监控及自动回滚 （必要时）。

  • 指标：部署指标被自动化，并用于管理生产环境中的部署并推动 持续改进。

• 第 5 级：持续运营（CO） – 团队在无责文化下协作工作，生产运营流程统一，且已建立统一的工具链用于完整生命周期管理，受 SLA、SLO、SLI 和 错误预算的管理：

  • 人员：开发、QA、发布和运维团队在无责文化中协作工作，确保产品质量和可靠性满足 利益相关者的要求。

  • 流程：生产运营流程在运营 和开发之间统一。

  • 技术：已建立统一的工具链，用于测试和监控应用程序、基础设施和 发布部署。

  • 指标：SLOs、SLIs、错误 预算和错误预算政策管理开发、交付、部署、和运营。

图 4.4 – 软件交付 CMM

没有标准的软件交付 CMM，但建议每个组织确定适合衡量该组织成熟度的模型。 该组织。

本章的以下部分提供了针对持续测试、质量、安全性和反馈的成熟度模型示例。 虽然没有标准模型，本章中呈现的模型与 第一章 中提供的定义以及 图 4**.4中说明的模型结构一致。

能力成熟度级别 – 持续测试

持续测试 CMM 在 图 4**.5 中概述了持续测试实践的五个成熟度级别：

• 级别 1：手动与未测量（混乱） – 临时和手动的测试过程。 基础测试工具的使用有限。 几乎没有任何结构化的测试指标或 KPI：

  • 人员：团队成员之间沟通不畅。 指责文化。

  • 流程：集成和交付过程的编排是手动的。

  • 技术：不同团队使用的工具各不相同。 没有 集成的工具链。

  • 指标：很少，甚至没有自动化的指标。 发布不可预测且 容易出错。

• 级别 2：持续集成（CI） – 初步自动化一些测试用例。 在 CI 流水线中集成测试。 测试覆盖率和有效性的基本指标：

  • 人员：开发人员与 QA 测试人员之间的初步合作开始。

  • 流程：测试流程已定义并自动化 用于 CI。

  • 技术：引入自动化测试工具用于 CI 测试用例。

  • 指标：基本的测试覆盖率和缺陷指标至少在 CI 过程中被跟踪。

• 级别 3：持续交付（CD1） – 测试完全集成到 CI/CD 流水线中。 增强的测试自动化能力。 定期使用指标进行测试 流程优化：

  • 人员：为持续测试实践建立了明确的角色。

  • 流程：根据需要，测试完全融入到开发生命周期中，以测试一个 发布候选版本。

  • 技术：使用一套一致的工具进行 测试自动化。

  • 指标：定期使用指标来改进测试流程和覆盖范围，以 发布候选版本。

• 级别 4：持续部署（CD2） – 高级、自动化且简化的测试流程。 高级的测试自动化和编排工具。 用于持续 测试改进的详细分析：

  • 人员：所有团队成员在测试中的高度协作。

  • 流程：标准化的先进自动化测试流程，包括用于部署的自动化测试 到生产环境。

  • 技术：已部署复杂的测试自动化和编排工具。

  • 指标：用于持续改进的详细指标和关键绩效指标（KPI）用于 部署验证。

• 级别 5：持续运营（CO） – 组织范围内聚焦质量和测试。 利用人工智能（AI）和机器学习（ML）进行自适应测试策略。 通过预测分析提高测试效率 和有效性：

  • 人员：全组织承诺于质量和 持续测试。

  • 流程：通过 AI 和 机器学习实现的自适应测试流程。

  • 技术：完全自动化、自学习的 测试系统。

  • 指标：使用预测分析 进行持续优化 测试。

该模型帮助组织评估并改进其持续测试实践，使其与软件交付和运营卓越的更广泛目标对齐。 每个级别提供了测试过程、技术和指标方面的具体关注领域，指导组织朝着持续 测试成熟度的方向发展。

图 4.5 – 持续测试 CMM

该模型对于组织评估并改进其持续测试实践非常有用。 它为每个级别定义了明确的标准，使组织能够识别在过程成熟度和技术集成方面所处的位置。 通过根据这些标准进行评估，组织可以 pinpoint（识别）具体的改进领域，并制定战略，朝着更高级别的测试成熟度进步，这对于实现更高效率、更高质量和更快的 软件交付至关重要。

能力成熟度等级 – 持续质量

该模型 在 图 4**.6 中展示了一个持续质量 CMM，包含 五个级别：

• 第 1 级：手动与未测量（混乱） – 这一层级的特点是关于质量的沟通有限，手动质量检查，分散的非集成工具，以及最小的质量 指标跟踪：

  • 人员: 关于质量的沟通有限。 反应式方法。

  • 过程: 手动质量检查。 没有集成到开发 生命周期中。

  • 技术: 分散的、非集成的 质量工具。

  • 指标: 很少，甚至没有质量指标。 最少的跟踪。

• 第 2 级：持续集成（CI） – 开发和 QA 团队在质量方面有一些协作，CI 期间进行自动化质量检查，基本的自动化测试工具与 CI 集成，并跟踪基本的质量指标 在 CI 过程中：

  • 人员: 开发和 QA 团队在质量方面有一定的协作 。

  • 过程: 自动化质量检查与 CI 集成 。

  • 技术: 基本的自动化测试工具与 CI 集成 。

  • 指标: 在 CI 过程中跟踪基本的质量指标 。

• 第 3 级：持续交付（CD1） – 增强团队协作以确保质量，将质量检查完全整合到 CD 流程中，先进的自动化测试和质量工具用于 CD，以及全面的质量度量指标，用于指导 CD 决策：

  • 人员：增强所有团队之间的协作，以确保 质量保障。

  • 过程：质量检查完全整合到 CD 流程中。

  • 技术：用于 CD 的先进自动化测试和质量工具。

  • 度量：跟踪全面的质量度量指标，指导 CD 决策。

• 第 4 级：持续部署（CD2） – 强调部署实践中的质量，自动化和简化的部署质量流程，确保部署质量的先进工具，以及详细的部署质量度量和 反馈循环：

  • 人员：强烈关注 部署实践中的质量。

  • 过程：自动化和简化的部署质量流程。

  • 技术：确保部署质量的先进工具。

  • 度量：详细的部署质量度量和 反馈循环。

• 第 5 级：持续运营（CO） – 全组织承诺于运维中的质量，开发与运维之间统一的质量流程，集成的监控和质量维护工具，以及先进的度量指标，包括 SLA、SLO、SLI 和错误预算，用于 管理质量：

  • 人员：全组织承诺于运维中的质量 。

  • 过程：开发与运维之间统一的质量流程。

  • 技术：集成的工具用于监控和 维护质量。

  • 度量：先进的度量指标，包括 SLO 和 SLI，用于 管理质量。

此模型对于描述组织的持续质量实践的成熟度级别非常有用，能够与软件交付和运营卓越的更广泛目标对齐。 每个级别定义了推进质量过程、技术和度量的特定关注领域，为组织在持续质量改进之路上提供指导。 通过根据模型的标准评估当前状态，组织可以识别需要开发或增强的特定实践，以达到下一个 成熟度级别。

图 4.6 – 持续质量 CMM

虽然没有标准的持续质量 CMM，但每个组织应该定义一个适合本组织的模型。 在 图 4**.6 中提供的模型可以作为创建特定于 该组织的模型的基础。

能力成熟度级别 – 持续安全性

图 4**.7 展示了一个具有五个级别的持续安全性 CMM，每个级别都涉及人员、过程、技术 和度量方面：

• 等级 1: 手动与未衡量（混乱） – 突出显示了有限的安全意识和协作，临时的过程，基本工具，以及 最小的度量：

  • 人员: 有限的质量沟通。 反应性方法。

  • 过程: 手动质量检查。 没有集成到开发 生命周期。

  • 技术: 不同、非集成的 质量工具。

  • 度量: 很少，甚至没有质量度量。 最小跟踪。

• 等级 2: 持续集成 (CI) – 安全性的某些协作，CI 过程中初步集成的安全检查，基本自动化工具，以及用于 漏洞识别的基本度量：

  • 人员: 开发和质量保证团队之间在质量方面的某些协作。 。

  • 过程: 自动化质量检查集成 到 CI 中。

  • 技术: 基本的自动化测试工具已集成 到 CI 中。

  • 度量: 在 CI 过程中跟踪的基本质量度量。

• Level 3: 持续交付 (CD1) – 加强团队协作，全面整合安全检查到 CD 流程中，先进的评估工具，以及全面的 安全指标：

  • 人员: 跨团队增强协作，确保 质量保障。

  • 流程: 完全整合到 CD 流程中的质量检查。

  • 技术: 用于 CD 的先进自动化测试和质量工具。

  • 指标: 跟踪全面的质量指标，引导 CD 决策。

• Level 4: 持续部署 (CD2) – 强调部署中的安全，自动化安全流程，实时监控工具，以及用于 快速响应的详细指标：

  • 人员: 强调部署实践中的质量。

  • 流程: 自动化和简化的质量流程 用于部署。

  • 技术: 确保部署质量的复杂工具。

  • 指标: 部署的详细质量指标和 反馈循环。

• Level 5: 持续运营 (CO) – 全组织承诺于安全，统一的流程，持续监控工具，以及先进的指标，如解决 安全事件的时间：

  • 人员: 全组织承诺于运营中的质量 保证。

  • 流程: 开发与运维之间的统一质量流程。

  • 技术: 集成的工具用于监控和 维持质量。

  • 指标: 先进的 指标，包括 SLO 和 SLI，用于 管理质量。

持续安全 CMM 帮助组织评估和发展其持续安全实践，确保安全在整个软件交付生命周期中无缝集成。 每个级别定义了推进安全流程、技术和指标的具体关注领域，指导组织朝着更具前瞻性和响应性的安全态势发展。 组织可以通过评估其实践与每个阶段的标准进行对比，从而确定当前的成熟度级别，识别改进领域并制定推进到更高成熟度级别的策略。

图 4.7 – 连续安全 CMM

虽然没有标准的连续安全 CMM，每个组织应定义一个适合自身的模型。 如 图 4**.7 所示的模型可以作为创建适用于 该组织的模型的基础。

能力成熟度级别 – 持续反馈

模型如 图 4**.8 展示了一个连续反馈 CMM，跨越五个级别：

• 第 1 级：手动与未测量 – 特点是有限的沟通、临时反馈收集、基本工具和 最小化的度量：

  • 人员: 有限的沟通和对反馈价值的理解。

  • 过程: 临时反馈收集，未有 正式流程。

  • 技术: 基本工具（如果有的话）用于 反馈收集。

  • 度量: 很少，甚至没有，用于衡量反馈实施 或影响的度量。

• 第 2 级：持续集成 – 在开发阶段内集成反馈，在持续集成过程中加以考虑，使用初步工具进行收集，并为频率 和影响设置基本度量：

  • 人员: 反馈已集成到开发和 集成阶段。

  • 过程: 在持续集成（CI）中考虑反馈。

  • 技术: 用于反馈收集的初步工具，已集成 到持续集成中。

  • 度量: 用于反馈频率和初步影响的基本度量作为持续集成的一部分，帮助决策过程。

• 第 3 级：持续交付 – 增强的协作、系统化的反馈集成、用于分析的高级工具和综合度量，用于评估实施 速度 和影响：

  • 人员: 增强的协作以集成 反馈。

  • 过程: 反馈系统化集成到 持续交付流程中。

  • 技术: 用于收集和 分析反馈的高级工具。

  • 度量指标：用于评估反馈实施速度和影响的全面度量指标，用于决定 交付决策。

• 第 4 级：持续部署 – 在部署中强烈关注反馈，简化整合，实时工具和详细的部署改进度量指标：

  • 人员：在部署策略中强烈关注反馈。

  • 过程：简化的反馈整合，以便快速 进行部署调整。

  • 技术：用于部署阶段的实时反馈工具。

  • 度量指标：用于反馈驱动的 部署改进的详细度量指标。

• 第 5 级：持续运营 – 全组织的承诺，统一的反馈流程，集成的持续工具和先进的度量指标，包括系统 可靠性改进：

  • 人员：全组织致力于 利用反馈。

  • 过程：跨开发和运营的统一反馈流程。

  • 技术：集成工具用于持续的反馈收集 和分析。

  • 度量指标：先进的 度量指标，包括因反馈导致的系统可靠性改进。

该模型有助于描述组织持续反馈实践的成熟度级别，并将其与提升用户满意度和降低生产故障率的更广泛目标对齐。 每个级别定义了推进反馈流程、技术和度量指标的具体领域，指导组织实现更有效和高效的反馈整合。 通过评估该模型，组织可以识别其在反馈成熟度方面的位置，并规划 战略性进步。

图 4.8 – 持续反馈 CMM

虽然没有标准的持续反馈 CMM，但每个组织应定义一个适合自身的模型。 提供的模型可以作为创建适用于 图 4**.8 的基础。 该模型可以作为创建适合组织的模型的基础。

总结

本章提供了一种系统和有纪律的工程方法，用于规划和实施持续测试、质量、安全和反馈。 本章强调了在数字转型中工程方法的必要性，将技术与流程和文化变革相结合。 其中包括七步转型工程蓝图，解释其在持续实践中的应用。 持续实践。

AI 工具与转型顾问的专业知识相结合，在转型过程的每个步骤中提供动态协同效应。 AI 为简化决策提供数据驱动的洞察力和自动化，而顾问则应用战略监督、行业知识和对 AI 数据的关键解读，有效指导转型。 这种协作方法确保组织转型不仅目标对齐，还利用尖端技术来增强成果。 增强成果。

本章还详细介绍了持续测试、质量、安全和反馈的 CMMs，展示了这些模型如何指导转型。 本内容对理解如何将实践提升到更高能力成熟度水平至关重要，确保在现代数字领域中实现平衡、系统化和增量化的转型方法。 数字领域。

在下一章中，我们将探讨转型目标设定的策略，以及如何使组织对目标达成一致。 目标。

第五章：确定转型目标

本章解释了一种规定性的方法，用于确定适合特定组织、产品和服务的持续测试、质量、安全性和反馈转型的目标。 帮助确定目标的工具已在本章中描述。 本章建立在上一章中描述的数字转型工程方法的基础上。 它还提供了如何为转型确定模型应用的指导。

在本章结束时，你将理解转型目标对齐的重要性，如何为转型确定模型应用，以及如何为持续测试、质量、安全性 和反馈设定目标。

本章分为以下 几个部分：

• 转型 目标分类

• 转型目标对齐的重要性 目标对齐的重要性

• 确定转型的具体目标

• 确定 模型应用

• 确定 持续测试的目标

• 确定 持续质量的目标

• 确定 持续安全的目标

• 确定 持续反馈的目标

让我们 开始吧！

注意

本章中讨论的计分卡示例可以通过 GitHub 上的 Excel 文件访问，该文件为 本书提供。

转型目标分类

为了使数字化转型成功，必须以一种支持清晰方向、可衡量结果，并与组织的整体战略愿景和目标对齐的方式来设定目标。 数字化转型的目标可以分为以下 七大类：

• 战略目标：每个 转型都需要一个或多个总体战略目标，旨在将数字转型工作与组织的宏观愿景和目标对齐，以确保竞争优势和市场领导地位。 所有其他目标必须支持 战略目标。

  示例：在接下来的 18 个月内，将数字销售渠道的收入提高 30%，以确保在 我们行业中占据前三的市场地位。

• 敏捷性目标：旨在通过采用敏捷方法和灵活的 技术解决方案，提高组织对市场变化和客户需求的响应能力。

  示例：通过在 12 个月内在所有团队中实施敏捷开发实践，将产品开发周期时间缩短 40%。

• 效率目标：旨在通过数字解决方案改进运营流程和资源利用，以 降低成本并提高 生产力。

  示例：在接下来的六个月内，自动化 50%的人工数据录入过程，以实现 20%的 运营成本降低。

• 稳定性目标：确保 组织的数字基础设施健壮可靠，支持持续运营并 最大限度地减少停机时间。

  示例：通过基础设施的增强和全面的 灾难 恢复计划的实施，在下一个财年内实现所有关键数字服务的 99.9%正常运行时间。

• 质量目标：专注于通过战略性地使用 数字技术提升客户 互动、服务和产品的质量。

  示例：通过部署一个个性化的客户服务平台，利用人工智能提升 客户互动，在一年内将客户满意度提升 25%。

• 安全目标：专注于加强网络安全 措施，并确保遵守相关法规以保护组织和 客户数据。

  示例：在接下来的六个月内消除组织数字基础设施中所有已识别的漏洞，并实现对行业 安全标准的全面合规。

• 团队满意度目标：优先提升 团队参与度、满意度和数字素养，通过有针对性的培训计划并培养支持性的 数字文化。

  示例：在接下来的九个月内，通过实施全面的数字素养计划并建立基于反馈的持续改进文化，将员工参与度提高 20%。

这些目标必须符合 SMART 标准，即具体、可衡量、可实现、相关且具有时间限制，为数字化转型工作提供明确方向。 专注于这七个领域可以确保组织采取全面的转型方法，既涵盖技术因素也考虑人力因素，从而推动数字时代的成功。 这不仅支持更有结构和更有焦点的转型努力，还帮助将举措与组织的更广泛 战略目标对齐。

图 5**.1 展示了 对于数字化转型最有用的目标分类。 每个圆圈代表一个不同的目标类别。

图 5.1 – 数字化转型目标分类

这些类别涵盖了组织在数字化转型过程中通常关注的广泛领域，突显了实现全面数字变革所需的多方位方法。

转型目标一致性的重要性

获得 组织与技术层面的目标对齐，涵盖数字化转型的七个目标分类，对于以下原因至关重要：

• 方向一致性：对齐确保所有努力共同推动组织的更广泛愿景和使命。 如果没有对齐，努力可能适得其反或无方向，导致资源的分配散漫且低效。

• 协同效应与效率：当 各团队之间的目标对齐时，不同的举措可以相互支持和增强，产生协同效应，从而提高整体效率。 目标不对齐可能导致重复努力或相互矛盾的举措。

• 风险缓解：组织内部目标的一致性有助于全面识别和管理风险。 如果目标不一致，可能会忽视风险或管理不当，最终导致失败 或违规。

• 资源优化利用：对齐确保组织的资源能够最优地用于共同的目标。 目标不对齐可能导致时间、金钱和 人力资本的浪费。

• 变革管理：目标一致有助于更顺利的变革管理，因为利益相关者了解转型努力的方向和目的。 目标不一致可能导致员工和 其他利益相关者的困惑与抵触。

• 衡量与适应：目标一致有助于制定一致的指标和关键绩效指标（KPI），使得追踪进展和进行有效调整变得更加容易。 目标不一致会使得衡量成功并有效调整 战略变得困难。

• 统一文化：共同的目标集有助于培养支持数字化转型的统一组织文化。 目标不一致可能导致文化碎片化，造成对 转型努力的接受和支持程度不一。

图 5**.2 展示了将转型目标与 战略目标对齐的概念。

图 5.2 – 转型目标对齐

在我的 咨询工作中，我看到许多组织在没有澄清目标，或者至少没有澄清一些关键目标的情况下，直接进入实施阶段。

每个分类中目标不一致的负面后果

如果我们未能对齐目标，正如 在 图 5**.2中所示，可能会导致以下不利后果：

• 战略目标：如果战略目标未能与其他转型目标对齐，可能会导致 IT 资源的错误分配，从而出现无法支持增加市场份额或收入的战略目标的项目，最终影响 竞争地位。

• 敏捷性目标：如果目标未对齐，组织可能无法快速响应市场变化，导致错失机会，无法满足客户期望，从而降低 市场相关性。

• 效率目标：目标不一致可能导致投资于与现有流程不兼容的技术，从而降低运营效率，未能实现预期的 成本节约。

• 稳定性目标：如果稳定性目标未对齐，可能会面临系统故障和停机的风险，从而导致重大运营中断和 客户信任的丧失。

• 质量目标：缺乏一致性可能导致由于技术使用不当或不足，造成糟糕的客户体验，从而导致客户满意度 和忠诚度降低。

• 安全目标：安全目标与技术基础设施之间的脱节可能导致漏洞和数据泄露，进而造成重大法律、财务及 声誉损害。

• 团队满意度目标：如果没有一致性，团队可能无法获得增强数字素养和参与感所需的支持或资源，这可能导致士气低落、高员工流失率，并且劳动力对于数字未来准备不足。

总之，各类转型目标的一致性确保组织朝着协调一致的方向前进，充分利用资源，管理风险，建立支持在数字时代持续成功的文化。 不一致性可能导致低效、风险增加、资源浪费以及无法实现预期的 转型成果。

确定转型的具体目标

每个类别中都有许多 目标。 如果一个组织的目标过多，可能会导致团队之间的混乱。 选择一套简明的最高优先级转型目标对于组织转型至关重要。 确定最佳目标集需要战略性和有条理的方法。 以下是有效引导此 过程的指南。

图 5**.3 展示了一个顺序过程，涉及四个阶段，旨在为组织转型设定和优先排序目标。

图 5.3 – 转型目标设定过程

四个阶段如下： ：

1. 转型目标评分卡：评分卡方法用于评估和分类转型目标。 评分卡的内容和结构需要根据转型的战略目标，与目标类别和目标进行相应安排。 转型目标评分卡应该围绕组织的战略目标量身定制。 转型目标评分卡应根据组织的战略目标进行定制。 如图5**.4所示，DevOps 转型目标评分卡是我用作 DevOps 转型基准的评分卡示例，适合用作持续测试、质量、安全和反馈等领域的评分卡基准。

   在评分卡中，每个目标分类下都描述了示例目标：敏捷性、安全性、满意度、质量、效率和稳定性。 在准备步骤 2时，需要选择并告知转型团队有关工作坊的过程。

2. 转型目标工作坊：第二阶段是协作方法，涉及利益相关者在一个或多个工作坊中参与，理解并为评分卡中的目标提供评分建议。 该工作坊应包括领导层以及来自架构开发、质量保证、运营、工具、基础设施、安全职能、发布管理、项目管理、DevOps 和 SRE 职能的相关利益相关者。 此时，应为目标设定一个时间框架。 一种好的做法是设置六个月的时间框架。 这个时间足够展示显著的进展，但又不会过长，导致设定目标的团队已经转向其他角色。

3. 确定评分：在工作坊结束时，下一步是根据评分卡中确立的标准和在工作坊期间获得的见解，对目标进行量化或打分。

4. 选择最高优先级的目标：流程的最后一步是根据前一步确定的排名分数，选择最关键的目标，集中精力在转型的最高优先级上。 选择排名前三的目标来专注于转型的任何阶段。 如果选择太多，团队将会迷茫，资源会分散，且转型的主要目标失败的风险将增加。 选择排名前三的目标。

这一四步目标设定过程是一个循环过程，上一阶段的结果可能会反过来影响未来迭代中的计分卡。 整体流程从概念化和分类，到协作、评估，最后到优先级排序。

通过以下步骤，组织可以选择一组简洁的高优先级、具体的转型目标，这些目标与其战略愿景、市场定位、利益相关者需求和运营能力相一致，为成功的 数字化转型 奠定基础。

图 5**.4 是我为 DevOps 使用的计分卡示例。 该计分卡旨在为优先事项生成排名数字。 每个目标的单位值必须选择以匹配 组织的状态。

图 5.4 – DevOps 转型目标计分卡

在研讨会期间，团队成员将从 1 到 5 选择一个“重要性评分”值（I），以表示每个目标对实现战略转型目标的重要性。 然后，团队确定当前状态和期望的未来状态。 计算当前状态与期望未来状态之间的期望改进百分比（%），作为值 P。 然后，通过计算 I x P，得出每个目标的总体评分。 最后，将得分从 1 排名至 n ，以确定最高优先级的目标。

使用 AI 聊天机器人帮助确定转型目标

AI 聊天机器人 可以通过多种创新方式，在推动数字转型目标设定方面发挥重要作用。 它们的能力可以被用来收集洞察、自动化任务和增强决策过程。 以下是 AI 聊天机器人 的一些帮助方式：

• 数据收集 与分析：

  • 调查与反馈：AI 聊天机器人可以进行调查并收集内部利益相关者和客户关于痛点、需求和数字转型期望的反馈。 这些数据对于设定相关且 有影响力的目标至关重要。

  • 市场洞察：聊天机器人可以用来收集和分析市场趋势以及竞争对手信息，帮助组织设定目标，确保它们保持竞争力 并且与时俱进。

• 增强 利益相关者参与度：

  • 利益相关者沟通：它们可以通过提供更新、收集反馈并回答关于数字化转型过程的疑问，促进与利益相关者的持续沟通。 这保持了利益相关者的参与，并使他们的期望与 转型目标保持一致。

• 促进协作：

  • 跨职能协作：通过与协作工具的整合，AI 聊天机器人可以 促进跨不同部门和团队的无缝 沟通，确保每个人都保持一致，朝着相同的数字化转型 目标共同努力。

• 支持决策：

  • 数据驱动的洞察：通过访问大量数据，AI 聊天机器人可以提供基于数据分析的实时洞察和建议。 这有助于决策者设定以数据为依据的目标，从而提高成功的机会。

  • 目标优先级：聊天机器人可以通过分析每个目标的潜在影响和可行性，使用如投资回报率（ROI）、客户影响和与 战略目标的对齐等标准，帮助确定数字化转型目标的优先级。

• 跟踪进展 与反馈：

  • 进度监控：它们可以追踪各项计划与设定目标的进展，并向相关利益相关者提供定期更新，确保任何偏差都能 及时得到解决。

  • 持续反馈循环：聊天机器人可以创建一个持续的反馈循环，收集关于什么有效、什么无效的见解。 这使得目标可以根据实际表现和反馈动态调整。

• 培训 与支持：

  • 数字素养：AI 聊天机器人可以为员工提供个性化的学习体验和支持，提升他们的数字技能和素养。 这支持了一个更能适应变化的文化，对于成功的 数字化转型至关重要。

  • 变更管理：通过互动指南和常见问题解答，聊天机器人可以解决关于数字化转型的疑虑和问题，帮助管理变更抗拒，培养对新技术 和流程的积极态度。

• 创新 与实验：

  • 创意生成：通过分析趋势和数据，聊天机器人可以为数字产品、服务或流程提出创新的想法，鼓励实验 和创新文化。

总之，AI 聊天机器人 可以显著简化 设置和实现数字化转型目标的过程，通过自动化和增强与数据收集、利益相关者互动、决策制定和进度跟踪相关的任务。 通过利用 AI 聊天机器人的能力，组织可以确保其数字化转型目标是信息充分的、战略对齐的，并且能够适应 变化。

确定每次转型多少个应用程序

一个组织是否应该逐个应用程序地进行数字化转型，还是同时处理多个应用程序，取决于多个因素，包括组织的规模、复杂性、资源可用性、战略目标和风险容忍度。 这两种方法各有优缺点，最佳策略通常是采取平衡且量身定制的方法。 以下是一些要考虑的细分点 。

一次处理一个应用程序

以下是 这种方法的 优点：

• 聚焦资源：集中处理一个应用程序可以更专注地分配资源，包括预算、人员和 管理注意力。

• 风险管理：由于范围仅限于一个应用程序，风险管理变得更加容易，从而简化了问题的监控和解决。 它们出现时，可以更迅速地处理。

• 学习与适应：从每次转型中获得的经验可以应用于后续的项目，随着时间的推移，可能提高效率和效果 。

• 更容易的变更管理：较小的范围使得管理用户和利益相关者之间的变更变得更加容易，有助于更顺利地采用，且 扰动更小。

以下是 其缺点：

• 整体转型较慢：这种方法可能会延长完成整个组织数字化转型所需的总时间。

• 回报延迟：数字化转型的收益可能需要更长的时间才能在整个组织中显现，因为改进是按顺序实施的。

同时进行多个应用

以下是这种方法的优点：

• 加速转型：使组织能够更快地实现转型目标，从而可能更快速地达成战略目标。

• 同时创新：允许组织同时创新和转型业务的各个方面，可能会释放不同应用之间的协同效应。

• 竞争优势：快速转型可以为快速变化的市场提供竞争优势，使组织能够更快适应市场变化和客户需求。

以下是缺点：

• 资源压力：可能会对资源（包括人员、预算和管理带宽）造成显著需求，进而可能导致员工倦怠和执行不佳。

• 增加的复杂性和风险：同时管理多个转型可能会显著增加复杂性和风险，包括失败或业务运营中断的风险。

• 变革管理挑战：更广泛的范围和更快的变革速度可能会让利益相关者更难以适应，可能导致抗拒或较低的采纳率。

定制化方法

实际上，最佳方法通常涉及一种定制化的策略，考虑到组织的特定背景和能力。平衡方法的一些考虑因素包括以下内容：

• 战略优先级排序：从最关键的应用开始，优先考虑那些对实现战略目标至关重要或回报率最高的应用。

• 能力评估：评估组织管理多个项目的能力，包括技术人员的可用性和财务资源。

• 风险承受度：考虑组织对风险和潜在操作中断的容忍度。

• 增量扩展：从单一应用开始，积累经验和能力，然后随着信心和 能力的提升逐步扩大转型范围。

根据所提供的背景，定制化数字转型方法提供了若干显著优势，能够极大地帮助寻求现代化运营和提升竞争力的组织。 以下是一些 关键优势：

• 战略优先级划分：定制化方法的主要优势之一在于它强调战略优先级划分。 通过关注对实现战略目标最为关键的应用 或那些提供最高 投资回报率 (ROI)，组织可以确保其资源得到高效分配。 这种优先级划分有助于将转型努力与整体商业目标对齐，进而提高这些举措直接促进 组织成功的可能性。

• 能力评估：另一个优势是定制化方法所倡导的深入能力评估。 这一评估通过考虑熟练人才和财务资源的可用性来评估组织管理多个项目的能力。 通过了解自身能力，组织可以将其转型战略量身定制，以匹配实际能力，从而降低过度扩展的风险，并确保转型努力在 长期内可持续。

• 风险承受度：这一点至关重要，因为数字转型可能涉及重大变化，可能会扰乱现有的流程。 由于定制化方法还考虑了组织对风险的容忍度和潜在操作中断，并将组织的风险承受度融入转型战略，方法帮助有效管理和减轻潜在风险。 这确保了组织不会进行可能危及其 运营稳定性的项目。

• 渐进式扩展：最后，量身定制的方法提倡渐进式扩展，这是有效管理变革的一个重要优势。 从单一应用程序开始，组织可以逐步积累经验和能力。 这种方法有助于在可控环境中发现潜在问题并从中学习，再逐步扩展。 渐进式扩展还有助于在利益相关者中建立信心，并减少对变革的抵触，因为转型的好处会逐渐显现并可靠。 地体现出来。

总之， 量身定制的方法提供了一种战略性、风险管理、能力导向且具有渐进扩展性的数字化转型方法。 这种方法不仅与组织的具体需求和条件相契合，还能最大化成功实施的机会，并促进 可持续增长。

选择一次转型一个应用程序还是多个应用程序，应与组织的战略目标、运营能力以及其在数字化转型过程中面临的具体挑战和机遇相一致。 转型之旅。

模型应用程序

选择一个应用程序作为 其他应用程序转型的模型，是一种为正在进行数字化转型的组织提供多个战略优势的方法。 这种方法可以有效地简化转型过程，降低风险，并提高整个组织成功的可能性。 以下是 主要优势：

• 概念验证 ：

  • 展示价值：将一个单独的应用程序作为模型，可以让组织展示数字化转型的实际好处和价值，这有助于获得全体利益相关者的支持。 董事会的支持。

  • 测试与学习：它提供了一个机会，在全面推广到整个组织之前，可以先在较小规模上测试新技术、流程和战略，根据 现实世界的反馈进行调整和优化。

• 风险管理：

  • 可控环境：一次转型一个应用程序能够提供一个更加可控的环境，用于管理风险并解决挑战，而不会使资源过载或对业务 运营造成重大干扰。

  • 降低失败风险：从任何问题或失败中获得的教训可以应用于后续转型，减少类似问题再次发生的可能性。

• 资源优化：

  • 聚焦投资：当资源集中在一个单一应用上时，可以更有效地进行资源分配和管理，确保财务、人力和技术资源得到高效利用。

  • 建立专业知识：专注于一个应用有助于在团队内部建立深厚的专业知识和能力，这些能力可以在后续的转型中得到充分利用。

• 增强的 变革管理：

  • 更顺畅的采纳：成功的模型应用可以作为案例研究，展示转型带来的积极影响，从而缓解用户和利益相关者的担忧与抵触。

  • 文化转变：早期的成功可以帮助培养创新文化和对变革的开放态度，为未来转型创造一个更加积极的环境。

• 简化实施：

  • 流程标准化：从模型应用转型中获得的经验可以帮助标准化流程、方法论以及数字化转型的最佳实践，在整个组织中推广。

  • 可扩展策略：从模型应用中获得的洞察可以指导可扩展的策略，这些策略可以调整并应用到其他应用中，可能加速转型过程。

• 战略对齐：

  • 与业务目标对齐：通过精心选择与战略业务目标紧密对接的应用，组织可以确保转型为业务绩效和客户满意度带来有意义的改进。

  • 反馈回路：初步的转型可以作为一个反馈回路，提供关于数字化转型如何影响业务各个方面的宝贵洞察，并且如何与整体业务战略对齐。

通过聚焦于单一应用作为模型，组织可以创建一个成功的蓝图，并将其复制到其他应用中，从而减少大规模数字转型所涉及的时间、成本和风险。 这种方法不仅促进了更可管理的转型过程，还帮助在组织内为数字化项目建立了动力和支持。

确定模型应用

仔细选择 模型应用至关重要。 本节描述了我帮助组织选择应用程序的的方法论。

图 5**.5 展示了一个详细的应用转型记分卡。 以下列表展示了如何利用记分卡选择符合给定标准的转型模型应用：

图 5.5 – 模型应用转型记分卡

某些 应用程序比其他应用程序更容易从 DevOps 中受益。 推荐的平均评分为 3 分或更高。

1. 定义评估标准：记分卡包括用于评估每个应用程序是否适合 DevOps 或 DevSecOps 转型的具体标准。

2. 分配权重：根据每个标准对实现组织 DevOps 转型目标的重要性，为每个标准分配权重。 这可能会根据组织的具体目标有所不同，例如缩短市场时间、提高运营效率或 降低风险。

3. 评估每个应用：根据提供的尺度对每个应用进行评分（例如，0 表示“不知道/不确定”，5 表示“非常高”）。 评分应基于当前评估、数据和 利益相关者的反馈。

4. 计算得分：对于每个应用，按照每个标准的评分乘以权重（如果权重的分配方式不同于简单的 1 到 5 的评分尺度），并将这些值相加以得到总得分。 该得分反映了应用程序在 DevOps 转型中的整体适用性。

5. 比较与选择：比较所有评估应用程序的总得分。得分最高的应用程序是最适合作为 DevOps 转型模型的候选者。该应用程序很可能在交付时间上有显著的提升潜力，支持创新文化，并与领导层目标保持一致，因此成为展示 DevOps 实践在组织中益处的理想候选者。

这种结构化的方法使我们能够客观评估每个应用程序的转型潜力，确保资源集中在具有最高影响力并与转型目标高度一致的领域。

确定持续测试的目标

考虑一个希望向持续测试转型的组织（持续测试在第一章中已定义），本章中提到的六个类别的转型目标示例如下：

• 敏捷性：

  • 我们将自动化测试集成到我们 CI/CD 管道的每个阶段。

  • 我们在开发团队中全面采用测试驱动开发（TDD）实践。

  • 我们实施了特性标记系统，允许我们在测试和生产环境中，针对特定用户群体测试新功能。

  • 我们在合并到主分支之前，增加了开发功能中具有自动化测试的比例，从而增强了我们的测试覆盖率。

• 效率：

  • 我们自动化了回归测试。

  • 我们利用临时测试环境，根据需求扩展测试工作量，从而减少环境配置时间。

  • 我们优化了测试自动化脚本，以减少执行时间，从而在接下来的八个月中不增加额外资源成本的情况下提高测试频率。

  • 我们实施并行测试策略，以减少整体测试周期时间。

• 稳定性：

  • 我们实现了持续测试基础设施的高百分比正常运行时间，确保测试操作不受中断。

  • 我们通过在测试阶段提前检测问题，减少了生产环境中的热修复，预计明年可见成效。

  • 我们通过实施自动化健康检查和恢复流程，确保因测试环境问题导致的停机时间降到最低。

  • 我们确保所有部署的回滚率保持在低水平。

• 质量：

  • 我们通过自动化与手动测试的协同作用，增加在代码到达生产环境之前的缺陷检测率。

  • 我们通过将持续的用户体验测试整合到发布流程中，提高用户满意度评分。

  • 覆盖关键用户旅程的自动化测试减少了用户报告的问题。

  • 我们每两周进行一次质量审计，旨在持续改进我们的内部质量指标，逐季提升。

• 安全：

  • 我们将自动化安全测试集成到每个 CI/CD 流水线的阶段中。

  • 我们进行安全合规性测试，确保发布符合我们的安全要求，从而减少与安全相关的事件。

  • 我们每季度为开发和 QA 团队进行安全培训，旨在减少因人为错误导致的安全漏洞。

  • 我们实施对第三方依赖项安全漏洞的持续监控，减少风险暴露时间。

• 团队满意度：

  • 我们建立了一个持续学习的文化，团队将在明年获得自动化测试工具的认证。

  • 我们提高了开发和 QA 团队在持续测试方面的支持和资源满意度。

  • 我们通过引入导师计划，将初级与高级专业人士配对，提升团队参与度评分。

  • 我们每月表彰和奖励在测试卓越方面的贡献，推动团队采纳创新的测试实践。

这些目标为一个强有力的持续测试策略奠定了基础，强调在敏捷性、效率、稳定性、质量、安全性和团队满意度方面的可衡量改进。图 5.6 是适用于目标设定研讨会的持续测试转型目标记分卡示例。

图 5.6 – 持续测试目标评分卡示例

在示例中，如 图 5**.6所示，持续测试转型的前三个最高排名目标是 以下内容：

• 我们将自动化测试集成到 CI/CD 管道的每个阶段。 从 20%到 90%的 管道阶段。

• 我们实现了一个功能标记系统，使我们能够在测试和生产环境中使用特定用户组测试新功能。 从 25%到 75%的 新功能。

• 我们实现了功能标记系统，使我们能够在测试和生产环境中使用特定用户组测试新功能。 从 35%到 90% 的团队。

通过在研讨会环境中将目标简化为一个短列表，团队成员会比没有参与的情况下更有承诺感。 他们的参与让目标更加明确。

确定持续质量的目标

考虑一个希望向持续质量转型的组织（在 第一章中定义），这里描述了本章中之前定义的六个类别的转型目标示例：

• 敏捷性：

  • 我们 在每次冲刺回顾中完成可执行的质量改进，从而提升了我们冲刺的 质量指标。

  • 在收到用户反馈后，我们快速部署新功能，确保我们的产品与 用户需求保持一致。

  • 我们将自动化测试集成到我们的 CI/CD 管道中，从而减少手动 测试时间。

  • 我们实现了功能标记，用以在特定用户组中测试新功能，提高了功能的 成功率。

• 效率：

  • 我们自动化了回归测试，减少了测试 周期时间。

  • 通过流程优化和工具集成，我们缩短了整体软件开发生命周期。

  • 通过简化开发和 部署流程，我们实现了年度开发成本的降低。

  • 我们通过更好的项目管理和预测，提升了资源利用率，减少了闲置时间。 和预测。

• 稳定性：

  • 我们通过实施主动监控和自动恢复过程，确保了生产环境的高可用性。

  • 我们通过全面的质量保障实践和强有力的预部署测试，减少了关键生产故障的发生。

  • 我们通过采用分阶段发布策略和增强的监控，减少了因稳定性问题导致的发布回滚。

  • 我们建立了一个持续监控框架，在问题影响用户之前，检测并解决了大部分潜在的稳定性问题。

• 质量：

  • 我们通过有针对性的质量改进和用户体验提升，提升了客户满意度评分。

  • 我们通过将用户反馈融入开发过程，减少了每次新版本发布后的用户报告问题。

  • 我们在生产部署前检测到大部分缺陷，从而确保了更高质量的发布。

  • 我们每月召开质量评审会议，导致我们内部质量指标逐季度的提升。

• 安全性：

  • 我们确保大部分代码库在部署前经过安全代码分析，从而减少了安全漏洞。

  • 我们确保符合所有相关安全法规，将合规性相关问题减少到 0。

  • 我们为开发团队提供季度安全培训，旨在减少因人为错误导致的安全事件。

  • 我们实施了一个持续的安全评估过程，在 72 小时内识别并修复了大部分新发现的漏洞。

• 团队满意度：

  • 我们通过增强的沟通、反馈机制和有针对性的培训计划，在下一年度实现了高团队满意度评分。

  • 我们为团队提供每月的职业发展机会，旨在实现高参与率。

  • 我们实施了一个同行认可计划，使每个团队成员每季度获得较高比例的认可，促进了积极的工作文化。

  • 我们确保团队通过持续的学习和发展计划，将数字素养报告为高水平。

图 5**.7 是持续质量转型目标评分卡的一个示例：

图 5.7 – 持续质量目标评分卡示例

在 下图示例中，持续质量转型的前三个最高排名目标如下： 图 5**.7： 如以下所示：

• 我们实施功能标记来测试新功能，选择特定用户群体进行测试，从而提高了我们功能的成功率。

• 我们将自动化测试集成到我们的 CI/CD 管道中，实现了手动测试时间的减少。

• 我们为开发团队提供季度安全培训，旨在减少由人为错误引起的安全事件。

通过在工作坊中将目标缩短为一个简短的清单，不同的团队成员会比没有他们参与的情况下更致力于这些目标。

确定持续安全目标

考虑一个希望实现持续安全转型的组织（该转型在 第一章中有所定义），以下是本章中定义的六个类别中每个类别的转型目标示例：

• 敏捷性：

  • 我们将 安全评估融入冲刺，确保大量新代码在发布前经过安全审查 。

  • 我们在识别安全漏洞后快速部署安全补丁，保持对所有系统的快速响应承诺。

  • 我们根据新兴威胁快速调整安全协议，保持领先于潜在的漏洞。

  • 我们经常进行敏捷回顾，专注于安全实践，根据最新的洞察不断优化我们的做法。

• 效率：

  • 我们将大部分常规安全监控任务自动化，减少了人工工作量，提升了我们的 运营效率。

  • 通过增强的分析和机器学习工具，我们缩短了检测安全威胁的时间。

  • 我们减少了非关键安全警报的响应时间，优化了我们的安全运营 中心的效能。

  • 我们简化了 事件响应流程，在控制和 修复行动的速度上取得了改善。

• 稳定性：

  • 通过强有力的设计和 冗余配置，我们确保了关键安全系统的高可用性。

  • 通过在我们的 部署过程中实施故障保护机制，我们确保零安全引发的停机时间。

  • 我们保持运营稳定，安全更新对系统性能造成的干扰比例较低。

  • 我们确保安全监控工具的持续运行，未计划的停机时间保持在较低水平。

• 质量：

  • 我们保持 关于服务安全性和隐私功能的用户满意度高分。

  • 我们确保所有面向客户的应用在发布时都存在较少的高风险漏洞。

  • 通过透明沟通和强有力的 安全措施，我们赢得了客户对数据保护实践的高度信任。

  • 通过积极的互动和 教育努力，我们减少了与安全相关的客户投诉数量。

• 安全性：

  • 我们在 48 小时内识别并 修复大部分关键漏洞。

  • 我们确保所有运营均符合国际网络安全标准的高比例。

  • 通过持续改善我们的 安全态势，我们减少了安全事件的发生频率。

  • 我们实现了年均缩短解决安全事件的平均时间，展示了我们在 事件管理中的效率不断提高。

• 团队满意度：

  • 通过有针对性的开发计划和支持性的 工作环境，我们提高了安全团队的工作满意度。

  • 我们确保开发团队每年接受最新的安全编码 实践培训。

  • 我们倡导安全意识文化，使得所有部门的安全知识评估通过率达到了 90%。

  • 我们实施了安全最佳实践的表彰计划，使得每个部门每季度至少有一项贡献被认可。

图 5**.8 是持续安全转型的目标评分卡示例：

图 5.8 – 持续安全目标评分卡示例

在 图示例中，图 5**.8中，持续安全转型的前三个最高排名目标如下：

• 我们确保所有操作都符合国际网络安全标准的高比例合规性。

• 我们自动化了大部分常规安全监控任务，减少了人工工作量，并提高了我们的 运营效率。

• 我们通过有针对性的开发 程序和支持性 的工作环境，提高了安全团队的工作满意度评分。

通过在研讨会设置中将目标简化为一个简短的清单，不同团队成员会比单纯宣告目标时更加致力于这些目标。

确定持续反馈的目标

考虑到一个希望转向持续反馈的组织（这在 第十章中定义），以下是本章所述六个类别中每个转型目标的示例：

• 敏捷性：

  • 我们与用户建立了一个 实时反馈循环，将从收到反馈到功能增强的周期时间减少。

  • 我们将客户反馈直接整合到我们的冲刺计划过程中，确保每个冲刺的工作都直接受到 用户洞察的影响。

  • 我们部署了一个用户验收测试平台，用于新功能，允许我们在首次发布后快速收集用户反馈并进行改进迭代。 初步发布。

  • 我们实施了一个自动化系统，用于收集、分析和 优先排序反馈。

• 效率：

  • 我们自动化了 反馈分析过程，减少了分类和处理反馈所需的时间。 。

  • 我们通过简化反馈驱动的开发过程来降低运营成本，消除在集成用户洞察时的低效。

  • 我们增强了产品分析工具，提供来自用户行为的可操作性洞察，提升了 反馈实施的速度。

  • 我们实施了持续交付管道，基于用户反馈评分自动更新，优化了资源使用并减少了手动 部署工作。

• 稳定性：

  • 我们确保用户反馈收集与分析系统的高可用性 ，支持不中断的 反馈循环。

  • 我们在高峰反馈期通过自动扩展基础设施来保持系统稳定，确保在关键发布 反馈阶段没有停机时间。

  • 通过强有力的测试和监控措施，我们减少了与反馈相关的系统故障发生率，提升了整体的 系统可靠性。

  • 我们为所有关键的反馈处理组件实施了故障转移机制，确保持续运作，避免任何单点 故障。

• 质量：

  • 通过将反馈融入开发过程，我们提升了整体产品质量，确保我们的管道阶段高效运行，从而提高客户 满意度评分。

  • 我们确保所有新功能在广泛发布之前，能够达到高百分比的正面反馈率，展示了我们基于 用户洞察力对质量的承诺。

  • 通过在整个开发过程中整合持续的用户测试，我们减少了发布后质量问题的数量。

  • 我们建立了一个包含用户反馈指标的质量 基准，旨在每个季度提升这些基准 。

• 安全：

  • 我们将用户反馈纳入我们的安全 审查流程，旨在快速识别并修复安全组织和用户提出的大部分安全问题。

  • 我们确保所有用户反馈渠道都是安全的，并符合数据保护法规，保护 用户数据。

  • 通过为团队提供持续的安全培训，结合用户反馈中的常见主题，我们减少了用户报告的安全事件。

  • 我们根据用户反馈趋势定期进行安全审计，旨在不断强化我们的网络安全 措施。

• 团队满意度：

  • 我们通过将团队反馈纳入运营改进，增加团队 参与度和满意度，通过 季度调查进行衡量。

  • 我们在整个组织中提升数字素养，推动这一进程的是基于反馈的培训课程。

  • 我们建立了一个团队反馈门户，推动流程变更，直接提升团队满意度 和生产力。

  • 我们识别并奖励对反馈过程的贡献，旨在提高团队士气和参与持续 反馈计划。

图 5**.9 是持续反馈转型的目标评分卡示例：

图 5.9 – 持续反馈目标评分卡示例

在示例中 显示在 图 5**.9中，持续反馈转型的前三个最高排名目标如下：

• 我们确保所有用户反馈渠道的安全性，并遵守数据保护法规，保护 用户数据。

• 我们确保所有用户反馈渠道的安全性，并遵守数据保护法规，保护 用户数据。

• 我们为新功能部署了用户接受测试平台，允许我们收集用户反馈，并在初始 发布 后迅速进行改进迭代。

通过在研讨会环境中将目标缩短为一个简短清单，不同的团队成员会比在没有他们参与的情况下更加投入于这些目标。

总结

本章为任何想要在今天快节奏的世界中应对变化的挑战的人提供了基石。 它详细阐述了将组织愿景与可操作且可衡量的目标对齐的重要性，涵盖了敏捷性、效率、稳定性、质量、安全性和团队满意度等多个领域。 本叙述鼓励领导者战略性地思考他们希望创造的未来，以及实现这一愿景所需的步骤。 实现。

这一章节将复杂的概念拆解为易于理解和可操作的见解，使其成为各级决策者不可或缺的资源。 通过一系列示例和最佳实践，它揭示了在转型背景下设定目标的过程，强调了持续反馈和适应性调整的重要性。 这种方法促使创新和持续改进的文化，确保转型工作扎根于运营能力和市场需求的现实之中。 聚焦于 SMART 目标为组织提供了一个指引，帮助它们朝着既雄心勃勃 又可实现的结果前进。

本章节呼吁那些希望主动迎接变革的组织采取行动。 它突出了清晰定义目标的变革力量及其对组织各方面产生的积极连锁效应。 从提升客户满意度到加强安全措施，再到促进团队间支持文化的建设，本章节勾画了一套可持续增长和韧性的整体框架。 这不仅仅是鼓励遵循最佳实践，更是激励组织在看待和应对变革时的根本转变。 本章节赋予并装备了领导者，将今天的挑战转化为 明日的成功。

接下来的章节将解释组织如何进行当前状态的发现，以便为 转型做好准备。

第六章：发现和基准测试

本章解释了发现组织当前状态的方法论和工具，涵盖与持续测试、质量、安全性和反馈转型相关的人员、流程和技术。 这一点对于制定转型的基准起点和优先事项至关重要。 本章中描述的方法论 和工具 包括调查、访谈、研讨会、 差距评估和 价值流映射。

本章结束时，您将理解发现和基准测试的方法论，以及差距评估和价值流映射的发现工具。 我们将通过讨论如何将发现和基准测试应用于持续测试、质量、安全性、 和反馈来结束本章。

本章根据以下标题进行组织： 以下是章节标题：

• 发现和基准测试的方法论 和基准测试

• 理解 当前状态发现

• 理解 差距评估

• 理解 CSVSM

• 生成型人工智能如何加速发现 和基准测试

让我们 开始吧！

技术要求

本书中提到的工具的可执行版本可以在与本书相关的资源页面找到： 书籍链接： https://github.com/PacktPublishing/Continuous-Testing-Quality-Security-and-Feedback。

发现和基准测试的方法论

第四章 概述了 我建议用于指导数字化转型的七步转型工程蓝图。 第四步 转型的步骤，称为 评估，是包含发现和基准测试的步骤。 进行发现和基准测试有四个组成部分，如 图 6**.1所示。

图 6.1 – 发现和基准测试的方法论

发现和基准测试的方法论与我在我的书中为 DevOps 所描述的方法相同，该书名为 《工程化 DevOps》。

四个组成部分如下： 如下所示：

• 当前状态发现：利用 在七步转型过程中前述步骤确定的目标输出，进行调查、访谈以及对当前环境和实践的扫描，涉及持续测试、质量、安全 和反馈。

• 实践能力评估：利用 当前状态发现 组件的输出，确定 每个实践在实践支柱中的重要性、当前状态以及存在的差距 ，这些支柱涉及持续测试、质量、安全 和反馈。

• CSVSM：利用 实践能力评估 组件的输出，选择价值，映射当前状态，并确定 价值流的当前状态基准。 价值流。

• 解决方案需求分析： 利用 当前状态发现 *、 实践能力评估和 CSVSM 组件的输出，确定解决方案与组织转型目标对齐的优先级。

前述步骤所描述的发现方法确保组织充分考虑相关数据和 当前状态。

理解当前状态发现

在数字化转型的 评估 阶段使用调查和访谈，对于收集全面且细致的洞察至关重要，这些洞察为战略提供依据，吸引利益相关者，管理风险，并指导持续改进。 这些工具帮助确保转型努力与组织的现实相契合，从而提高实现有意义且 可持续变革的可能性。

调查

调查 是一种 强有力的工具，旨在通过全面评估方法发现组织人员、流程和技术的当前状态。 它们通过提供可以分析的定量见解，补充了访谈和其他数据收集方法，从而帮助识别趋势、模式和改进领域。

为何进行调查？

以下是调查的重要性及其执行方式：

• 广泛的覆盖面和可扩展性：调查可以覆盖组织内各个层级和部门的大量受访者，从而提供对当前状态的全面视角。 当前状态。

• 可量化数据：调查可以生成可量化的数据，这些数据便于分析，识别趋势、比较子群体，以及与基准或 随时间的变化进行衡量。

• 匿名性和诚实性：调查可以提供匿名性，这可能鼓励更诚实的回答，特别是在 敏感话题上。

• 标准化：调查确保从所有受访者那里收集相同的信息，使得比较和分析回应变得更容易。 分析回应。

• 效率：调查比进行个别访谈更具时间和成本效益，尤其适用于 大规模的组织。

如何进行调查

步骤如下： 定义 如下：

1. 定义目标：清晰定义你希望从调查中学到的内容。 这将指导你问题的设计和数据分析。

2. 设计调查：设计清晰、简明并直接相关的问卷。 确保问题不带偏见，不引导受访者做出特定回答。

3. 选择合适的平台：选择一个所有参与者都能访问并提供所需功能的调查平台（例如，匿名选项、数据分析工具）。

4. 分发调查：将调查发送给精心挑选的样本或目标人群。 确保传达调查的目的、数据的使用方式以及参与的奖励。

5. 最大化响应率：使用提醒和跟进来鼓励参与。 考虑时间安排，确保调查既不太长也不 过于复杂。

6. 分析数据：使用统计方法分析数据。 寻找显著的趋势、相关性和群体之间的差异。 群体之间的差异。

7. 报告结果：以清晰、可操作的方式呈现结果。 突出关键洞察、潜在的改进领域，以及基于数据的建议。

8. 采取行动并跟进：利用调查结果来指导战略决策和改进计划。 同样，向参与者反馈 因其反馈而采取的变更或行动也至关重要。

最佳实践

以下是我们可以 实施的一些措施，以确保从 这个过程获得最佳效果：

• 确保匿名性和保密性：明确说明你将如何保护受访者的隐私以及数据将如何使用。 这鼓励了参与 和诚实。

• 保持相关性：确保每个问题都能为你的目标做出贡献。 不必要的问题可能会降低完成率，并削弱 有价值的见解。

• 注意偏见：避免引导性问题或可能影响回答的措辞。 中立语言有助于获取更多 准确的数据。

• 考虑时间和频率：选择一个合适的时间来分发调查问卷，避免过度调查，因为过度调查可能导致 调查疲劳。

让我们通过一个例子来理解这一点。

示例调查

图 6**.2 展示了一个 关于持续测试实践的示例调查。 对于调查中的每一个实践陈述，用户输入一个重要性得分、当前实践水平得分以及任何 澄清评论。

图 6.2 – 持续测试的示例调查

进行调查是一种 有效的方式，可以收集关于组织的人、流程和技术的宝贵数据。 如果操作得当，调查可以提供推动战略改进和实现 组织目标所需的见解。

访谈

进行访谈 以发现一个组织的人、流程和技术的现状是总体评估方法中至关重要的一部分。 这些访谈有助于理解现有状况、识别差距并发现 改进的机会。

为什么进行访谈？

这就是为什么 访谈很重要以及它们应该如何进行的原因：

• 获取定性见解：访谈提供了深入的定性见解，帮助了解组织成员在其人员、流程 和技术方面的经验、看法和意见。

• 识别优点和缺点：通过对话，可以识别出组织当前设置中的优点和缺点，这些可能无法通过诸如问卷调查等定量方法显现出来。

• 促进利益相关者参与：直接让利益相关者参与其中，让他们感到被重视和听到，这有助于提高对任何由评估结果推动的变革计划的支持。

• 制定定制化解决方案：理解特定的挑战和背景有助于制定量身定制的解决方案，这些解决方案更有可能 取得成功。

• 揭示隐藏问题：访谈可以揭示出一些未被记录或在正式流程中未得到充分关注的问题和瓶颈。

如何进行访谈

图 6**.3 展示了进行访谈的 建议步骤。

图 6.3 – 示例访谈过程

这些步骤如下 所定义 ：

1. 定义目标：清晰地概述你希望从关于组织的人员、流程 和技术的访谈中学到的内容。

2. 选择受访者：从组织内不同层级和部门选择多样化的参与者，以获得 全面的视角。

3. 准备问题：设计开放性问题，鼓励受访者提供详细的回答。 确保问题覆盖所有感兴趣的领域，但也要保持灵活，以便在访谈过程中探讨新出现的见解。

4. 选择合适的访谈形式：根据参与者的可用性以及是否需要视觉线索或演示，决定访谈是面对面、电话还是通过视频会议进行。

5. 创造一个舒适的环境：确保受访者感到舒适，并理解访谈的目的是为了改进，而非评判 或责备。

6. 记录并转录访谈：在得到同意后，录制访谈以确保准确捕捉信息，并将其转录 用于分析。

7. 分析并综合发现：寻找回答中的模式、趋势和差异。 识别常见问题、独特见解和潜在改进领域。

8. 报告与行动：编写报告，总结发现、见解和建议。 将此报告作为规划和 实施变更的基础。

9. 后续跟进：实施变更后，跟进参与者，评估这些变更的影响和效果。 这也有助于保持参与度，并对 他们的意见表示感谢。

最佳实践

以下是我们 可以实施的一些措施，以确保我们从 这一过程中获得最佳效果：

• 确保保密性：向参与者保证，他们的回答将被保密。 这可以鼓励开放 和诚实。

• 保持客观和非评判性：以开放的心态进行每次访谈，避免根据回答做出评判。 根据回应做出判断。

• 使用熟练的访谈员：访谈员应具备强大的人际交往能力，善于倾听，并能够深入探讨而不引导 受访者。

作为整体评估方法的一部分，进行访谈对深入了解一个组织的当前状况至关重要。 它有助于识别可以指导战略规划和 运营改进的可行洞察。

示例访谈问题

以下问题是一些示例 ，旨在揭示现有流程、工具、挑战以及团队对转型为持续测试的准备情况。 类似的问题可以用于持续质量、安全 和反馈：

• 您能描述一下您团队/组织当前的软件测试流程吗？

  • 目的：这个开放性问题旨在收集关于现有测试流程的全面信息，包括手动和自动化测试实践、测试在开发生命周期中的集成以及涉及的角色 等方面。

• 当前使用了哪些工具和技术进行测试，它们的效果如何？

  • 目的：这个问题旨在了解现有的工具集，包括任何测试自动化工具、测试管理软件和开发环境。 它还引发了关于这些工具的有效性、潜在的不足以及遇到的任何 限制的讨论。

• 你目前如何 处理测试数据管理和测试 环境配置？

  • 目的：测试数据管理和测试环境配置是持续测试的关键组成部分。 这个问题旨在揭示有关测试数据和环境的创建、维护和使用的实践，识别需要改进 或自动化的领域。

• 你能分享一下在当前的 测试过程中遇到的挑战或瓶颈吗？

  • 目的：识别现有的挑战和瓶颈对于规划成功的持续测试转型至关重要。 这个问题鼓励面试者讨论在效率、质量、覆盖面或团队协作中遇到的障碍。

• 在你看来，哪些关键领域需要改进，以支持向 持续测试的转型？

  • 目的：这个问题直接引导面试者识别潜在的改进领域，并将目标与持续测试的转型对齐。 它可以揭示团队的准备情况、技能差距以及 对新工具 或流程的需求。

这些问题旨在帮助全面理解当前的测试环境、面临的挑战以及通过持续测试转型提升测试实践的机会。 回答将为制定量身定制、有效的持续测试实施策略提供宝贵的见解。

了解差距评估

差距评估 在数字化转型中扮演着关键角色，作为一种战略工具，用于将组织当前的流程、技术和能力与其期望的未来状态或行业基准和最佳实践进行比较。 差距评估的主要目标是识别组织当前与实现数字化转型目标所需状态之间的差异（即差距）。 这些评估至关重要，原因有很多，它们的进行和结果的利用遵循一种 结构化的方法。

图 6**.4 展示了差距评估摘要的一个示例。 根据重要性和 差距得分 对实践领域的当前实践水平进行评分。 所有实践领域的得分将被排序，以确定各实践领域的 优先级。

图 6.4 – 差距评估示例

为什么差距评估很重要

以下是 差距评估为何重要以及如何 进行的原因：

• 识别不足与机会：差距评估有助于找出组织在数字化转型目标或行业标准方面的具体不足，清晰地展示出改进 或投资的领域。

• 优先安排行动：通过突显最显著的差距，组织可以优先推进那些对实现数字化转型目标具有最大影响的举措，确保资源的高效分配。

• 定制化战略制定：通过差距评估获得的洞察力使得组织能够制定量身定制的战略，解决其独特的挑战并利用其特定的优势，而不是采用 一刀切的方法。

• 风险管理：了解差距有助于识别转型过程中可能面临的风险和障碍，从而为制定 缓解策略提供依据。

• 衡量进展：通过建立当前状态的基准，差距评估使得组织能够随着时间推移衡量进展，提供了一种定量的方式来跟踪其数字化转型努力的有效性。

差距评估如何进行

步骤如下： 定义 如下：

1. 定义目标和范围：清晰列出数字化转型的目标，并定义差距评估的范围，包括需评估的流程、技术和能力。

2. 评估当前状态：收集有关组织技术、流程和人员的当前状态数据。 这可以通过调查、访谈、研讨会和现有文档的审查来完成。

3. 定义期望的未来状态：阐明组织在数字化转型后的未来状态愿景，包括新技术的采用、流程改进和能力提升。

4. 识别差距：将当前状态与期望的未来状态进行对比，以识别差距。 这包括分析能力、流程和技术方面的差异。

5. 优先排序差距：根据差距对组织目标的影响及其紧迫性评估已识别的差距。 这有助于优先处理最需要解决的差距。

6. 制定行动计划：为每个优先级差距制定详细的行动计划，明确解决差距所需的步骤，包括资源分配、时间表和责任方。

差距评估结果的应用

差距评估的结果用于确定战略规划、资源分配、实施路线图以及转型过程中的进展和绩效衡量标准：

• 战略规划：差距评估结果输入战略规划过程中，有助于通过集中解决最关键的差距来塑造数字化转型战略。

• 资源分配：评估中的洞察指导资源（预算、人员、时间）分配，优先支持解决最重要差距并提供最大投资回报的举措。

• 实施路线图开发：调查结果有助于制定详细的数字化转型路线图，概述关闭已识别差距所需采取的各项措施。

• 性能监控：初步的差距评估提供了一个基准，用于衡量数字化转型的进展。 后续评估可以用来监控进展并根据 需要 调整策略。

差距评估是成功数字化转型的基础元素，它提供了量身定制战略、优先事项管理、风险控制以及最终引导组织走向期望未来状态所需的洞察，以一种 结构化的 和 知情的方式。

已知的持续测试良好实践

以下是已知良好实践的示例，这些实践对应于 持续测试实践支柱 中的 第一章。这些实践可用于 基准评估组织当前的持续 测试实践：

• 支柱 1： 测试自动化：

  • 单元测试针对每一段 代码实现自动化。

  • 集成测试用于确保组件之间的交互按 预期工作。

  • 系统测试实现自动化，以验证应用程序的行为 是否符合预期。

  • 用户验收测试实现自动化，以确认系统是否满足 用户需求。

  • 测试套件持续更新和重构，以确保相关性 和效率。

  • API 测试包含在自动化策略中，以确保 接口的可靠性。

  • 性能测试被自动化并定期执行，以监控 系统的响应性。

• 支柱 2：与开发的整合 ：

  • 测试驱动开发 (TDD) 被实践，测试在 编写代码之前编写。

  • 行为驱动开发 (BDD) 被采用 以确保与 预期行为的一致性。

  • 自动化测试被集成到 CI/CD 管道的每个阶段，以便 即时反馈。

  • 鼓励使用结对编程或启用 Copilot 的结对编程，以提升代码质量并促进 即时测试。

  • 功能开关用于管理和测试 新特性。

  • 安全测试在 开发周期的早期进行集成。

  • 在开发过程中使用静态代码分析工具来提前捕获潜在的 问题。

• 支柱 3： 测试反馈：

  • 仪表板 被设置为即时 查看 测试结果。

  • 为测试失败配置警报，以便于 快速响应。

  • 测试结果的趋势被分析，以识别需要改进的 领域。

  • 已建立反馈机制以增强测试策略 。

  • 测试日志和详细信息被轻松获取，以便快速 诊断问题。

  • 视觉测试工具被用来检测 UI 变化。

  • 利用人工智能和机器学习进行预测分析 测试结果。

• 支柱 4： 测试指标：

  • 缺陷 密度被测量，以跟踪每个 代码单元中的问题数量。

  • 测试覆盖率被计算，以确保 全面的测试。

  • 平均修复时间 (MTTR) 被监控，以评估问题 的解决效率。

  • 测试通过/失败率被跟踪，以衡量 整体质量。

  • 测试执行频率被分析，以优化测试 套件。

  • 测试效率被评估，以评估 测试工作的生产力。

  • 缺陷逃逸率被记录下来，以衡量问题 达到生产环境的发生率。

• 支柱 5： 基于风险的测试：

  • 测试工作 根据关键 业务功能的优先级进行排序。

  • 安全漏洞的优先级是通过威胁建模识别的，高优先级的漏洞测试被分配为 高优先级。

  • 高流量功能经过集中的 性能测试。

  • 测试资源根据组件的复杂性和风险 进行分配。

  • 关键系统路径会进行 压力测试。

  • 基于用户 行为分析对高风险用户场景进行测试。

  • 有频繁问题历史的区域被优先考虑 进行测试。

• 支柱 6：测试环境与测试 数据管理：

  • 测试环境会自动设置并 销毁。

  • 在测试环境中通过容器化复制生产环境的条件 。

  • 通过数据掩码 和匿名化来确保测试数据的隐私。

  • 测试环境的版本控制得以保持 以确保一致性。

  • 服务虚拟化用于模拟不可用的 系统组件。

  • 测试数据具有多样性和全面性，以便进行 准确的测试。

  • 测试环境会定期更新，以匹配 生产设置。

• 支柱 7：协作 与沟通：

  • 质量保证 协调通过定期的跨职能 团队会议得到促进。

  • 通过共享工具，支持透明的测试进度 进行追踪。

  • 团队成员之间保持实时通信 。

  • 通过无责文化，促进开放地讨论失败 和学习。

  • 成功的测试策略和经验在 团队之间共享。

  • 通过配对测试，开发人员与测试人员之间的知识差距得以弥合 。

  • 测试知识和见解被记录并通过 协作平台共享。

• 支柱 8：持续学习 与适应：

  • 测试工具和流程定期进行评审 并改进。

  • 通过参与工作坊 和会议，跟随最新的测试趋势。

  • 鼓励尝试新的测试方法 。

  • 测试策略根据来自 生产问题的反馈进行调整。

  • 每个发布周期的学习通过回顾会议得以促进 。

  • 通过认证 和培训支持测试团队的发展。

  • 测试流程持续被 通过分析不断优化 以改进。

已知的持续质量管理良好实践

以下是对应 已知良好实践的示例 ，这些实践对应于 持续质量实践支柱 ，见 第一章。这些实践可用于基准测试当前组织的持续质量实践状况：

• 支柱 1: 以用户为中心的关注：

  • 定期收集并分析用户反馈，以指导 质量改进。

  • 一致性地进行可用性测试，以确保用户界面的直观性 和效率。

  • 定期部署客户满意度调查，并利用结果来指导 开发优先级。

  • 用户体验指标持续被监控，以评估并 提升满意度。

  • 与用户建立反馈回路，以快速识别并解决 可用性问题。

• 支柱 2: 集成的 质量指标：

  • 缺陷率在软件开发 生命周期的各个阶段进行追踪。

  • 系统正常运行时间指标被监控，以确保可靠性 和可用性。

  • 性能基准已设定并进行测量，以保持应用程序的最佳 速度。

  • 质量指标已集成到 CI/CD 管道中，以提供 实时可视化。

  • 定期进行代码质量评估，以 保持标准。

• 支柱 3: 积极的 质量保证：

  • 静态代码分析早期并且频繁进行，以检测 潜在问题。

  • 在开发周期开始时进行设计评审，以确保 架构的合理性。

  • 定期进行架构评估，以防止可扩展性和 性能问题。

  • 代码评审对于所有新的提交是强制性的，以保持 高质量标准。

  • 通过自动扫描积极识别并修复 安全漏洞。

• 支柱 4: 持续改进：

  • 定期 进行回顾，反思 流程并识别 改进机会。

  • 鼓励团队成员持续学习，以采用 最佳实践。

  • 流程和工具的有效性会持续进行审查 以优化。

  • 质量改进目标在开发过程中设定并跟踪。

  • 通过促进质量实践的创新，保持领先于 新兴挑战。

• 支柱 5：协作 与沟通：

  • 跨职能团队紧密合作，以确保统一的 质量方法。

  • 质量目标和指标在各个部门之间透明沟通。

  • 定期举行同步会议，讨论质量问题 和解决方案。

  • 一个通用平台用于跟踪和管理 与质量相关的活动。

  • 利益相关者在开发过程中早期参与，以对齐 质量期望。

• 支柱 6：稳定和 可靠的发布：

  • 在每次发布前进行全面的 测试，以确保稳定性。

  • 发布流程已标准化并自动化，以最小化 人为错误。

  • 部署实践包括金丝雀发布和蓝绿部署，以 确保可靠性。

  • 发布后 监控已实施，以快速发现并解决 任何问题。

  • 回滚程序已建立并测试，以供 紧急使用。

• 支柱 7： 风险管理：

  • 项目生命周期内定期进行风险评估 。

  • 工作重点根据对用户满意度和 系统稳定性的潜在影响进行优先排序。

  • 维护并更新风险登记册，以跟踪和管理 已识别的风险。

  • 为高风险场景制定应急计划，以减轻 潜在影响。

  • 利益相关者定期收到有关风险状态和 缓解策略的更新。

• 支柱 8： QA 自动化：

  • 利用自动化测试工具高效地增加测试 覆盖率。

  • 持续集成 (CI)流程 包括自动化的 质量检查。

  • 将自动化性能测试集成到 开发周期中。

  • 回归测试自动化，以确保新更改不会破坏 现有功能。

  • 自动化 脚本定期审查和更新，以适应新的 测试 需求。

这些实践确认了在开发、交付和生产过程中整合质量的承诺，专注于提升用户满意度，并实现更稳定、可靠的发布，减少 用户问题。

持续安全的已知良好实践

以下是与持续安全实践支柱相关的已知良好 实践示例 ，这些实践对应于 第一章。这些实践可以用来基准当前组织的持续安全实践状态：

• 支柱 1: DevSecOps 文化:

  • 安全责任由所有团队成员共同承担，而非局限于 某一小组。

  • DevOps 实践与安全原则从 一开始就被整合。

  • 针对安全实践的跨职能培训提供给所有 团队成员。

  • 鼓励跨开发、运维和 安全团队进行定期的安全沟通。

  • 安全目标与整体项目目标 和度量标准保持一致。

• 支柱 2: 安全意识 与培训:

  • 定期为所有 团队成员开展安全培训课程。

  • 开发了意识提升项目，确保每个参与者都始终关注安全。

  • 安全最佳实践已集成到新员工的入职流程中。

  • 提供持续的安全学习机会，以保持 技能的更新。

  • 网络钓鱼模拟和其他安全演练用于评估 团队的准备情况。

• 支柱 3: 安全集成于 生命周期中:

  • 安全 需求在 每个项目开始时定义。

  • 安全工具和实践被嵌入到 CI/CD 流水线中。

  • 代码审查包括安全分析，以便尽早发现 漏洞。

  • 在每个 软件生命周期阶段都设立了安全检查点。

  • 使用协作工具将安全洞察整合进 开发工作流程中。

• 支柱 4：自动化 安全测试：

  • 软件组成分析 (SCA) 和 静态应用安全测试 (SAST) 会 自动执行 在所有 代码提交时。

  • 动态应用安全测试 (DAST) 会在 开发 过程中定期进行。

  • 自动化漏洞扫描集成到 构建过程中。

  • 安全依赖项通过 自动化工具检查其漏洞。

  • 容器和编排镜像会自动扫描，查找配置错误 和漏洞。

• 支柱 5：主动 风险管理：

  • 安全风险评估会定期进行。

  • 针对新功能和 重大变更进行威胁建模。

  • 潜在的安全漏洞会在部署前被识别并减轻 风险。

  • 安全控制措施会根据最新的 威胁情报进行审查和更新。

  • 利益相关者会被告知潜在风险和 缓解策略。

• 支柱 6：快速 事件响应：

  • 已建立 应急响应计划 并 定期更新。

  • 定期进行事件响应演练以确保 团队的准备就绪。

  • 安全事件通过 持续监控迅速被识别。

  • 自动化工具用于协助快速遏制 安全漏洞。

  • 事后分析会进行，以便从安全事件中学习并 改进响应措施。

• 支柱 7：持续监控 与合规性：

  • 持续监控解决方案被部署以实时检测安全威胁。

  • 安全警报会根据严重性和 潜在影响进行优先级排序。

  • 始终如一地验证遵守安全标准和法规。 。

  • 定期进行安全审计，以评估并改进 安全态势。

  • 合规文档被维护并 定期更新。

• 支柱 8：反馈与 持续改进：

  • 已经建立反馈机制，以便收集来自 安全事件的洞察。

  • 从事件中汲取的经验教训被共享给各团队，以 防止再次发生。

  • 安全实践根据反馈定期审查和更新。 。

  • 不断变化的安全威胁被监控，以便相应地调整安全 策略。

  • 持续 改进周期应用于 安全流程 和工具。

这些实践积极概述了在持续安全框架下，针对安全事件减少及其 解决时间的主动、集成和持续的安全方法。

已知的持续反馈良好实践

以下是对应于 《持续反馈实践支柱》的已知良好实践示例， 该支柱适用于持续反馈的实践 在 第一章。这些 实践可用于基准测试组织当前的持续反馈实践状态：

• 支柱 1：利益相关者和 用户参与：

  • 定期举行与利益相关者和用户的反馈会议，以便 收集见解。

  • 调查和反馈表单频繁部署，以便捕捉 用户体验。

  • 建立了一个反馈门户，供利益相关者随时提交他们的 意见。

  • 社交媒体和论坛的反馈被积极监控 并收集。

  • 组织利益相关者和用户工作坊，以深入分析 反馈。

• 支柱 2：反馈整合在 开发过程中的应用：

  • 反馈直接与开发积压任务相关联，以便优先排序。 。

  • 已建立一个快速反馈分类和整合到开发周期中的过程。 。

  • 开发团队定期召开会议，审查并处理 反馈。

  • 自动化工具被用于简化反馈集成到 开发流程中。

  • 反馈指标会被跟踪，以通知开发的优先级 和决策。

• 支柱 3：快速迭代 和实施：

  • 开发周期被缩短，以便更快地 实施反馈。

  • 持续 部署实践被 采用，以加速 发布周期。

  • A/B 测试用于基于 用户反馈快速迭代。

  • 反馈实施的有效性会在 冲刺回顾中进行审查。

  • 原型设计和最小可行产品（MVP）用于根据反馈测试和完善想法。

• 支柱 4：数据驱动 决策：

  • 反馈通过定量分析，以识别趋势 和优先事项。

  • 用户行为分析工具用于理解 反馈背景。

  • 决策过程围绕反馈 分析结果进行结构化。

  • 维护一个反馈仪表盘，用于可视化反馈数据，以便做出 明智决策。

  • 情感分析应用于定性反馈，以获得 更深刻的见解。

• 支柱 5：反馈透明性 和沟通：

  • 反馈 的行动和决策会定期反馈给 利益相关者。

  • 维护一个公开的路线图，展示反馈 如何影响开发。

  • 论坛和社区渠道用于讨论反馈和 相关行动。

  • 关于反馈实施进度的定期更新 会被提供。

  • 从反馈中获得的挑战和经验教训会公开分享 给利益相关者。

• 支柱 6：持续学习 和适应：

  • 反馈见解被纳入持续 改进过程。

  • 鼓励团队基于反馈进行实验，以找到 最佳解决方案。

  • 从反馈中学到的东西会在团队之间分享，以促进 组织增长。

  • 反馈循环不断优化，以提高效率 和效果。

  • 过程和实践的调整基于持续的 反馈分析。

• 支柱 7：衡量影响 和效果：

  • 与反馈实施速度相关的度量指标被跟踪 并优化。

  • 反馈对系统可靠性的影响是 持续监控的。

  • 用户满意度调查被分析以衡量 反馈效果。

  • 由于反馈导致的发布频率和恢复时间的变化 会被评估。

  • 通过定期审计 和评估来审查反馈循环的有效性。

• 支柱 8：平衡速度 和质量：

  • 质量 保证过程 与快速反馈 实施策略相结合。

  • 根据对系统质量 和可靠性的潜在影响，反馈被优先处理。

  • 自动化测试被扩大，以在快速实施 反馈的同时保持质量。

  • 同行评审和结对编程用于在 反馈实施中平衡速度与质量。

  • 发布门控被建立以确保反馈实施符合 质量标准。

这些实践 确认了一种战略性 方法，用于利用利益相关者和用户反馈来提升系统可靠性，加快发布频率，并改善恢复时间，同时始终强调 维护质量的重要性。

图 6**.5 展示了一个连续测试的差距评估工具示例，该工具可以获取调查的输出并为每个 实践计算差距得分。

图 6.5 – 差距评估工具

当输入重要性和实践水平的值时，工具会生成一个差距得分的总结，并以总结格式显示在 图 6**.4中。该工具还可以用于确定连续测试、质量、安全性和反馈的差距，当每个主题的实践加载到 工具中时。

理解 CSVSM

当前状态价值流图 (CSVSM)在 数字化转型的评估、发现和基准测试阶段中的背景下，特别是涉及持续测试、质量、安全性和反馈时，是一种战略性和分析性工具，用于可视化和理解将信息和流程传递给客户所需的流动。

图 6**.6 是一个 CSVSM 的示例：

图 6.6 – CSVSM 示例

在数字化转型领域，特别是聚焦于持续测试、质量、安全性和反馈方面，CSVSM 在识别现有流程和系统中的低效、瓶颈和改进空间方面发挥着关键作用。 以下是 CSVSM 在 这些领域中的应用：

• 评估:

  • 识别当前流程：CSVSM 有助于详细绘制现有的测试、质量保证、安全性和反馈收集流程。 此步骤对于理解当前任务的执行方式、任务的顺序以及不同角色之间的互动 和技术的关系至关重要。

  • 识别低效：通过可视化当前状态，冗余流程、延迟以及可能影响质量或安全的区域会变得显而易见。 这种可视性对于 改进目标至关重要。

• 发现:

  • 突出改进领域：发现阶段涉及分析 CSVSM，识别可以引入或优化数字工具和方法的领域。 这包括整合自动化测试、增强安全协议、改进质量检查和优化 反馈机制。

  • 利益相关者参与：CSVSM 通过提供清晰的当前流程描述并突出数字化改进领域，促进利益相关者之间的讨论。 这有助于将转型目标与业务目标 和用户需求对齐。

• 基准测试:

  • 建立绩效指标：CSVSM 作为衡量数字化转型举措有效性的基准。 通过建立与测试速度、质量水平、安全标准和反馈循环效率相关的 关键绩效指标 (KPI)，组织可以随时间监测进展 。

  • 与最佳实践进行对比：组织可以使用 CSVSM 将当前状态与行业最佳实践或标准进行对比。 这种对比有助于识别差距和可以采用新技术 或方法的领域，从而带来 显著的收益。

• 数字化转型到 持续战略：

  • 持续测试：CSVSM 识别测试过程中的瓶颈，这些瓶颈可以通过自动化解决，从而实现更快速、更频繁的 测试周期。

  • 质量：通过突出缺陷或问题出现的领域，CSVSM 有助于实施质量改进措施，如更严格的测试协议或在开发过程中更早阶段的质量检查。 开发过程。

  • 安全性：通过 CSVSM 可以定位安全漏洞，从而在整个开发 生命周期中采用增强的安全实践和工具。

  • 反馈：CSVSM 能够揭示在收集和响应反馈方面的延迟或低效，指导实施更有效的反馈循环，从而促进 持续改进。

总之，CSVSM 是数字化转型旅程中的基础工具，特别是在关注持续测试、质量、安全性和反馈的领域。 它提供了现有流程的全面视图，促进了针对性改进、利益相关者的参与，并有效地衡量朝着 数字成熟度的进展。

创建 CSVSM 的步骤

创建一个 用于持续测试的 CSVSM 涉及多个步骤，旨在理解和可视化现有的测试流程，识别低效之处，并突显实施持续测试实践的机会。 以下是相关步骤的简要指南：

1. 定义范围 和目标：

   • 范围：确定要映射的流程边界，重点关注软件开发生命周期中的测试活动。 。

   • 目标：清晰地说明通过持续测试你希望实现的目标，例如缩短上市时间、提高测试覆盖率或 提升质量。

2. 组建一个 跨职能团队：

   • 组建一个包括测试过程中不同领域成员的团队，如开发人员、测试人员、质量保障经理和运营人员。 这能确保从多个角度全面了解流程。 。

3. 映射当前流程 ：。

   • 数据收集：收集当前测试流程的数据，包括使用的工具、活动顺序、每项活动所需时间以及团队之间的交接。 。

   • 可视化表示：使用价值流映射工具，或者仅用笔和纸创建当前测试流程的可视化表示。 标出流程中的每个步骤，并附上如持续时间、等待时间和测试频率等指标。

4. 识别并标出增值和 非增值步骤：

   • 分析 每个步骤，确定它是否从客户的角度为最终产品增加价值。 标出没有增加价值的步骤（浪费），例如延迟、不必要的交接，或 冗余的测试。

5. 识别瓶颈和延迟区域 ：。

   • 寻找流程中出现延迟、工作积压或瓶颈限制工作流的步骤。 这些是影响效率的关键领域 ，对测试过程有重大影响。

6. 收集反馈：

   • 与团队及其他利益相关者互动，收集对当前测试流程的见解和反馈。 这可以提供有价值的背景信息，并帮助识别初步映射中未显现的改进领域。 。

7. 分析地图 寻找机会：

   • 在清晰展示当前状态后，识别引入持续测试实践的机会。 这包括自动化重复任务、改进测试数据管理、将测试更早集成到开发过程中（向左移），以及增强开发人员 与测试人员之间的协作。

8. 未来状态的规划 ：

   • 根据分析，绘制一个未来状态的价值流图，融入旨在解决已识别的低效问题并实现 目标的持续测试实践。 第一步。

创建一个持续测试的 CSVSM 是转向更高效、更有效、持续测试流程的关键步骤。 它帮助组织可视化当前实践，识别低效问题，并规划有针对性的改进，以提高质量和 缩短上市时间。

需要克服的价值流映射挑战

CSVSM 是理解和优化流程的重要工具，它通过可视化信息、材料和工作流在系统中的流动来实现。 然而，在复杂环境中实施 CSVSM，尤其是数字化转型朝着持续测试、质量、安全和反馈的方向发展，面临着一系列挑战和障碍。 认识到这些挑战是制定有效策略以 克服它们的第一步。

挑战和障碍

让我们了解一下 CSVSM 中的挑战：

• 流程的复杂性：许多 组织的流程非常复杂、交织在一起，有时甚至没有文档记录，这使得准确绘制 当前状态变得困难。

• 利益相关者的参与：确保所有相关利益相关者的参与和合作可能会面临挑战，特别是在大型或部门割裂的组织中，不同部门可能有 相互竞争的优先事项。

• 数据过载：与流程、延迟和低效相关的数据量庞大，可能会让人不知所措，从而难以识别需要解决的最关键问题。 问题。

• 对变革的抵制：员工和管理层可能会抵制价值流映射过程中提出的变革，尤其是在他们对现状感到满意或害怕变革的影响时。 的影响。

• 缺乏专业知识：有效开展 CSVSM 练习需要一定的专业知识和经验，这可能在组织内部不存在。 组织内部可能缺乏这种专业知识。

克服障碍的建议

以下是一些克服 CSVSM 挑战 的方法：

• 简化并优先排序：将复杂的过程分解为较小、易管理的部分，并根据它们对整体价值流的影响来进行优先排序。 这样可以让映射更加可管理 并且更具焦点。

• 参与和沟通：通过从一开始就积极吸引利益相关者，培养透明和包容的文化。 清晰地传达 CSVSM 的好处，以及它如何积极影响 他们的工作。

• 利用技术：使用能够有效管理和分析数据的软件工具和平台。 例如，生成式人工智能可以自动化部分数据收集和分析过程，突出关键领域 的重点。

• 主动应对抗拒：实施变更管理策略，正面应对恐惧和抗拒情绪。 包括培训、研讨会以及清晰的沟通，向组织及其员工说明变更及其带来的好处。

• 寻求外部专业知识：如果缺乏内部专业知识，可以考虑聘请专门从事 CSVSM 的外部顾问，帮助组织完成这一过程。 这也有助于将知识和技能传递给 内部团队。

• 迭代方法：将 CSVSM 视为一个迭代过程，而非一次性项目。 持续改进应是目标，随着更多信息的收集和数字化转型的推进，可以进行调整和完善。 数字化转型的进程。

• 庆祝成功：承认并庆祝通过 CSVSM 取得的改进和成功。 这能够提升士气，并展示接受变革的切实好处。

通过承认这些挑战并有策略地应对，组织可以有效利用 CSVSM 促进数字化转型，提升持续测试、质量、安全性和反馈机制。 这一方法不仅能简化流程，还能培养持续改进 和创新的文化。

生成式 AI 如何加速发现和基准测试

生成式 AI 可以显著 提高当前状态发现、基准测试差距评估和 CSVSM 创建的效率和质量，具体表现为以下几种 有影响力的方式：

• 自动化数据收集 和分析：

  • 效率：生成式 AI 可以自动化收集当前状态流程中使用的各种系统和工具的数据。 通过解析日志、项目管理工具和开发环境，AI 可以快速收集必要的信息，从而减少人工工作量 和时间。

  • 质量：AI 算法比人工方法更准确、一致地分析这些数据，识别出人类分析师可能无法察觉的模式、瓶颈和低效。

• 增强的价值流可视化：

  • 效率：AI 可以根据收集到的数据自动生成价值流的可视化表示。 这种自动化加速了 CSVSM 的创建，使团队可以将精力集中在分析和改进策略上，而不是手工绘制 地图。

  • 质量：生成式 AI 可以生成更详细和动态的可视化，将实时数据和分析直接集成到价值流图中。 这提供了对过程流、变化 和低效的更深入理解。

• 预测分析用于基准测试和 差距评估：

  • 效率：通过 机器学习模型，AI 可以根据当前流程预测结果，并将其与行业基准或期望的性能水平进行比较。 这加速了基准测试和差距评估阶段，通过提供关于差距存在位置及其 潜在影响的即时洞察。

  • 质量：AI 的预测能力使得能够更准确地预测改进的效果及其预期收益。 通过模拟价值流图中的变化，组织可以优先考虑那些提供最高投资回报的干预措施 。

• 自然语言处理（NLP）用于 增强发现：

  • 效率：自然语言处理（NLP）可以分析来自访谈、开放式调查反馈和文档中的定性数据，从中提取关于当前状态的洞察，这些洞察可能通过单纯的定量方法无法捕捉。 方法。

  • 质量：这种深度分析可以揭示潜在的问题、利益相关者的看法以及隐藏的改进机会，这对全面理解当前状态以及制定有针对性的 改进策略至关重要。

• 持续改进 反馈循环：

  • 效率：生成式人工智能可以促进基于 CSVSM 分析实施的过程变更的持续监控。 通过持续分析性能数据，人工智能可以实时建议对过程进行调整，确保价值流 保持优化。

  • 质量：这种持续优化有助于保持高质量标准，并迅速适应业务环境或 技术领域的变化。

• 协作与 利益相关者参与：

  • 效率：基于人工智能的平台可以通过提供一个集中式、互动的环境来增强团队成员之间的协作，用于分析和讨论价值流图。 这提高了利益相关者会议的效率和 决策过程。

  • 质量：改进的协作确保在分析过程中考虑到多元化的观点，从而制定出更加全面和有效的 改进 策略。

总之，生成式人工智能为自动化和增强当前状态发现、基准评估、差距评估以及 CSVSM 创建的过程提供了强大的工具。 通过利用人工智能的能力，组织可以实现对其当前状态的更准确、更详细、更高效的分析，从而在其 价值流中实现有针对性且有效的改进。

总结

在迈向持续测试、质量、安全性和反馈领域数字环境卓越的转型过程中，全面评估的关键作用不可过分强调。 本章将深入探讨访谈、调查、差距评估和价值流映射的细致方法论，作为发现和基准测试的基础工具。 通过富有互动性的访谈和精心设计的调查，组织可以捕捉到利益相关者的细致见解，这些利益相关者涵盖了从前线开发人员到高级管理层的各个层级。 这些工具不仅能揭示当前实践和流程的状态，还能促进包容性和开放沟通的文化，为 有针对性的改进铺平道路。

差距评估作为一个关键的分析工具，能够清晰地界定数字实践的当前状态与期望的未来状态。 通过系统地识别改进领域，组织可以优先考虑那些对质量、安全性和反馈机制产生最大影响的举措。 与此相辅相成，价值流映射提供了信息流和过程流的可视化表现，突显出阻碍进展的低效和瓶颈。 这种全面的方法确保在追求 数字卓越的过程中没有遗漏任何关键环节。

生成性人工智能的出现标志着在提升这些评估的效率和质量方面迈出了重要的一步。 通过自动化数据收集、分析，甚至生成价值流图，人工智能技术解放了宝贵的人力资源，使其能够专注于战略决策和实施。 此外，人工智能的预测分析能力为潜在的未来状态提供了前所未有的洞察，使得组织能够以更大的信心做出数据驱动的决策。 人类专业知识与人工智能计算能力的协同作用加速了数字化转型的步伐，确保组织在不断变化的 竞争格局中保持竞争力。

随着我们向前迈进，下一章将深入探讨支撑持续测试、质量、安全性和反馈的技术骨架。 我们将探索各种正在重塑 数字领域的技术框架和工具。

第七章：选择工具平台和工具

在软件开发的快速变化环境中，持续改进在测试、质量、安全性和反馈方面的强调从未如此重要。 本章作为一本全面指南，帮助您理解那些能够通过自动化和高效实践维持卓越的工具平台和工具。 本章解开了工具平台和工具的神秘面纱，深入探讨它们的核心定义、功能和它们在简化 软件工作流程中的关键作用。

本章为您提供了深入理解每个平台和工具如何被利用，以在不断变化的 技术挑战面前，培养持续改进和韧性文化的方式。

选择合适的工具平台和工具是一个至关重要的决策，它可能会显著影响开发过程和流程的效率和效果。 本章描述了一种方法论和工具，帮助您在选择工具平台和工具时做出明智的决策。 这种方法旨在引导您评估您的具体需求、不同选项的优缺点，并使您的选择与您的 战略目标相一致。

到本章结束时，您将全面理解软件开发中工具平台和工具的基本概念。 我们还将讨论用于持续测试、质量保证、安全性、 和反馈的各种工具平台和工具。

最后，我们将了解选择最适合您项目的平台和工具的战略方法，确保它们与您的目标对齐，并提升您的开发 生命周期。

本章按以下 标题组织：

• 工具平台和 工具概念

• 持续测试、质量、安全性、 和反馈的工具平台和工具

• 平台的来源 和工具

• 比较工具平台 和工具的因素

• 选择工具平台 和工具的方法

让我们 开始吧！

工具平台和工具概念

工具平台 和工具 是软件开发生态系统中密切相关但又各自独立的概念，它们通过协调、自动化和集成能力在简化和增强各个流程中发挥着至关重要的作用。 它们之间的关系如下： 。

工具平台

这些是 全面的、结构化的环境，为开发、测试、部署和管理软件应用程序提供了基础。 平台通过提供一套指导方针、编码标准、库和辅助工具，定义了构建和部署应用程序的标准化方式。 它们旨在通过减少重复操作、促进代码重用、并提供一套共同的实践和惯例来简化开发过程。 一个合法的工具平台应该支持与其他工具的集成能力。 平台不仅包括开发工具，还包括运行时环境、服务和 API，应用程序和其他工具可以使用它们。 一个平台可以承载其他工具，并提供数据服务、API、分析等，促进在统一环境中运行和管理工具应用程序。 。

让我们来看看 这些特性：

• 可扩展性：平台被设计为能够扩展并与各种应用程序和服务集成。 它们提供一组工具和服务，应用程序 可以利用。

• 生态系统：这通常包括一个市场或社区，第三方服务和集成可以添加到其中，以 增强功能。

• 灵活性：虽然 平台提供了许多工具和服务，但通常在应用程序的开发、部署 和管理上提供更多的灵活性。

工具

在软件开发的背景下，工具 是执行特定任务或功能的特定软件或应用程序。 这些工具可以是编译器、调试器和代码编辑器，也可以是用于版本控制、项目管理、持续集成和测试的更专业的工具。 工具通常被设计为集成到更大的开发工作流中，它们可以是独立的、是更大生态系统的一部分，或与 工具平台集成。

工具平台与工具之间的关系

图 7**.1 展示了工具平台、工具和 目标应用程序之间的关系。

图 7.1 – 工具平台、工具和应用程序之间的关系

工具平台、工具和应用程序之间的关系可以通过查看基础集成、标准化和效率的能力来解释，了解它们如何互补、如何增强彼此的功能，如 下文所述。

• 基础和集成: 工具平台 作为工具运行的基础或生态系统。 它们通常内置工具，或以允许无缝集成外部工具的方式设计。 例如，Web 开发平台可能包含内置的模板引擎和数据库迁移工具，但也允许集成外部的测试工具或 开发环境。

• 标准化与效率: 平台提供工具遵循的指南和标准，确保开发实践的一致性和效率。 当工具在这些平台中使用时，有助于自动化重复任务、提高生产力，并确保开发实践符合 平台设定的标准。

• 互补性: 工具 通过提供平台可能无法直接覆盖的特定功能来补充平台。 例如，虽然平台可能规定应用程序的结构并提供构建应用程序的基本组件，但版本控制系统、持续集成流水线和测试工具等工具，通过为团队协作、代码集成和 质量保证提供功能，补充了平台。

• 增强: 工具可以通过添加新功能、提升性能或使开发工作流程更加灵活高效，来增强平台的能力。 开发者通常选择那些与他们选择的平台兼容的工具，以确保顺利的 开发过程。

工具平台和工具是相互依赖的，平台为开发提供结构化环境和标准，而工具则提供在这些平台中高效执行开发任务所需的特定功能。 这种关系使得软件应用的开发更加高效、可维护 并且可扩展。

持续测试、质量、安全性和反馈的平台与工具

持续测试、质量、安全性和反馈的平台与工具，尽管在其主要关注点上有所不同，但它们相互关联，并且在实践中常常重叠。 以下部分将解释它们如何区分以及如何相互补充。

持续测试平台和工具

持续测试 的特点是专注于自动化测试，以验证软件是否满足每个测试用例的通过标准，在开发和交付过程中。 它是迭代的，并且集成到 开发管道中。

• 工具和工具平台：这包括覆盖所有类型测试的自动化测试工具，包括单元测试、集成测试、系统测试和 性能测试。

• 补充：它通过早期识别缺陷，确保新功能和变更不会引入回归问题。 通过将用户和利益相关者的反馈纳入测试中，持续反馈得以融入，以确保开发的内容与期望保持一致。

许多工具可以被归类为工具平台 和持续测试工具。 以下是一些示例：

• 工具平台：

  • Jenkins：尽管它通常被归类为 持续集成和持续部署 （CI/CD）工具，但由于其广泛的插件生态系统，Jenkins 也可以看作是一个持续测试平台，它能够与各种测试工具集成，使得自动化测试成为构建和 部署过程的一部分。

  • TestRail：此工具提供全面的测试用例管理，帮助组织、管理和追踪测试过程。 它与许多问题跟踪和 自动化工具集成，增强了 持续 测试的工作流程。

• 工具：

  • Selenium：一种自动化 测试工具 ，用于 Web 应用程序，可以集成到各种开发 环境和平台中进行 端到端自动化。

  • Postman：虽然主要是一个用于 API 测试的工具，Postman 可以集成到工具平台中进行自动化 API 测试，促进持续的 测试工作。

持续质量平台和工具

持续质量 的特点在于强调在所有流程中整合质量指标。 这不仅仅是发现缺陷，而是通过从一开始就纳入质量标准来预防缺陷。 从一开始就注重质量。

• 工具和平台：这些包括质量管理系统、代码质量指标工具，如 SonarQube，以及监控工具，能够跟踪质量指标 随着时间的推移。

• 补充工具：得益于提供即时反馈的持续测试工具，能够评估代码质量。 持续反馈机制是理解用户对质量期望的关键。 持续安全是质量的一个子集，因此确保安全的工具也对整体质量有所贡献。

许多工具可以被归类为持续质量的工具平台和工具。 以下是一些例子：

• 工具平台：

  • SonarQube：作为一个质量框架，它能够与开发 环境、CI/CD 流水线和版本控制系统集成，持续检查代码质量和 安全漏洞。

  • Codacy：一个 平台，通过静态代码分析自动 识别问题。 它与 GitHub、GitLab 和 Bitbucket 集成，支持协作和集成的代码质量 方法。

• 工具：

  • Coverity：一个 静态分析工具，能够识别软件漏洞和 质量问题，并可以 集成到 CI/CD 流水线中进行 持续分析。

  • ESLint：作为一个工具，它专注于 JavaScript 代码的 Lint 检查和修复问题，但 它可以集成到各种开发工作流中进行持续的代码 质量检查。

持续安全平台和工具

持续安全的特点在于它将安全性因素融入到开发的各个阶段。 它是主动的，旨在在 安全问题发生之前 预防它们。

• 工具和平台：这些包括 静态应用程序安全测试（SAST）， 动态应用程序安全测试（DAST），以及用于管理凭证 和秘密的工具，如 HashiCorp Vault。

• 补充：安全性是质量的一部分；因此，持续的安全工具对于持续的质量至关重要。 它们还受益于用于自动化安全测试的持续测试工具。 持续反馈可以为安全问题提供洞察， 来自用户 和利益相关者。

许多工具可以归类为持续安全的工具平台和工具。 以下是一些示例：

• 工具平台：

  • OWASP Zed Attack Proxy (ZAP)：它可以 集成到 CI/CD 流水线中进行 自动化 安全测试，使其成为更广泛 安全框架的一部分。

  • Metasploit Framework：除了 作为一个利用工具，它与各种渗透测试工具和环境集成，促进了全面的安全测试和 验证框架。

• 工具：

  • Nmap：虽然 Nmap 是一个用于网络探索和安全审计的工具，但它通常被集成到安全框架中，作为自动化网络扫描 和监控的一部分。

  • Burp Suite：主要是一个 用于 Web 应用程序安全测试的工具，它通过其 API 和集成提供扩展性，使其成为更大安全 评估框架的一部分。

持续反馈平台和工具

持续反馈 的特点在于它涉及收集并将利益相关者和用户的反馈纳入开发周期中，以不断改进 产品。

• 工具和平台：这些包括用户反馈平台、功能标记工具，如 LaunchDarkly，以及 可以提供有关用户如何与 应用程序互动的监控工具。

• 补充工具：反馈可以通过突出需要额外覆盖的领域，推动持续测试的改进。 它通过强调用户最关心的内容，直接支持持续质量改进。 对于持续的安全性，用户反馈可能揭示出感知的或实际的安全问题，从而 得到解决。

许多工具可以被分类为工具平台和用于持续反馈的工具。 以下是一些示例：

• 工具平台：

  • Salesforce Service Cloud：除了作为一个 流行的 客户关系管理（CRM） 工具外，它还提供一个 平台，整合了各种 反馈和支持工具，使得 能够全面管理客户反馈 跨渠道的互动。

  • Zendesk：提供一个 客户服务和互动平台， 它与多个反馈、支持和分析工具集成，创建了一个统一的系统来收集并响应 客户见解。

• 工具：

  • Typeform：一个 创建互动式调查和表单的工具，可以集成到网站或平台中进行直接 反馈收集。

  • Hotjar：提供通过热力图、会话录制和 调查收集反馈的工具。 虽然主要是一个工具，但它支持集成，使其能够融入更广泛的反馈和 分析框架。

重叠与集成

许多工具服务于多重目的。 例如，一个综合性的持续测试工具可能包括安全测试功能，从而也能满足持续 安全需求。

类似地，支持持续反馈的项目管理工具可能会集成质量和 测试仪表板。

像 GitLab 或 Jenkins 这样的 DevOps 平台可以协调一个包含持续测试、质量、安全和 收集反馈的管道。

总之，虽然工具和平台可以根据其主要功能进行分类，但最有效的开发和交付管道将整合这些类别，认识到它们不是孤立的，而是一个紧密结合的整体。 目标是开发不仅功能完善，而且高质量、安全，并与用户需求 和期望高度一致的软件。

平台和工具的来源

选择平台和工具时，最关键的决策之一是决定每个平台和工具的来源。 图 7**.2 显示了开源工具、供应商产品工具与 自制 (DIY) 工具在持续测试、质量、安全 和反馈方面的优缺点。

图 7.2 – 工具平台和工具的来源

让我们详细探讨一下这些工具。

开源工具

在接下来的 段落中，我们将探讨用于持续测试、质量、安全 和反馈的开源工具。

开源持续测试工具

开源持续测试 工具使团队能够无缝地将测试集成到软件开发和部署过程中，而不受专有软件的成本限制。 这些工具可以在开发的每个阶段进行自动化测试，确保尽早发现错误并及时解决，以维护 软件质量。

示例：Selenium 是一款广泛使用的开源工具，用于自动化 web 浏览器，允许开发者编写测试用例，模拟用户在各种浏览器 和平台上的交互。

开源质量工具

开源 质量工具为保持软件开发中的高标准提供了一种具有成本效益的解决方案。 它们允许进行静态代码分析、监控代码复杂性和遵循编码标准，帮助保持干净高效的 代码库。

示例：SonarQube 是一个开源平台，持续检查代码质量，使用静态分析自动审查代码并检测 bug、代码异味和安全漏洞。

开源安全工具

开源安全工具提供了诸如渗透测试和漏洞扫描等基本的安全功能，无需付费，从而帮助组织有效地增强其应用程序的安全态势。

示例：OWASP ZAP 是一个领先的开源安全工具，由网络安全领域最具声誉的组织之一 OWASP 开发，旨在在开发和测试阶段找出 web 应用中的安全漏洞。

开源反馈工具

开源反馈工具帮助组织高效地收集和管理用户或利益相关者的反馈，促进产品开发中的持续改进。这些工具能够融入开发工作流，使团队能够直接收集并回应用户的见解和期望。

示例：MantisBT 是一个开源问题跟踪器，提供一个简单却强大的平台来跟踪用户反馈和问题，帮助组织根据真实的用户体验改进和增强产品。

开源工具的优势

• 成本效益：开源工具通常是免费的，可以显著降低成本。

• 社区支持：通常有一个庞大的社区提供支持和开发，这有助于排除故障并改进工具。

• 灵活性与定制化：开源允许根据特定需求进行定制。

• 透明性：开源性质意味着你可以检查和修改代码，这对安全审计非常有利。

开源工具的缺点

• 支持与维护：缺乏正式的支持可能是一个挑战，通常需要依赖社区支持，但社区支持的质量可能不稳定。

• 学习曲线：这些工具可能有较陡的学习曲线，特别是对于那些不熟悉相关技术的团队。

• 集成：与现有系统的集成可能需要更多的努力，特别是当这些系统 是专有时。

• 可靠性：一些开源项目可能没有商业产品那样可靠的维护。

供应商产品工具

供应商产品工具 用于持续测试，提供支持自动化测试的先进集成解决方案，贯穿软件开发和部署过程。 这些商业工具通常提供增强的支持、可扩展性和量身定制的附加功能，满足企业需求，确保全面的测试和 质量保证。

示例：TestComplete 是一个商业化的自动化测试平台，使团队能够创建、管理并运行跨桌面、网页和移动应用程序的测试。 TestComplete 提供丰富的功能集，包括 GUI 测试、脚本或无脚本的测试创建，以及与 DevOps 流水线中其他工具的集成。

质量产品工具

商业质量工具 提供稳健的解决方案，用于维持软件代码质量的高标准。 这些工具通常提供全面的分析、与开发环境的广泛集成和专业支持，帮助团队遵循最佳实践并改善 代码健康。

示例：Coverity 是 一款静态代码分析工具，帮助开发人员通过在问题进入生产环境之前检测并解决代码库中的缺陷和漏洞，从而编写更安全、更可靠的代码。 生产环境。

安全产品工具

供应商产品安全工具 提供复杂的安全解决方案，包括自动化威胁检测、实时保护和事件响应能力等高级功能。 这些工具由专业支持和持续更新提供支持，以应对不断变化的 安全威胁。

示例：Veracode 是一个可扩展的、基于政策的应用程序安全平台，提供自动化的基于云的服务，用于在软件 开发生命周期中保护网页、移动和第三方企业应用程序。

反馈产品工具

商业反馈工具旨在高效地捕捉和管理来自多个渠道的用户反馈。 这些工具通常提供全面的分析功能，能够与 CRM 系统集成，并提供与用户直接互动的工具，从而增强根据用户反馈推动 产品开发的能力。

示例: UserVoice 是一款产品反馈管理软件，帮助企业收集和分析客户反馈，优先考虑功能需求，以更好地使产品开发与 用户需求对接。

供应商产品工具的优点

• 专业支持: 这些 工具通常提供专业支持 和培训。

• 可靠性: 供应商有商业利益来维护和更新 他们的产品。

• 易用性: 它们通常设计得非常注重用户友好性，通常提供更顺畅的 入职流程。

• 集成性: 它们可能提供更好的与其他工具和服务的集成，特别是在 同一生态系统内。

供应商产品工具的缺点

• 成本: 这些工具可能非常昂贵，特别是持续的 许可费用。

• 厂商锁定: 可能会存在厂商锁定的风险，使得切换到其他工具 或厂商变得困难。

• 定制化程度较低: 它们的定制化程度可能不如 开源选项。

• 不透明性: 闭源的性质意味着你不能检查或修改代码，这可能对 对安全要求较高的环境构成隐患。

自助开发或自制工具

自助开发或 自制工具，如果组织没有预算购买供应商产品工具，又不想使用 开源工具，可能是一个有吸引力的选择。

自制的持续测试工具

自制的持续 测试工具是根据特定项目或组织需求定制开发的解决方案。 这些自制工具允许团队将独特的测试流程和自动化框架直接集成到他们的开发环境中，从而完全控制测试功能和 集成能力。

示例：自定义自动化框架是一个使用开源库（如 Selenium 或 Appium）构建的定制化测试框架，经过修改和扩展，结合自定义脚本和插件，以满足组织软件项目的特定测试需求。

DIY 质量工具

DIY 质量 工具是在内部开发的，用于维护符合组织开发实践的代码标准和质量。 这些工具可以专门设计，与现有工作流程集成，提供针对代码质量的深入见解和分析。

示例：内部代码审查工具是一个内部开发的工具，能够与版本控制系统集成，自动化代码审查和质量检查，专门用于执行组织的编码标准 和实践。

DIY 安全工具

自建 安全工具是为了满足特定的安全需求而构建，并能与组织现有的 IT 基础设施无缝集成。 这些工具可以进行定制，提供专业的安全监控、威胁检测和事件响应，专门针对公司独特的环境和安全政策进行调整。

示例：自定义安全仪表板是一个自主开发的综合仪表板，能够汇总组织内部来自各个来源的安全警报、日志和数据，并配备自定义算法，根据 历史数据 检测异常和潜在威胁。

DIY 反馈工具

DIY 反馈工具 允许组织在其产品生态系统内直接创建定制化的用户反馈收集和管理系统。 这些工具可以根据需要进行定制，以捕获特定类型的用户输入，并与产品功能深度集成，从而提供 可操作的见解。

示例：内部反馈门户是一个定制化开发的内部门户，旨在收集产品互动各个阶段的用户反馈，并与组织的产品管理和问题跟踪系统集成，以促进直接的用户参与和更快的 响应时间。

DIY 工具的优势

• 完全定制化：这一点 可以完全根据组织的特定需求进行定制。

• 控制：对开发、部署和 维护过程拥有完全控制权。

• 集成性：可以设计为与现有基础设施无缝集成。

DIY 工具的缺点

• 资源密集型：开发和维护定制工具需要大量的时间和专业知识。

• 支持：没有外部支持；组织负责解决任何问题。

• 可持续性：随着技术发展和内部资源变化，可能无法在长期内持续。

• 风险：如果内部团队缺乏必要的专业知识，则风险较高。

每种类型的工具都有其适用的地方，这取决于组织的需求、资源和目标。企业通常会使用这些工具的组合，以平衡每种工具的优缺点。对于持续的测试、质量、安全性和反馈，正确的选择将取决于定制化的重要性、可用预算、对支持的需求以及对工具和流程的控制程度。

比较工具平台和工具的因素

以下是选择工具平台和工具进行持续测试、质量、安全性和反馈时需要考虑的因素：

• 兼容性和集成性：工具应能够轻松与现有工作流程、正在使用的其他工具以及整体 IT 基础设施集成。无缝集成有助于自动化管道并减少摩擦。

• 范围和覆盖面：确定工具或平台提供的测试、质量、安全性和反馈的范围。覆盖面越广，随着项目的演变，它更有可能满足各种需求。

• 可用性和学习曲线：考虑工具的易用性以及培训员工所需的时间。易于使用且易于学习的工具可以更快地被采纳。

• 自动化能力：对于持续的流程，自动化是关键。评估工具在自动化重复任务和集成到 CI/CD 管道中的能力。

• 报告与分析：生成有洞察力的报告和分析的能力对于持续改进至关重要。 工具应提供全面的报告功能，用于跟踪进展并做出 数据驱动的决策。

• 社区与支持：考虑开源工具周围的社区或供应商提供的支持。 强大的社区或良好的支持对解决问题和 最佳实践非常宝贵。

• 成本：评估总体拥有成本，而不仅仅是初始价格。 这包括许可费用、维护、支持和供应商产品的培训成本，以及 自主研发解决方案的开发和维护成本。

• 性能与可扩展性：所选择的工具应能在预期的负载下良好运行，并且 具备可扩展性，以满足不断增长的需求 ，而不会导致成本 或复杂性的显著增加。

• 安全性与合规性：确保工具或平台不会引入安全漏洞，并且符合相关行业标准 和法规。

• 灵活性与可定制性：能够根据特定项目需求定制工具是一个重要优势，尤其适用于 复杂项目。

• 供应商稳定性与路线图：选择供应商工具时，要考虑供应商的稳定性、声誉以及产品路线图，确保它能够继续满足你未来的需求。

• 更新频率与维护：了解工具的更新频率。 频繁的更新可能表明活跃的开发状态，但也要考虑跟进 这些更新所需的努力。

• 反馈机制：对于专注于反馈的工具，评估它们如何收集、分析和管理反馈。 该工具应能够提供可操作的洞察，以改善 开发过程。

• 云原生：这指的是工具是否为云环境设计并能原生集成，这对可扩展性、韧性和 远程访问性非常重要。

• 可扩展架构：具有可扩展或插件架构的工具可以更容易地根据特定需求进行定制，支持与其他工具的集成，并能随着 需求变化而演变。

• 可用的未来发展路线图：了解工具的未来发展路线图可以为工具的长期使用和未来能力提供洞察，并与长期 战略目标相一致。

• 可用的 API：拥有一个强大且文档完善的 API 对于自动化、与其他工具的集成以及自定义 开发工作至关重要。

图 7**.3 提供了一个比较表，方便对比不同的替代平台 和工具。

图 7.3 – 平台和工具的比较

请记住，这些因素的重要性会根据你组织的具体背景和需求有所不同。 在做出最终决定之前，试用工具通常是有益的，以确保它符合你的期望 和要求。

示例工具平台和工具

图 7.4, 7.5, 和 7.6 提供了一个分类和示例工具平台及工具的列表 ，这些可以用于持续测试、质量、安全和反馈的应用。 有许多分类和示例可以 选择。

下图列出了以字母 A 到 C 开头的工具。

图 7.4 – 示例工具平台和工具（A-C）

下图 列出了以字母 D 到 P 开头的工具。

图 7.5 – 示例工具平台和工具（D-P）

下图 列出了以字母 Q 到 Z 开头的工具。

图 7.6 – 示例工具平台和工具（Q-Z）

本节 解释了在选择用于持续测试、质量、安全和反馈的工具平台和工具时需要考虑的重要因素。 它提供了一个有用的比较表，用于比较替代平台和工具，并对持续测试、质量、安全和反馈的应用进行了分类。 下一节将描述选择工具平台 和工具的方法论。

选择工具平台和工具的方法论

图 7**.7 展示了 基于行业最佳实践的普遍推荐方法，用于选择持续测试、质量、安全 和反馈的工具。 。

图 7.7 – 工具平台和工具选择方法论

以下是每个步骤的 选择过程中的 活动 ：

1. 定义你的需求：首先了解你组织的具体需求。 这包括运营规模、项目复杂性、团队技能以及你希望通过持续测试、质量、安全 和反馈实现的具体目标。

2. 市场调研：进行调研，识别市场上满足你需求的工具。 这应包括开源和商业选项。 图 7**.2 展示了选择源选项时需要考虑的因素。

3. 功能比较：根据你的需求比较不同工具的功能。 特别注意云原生能力、可扩展架构、未来可用路线图以及可用的 API 等方面。 图 7**.3 展示了一个比较图的示例，可以用来组织 比较内容。

4. 社区与支持：评估开源工具的社区支持和商业产品的客户服务。 强大的社区或良好的客户支持对解决可能出现的问题至关重要。

5. 成本分析：考虑总拥有成本，包括供应商产品的许可费用、开源工具的运营成本，以及自制解决方案的开发和维护成本。 自制解决方案。

6. 安全性和合规性：确保工具符合您的组织所需遵守的相关安全性和数据保护法规。 法规。

7. 概念验证：对入围工具实施概念验证，看看它们在您的环境中的表现。 这还将帮助评估学习曲线及与现有系统的集成难易程度。

8. 供应商评估：如果 考虑使用供应商工具，评估供应商的稳定性、声誉，以及他们 产品路线图的稳健性。

9. 性能和可扩展性：确保工具在预期负载下表现良好，并能够根据您的 业务需求进行扩展。

10. 集成能力：工具应能够与您现有的 CI/CD 管道以及 其他工具无缝集成。

11. 反馈循环：工具应促进快速的反馈循环。 专注于反馈的工具应允许轻松收集、分析和实施用户及 利益相关者的反馈。

12. 文档和学习资源：确保提供全面的文档和学习资源，使您的团队能够快速 上手。

13. 最终选择：使用评分系统评估每个工具如何与您的标准对比。 让关键利益相关者参与最终决策，以 确保获得支持。

14. 迭代评估：工具 应定期评估 以确保它们在组织发展和演变的过程中继续满足需求。 需求。

请记住，工具的选择是一个战略决策，可能会对您组织高效、安全地交付高质量软件的能力产生长期影响。 因此，投入必要的时间和资源来做出 明智的决策至关重要。

确定足够工具的数量

选择正确的 连续测试、质量、安全和反馈工具平台及工具数量，在企业内部受到多个关键因素的影响。 目标是在不引起工具泛滥或不必要复杂性的情况下，实现全面覆盖和集成能力的平衡。 通常确定足够工具的因素如下：

• 项目范围：企业承担的项目的规模、数量和复杂性决定了所需工具的范围。 更大规模且架构更复杂的项目可能需要针对不同测试和安全层面的专门工具。

• 技术栈：企业应用中使用的技术栈的多样性可能需要不同的工具。 每个层面（前端、后端、数据库等）和技术（语言、框架）可能都需要专门的工具来进行最佳测试和安全性保障。

• 集成能力：工具应与现有的工作流程、CI/CD 流水线和其他工具无缝集成。 所需的集成程度可以限制或扩展有效利用的工具数量，而不会导致信息孤岛或集成困难。

• 合规性和法规要求：根据行业不同，企业可能需要遵守特定的法规标准（例如 GDPR、HIPAA、PCI-DSS），这些法规要求特定的安全、质量和反馈机制，从而影响工具的选择和数量。

• 团队技能：开发、质量保证和安全团队在某些工具或类型的工具上的专业知识和经验可能会影响选择。 选择团队能够有效使用和管理的工具至关重要。

• 预算限制：工具的成本，包括许可证、培训和维护，发挥了重要作用。 关键在于找到在可用预算范围内提供所需功能的工具组合。

• 整体战略和目标：企业关于市场速度、质量基准、安全姿态和客户满意度目标的战略将极大地影响工具需求的全面性。

• 反馈和持续改进：工具在提供可操作反馈和支持持续改进方面的有效性至关重要。 那些 能够提供全面洞察且不会让团队感到压倒性的工具 更受欢迎。

平衡之道

适当数量的工具 能够全面覆盖测试、质量、安全性和反馈，而不会产生功能重叠，从而浪费资源或造成混乱。 关键在于实现平衡，使每个工具都能提供独特的价值，能够与其他工具良好集成，并支持企业的整体目标，而不会形成笨重的工具链，从而拖慢流程或 复杂化工作流。

定期评估工具链的有效性，并根据项目的发展、技术的变化以及企业的成长进行调整，是维持 这一平衡的关键。

总结

本章概述了工具平台和工具在通过持续的测试、质量、安全性和反馈来增强软件开发中的重要性。 它详细阐述了这些工具和平台在自动化、集成和简化开发流程中所发挥的独特而又互相关联的作用。 选择的关键在于了解每个工具的功能和集成能力，并将其与战略目标对齐。 本章还详细介绍了选择合适工具的方法论，强调了兼容性、自动化和成本等因素，确保它们能够补充开发生命周期并支持 持续改进。

在下一章中，我将探讨 人工智能/机器学习 (AI/ML) 在持续测试、质量、安全性 和反馈中的应用。

第八章：将 AI/ML 应用于持续测试、质量、安全和反馈

本章深入探讨了 人工智能 (AI) 和 机器学习 (ML) 在软件开发生命周期中的变革性作用，特别关注 如何提升持续测试、质量、安全和 反馈实践。

本章开始时概述了 AI/ML 的应用。 它解释了这些技术如何重新塑造持续测试、质量、安全和反馈的领域。 每个部分深入探讨了旨在自动化和优化流程的 AI/ML 策略，从早期的代码测试到部署后的监控。 这些都是为了促进无缝、持续集成和交付管道的实现，借助 AI 驱动的工具链。

本章为选择能在您的持续测试、质量、安全和反馈转型项目中有效整合的 AI/ML 工具提供了方法论。 的建议。

通过本章的学习，您将全面了解适用于持续测试、质量、安全和反馈的 AI/ML 工具。 您还将学会一种系统的方法来选择 AI/ML 工具。

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

• AI/ML 应用

• 用于 持续测试的 AI/ML

• 用于 持续质量的 AI/ML

• 用于 持续安全的 AI/ML

• 用于 持续反馈的 AI/ML

• 选择 AI/ML 工具的方法

让我们 开始吧！

AI/ML 应用

在快速发展的 软件开发和运维领域，AI 和 ML 正在改变组织如何看待持续测试、质量、安全、 以及反馈。

如 图 8**.1所示，这些技术已经成为帮助组织应对数字化转型复杂性的重要工具，尤其是在 DevOps、DevSecOps 和 SRE 等框架下。 通过利用 AI/ML 的力量，企业不仅加速了开发周期，还以前所未有的方式增强了其应用的稳健性和安全性。 。

图 8.1 – AI/ML 在持续测试、质量、安全性和反馈中的应用

近年来，AI/ML 技术取得了显著进展，达到了能够有效 集成到持续集成/持续部署 （CI/CD） 流水线的复杂程度，在这些流水线中，速度和效率的需求必须与质量和安全的要求相平衡。 AI/ML 通过自动化复杂任务、预测潜在问题并提供可操作的见解，从而减少人工工作，促进了人力资源的更战略性使用。 人力资源。

AI/ML 的应用 包括从数据中学习、适应新信息并随着时间推移不断改进的能力。 这一能力在识别模式、预见潜在漏洞和优化测试策略方面具有无价的价值。 在质量保证中，AI 驱动的工具可以预测最可能出现故障的区域，并相应地定制测试工作。 在安全性方面，ML 算法可以检测到表明潜在威胁的异常情况，而在操作中，AI 可以增强反馈机制，进而使系统更加稳健和 响应迅速。

本章后续部分将深入探讨 AI/ML 在持续测试、质量、安全性和反馈领域中的具体应用案例。 这些例子将展示 AI/ML 如何不仅简化流程，还提升软件开发和维护的标准。 本章提供了 AI/ML 对致力于卓越的数字化转型组织的变革潜力的全面概述。 转型之旅。

AI/ML 在持续测试中的应用

将 AI 和 ML 集成到 软件的持续测试活动中，可以显著简化流程，解决每个活动中可能出现的瓶颈，正如在 图 8**.2中所示。

图 8.2 – AI/ML 在持续测试活动中的应用

以下是这些技术在各种 测试活动中的应用：

1. 需求分析：

   • 解释：确保 测试场景与业务需求以及 用户需求一致。

   • 瓶颈: 错误的解读或不完整的分析可能导致不足的 测试覆盖率。

   • AI/ML 解决方案: NLP 可以自动提取和解释需求，确保全面且准确的 测试覆盖率。

2. 测试策略:

   • 解释: 概述 测试方法、目标 和资源。

   • 瓶颈: 不清晰的策略可能导致测试工作效率低下和 资源分配不当。

   • AI/ML 解决方案: AI 可以分析历史数据，建议最有效的测试策略，并预测 资源需求。

3. 测试 计划:

   • 解释: 指导测试过程、时间表 和责任的详细文档。

   • 瓶颈: 不灵活的计划可能难以适应项目变化， 导致延迟。

   • AI/ML 解决方案: ML 算法可以根据项目的持续发展和 过去的结果建议调整测试计划。

4. 测试用例:

   • 解释: 执行测试的 特定条件。

   • 瓶颈: 开发耗时且维护 测试用例的工作量巨大。

   • AI/ML 解决方案: AI 可以从需求 文档中自动生成测试用例，提高效率 和覆盖率。

5. 测试脚本:

   • 解释: 自动化 脚本执行 测试用例。

   • 瓶颈: 脚本开发和维护可能 消耗大量资源。

   • AI/ML 解决方案: AI 可以根据应用或测试用例的变化生成并更新测试脚本，减少 维护工作量。

6. 测试数据:

   • 解释: 测试中使用的数据集，用于模拟 现实世界场景。

   • 瓶颈: 创建、管理和维护准确的测试数据 是一个挑战。

   • AI/ML 解决方案: AI 可以自动生成和管理测试数据，确保其相关性 和多样性。

7. 测试环境:

   • 解释: 测试进行的设置，尽可能地模拟生产环境。

   • 瓶颈: 测试环境的配置和维护 非常复杂。

   • AI/ML 解决方案: AI 可以根据测试需求预测并配置最优的测试环境，减少 设置时间。

8. 与 依赖系统的协调:

   • 解释: 确保被测试系统与数据库和 其他应用程序正确交互。

   • 瓶颈: 依赖管理可能会 导致延迟。

   • AI/ML 解决方案: AI 可以自动检测并解决集成问题，提升 协调效率。

9. 测试 活动设置:

   • 解释: 组织并安排一系列 测试执行。

   • 瓶颈: 需要精心规划，并可能受限于 资源限制。

   • AI/ML 解决方案: AI 可以根据风险和 影响分析帮助安排和优先考虑测试活动。

10. 测试执行:

    • 解释: 运行测试用例和脚本的过程，包括自动化 和手动。

    • 瓶颈: 耗时较长，尤其是对于 手动测试。

    • AI/ML 解决方案: AI 可以优先执行测试并识别不稳定的测试，简化 过程。

11. 测试判定报告 :

    • 解释: 确定并报告 测试执行的结果。

    • 瓶颈: 手动判定结果可能 很慢。

    • AI/ML 解决方案: AI 可以自动解读测试结果，加速 报告。

12. 数据日志记录 :

    • 解释: 记录与测试相关的数据，以便 进一步分析。

    • 瓶颈: 广泛的数据收集可能会 压垮资源。

    • AI/ML 解决方案：AI 可以智能地过滤并记录相关数据， 减少噪声。

13. 测试 结果分析：

    • 解释：分析 测试结果以识别缺陷 和问题。

    • 瓶颈：需要大量时间 和专业知识。

    • AI/ML 解决方案：ML 算法可以快速识别测试结果中的模式和异常，突出 潜在问题。

14. 测试 结果报告：

    • 解释：向利益相关者 传达发现 的结果。

    • 瓶颈：编写报告 非常耗时。

    • AI/ML 解决方案：由 AI 驱动的自动化报告工具可以快速生成有洞察力和全面的 报告。

15. 等待资源修复 失败的测试：

    • 解释：等待修复 已识别问题时的停机时间。

    • 瓶颈： 阻碍 测试进展。

    • AI/ML 解决方案： AI 可以 预测可能失败的领域，并提出 潜在的修复方案。

将 AI/ML 应用于软件测试活动 带来了许多优势，但也引入了一些挑战，正如 图 8**.3所示。解决这些问题需要技术解决方案、流程调整和 文化变革的结合。

图 8.3 – AI/ML 持续测试挑战

在这里，我们讨论一些 常见问题及其克服策略：

• 缺乏对正在测试应用程序的直观理解 ：

  • 问题：AI/ML 模型可能无法完全理解应用程序的上下文或其功能的细微差别，从而导致测试场景的有效性降低。

  • 解决方案：通过更丰富的上下文数据增强 AI 模型，并引入反馈循环，允许测试人员细化和调整 AI 生成的测试用例。 采用强化学习等技术还可以帮助 AI 模型随着时间推移更好地理解应用程序的上下文。

• 测试会话之间的 重复性和一致性：

  • 问题：AI 驱动的测试可能会为相同的输入在不同的会话中生成不同的输出，从而使测试一致性 和可追溯性变得复杂。

  • 解决方案：为 AI 模型及其训练数据实施版本控制，确保测试会话的一致性。 采用确定性方法与 AI 结合，保持核心稳定、 可重复的测试。

• 对 生成的测试的理解缺乏：

  • 问题：测试人员可能会发现理解或信任 AI 生成的测试用例的合理性具有挑战性，这会影响他们有效评估测试 结果的能力。

  • 解决方案：将可解释性功能纳入 AI/ML 模型，以提供对其决策过程的洞察。 通过教育和透明度培养信任和理解文化，说明 AI 模型的操作方式。

• 测试覆盖率：

  • 问题：AI/ML 可能无法充分覆盖所有测试场景，可能漏掉 关键缺陷。

  • 解决方案：将 AI/ML 与传统的测试方法相结合，以确保全面覆盖。 定期审查并调整 AI/ML 模型生成测试用例时使用的标准，确保它们与不断变化的应用功能 和风险保持一致。

• 与不同 测试工具的兼容性**：

  • 问题：AI/ML 模型可能无法与现有的测试工具和框架无缝集成，从而限制其 实用性。

  • 解决方案：开发或使用具有广泛 API 支持和集成功能的 AI/ML 解决方案。 与工具供应商合作或贡献开源项目，以 提高兼容性。

• 团队的接受度 ：：

  • 问题：测试人员 和开发人员可能会对 AI 驱动的测试持怀疑或抵触态度，担心职位替代或不信任 AI 的有效性。

  • 解决方案：教育 并让团队参与 AI/ML 测试策略的开发和实施。 展示 AI/ML 在增强他们角色而非取代它们方面的价值，重点将 AI 作为应对日常任务的工具，让团队能够专注于更复杂且 更有成就感的工作。

• 数据质量 和可用性：

  • 问题：AI/ML 模型需要大量高质量数据进行训练。 不充分或低质量的数据可能导致 无效的测试。

  • 解决方案：投资于数据策划和生成策略，例如合成数据创建，确保模型得到 良好的训练。

• 持续学习 和适应性：

  • 问题：随着应用的不断发展，AI/ML 模型可能会变得过时。

  • 解决方案：建立持续学习机制，使模型定期通过新数据和反馈进行更新，确保它们始终保持相关性 和有效性。

• 伦理与 偏见考量：

  • 问题：AI/ML 测试模型可能会继承或放大其训练数据中的偏见，导致不公平或 歧视性结果。

  • 解决方案：实施 伦理准则和偏见检测方法，用于 AI/ML 模型的开发和使用。 定期审计模型以发现偏见，并根据需要进行修正。

通过这些深思熟虑的策略来应对挑战，组织可以最大限度地发挥 AI/ML 在测试活动中的优势，同时减轻潜在的负面影响，从而实现更高效、更有效和更值得信赖的 测试流程。

AI/ML 辅助的持续测试在实际应用中的案例

一个实际应用案例是 在使用如 Applitools这样的工具时，该工具利用视觉 AI 来自动化并简化多个网页和移动应用程序中 用户界面 (UI)的验证工作。 这种 AI 驱动的方法使团队能够通过将当前版本的应用 UI 与先前捕获并验证为正确的基准图像进行比较，来检测不一致或视觉回归 问题。

这种方法通过自动检测布局问题、颜色不匹配或 UI 元素的意外变化等视觉问题，极大地减少了手动测试所需的时间和精力。 AI 组件随着时间推移会适应 UI 的变化，从而保持其有效性，即使应用程序发生变化。 通过将此类工具集成到开发管道中，组织可以确保更准确、高效和可扩展的测试过程，最终实现更快速的部署周期和更高质量的 软件产品。

AI/ML 用于持续质量

在开发、交付和生产生命周期中实施持续质量涉及若干活动，旨在确保稳定的发布并提升用户满意度，如 图 8**.4所示。

图 8.4 – 用于持续质量活动的 AI/ML

以下是此方法所需的活动列表，列出了潜在的瓶颈以及 AI/ML 如何解决 这些挑战：

1. 质量 指标集成：

   • 描述：将 质量指标嵌入到软件开发生命周期的每个阶段，以持续监控和改进 质量。

   • 瓶颈：手动收集和分析质量指标可能会耗时且容易出错，可能会拖慢 开发过程。

   • AI/ML 应用：AI 可以自动化从各种工具和平台中提取、监控和分析质量指标，提供实时洞察和预测，以防止 质量问题。

2. 自动化 代码审查：

   • 描述：利用 工具自动审查代码中的潜在问题、遵循编码标准和安全漏洞，代码一旦 提交，就会立即进行检查。

   • 瓶颈：自动化代码审查工具中的高误报率可能会导致开发人员疲劳，并减缓 审查过程。

   • AI/ML 应用：机器学习模型可以从历史代码审查数据中学习，以减少误报并突出最相关的问题，从而简化 审查过程。

3. 持续测试：

   • 描述：在 CI/CD 流水线中运行自动化测试，以尽早识别缺陷 尽可能早。

   • 瓶颈：创建和维护覆盖应用各个方面的综合测试套件可能会消耗大量资源，并可能导致发布速度变慢。

   • AI/ML 应用：AI 可以根据代码库的变化和用户行为生成测试用例，确保相关且高效的 测试覆盖。

4. 实时用户 反馈分析：

   • 描述：实时收集和分析来自多个渠道的用户反馈，以识别问题和改进领域。

   • 瓶颈：手动分析来自多个来源的用户反馈可能会不堪重负，并延迟识别 关键问题。

   • AI/ML 应用：NLP 和情感分析算法可以自动对用户反馈进行分类和优先级排序，从而加快对关键问题 和趋势的响应。

5. 预测漏洞与 问题检测：

   • 描述：基于历史数据和代码变更模式预测潜在的漏洞和问题。

   • 瓶颈：在没有历史背景的情况下识别潜在问题可能是具有挑战性的，可能导致问题在发布后未被注意到 直到发布后。

   • AI/ML 应用：ML 模型可以分析代码变更、提交历史和问题跟踪器，预测最可能引入缺陷的代码区域，从而采取 预防措施。

6. 部署 风险评估：

   • 描述：根据质量指标、测试结果和历史 部署数据评估新发布的风险。

   • 瓶颈：手动风险评估可能具有主观性和不一致性，可能导致不必要的延迟或 被忽视的问题。

   • AI/ML 应用：AI 算法可以通过分析大量数据集提供客观的风险评估，帮助团队做出明智的决策 关于发布。

7. 生产监控与 异常检测：

   • 描述：监控生产环境中的意外行为、性能问题和 安全威胁。

   • 瓶颈：筛选大量监控数据以识别异常可能会延迟问题的检测和解决 。

   • AI/ML 应用：机器学习模型可以持续分析监控数据，实时检测异常，减少检测时间并提高 响应 效率。

通过将这些活动整合到开发、交付和生产生命周期中，组织可以显著增强其持续质量策略。 AI/ML 应用在克服与这些活动相关的瓶颈方面起着至关重要的作用，使发布更加稳定，并提高 用户满意度。

将 AI/ML 应用于 持续质量活动带来了显著的优势，但也带来了可能妨碍其有效性的挑战，正如在 图 8**.5中所示。

图 8.5 – AI/ML 在持续质量中的挑战

识别这些问题对于制定应对策略至关重要。 以下是将 AI/ML 融入持续质量工作中的一些常见问题，以及 建议的解决方案：

• 缺乏对 客户心态的直观理解：

  • 问题：AI/ML 模型可能无法自然地理解客户期望的细微差异或用户与应用程序的交互方式，这可能导致质量改进不一致。

  • 策略：为了弥合这一差距，将 AI/ML 洞察与直接的客户反馈机制和用户行为分析相结合。 利用自然语言处理（NLP）分析客户评论和反馈，可以提供有助于模型训练和调整的定性见解，使 AI 驱动的质量改进与 用户期望保持一致。

• 关于 客户环境的不确定性：

  • 问题：AI/ML 模型可能难以预测和测试各种用户环境（设备、操作系统和网络条件），可能会忽略关键的 质量问题。

  • 策略: 实施合成数据生成和仿真技术可以帮助创建多样化的场景，模拟各种客户环境。 结合真实世界的使用数据，可以训练 AI/ML 模型更好地预测并解决特定环境中的 质量问题。

• 数据隐私和 安全问题:

  • 问题: 收集和使用 AI/ML 的数据，尤其是用户反馈和行为数据，引发了关于隐私和 数据安全的担忧。

  • 策略: 使用隐私保护的数据分析技术，如差分隐私和联邦学习，训练模型而不泄露用户个人数据。 通过采用数据治理框架，确保符合数据保护法规，优先考虑用户同意和 数据最小化。

• 模型偏差 与公平性:

  • 问题: AI/ML 模型可能会无意中 学习到训练数据中的偏差，从而导致质量改进中的不公平或歧视性结果。

  • 策略: 定期审查 AI/ML 模型的偏差，并实施公平意识的机器学习实践。 这包括多样化训练数据、应用去偏差技术，并设定公平性标准来评估 模型输出。

• 适应性 对快速变化的响应:

  • 问题: 基于历史数据训练的 AI/ML 模型可能无法迅速适应用户行为、市场趋势或新特性引入的快速变化。

  • 策略: 将持续学习机制融入 AI/ML 模型中，允许根据新数据进行频繁的再训练和更新。 采用在线学习等技术可以使模型实时适应 变化。

• AI/ML 模型的复杂性 及其可解释性:

  • 问题: 一些 AI/ML 模型的“黑箱”性质使得团队难以理解和信任其预测和推荐，尤其是在 质量改进方面。

  • 策略：专注于开发和 应用 可解释的 AI (XAI)方法，提供对 AI 模型决策过程的洞察。 通过提供培训和资源，促进透明文化，帮助团队成员理解 AI/ML 模型如何促进 质量成果。

• 与现有工具 和工作流的集成：

  • 问题：将 AI/ML 解决方案无缝集成到现有的持续质量流程和工具中可能会遇到挑战，可能导致中断 和低效。

  • 策略：采用提供广泛 API 支持、插件和与现有质量保证及开发平台集成能力的 AI/ML 工具。 考虑逐步集成策略，允许渐进式适应 和学习。

解决这些 挑战需要一种深思熟虑的方法 ，结合技术解决方案、流程调整和持续学习。 通过认识并战略性地解决这些问题，组织可以充分利用 AI/ML 的潜力，提升持续质量的倡议，从而提高用户满意度并降低生产 失败率。

AI/ML 辅助的持续质量的实际应用场景

一个实际的 使用 AI/ML 辅助工具维护软件开发中持续质量的例子可以在 SonarQube中看到，SonarQube 是一个开源平台，利用 ML 增强代码质量分析。 SonarQube 通过使用静态分析方法并结合 ML 算法扫描代码库中的漏洞、缺陷和代码异味。 这些算法通过学习大量的代码数据集，能够更好地识别传统方法可能遗漏的复杂编码问题。 可能错过的复杂编码问题。

这一 ML 能力使 SonarQube 能够随着时间的推移自适应地提高其分析准确性，从各种代码库中的模式和修正中进行学习。 通过将 SonarQube 集成到 CI/CD 管道中，开发人员可以实时获得代码质量反馈，确保质量检查成为开发过程的一个核心部分，而不是事后的补充。 这种持续的自动化审查有助于保持高标准的编码规范，减少技术债务和生产环境中缺陷的可能性。 生产环境中的缺陷。

AI/ML 在持续安全中的应用

实施持续的 安全性涉及在开发、交付和运维生命周期中无缝集成主动和被动的安全措施。 这种方法旨在最大限度减少安全事件的频率和影响。 图 8**.6 展示了实现 持续安全所需的关键活动。

图 8.6 – 用于持续安全活动的 AI/ML

以下解释了潜在的瓶颈以及 AI/ML 如何缓解 这些挑战：

1. 安全性 需求分析：

   • 描述：定义 并理解特定于应用程序及其运行环境的安全需求。

   • 瓶颈：耗时的分析以及可能忽略 关键需求。

   • AI/ML 应用：AI 驱动的工具可以分析项目文档和代码，自动识别适用于项目的安全需求和规范，加快过程并 减少遗漏。

2. 安全编码 实践培训：

   • 描述：培训 开发团队掌握安全编码实践，防止 引入漏洞。

   • 瓶颈：保持培训材料的更新，并确保所有开发人员都掌握最新知识可能 具有挑战性。

   • AI/ML 应用：ML 算法可以根据代码库中最常见的安全错误定制个性化的培训内容，确保相关且 及时的培训。

3. 自动化 漏洞扫描：

   • 描述：定期使用 自动化工具扫描代码库及依赖项，查找已知漏洞。

   • 瓶颈：高误报率可能会压倒开发人员，且扫描可能会拖慢 CI/CD 流水线。

   • AI/ML 应用：AI 模型可以根据历史数据优先处理漏洞，减少误报的干扰，并将精力集中在最 关键的问题上。

4. 动态应用安全 测试 （DAST）：

   • 描述：对正在运行的应用程序进行自动化安全测试，以识别 运行时漏洞。

   • 瓶颈：DAST 可能资源密集且速度较慢，可能会 延迟部署。

   • AI/ML 应用：AI 可以通过关注近期更改或已知漏洞的区域来优化测试运行，提高速度 和效率。

5. 威胁建模与 风险评估：

   • 描述：分析 潜在威胁并评估风险，以优先考虑 安全工作。

   • 瓶颈：手动威胁建模费时，且可能无法捕捉到不断变化的 威胁格局。

   • AI/ML 应用：AI 算法可以通过分析代码更改和外部威胁情报来自动化威胁建模，提供实时 风险评估。

6. 安全 事件检测：

   • 描述：使用 自动化工具监控应用程序和基础设施中的安全事件。

   • 瓶颈：警报量可能会让安全团队不堪重负，从而导致威胁被遗漏或 忽视。

   • AI/ML 应用：机器学习（ML）可以增强异常检测，区分正常行为和潜在安全事件，减少误报和 警报疲劳。

7. 事件响应 与修复：

   • 描述：快速响应并减轻安全事件的影响， 高效进行。

   • 瓶颈：手动响应过程可能较慢，从而延长 解决时间。

   • AI/ML 应用：AI 驱动的自动化可以为常见事件触发预定义响应动作，加快解决时间，并释放资源用于更 复杂的分析。

8. 持续 反馈循环：

   • 描述：将安全运营中的反馈纳入开发中，以防止 未来的事件。

   • 瓶颈：孤立的团队和流程可能妨碍有效的反馈沟通。

   • AI/ML 应用：AI 工具可以分析事件报告和反馈，以识别模式并建议改进开发实践，推动持续改进的文化。

通过利用 AI/ML 应用程序支持每项活动，组织可以显著提升其持续的安全态势，确保安全措施与开发实践和新兴威胁同步演进。

将 AI/ML 应用于持续安全活动提供了显著的好处，例如自动化重复任务和增强检测能力。然而，这种整合也伴随一些挑战，如图 8.7 所示。

图 8.7 – AI/ML 持续安全挑战

解决这些问题对于在持续安全框架中有效利用 AI/ML 至关重要。以下是常见问题及应对策略：

• 攻击者心态缺乏直观理解：

  • 问题：AI/ML 模型可能未能充分捕捉人类攻击者的创造力和适应性，可能错过新颖或复杂的攻击路径。

  • 策略：结合对抗性 AI 技术和红队演练，训练 AI/ML 模型应对更广泛的攻击场景，包括需要类人直觉和创造力的情境。通过持续学习实践，AI/ML 系统定期更新，融入来自最新威胁情报和现实世界攻击模式的洞察。

• 关于目标环境的不确定性：

  • 问题：AI/ML 系统可能没有完全掌握目标环境的知识，导致威胁建模和漏洞评估不准确。

  • 策略：将 AI/ML 与动态发现工具结合使用，持续更新系统对环境的理解。实施混合模型，将 ML 洞察与安全专家输入结合，确保全面覆盖环境变量。

• 数据质量 和数量：

  • 问题：AI/ML 模型需要大量高质量的数据才能有效训练。不充分或低质量的数据可能导致预测不准确和模型不稳定。

  • 策略：利用合成数据生成技术来增强训练数据集，确保 AI/ML 模型能够访问多样化和全面的数据。与可信实体建立合作伙伴关系和数据共享协议，进一步丰富数据集。

• 不断发展的 威胁环境：

  • 问题：网络威胁环境的快速变化可能会超过 AI/ML 模型的学习能力，导致其随着时间推移变得不那么有效。

  • 策略：实施持续学习机制，使 AI/ML 模型能够实时适应新威胁。这包括集成自动化威胁情报流和使用无监督学习技术来检测新型模式。

• 模型透明度 和可解释性：

  • 问题：某些 AI/ML 模型的“黑箱”特性使得安全团队难以理解某些决策背后的推理，从而影响信任和责任。

  • 策略：专注于开发和应用 XAI 技术，以提供对模型决策过程的洞察。这包括使用本身提供更多透明度的模型，或采用可以解释模型输出的工具。

• 与现有安全工具 和工作流的集成：

  • 问题：将 AI/ML 无缝集成到现有的安全工具和工作流中可能面临挑战，可能导致操作效率低下。

  • 策略：优先考虑提供强大 API 支持并兼容标准安全工具和平台的 AI/ML 解决方案。采用分阶段集成方法，允许逐步调整和优化工作流。

• 伦理考量 和偏见：

  • 问题：AI/ML 模型可能会继承其训练数据中的偏见，可能导致不道德的结果或在安全操作中产生歧视性行为。

  • 策略：定期审计 AI/ML 模型，以识别和缓解偏见。 在训练阶段融入多样化的数据集，并让跨学科团队参与开发过程，确保优先考虑伦理问题。

通过识别并战略性地解决这些挑战，组织可以更有效地利用 AI/ML 在持续安全工作中的力量，从而增强检测能力、改善响应时间，并提升 安全态势的韧性。

AI/ML 辅助的持续安全实际应用案例

AI/ML 辅助工具在持续安全中的一个显著的实际应用是通过 Darktrace，这是一个 由 AI 驱动的网络安全平台。 Darktrace 利用机器学习算法学习组织网络的正常行为，从而实时检测和响应威胁。 通过持续监控网络流量，并使用无监督学习来构建组织内每个设备、用户和网络的“自我”理解，Darktrace 能够识别出可能表明 网络攻击的异常行为。

这种主动的方法使系统能够自主地迅速响应正在进行的网络威胁，通常在风险升级为严重漏洞之前就能进行有效的缓解。 例如，如果 Darktrace 检测到一个未知设备试图进行异常的数据传输，它可以自动中断这些可能的恶意活动，从而有效保护敏感数据。 这种增强了 AI 的监控和响应能力，较传统的基于规则的安全系统有了显著进展，使组织能够动态适应不断变化的安全 环境。

AI/ML 用于持续反馈

实施持续反馈 涉及在开发、交付和生产生命周期中系统性地收集、分析并根据用户和利益相关者的反馈进行行动。 这一过程旨在提升软件的可靠性以及团队对变化的响应能力。 图 8**.8 展示了持续反馈所需的关键活动。

图 8.8 – AI/ML 用于持续反馈活动

潜在的瓶颈以及 AI/ML 解决方案来应对这些挑战，详见下述清单：

1. 反馈收集：

   • 描述：收集来自各种来源的反馈，包括用户调查、支持票据和社交媒体。

   • 瓶颈：反馈的数量和种类可能会让手动处理工作不堪重负，导致响应时间变慢。

   • AI/ML 应用：自然语言处理和情感分析可以自动分类和优先排序反馈，帮助团队迅速识别和解决最关键的问题。

2. 反馈分析：

   • 描述：分析收集到的反馈，以识别共同的主题、用户痛点和潜在的改进点。

   • 瓶颈：手动分析耗时且可能无法准确捕捉到用户情感的全貌。

   • AI/ML 应用：AI 驱动的文本分析和模式识别可以从大量反馈数据中揭示洞察，突出那些可能并不显而易见的改进领域。

3. 集成到 开发工作流程中：

   • 描述：将可操作的反馈整合到开发积压工作中，并在冲刺中优先处理。

   • 瓶颈：将反馈整合到现有的开发工作流程中可能会打乱计划中的时间表和资源分配。

   • AI/ML 应用：机器学习算法可以评估实施反馈的影响和工作量，自动建议优先级和调整开发路线图。

4. 功能实现 和测试：

   • 描述：根据用户反馈开发和测试新功能或修复。

   • 瓶颈：根据反馈迅速实施和测试变更可能会加大资源压力，并可能引入新的问题。

   • AI/ML 应用：由 AI 驱动的自动化测试工具可以快速验证新功能和修复，确保它们符合质量标准，同时不会显著拖慢开发进度。

5. 发布 和监控：

   • 描述：将更新部署给用户，并监控变更对系统可靠性和用户满意度的影响。

   • 瓶颈：持续部署变更可能会导致生产环境不稳定，进而影响 系统可靠性。

   • AI/ML 应用：基于 AI 的监控工具可以实时检测异常和回退情况，从而进行快速恢复操作，最大限度减少对 用户的负面影响。

6. 反馈 闭环：

   • 描述：通知 利益相关者和用户关于他们反馈的响应措施，完成反馈 闭环。

   • 瓶颈：有效地将反馈实施情况传达给大量用户可能是一个挑战， 且需要大量资源。

   • AI/ML 应用：自动化沟通工具，如聊天机器人或个性化电子邮件，可以通知用户关于他们反馈的状态，从而增强透明度 和信任。

7. 影响分析：

   • 描述：通过分析与用户满意度和 系统可靠性相关的指标，评估响应反馈所做变更的有效性。

   • 瓶颈：手动将反馈驱动的变更与系统性能和用户满意度的结果进行关联可能非常复杂 且不准确。

   • AI/ML 应用： 高级分析和 ML 模型可以衡量特定变更对关键绩效指标的影响，为反馈实施的价值提供清晰的见解。

通过整合这些活动并利用 AI/ML 应用，组织可以显著提升其持续反馈流程。 这种方法不仅加快了宝贵反馈的实施，还确保了变更对系统可靠性和 用户满意度的正面影响。

将 AI/ML 应用到持续 反馈流程中，可以改变组织收集、分析和处理反馈的方式。 然而，正如 图 8**.9所示，将这些技术集成进来也面临着一系列挑战。 理解这些问题对于制定有效的策略以 减少它们至关重要。

图 8.9 – AI/ML 在持续反馈中的挑战

以下是与利用 AI/ML 进行持续反馈活动相关的常见问题及 提出的解决方案：

• 数据质量 和多样性：

  • 问题：AI/ML 模型需要高质量且多样化的数据才能准确分析反馈。 低质量或有偏的数据可能导致不准确的洞察和 误导性的决策。

  • 策略：实施强大的数据收集和预处理方法，以确保数据的质量和代表性。 定期审查和更新数据收集策略，以减少偏差并提高 反馈数据的多样性。

• 误解 反馈：

  • 问题：AI/ML 模型，特别是基于自然语言处理（NLP）的模型，可能会误解用户反馈的细微差别和上下文，进而导致错误的优先级排序或对 用户需求的误解。

  • 策略：将 AI/ML 分析与人工审查相结合，尤其是对于复杂或在决策中具有重大影响的反馈。 采用混合方法可以确保 AI 驱动的洞察通过 人工专业知识得到验证。

• 适应不断变化的 用户期望：

  • 问题：用户期望和反馈的背景可能会迅速变化，这使得静态的 AI/ML 模型难以保持长期的准确性。 随着时间推移，这种挑战更加明显。

  • 策略：采用持续学习的方法，使 AI/ML 模型能够定期更新数据。 这可以涉及在线学习等技术，使模型能够实时适应反馈趋势 和模式的变化。

• 与 现有系统的集成：

  • 问题：将 AI/ML 无缝集成到现有的反馈和开发工作流程中可能在技术上具有挑战性，可能会导致 反馈循环的中断。

  • 策略：关注那些提供灵活集成能力的 AI/ML 解决方案，以便与现有工具和平台兼容。 采用分阶段实施的方法，逐步引入 AI/ML 功能，根据 初步结果进行调整和优化。

• 确保用户隐私 和信任：

  • 问题：利用 AI/ML 分析用户反馈会引发关于用户隐私和数据安全的担忧，可能会削弱 用户信任。

  • 策略：采用并 明确传达严格的数据隐私政策，确保用户反馈在符合相关法规（例如 GDPR）的情况下进行分析。 采用隐私保护的 AI/ML 技术，如联邦学习或差分隐私，分析数据而不侵犯 个人隐私。

• 过度依赖 AI/ML 洞察：

  • 问题：可能会过度依赖 AI/ML 进行决策，忽视了人类直觉和理解在 解读反馈中的重要性。

  • 策略：制定指导方针，鼓励在决策中采取平衡的方式，将 AI/ML 生成的洞察与人工判断相结合。 培养一种文化，重视技术与人类专业知识在提升产品和 服务质量中的互补作用。

• 反馈量 与可扩展性：

  • 问题：反馈量庞大可能会压倒 AI/ML 系统，尤其是在需要快速扩展的场景中。

  • 策略：设计具有可扩展性的 AI/ML 系统，利用基于云的解决方案和分布式计算技术有效处理大规模数据集。 定期评估系统性能和可扩展性，必要时对基础设施进行调整，以 满足需求。

通过积极解决这些挑战，组织可以有效地在持续反馈过程中利用 AI/ML，确保准确收集、分析并采取行动，推动持续改进 和创新。

AI/ML 辅助的持续反馈的实际应用案例

使用 AI/ML 辅助工具进行持续反馈的实际示例由 Medallia展示， 这是一个利用 AI 实时分析来自多个渠道的客户反馈的平台。 Medallia 的 AI 组件，称为 Medallia Athena，利用 自然语言处理 (NLP) 和机器学习理解、分类并优先处理 来自调查、社交媒体和直接客户互动等渠道的客户情感、意见和行为。

这项技术使企业能够自动检测新兴趋势、情感变化以及客户体验中潜在的问题，并在其发生时作出响应，从而让公司迅速解决问题并利用反馈。 例如，如果某些地区或群体的客户满意度出现负面趋势，Medallia 可以立即警告经理，帮助他们迅速采取行动解决问题，提升服务质量，并持续提高客户满意度。 这种实时反馈处理和响应机制对希望在动态市场中保持高水平客户参与和满意度的企业至关重要。

选择 AI/ML 工具的方法论

为 持续测试、质量、安全性和反馈选择合适的 AI/ML 工具，需要一个全面的方法论，确保所选工具与组织目标一致，能够与现有系统无缝集成，并有效应对这些领域中的具体挑战。 在区分生成性 AI 工具（生成新数据或内容）与预测性 AI 工具（根据输入数据预测结果）时，选择过程必须考虑到与这些技术的功能、应用和潜在影响相关的独特因素。

图 8**.10 展示了一个结构化的方法论，用于选择 AI/ML 工具，强调了选择生成性 AI 工具与预测性 AI 工具之间的差异。

图 8.10 – 选择 AI/ML 工具的方法论

每个步骤在 以下列表中 进行了描述：

1. 定义目标 和需求：

   • 对于两者：明确指出您希望通过将 AI/ML 工具集成到持续测试、质量、安全性和反馈流程中所要实现的目标。 识别具体的挑战和需求，例如减少安全警报中的误报或加速 反馈循环。

   • 差异：对于生成型 AI 工具，重点关注创意、内容生成能力以及工具生成多样化输出的能力。 对于预测型 AI 工具，优先考虑准确性、可靠性，以及工具处理庞大数据集并提供 可操作性洞察的能力。

2. 评估兼容性 与集成性：

   • 对于两者：评估 AI/ML 工具与您现有的开发、测试和部署环境的集成效果。 考虑与当前工作流程、数据格式 和平台的兼容性。

   • 差异：生成型 AI 工具可能需要更强大的创意输入和输出处理能力，而预测型 AI 工具则通常需要强大的数据处理和分析功能，能够无缝集成您的数据源和 分析平台。

3. 评估性能 与可扩展性：

   • 对于两者：根据与目标相关的基准测试工具的性能，包括处理速度、准确性和可扩展性，以应对不断增长的数据量 和复杂性。

   • 差异：对于生成型 AI 工具，评估生成内容的质量和相关性。 对于预测型 AI 工具，关注预测的准确性、数据处理的速度以及模型在 不同条件下的表现。

4. 审查合规性和 伦理考量：

   • 对于两者：确保工具符合数据隐私、安全法规和伦理指南。 考虑 AI/ML 模型的透明度以及 它们的决策。

   • 差异：生成型 AI 工具可能需要额外审查生成内容的原创性和版权问题。 预测型 AI 工具可能需要更深入地审视预测中的潜在偏差和 决策过程。

5. 进行 试点测试：

   • 对于两者：实施一个试点项目，在受控环境中测试选定的 AI/ML 工具。 监测其对工作流效率、质量改进和 用户满意度的影响。

   • 差异：对于 生成式 AI 工具，试点测试应重点评估生成输出的创新性、种类和适用性。 对于预测式 AI 工具，应强调预测的准确性、时效性和与 实际场景的相关性。

6. 分析 成本效益：

   • 对于两者：评估实施、培训和维护的成本与预期收益之间的关系，例如提高效率、增强安全性或加速产品 开发周期。

   • 差异：生成式 AI 工具可能涉及与创造力和内容生成能力相关的成本，这可能会带来新的产品特性或内容策略。 预测式 AI 工具通常需要在数据处理和分析能力上进行投资，从而显著改善 决策过程。

7. 收集反馈并 优化选择：

   • 对于两者：收集试点用户和利益相关者的反馈，以优化工具选择。 考虑易用性、结果的满意度以及任何意外的 挑战。

   • 差异：生成式 AI 工具的反馈可能集中在生成内容的创造力和实用性上。 对于预测式 AI 工具，反馈可能侧重于预测的准确性、实用性和 可操作性。

通过遵循这一方法论，并意识到选择生成式和预测式 AI 工具之间的细微差别，组织可以做出符合其战略目标的明智决策，推动持续的测试、质量、安全性和 反馈计划。

总结

本章描述了在持续测试、质量、安全性和反馈实践中集成的 AI 和 ML 启用工具。 它解释了 AI/ML 技术如何大大提高开发和交付过程的效率、安全性和响应能力。 讨论提供了一个实用的框架，用于通过 AI/ML 启用工具自动化和增强任务。

选择合适的 AI/ML 工具是有效整合这些技术的关键步骤。 生成性和预测性 AI 工具的区别强调了在工具选择中采取深思熟虑的方法的重要性，确保所选解决方案与组织目标一致，并应对持续过程中的挑战。 本章识别了应用 AI/ML 所伴随的挑战和考虑因素。 诸如数据质量、隐私问题以及在自动化与人工监管之间保持平衡的需求，都是战略实施 AI/ML 的基础。 AI/ML 的战略实施。

展望未来，下章将展示持续测试、质量、安全和反馈在推动 DevOps、DevSecOps 和 SRE 实践的组织中的应用案例。 通过实际示例和深入分析，它将展示 AI/ML 如何不仅简化操作，还提升软件开发和维护的标准，标志着向更敏捷、更具韧性和高效的数字化转型之旅迈出重要的一步。 转型之旅。

第三部分：深入探讨路线图、实施模式和衡量标准

第三部分 本书的这一部分将重点转向在 DevOps、DevSecOps 和 SRE 领域中应用持续测试、质量、安全和反馈的实际方面。 本部分的结构旨在为读者提供如何在其组织内实现这些持续战略的全面理解。 他们的组织。

从真实世界的应用案例开始，展示了这些实践在不同操作环境中的变革性力量，提供了实现更高运营成熟度的见解。 随后，书中引导读者通过制定符合其组织目标的战略路线图的过程，确保数字化转型之旅的良好对接。 接下来，它探讨了各种实施模式，提供了结构化的方法，这些方法已被证明能提高这些战略路线图的成功率。 最后，本部分通过强调衡量进展和结果的重要性来结束，向读者提供了跟踪和评估其持续实践有效性的工具和框架。 本书的这一部分对于任何希望在数字化转型过程中实际实施并受益于持续测试、质量、安全和反馈的读者来说都至关重要。 转型工作。

本部分包括以下章节：

• 第九章**，与 DevOps、DevSecOps 和 SRE 的集成用例

• 第十章**，制定实施路线图

• 第十一章**，理解转型实施模式

• 第十二章**，衡量进展和结果

第九章：与 DevOps、DevSecOps 和 SRE 集成的使用案例

正如在 图 9**.1中所示，本章描述了在 DevOps、DevSecOps 和 SRE 框架下，如何实际应用持续测试、持续质量、持续安全性和持续反馈。 这些使用案例展示了组织如何转变为更高水平的 运营成熟度。

图 9.1 – DevOps、DevSecOps 和 SRE 的使用案例

本章分为几个关键部分。 第一部分， DevOps、DevSecOps 和 SRE 的使用案例，解释了这些实践如何帮助创建强大、韧性和响应迅速的 IT 生态系统。 接下来的部分，DevOps 的使用案例，DevSecOps 的使用案例，和SRE 的使用案例 解释了每种持续 方法的应用如何运作。

本章还解释了如何在 DevOps、DevSecOps 和 SRE 实践中有效地集成持续测试、质量、安全性和反馈。

其中，持续集成 部分提供了一个前瞻性的视角，讨论了如何随着时间的推移维护和发展这些集成，确保组织能够应对新兴挑战，同时保持其 操作实践的完整性和有效性。

在本章结束时，您不仅将探索各种不同的使用案例，还将掌握实施和维持这些集成所需的技能，能够在您的组织中推动这些集成的实施与持续发展。 无论您是经验丰富的实践者，还是刚接触 DevOps、DevSecOps 和 SRE 的新手，本章将为您提供必要的知识和见解，帮助您驾驭现代软件交付和运营的复杂性，推动您组织各个方面的持续改进。 技术生态。

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

• DevOps 的使用案例 使用案例

• DevSecOps 的使用案例

• SRE 的 使用案例

• 持续集成

让我们 开始吧！

DevOps 的使用案例

DevOps 哲学强调开发与运维的无缝集成，以提升软件交付的敏捷性、速度和质量。 实现这种集成的关键是将持续实践—测试、质量、安全性和反馈—贯穿整个软件开发生命周期，如 图 9**.2所示。

图 9.2 – DevOps 的使用案例

本节概述了如何将这些持续实践应用于 DevOps 各阶段，确保构建和维护强大软件系统的整体方法。

需求阶段

软件价值流的 需求阶段 指的是定义和记录软件产品必要规格和预期的初始阶段。 在这一阶段，包括业务分析师、产品经理和客户在内的利益相关者合作，阐明软件应具备的功能需求和非功能需求（如性能），并制定清晰且可操作的要求，指导整个开发过程。 这一阶段对于确定项目范围、优先排序特性以及确保最终产品符合用户需求和 商业目标至关重要。

• 持续测试使用案例 – 需求验证:

  • 解释: 在开发开始前，自动化测试需求以验证其清晰性、一致性和可测试性。

  • 重要性: 防止需求中的误解或模糊性，避免导致 昂贵的返工。

  • 挑战: 开发一个能够自动化测试需求的框架可能 会很复杂。

  • 策略: 利用 行为驱动开发 (BDD)框架创建基于需求的可测试 规格。

• 持续质量使用案例 – 质量 标准定义:

  • 解释: 建立与客户期望和 商业目标一致的清晰质量标准。

  • 重要性: 为质量设定基准，指导开发和 测试工作。

  • 挑战：平衡全面的质量标准与现实的项目范围 和时间表。

  • 策略：与利益相关者合作定义关键质量属性，并结合反馈循环进行 持续优化。

• 持续安全用例 – 威胁建模：

  • 解释：在生命周期的早期识别潜在的安全威胁和漏洞，以指导项目的安全态势。

  • 重要性：确保安全考虑从一开始就整合，减少 后期漏洞的风险。

  • 挑战：进行彻底的威胁建模需要专业知识，且可能非常耗时；在设计阶段之前进行威胁建模可能对某些设计不够充分，可能需要等到设计 完成后才行。

  • 策略：利用自动化威胁建模工具并定期进行培训，增强团队内部的安全专业知识。

• 持续反馈用例 – 利益相关者反馈 关于需求：

  • 解释：收集并整合利益相关者对定义需求和 质量标准的反馈。

  • 重要性：确保项目与利益相关者期望和 商业目标保持一致。

  • 挑战：管理和优先处理来自 不同利益相关者的反馈。

  • 策略：实施结构化的反馈流程并使用优先级矩阵有效处理 反馈。

开发阶段

软件价值流的 开发阶段 是实际编码 和软件创建的阶段。 在这一阶段，开发人员通过编码和初步单元测试将定义的需求转化为功能性软件。 这是一个关键阶段，软件的基础和核心功能在此阶段被构建，为后续的集成和测试活动奠定基础，这些活动将在 价值流中继续进行。

• 持续测试用例 – 单元测试：

  • 解释：开发者在代码开发的同时编写并执行单元测试，以验证单独的功能或组件。

  • 重要性：尽早发现缺陷，提高代码质量并减少后续测试工作量。

  • 挑战：确保全面的覆盖率，并在代码演进时维护测试。

  • 策略：采用测试驱动开发（TDD）实践，并利用自动化工具跟踪覆盖率并标记遗漏的测试。

• 持续质量用例 – 代码质量分析：

  • 解释：使用静态代码分析工具自动分析代码质量，强制执行编码标准并识别潜在问题。

  • 重要性：保持高代码质量、可读性和可维护性。

  • 挑战：配置分析工具，提供有意义的见解，同时避免让开发者被虚假警报淹没。

  • 策略：根据项目需求定制工具配置，并根据反馈定期审查阈值。

• 持续安全用例 – 安全编码实践：

  • 解释：将安全最佳实践和指南整合到开发过程中，以防止常见的安全漏洞。

  • 重要性：减少软件中的漏洞，增强整体安全态势。

  • 挑战：保持开发团队更新不断发展的安全实践，并在不影响生产力的情况下整合安全措施。

  • 策略：提供定期的安全培训，并将安全检查工具集成到开发环境中。

• 持续反馈用例 – 同行代码评审：

  • 解释：定期进行同行代码评审，提供有关代码质量、设计和安全性的建设性反馈。

  • 重要性：促进知识共享，提高代码质量，并培养协作文化。

  • 挑战：确保及时有效的评审，同时不拖慢开发进程。

  • 策略：实施轻量级审查流程，并利用 工具自动化 日常检查。

持续集成阶段

该 持续集成阶段 涉及将不同团队成员开发的单独代码片段合并成一个完整的软件系统，并进行全面的测试，以确保所有组件能够无缝协作。 这是一个关键的检查点，在这个阶段，可以识别并解决集成组件之间的冲突和错误，确保软件的功能性和稳定性，之后才能进入交付阶段，交付阶段是为产品发布做准备，但不包括部署。

• 持续测试用例 – 集成测试：

  • 解释：自动化测试不同组件或系统的集成，以验证它们是否按预期协同工作。 。

  • 重要性：识别由集成组件或系统之间的相互作用引起的问题。 。

  • 挑战：设计和维护一套全面的集成测试，覆盖所有关键的相互作用。 。

  • 策略：使用合同测试验证交互，模拟外部依赖关系，以进行更可靠且更快速的测试。 。

• 持续质量用例 – 构建 质量检查：

  • 解释：将质量检查集成到持续集成管道中，自动评估并强制执行每个构建的质量标准。 。

  • 重要性：确保每次构建在继续推进之前符合预定义的质量标准。 管道中的质量检查。

  • 挑战：定义并维护相关的、现实的质量指标，准确反映项目的质量目标。 。

  • 策略：根据项目进展和质量分析工具的反馈，定期审查并调整质量指标。 。

• 持续安全用例 – 自动化 安全扫描：

  • 解释：将自动化安全扫描工具纳入持续集成过程，以检测代码及其依赖项中的漏洞和安全问题。 。

  • 重要性：在 开发过程的早期识别并减轻安全风险。

  • 挑战：在不显著减慢 CI 管道的情况下，集成全面的安全扫描。

  • 策略：实施增量扫描，并根据代码变化和已知的 风险区域优先进行扫描。

• 持续反馈用例 – 构建 反馈循环

  • 解释：为开发人员提供关于集成尝试成功或失败的即时反馈，包括质量、安全性和 测试结果的详细信息。

  • 重要性：使开发人员能够快速解决问题并从 集成失败中学习。

  • 挑战：将来自各种工具和流程的反馈聚合为 可操作的见解。

  • 策略：使用 仪表板和通知系统整合反馈，并根据严重性 和影响优先处理 问题。

持续交付阶段

在 持续交付阶段 的 软件价值流中，每一次通过集成阶段自动化测试的变更都会自动准备发布到生产环境。 这涉及到对软件进行打包，进行进一步的自动化测试以验证发布，并确保软件始终可部署。 此阶段对于保持稳定的更新流至关重要，使得新的功能和修复能够快速高效地交付给用户。 。

• 持续测试用例 – 预发布测试：

  • 解释：在一个镜像生产环境的暂存环境中执行一整套自动化测试，以验证 发布。

  • 重要性：确保发布候选版本在一个与生产环境高度相似的环境中进行全面测试。 。

  • 挑战：维护一个最新且准确的暂存环境，其中包括所有必要的数据 和配置。

  • 策略：使用基础设施即代码 （IaC）来 管理和复制与生产环境相似的环境，并实施蓝绿部署以 最小化差异。

• 持续质量使用案例 – 发布 质量关卡：

  • 说明：定义和执行发布前必须通过的质量关卡，基于测试结果、质量指标和 安全扫描。

  • 重要性：保证只有符合所有质量和安全标准的发布才会部署，从而减少 生产环境中的问题风险。

  • 挑战：平衡严格的质量标准与快速交付的需求，避免在 发布过程中出现瓶颈。

  • 策略：持续评估和调整质量关卡，以确保与不断变化的项目需求和风险容忍度保持一致。

• 持续安全使用案例 – 安全审查 和审批：

  • 说明：在发布部署到生产环境之前，进行最后的安全审查并获得安全团队的批准。

  • 重要性：确保所有安全问题已得到解决，并且发布符合组织的 安全政策。

  • 挑战：在开发、安全和运维团队之间进行协调，以确保及时评审而不 延迟发布。

  • 策略：将自动化的安全检查和风险评估集成到交付过程中，以简化 安全审查。

• 持续反馈使用案例 – 利益相关者审查 和签字确认：

  • 说明：根据发布是否符合要求、质量标准和 安全政策，收集利益相关者的最终批准。

  • 重要性：确保发布与业务目标和利益相关者期望一致，最大限度减少 部署后问题的风险。

  • 挑战：管理与多方利益相关者的期望和沟通，以获得 及时的签字确认。

  • 策略：使用自动化发布说明和仪表盘提供关于发布状态的透明更新 并便于更轻松的 利益相关者审查。

持续部署阶段

软件价值流的 持续部署阶段 涉及将每一个成功通过持续交付过程的变更自动部署到生产环境，确保更新能够频繁且可预测地发布。 在这一阶段，部署测试至关重要，用于验证发布在实际环境中的正确性。 如果这些测试失败，系统会自动回滚到先前的稳定版本，以保持服务的连续性并尽量减少中断。 这个自动化过程通过确保持续不断的改进和修复流动，提升了对市场和用户需求的响应能力。 并修复问题。

• 持续测试用例 – 金丝雀测试：

  • 解释：逐步将变更推送给小部分用户，以监控性能并在全面发布前发现问题。 全量发布前。

  • 重要性：允许以可控的方式检测并缓解潜在问题，减少对广泛 用户群体的影响。

  • 挑战：设计有效的金丝雀测试，提供有意义的反馈而不影响 用户体验。

  • 策略：利用功能标志和自动化监控工具来管理和分析 金丝雀部署。

• 持续质量用例 – 持续监控 质量指标：

  • 解释：在生产环境中实施实时质量指标监控，以确保持续符合 质量标准。

  • 重要性：提供关于生产环境中应用质量的持续洞察，使得可以迅速响应 任何性能下降。

  • 挑战：选择有意义的质量指标并设置合适的阈值 用于警报。

  • 策略：定期基于历史性能数据和反馈 回顾并调整质量指标和阈值。

• 持续安全用例 – 持续 合规监控：

  • 解释：实时监控安全政策和法规的合规性，确保 持续遵守。

  • 重要性：保持应用程序的合规性状态，降低安全漏洞和 合规性问题的风险。

  • 挑战：实施全面的合规监控，涵盖所有相关的法规和政策，同时避免给团队带来 误报。

  • 策略：使用专门的合规监控工具，定期更新合规规则以反映 法规的变化。

• 持续反馈用例 – 用户 行为分析：

  • 解释：收集和分析用户行为数据，以收集已部署功能的反馈，并识别需要 改进的领域。

  • 重要性：提供关于用户如何与应用程序互动的直接洞察，突出潜在的提升 或调整领域。

  • 挑战：在收集和分析 行为数据时确保用户隐私和数据安全。

  • 策略：实施明确的数据收集政策，使用匿名化技术，并在必要时 获得用户同意。

持续运营阶段

持续 运营阶段 持续 直到下一个版本的软件被 部署。 在此阶段，软件会持续监控和维护，以确保其表现最佳。 如持续测试、质量保证、安全监控和收集反馈等实践对于此阶段至关重要。 它们有助于及时发现并解决任何操作问题，保持安全标准，并将用户反馈纳入未来的更新。 这一持续循环帮助软件在提供一致的性能和安全性的同时，适应不断变化的用户需求，直到 下一次部署。

• **持续测试用例 – ** 部署后测试：

  • 解释：在部署后，在生产环境中进行自动化测试，以验证应用程序在 实际条件下的表现。

  • 重要性：确认部署的成功与应用程序的操作稳定性。

  • 挑战：实施不干扰的测试，这些测试可以在生产环境中运行而不影响 用户体验。

  • 策略：使用合成监控和影子流量模拟真实用户交互，而不影响 实际用户。

• 持续质量使用案例 – 持续 质量改进：

  • 解释：利用从生产环境收集的反馈和数据，持续改进 应用程序的质量。

  • 重要性：确保应用程序根据用户需求和反馈不断发展，保持高质量 标准。

  • 挑战：在持续开发和 运营任务中优先处理质量改进措施。

  • 策略：实施结构化流程，审查反馈、进行根本原因分析，并将质量改进融入 开发积压任务中。

• 持续安全使用案例 – 持续 安全补丁：

  • 解释：实施自动化流程，向应用程序及其依赖项应用安全补丁和更新。

  • 重要性：确保应用程序免受已知漏洞的攻击，从而降低被利用的风险 。

  • 挑战：确保补丁不会引入新问题或降低 应用程序性能。

  • 策略：使用自动化测试和金丝雀发布来验证补丁的安全性，确保其在 广泛发布前没有问题。

• 持续反馈使用案例 – 实时用户 反馈收集：

  • 解释：利用工具和流程实时收集并分析用户反馈，能够立即对问题 和建议采取行动。

  • 重要性：使组织能够迅速响应用户需求，提升 用户体验。

  • 挑战：管理和优先处理来自 不同来源的大量实时反馈。

  • 策略：实施 反馈管理系统，以汇总并优先处理反馈，并将反馈分析融入常规的 开发周期。

将持续测试、质量、安全性和反馈整合到 DevOps 生命周期的每个阶段，对于开发和维护高质量、安全性强且以用户为中心的软件至关重要。 尽管在实施这些持续实践时会遇到挑战，但所提出的策略提供了克服这些难题的框架，确保 DevOps 方法的好处能够得到充分实现。 通过采纳这些实践，组织可以增强敏捷性、提高软件质量、加强安全措施，并更有效地响应用户需求，在今天竞争激烈且快速发展的 数字环境中取得成功。

DevOps 的真实案例

一个成功整合持续测试、质量、安全性和反馈实践到 DevOps 流程中的真实案例，可以在一家金融服务公司中看到，该公司旨在提高其软件部署频率和可靠性。 在这个场景中，公司利用 Jenkins 作为其 DevOps 流程的核心部分，自动化并管理持续集成和交付过程。 Jenkins 协调一系列阶段，包括构建代码、运行自动化测试和部署到 暂存环境。

通过使用 Selenium 进行自动回归和功能测试，实施持续测试，确保每个新版本在不破坏现有功能的情况下按预期运行。 为确保质量，集成了 SonarQube 进行静态代码分析，识别潜在的 bug 和漏洞，以保持高代码 质量标准。

在安全性方面，使用 OWASP ZAP 工具 在 CI/CD 过程中进行自动化安全扫描，确保在部署前识别和修复漏洞。 此外，通过集成功能标记工具如 LaunchDarkly，增强了反馈机制，允许在生产环境中实时获取新功能的用户反馈，而不影响所有用户。 这种集成不仅加快了反馈循环，还允许更安全、逐步的 发布，并根据 用户反馈快速调整。

这种工具与实践的结合确保了公司软件发布的安全性、可靠性，并与用户期望对接，从而显著提升了整体软件交付 生命周期。

DevSecOps 用例

采用 DevSecOps 在当今的软件开发和部署实践中至关重要，强调在整个 DevOps 生命周期中无缝集成安全措施，如 图 9**.3所示。

图 9.3 – DevSecOps 用例

这种方法不仅加速了交付时间，还确保了安全性成为基础组成部分，而不是事后补充。 本节深入探讨了持续测试、持续质量、持续安全和持续反馈在 DevSecOps 生命周期每个阶段的应用：需求、开发、持续集成、持续交付、持续部署和持续运营。 对于每个阶段，我们探讨了不同的用例、其重要性、相关挑战以及应对这些 挑战的策略。

需求阶段

• 持续测试用例 – 安全性 需求验证：

  • 解释：自动化安全需求的验证，确保 它们是可测试的，并与安全政策 和标准保持一致。

  • 重要性：为项目设定清晰的安全基准，指导后续的开发和 测试工作。

  • 挑战：开发能够有效验证细致的 安全需求的自动化工具或脚本。

  • 策略：利用 BDD 技术定义可测试格式的安全需求。

• 持续质量用例 – 质量和安全 标准定义：

  • 解释：建立全面的质量和安全标准，确保项目在其 生命周期中遵守。

  • 重要性：为评估软件的质量和安全性提供一套明确的标准，确保一致性 和合规性。

  • 挑战：在严格的质量和安全标准与实际开发和 部署时间表之间取得平衡。

  • 策略：制定逐步发展的标准，随着项目的进展不断演化，允许灵活性而不妥协于 核心原则。

• 持续安全用例 - 威胁建模和 风险评估:

  • 解释: 进行威胁建模和风险评估，早期识别潜在安全威胁和漏洞 生命周期。

  • 重要性: 通过突出需要额外安全措施的领域，指导设计和开发过程。 安全措施。

  • 挑战: 需要深入的安全专业知识和对 项目相关的潜在攻击向量的理解。

  • 策略: 利用自动化威胁建模工具，并结合外部安全专家进行 综合评估。

• 持续反馈用例 - 利益相关者安全 期望对齐:

  • 解释: 参与 与利益相关者对齐期望，关于 安全姿态 和优先级。

  • 重要性: 确保项目的安全措施符合或超出利益相关者的期望，避免 后期误解。

  • 挑战: 促进技术团队和具有不同安全知识水平的利益相关者之间的有效沟通。 。

  • 策略: 使用清晰、非技术性语言描述安全措施及其对 项目结果的影响。

开发阶段

• 持续测试用例 - 安全 编码实践:

  • 解释: 实施安全编码实践涉及利用静态和动态分析工具在编码过程中检测漏洞。 写。

  • 重要性: 减少代码库中的漏洞数量，增强 应用程序的整体安全姿态。

  • 挑战: 将这些工具集成到开发工作流中，而不影响 开发者的生产力。

  • 策略: 将安全工具集成到 IDE 中，并为开发人员提供即时反馈，以便在编码时纠正问题。 他们编码。

• 持续质量用例 - 代码审查和分析 质量保证:

  • 解释: 进行自动化和手动代码审查，确保遵循质量和 安全标准。

  • 重要性: 通过促进同行监督和利用自动化工具来检测问题，推动高代码质量和安全性。

  • 挑战: 管理彻底代码审查所需的额外时间和资源。

  • 策略: 使用静态分析工具自动化常规检查，并优先对复杂或关键部分的代码库进行手动审查。

• 持续安全用例 – 安全 单元测试:

  • 解释: 开发 并执行专门设计用于验证应用程序中安全功能和控制的单元测试。

  • 重要性: 确保安全机制按预期工作，防止已知漏洞和 攻击向量。

  • 挑战: 创建涵盖广泛安全场景的全面测试用例。

  • 策略: 结合手动安全专业知识和自动化工具，生成并执行以安全为重点的单元测试。

• 持续反馈用例 – 开发者对 安全实践的反馈:

  • 解释: 收集并根据开发者对已实施安全实践的有效性和效率的反馈进行调整。

  • 重要性: 通过根据实际开发经验改进实践，提升应用程序的安全姿态。

  • 挑战: 鼓励开发人员提供开放和建设性的反馈，尤其是那些可能不是 安全专家的开发者。

  • 策略: 建立开放沟通和持续学习的文化，强调安全在 开发过程中的价值。

持续集成阶段

• 持续测试用例 – 自动化 安全扫描:

  • 解释: 将自动化安全扫描工具集成到 CI 流水线中，以检测漏洞和配置错误，当新代码 被集成时。

  • 重要性：在开发过程中及早识别和解决安全问题，减少漏洞进入 生产环境的风险。

  • 挑战：在扫描的彻底性与维持快速 CI 管道的需求之间保持平衡。

  • 策略：实施增量扫描，并根据代码库的变化和已知的 高风险区域优先扫描。

• 持续质量使用案例 – 构建 质量保证：

  • 解释：通过将质量检查集成到 持续集成（CI）流程中，确保每次构建都符合预定义的质量标准。

  • 重要性：在整个开发过程中保持一致的质量水平，防止质量随时间 下降。

  • 挑战：定义并强制执行既全面又现实的质量标准。

  • 策略：使用自动化工具来衡量和报告质量指标，并根据历史数据和 项目演变调整标准。

• 持续安全使用案例 – 依赖扫描：

  • 解释：作为持续集成（CI）流程的一部分，自动扫描依赖项中的已知漏洞。

  • 重要性：防止通过第三方库和框架引入漏洞，这是一种常见的 攻击途径。

  • 挑战：跟上最新的漏洞数据库，并管理 误报。

  • 策略：将实时漏洞信息流集成到扫描工具中，并建立一个过程来审查并处理 扫描结果。

• 持续反馈使用案例 – CI 管道的安全 和质量反馈：

  • 解释：在 CI 过程中立即向开发人员提供有关安全性和质量问题的反馈。

  • 重要性：能够迅速解决问题，促进持续改进的文化。

  • 挑战：将来自多个工具的反馈汇总成可操作的见解， 供开发人员参考。

  • 策略：使用仪表板和集成开发工具来整合并 优先处理反馈，突出关键问题以便 立即行动。

持续交付阶段

• 持续测试用例 - 安全性和 质量网关：

  • 解释：将安全性和质量网关作为 CD 流程的一部分，确保只有符合严格标准的代码才能被推进到 后续阶段。

  • 重要性：作为最后的检查，防止不安全或低质量的代码被部署 到生产环境。

  • 挑战：定义适当的通过网关的门槛，而不妨碍 交付过程。

  • 策略：为网关建立明确、可衡量的标准，并根据项目结果和 利益相关者反馈定期审查。

• 持续质量用例 - 发布 候选测试：

  • 解释：对发布候选进行全面的安全性测试，以验证其功能和是否符合 安全标准。

  • 重要性：确保发布在功能上完整，并且符合项目的 质量基准。

  • 挑战：高效地执行一系列测试，而不延迟 发布过程。

  • 策略：尽可能自动化测试过程，并根据风险和 影响评估优先进行测试。

• 持续安全用例 - 部署前 安全审查：

  • 解释：在部署前执行最终的安全审查和批准流程，以验证符合 安全政策。

  • 重要性：确保发布符合所有组织和监管的 安全要求。

  • 挑战：及时进行全面审查，以避免 延迟部署。

  • 策略：通过自动化和预定义的检查表简化审查过程，并确保安全人员被整合进 DevSecOps 团队。

• 持续反馈用例 - 发布 反馈收集：

  • 说明：收集利益相关者对发布过程的反馈，包括安全性和质量方面，以推动 未来的改进。

  • 重要性：识别流程改进和提升的领域，推动交付实践的持续改进。

  • 挑战：有效地收集和处理来自不同利益相关者的反馈。

  • 策略：实施结构化反馈机制和定期回顾会议，讨论 反馈并 规划行动。

持续部署阶段

• 持续测试用例 – 部署后验证：

  • 说明：自动验证 部署上线后在生产环境中的完整性和安全性。

  • 重要性：确认应用程序的成功部署及其操作的 安全状态。

  • 挑战：在不影响实时环境或 用户体验的情况下进行全面验证。

  • 策略：利用金丝雀部署和合成事务以受控方式验证部署。

• 持续质量用例 – 生产环境 监控：

  • 说明：持续监控生产环境，以确保其符合质量和 性能标准。

  • 重要性：通过主动识别和解决质量问题，保持高水平的用户满意度和系统可靠性。

  • 挑战：在大量监控数据中筛选出 可操作的洞察。

  • 策略：实施智能监控解决方案，利用机器学习根据严重性 和影响来优先处理问题。

• 持续安全用例 – 实时 威胁检测：

  • 说明：采用实时监控和威胁检测工具，识别并应对生产环境中的安全事件。

  • 重要性：通过快速检测和响应，最小化安全漏洞的潜在影响。

  • 挑战：平衡灵敏度和特异性，最小化假阳性，同时确保不忽视任何重大威胁。

  • 策略：根据历史事件数据微调检测算法，并定期更新威胁情报来源。

• 持续反馈使用案例 – 用户 体验监控：

  • 解释：收集并分析用户反馈和使用数据，以了解应用程序的真实世界体验。

  • 重要性：提供有关用户如何与应用程序互动的见解，并指出可以改进的地方以提高满意度。

  • 挑战：整合来自多个渠道的反馈，并将其转化为可操作的改进措施。

  • 策略：实施全面的用户分析和反馈工具，并建立跨职能团队，以敏捷方式处理反馈。

持续运营阶段

• 持续测试使用案例 – 操作 准备性测试：

  • 解释：进行持续测试，确保系统随时准备处理操作需求，包括负载测试和灾难恢复模拟。

  • 重要性：确保系统在不同操作条件下的韧性和可靠性。

  • 挑战：在不影响生产系统或用户体验的情况下，模拟现实的操作场景。

  • 策略：利用影子流量和模拟工具，在受控环境中模拟真实用户行为和操作条件。

• 持续质量使用案例 – 质量 改进举措：

  • 解释：根据反馈和监控数据实施持续质量改进举措，以提高系统性能和用户满意度。

  • 重要性：确保应用程序随着时间的发展，满足用户需求和质量预期。

  • 挑战：优先考虑并实施改进，平衡新功能开发与质量提升。

  • 策略：采用数据驱动的方法，识别质量改进机会，并将其整合到产品路线图中。

• 持续安全用例 – 持续合规性和安全 态势管理：

  • 解释：持续监控和调整应用程序的安全状态，以确保符合不断变化的安全政策和标准。

  • 重要性：保持应用程序的安全完整性，适应新威胁和合规要求。

  • 挑战：跟上安全标准和监管要求的变化，并在不干扰运营的情况下实施变更。

  • 策略：利用自动化合规性监控工具，并建立专门的团队来监督安全态势管理。

• 持续反馈用例 – 运营 反馈循环：

  • 解释：与运营团队建立反馈循环，根据实际经验和事件持续改进运营实践。

  • 重要性：通过从前线汲取经验教训，提高运营效率和可靠性。

  • 挑战：有效地捕获并将来自运营的反馈整合到持续改进的过程中。

  • 策略：在事件发生后实施定期的回顾和总结，并将运营反馈整合到开发和安全实践中。

在 DevSecOps 生命周期中融入持续测试、质量、安全性和反馈代表了一种全面的软件开发和部署方法，确保在每个阶段都将安全性集成进来。 虽然在实施过程中存在挑战，但战略性的方法（从自动化和工具集成到利益相关者参与和持续学习）可以有效解决这些障碍。 通过拥抱这些持续的实践，组织不仅能够提升其安全态势，还能够提高整体软件质量和运作效率，从而在竞争激烈的软件开发领域中稳步前行，展现出信心 和韧性。

DevSecOps 的真实使用案例

一个真实的使用案例 涉及将持续测试、质量、安全性和反馈实践集成到 DevSecOps 管道中的应用可以在一个旨在确保其患者数据管理系统的安全性和高效性的医疗软件提供商中看到。 在这种情况下，该公司利用 GitHub Actions 自动化工作流程，从而有助于简化开发和运维过程，所有工作都在一个 平台上进行。

持续测试通过 Cypress 进行，这是一种 端到端的测试框架，用于自动测试每次代码提交和拉取请求中的功能和集成问题。 在质量方面，该公司在开发环境中集成了 ESLint，用于维持高标准的代码并捕捉语法错误及其 JavaScript 代码中的问题模式。

安全性是一个至关重要的问题，因为健康数据的敏感性。 该公司在管道中集成了 Aqua Security，用于扫描容器镜像中的漏洞，并在整个开发生命周期中强制执行安全策略。 反馈通过如 Jira 这样的工具持续收集，在这些工具中，生产环境中的错误和用户反馈被记录并直接关联到开发任务。 这有助于快速响应问题，并根据 用户影响优先安排开发工作。

通过将这些工具和实践集成到其 DevSecOps 管道中，医疗软件提供商提高了交付安全、高质量软件的能力，同时确保遵守严格的 行业规范。

SRE 的使用案例

站点可靠性工程 (SRE) 是一个学科，运用软件工程的各个方面解决基础设施和运营中的问题，专注于系统的可靠性、可扩展性和可维护性。 SRE 将持续测试、持续质量、持续安全和持续反馈整合到系统开发和运营的生命周期中，如 图 9**.4所示。

图 9.4 – SRE 用例

本节 探讨了在 SRE 生命周期的每个阶段实施这些持续实践：需求、开发、持续集成、持续交付、持续部署和持续运营。 每个阶段都有独特的用例，突出了它们的重要性、涉及的挑战以及克服 这些挑战的策略。

需求阶段

• 持续测试用例 – 可靠性 需求验证：

  • 解释：确保 可靠性需求 被清晰地定义、可衡量，并能够通过 自动化测试进行验证。

  • 重要性：为整个系统生命周期中的可靠性工程奠定了坚实的基础。

  • 挑战：量化和创建自动化测试以满足可靠性需求可能 非常复杂。

  • 策略：利用 服务级目标 (SLOs) 和 错误预算作为可靠性的可衡量指标，并将其融入自动化 测试框架。

• 持续质量用例 – 质量 属性规格：

  • 解释：定义与可靠性、可维护性 和可扩展性相关的具体质量属性。

  • 重要性：引导设计和开发过程，构建一个满足用户和 业务需求的高质量系统。

  • 挑战：在不妥协功能性的情况下，平衡各种质量属性。

  • 策略：根据利益相关者的反馈和对系统可靠性 及性能的潜在影响来优先考虑质量属性。

• 持续安全用例 – 安全 需求规划：

  • 解释：根据系统的 威胁模型识别并整合安全要求和控制措施。

  • 重要性：确保从一开始就将安全考虑融入系统， 最小化漏洞。

  • 挑战：跟上不断变化的安全威胁并确保 全面覆盖。

  • 策略：定期进行威胁建模会议，并根据新出现的威胁 和漏洞更新安全需求。

• 持续反馈用例 – 需求 反馈循环：

  • 解释：建立收集并整合利益相关者和 最终用户需求反馈的机制。

  • 重要性：确保系统的需求与用户需求和 业务目标保持一致。

  • 挑战：高效管理和优先处理大量反馈。

  • 策略：实施结构化的反馈收集流程并定期审查更新需求， 以便根据反馈进行调整。

开发阶段

• 持续测试用例 – 单元和集成测试 以确保可靠性：

  • 解释：开发专注于系统可靠性方面的单元和集成测试，例如容错和 优雅降级。

  • 重要性：在 开发阶段及早识别并解决可靠性问题。

  • 挑战：创建能够真实反映 生产环境的测试场景。

  • 策略：利用混沌工程原理模拟现实条件，将韧性测试融入 开发过程。

• 持续质量用例 – 代码 质量标准：

  • 解释：通过自动化的 linting、代码审查和静态 分析工具强制执行代码质量标准。

  • 重要性：保持高代码质量，提高系统的可维护性 和可靠性。

  • 挑战：确保遵守质量标准，而不妨碍 开发速度。

  • 策略：在可能的情况下自动化质量检查，并将其集成到开发者的工作流中，以提供 即时反馈。

• 持续安全使用案例 – 安全 开发实践：

  • 解释：将安全编码实践和工具纳入开发过程，以便及早识别和修复安全 问题。

  • 重要性：减少在开发过程中引入安全漏洞的风险。

  • 挑战：保持开发团队了解最新的安全实践，并将其无缝集成到 开发过程。

  • 策略：提供持续的安全培训，并将安全工具直接集成到 开发环境中。

• 持续反馈使用案例 – 开发者 体验反馈：

  • 解释：收集开发团队对工具、实践和流程的反馈，识别改进 的领域。

  • 重要性：增强开发过程和工具，提高生产力和 工作满意度。

  • 挑战：建立一种文化，在这种文化中，反馈是定期给出的并且 得到采取行动。

  • 策略：实施定期回顾和匿名反馈工具，以 鼓励 开放沟通。

持续集成阶段

• 持续测试使用案例 – 自动化可靠性测试 在 CI 中：

  • 解释：将自动化可靠性测试集成到 CI 流水线中，包括负载测试和 混沌实验。

  • 重要性：确保每次更改在合并前都经过审查，评估其对系统可靠性的影响。

  • 挑战: 设计并维护一套高效的可靠性测试，确保可以快速运行并提供 有意义的反馈。

  • 策略: 聚焦增量测试，并根据历史问题和 高风险区域优先测试。

• 持续质量用例 – 持续代码 质量监控:

  • 解释: 利用 CI 管道中的工具，持续监控并报告代码 质量指标。

  • 重要性: 保持代码质量的一致性，提高维护的便捷性 和可扩展性。

  • 挑战: 定义准确反映代码库健康状况的有意义质量指标。

  • 策略: 使用静态代码分析、代码复杂度指标和代码覆盖率报告的结合来 监控质量。

• 持续安全用例 – CI 安全扫描:

  • 解释: 在 CI 过程中进行安全扫描和分析，以便尽早识别 漏洞。

  • 重要性: 最小化将不安全代码部署到后续阶段或生产环境的风险。

  • 挑战: 在不显著拖慢 CI 过程的情况下，集成全面的安全扫描。

  • 策略: 使用增量和差异扫描技术，聚焦于新引入的变更和已知的 高风险区域。

• 持续反馈用例 – CI 反馈 用于改进:

  • 解释: 向开发人员提供 CI 过程的即时反馈，包括测试失败、安全扫描结果和 质量指标。

  • 重要性: 使开发人员能够快速解决问题，改善代码库的整体健康状况和 安全性。

  • 挑战: 将来自多个来源的反馈聚合成 可操作的见解。

  • 策略: 使用集成的仪表盘和通知系统来整合反馈，并根据严重性 和影响优先排序。

持续交付阶段

• 持续测试用例 – 部署前测试：

  • 解释：在与生产环境相似的预发布环境中进行全面测试，以验证变更 在部署前的有效性。

  • 重要性：在受控环境中识别任何问题，减少生产事故的风险。

  • 挑战：确保预发布环境在数据、规模 和配置方面准确反映生产环境。

  • 策略：使用基础设施即代码（IaC）管理环境配置，并保持预发布与生产环境 同步。

• 持续质量用例 – 发布 质量保证：

  • 解释：验证每次发布是否符合已设定的质量基准 在部署前。

  • 重要性：确保仅部署高质量的变更，保持生产环境的完整性和可靠性。

  • 挑战：定义并执行既现实又严格的质量基准，以确保 高标准的维护。

  • 策略：自动化质量检查，并基于质量指标对部署进行门控，结合人工审查流程以应对 关键发布。

• 持续安全用例 – 安全审查和 合规检查：

  • 解释：在部署前进行最终的安全审查和合规检查，以确保发布符合所有安全要求 和法规。

  • 重要性：防止安全漏洞和合规违规，保护组织及其 用户。

  • 挑战：快速进行彻底的审查，以避免 延迟部署。

  • 策略：尽可能自动化合规性和安全审查过程，使用代码政策来强制执行 安全标准。

• 持续反馈用例 – 部署前 利益相关者反馈：

  • 解释：收集利益相关者对即将变更和发布的反馈，以确保其与业务目标和 用户期望一致。

  • 重要性：使开发工作与业务目标和用户需求保持一致，从而提高 交付更改的价值。

  • 挑战：高效地收集和整合来自广泛利益相关者的反馈 。

  • 策略：使用功能标志和金丝雀发布，在完全部署前以受控方式收集变更的反馈。

持续部署阶段

• 持续测试用例 - 自动化 部署测试：

  • 解释：自动 测试部署过程和应用部署后的状态，以验证部署是否成功并确保 操作状态正常。

  • 重要性：确保部署过程的可靠性，并且应用在部署后仍然保持功能性 。

  • 挑战：创建能够准确验证部署成功和应用在生产环境中操作状态的测试 。

  • 策略：使用冒烟测试和合成事务验证关键 功能在部署后的有效性。

• 持续质量用例 - 持续监控 质量指标：

  • 解释：持续监控生产中的应用和基础设施质量指标，确保其符合 预定义标准。

  • 重要性：提供实时的洞察力，了解部署对应用质量和 用户体验的影响。

  • 挑战：确定哪些质量指标最能反映用户体验和 系统性能。

  • 策略：实施全面的监控解决方案，跟踪各种指标，利用机器学习识别异常 和趋势。

• 持续安全用例 - 持续 安全监控：

  • 解释：实施持续监控以检测 生产环境中的安全威胁和漏洞。

  • 重要性：能够实时检测和响应安全事件，最大限度地减少 潜在的损害。

  • 挑战：过滤和优先处理警报，以有效管理安全数据的量，同时不遗漏 关键威胁。

  • 策略：利用 先进的 安全信息和事件管理 (SIEM) 系统，并集成自动化 响应机制。

• 持续反馈用例 – 实时用户 反馈收集：

  • 解释：实时收集和分析用户反馈，以评估部署对用户满意度 和体验的影响。

  • 重要性：提供关于变化如何影响用户的即时见解，便于在必要时迅速进行调整。

  • 挑战：将反馈收集机制融入用户体验中，且不 干扰用户。

  • 策略：实施不干扰的反馈工具，如应用内调查和使用分析，直接 收集用户的见解。

持续运营阶段

• 持续测试用例 – 生产流量和 负载测试：

  • 解释：模拟 生产流量和负载，以测试系统在 现实世界条件下的 容量和可扩展性。

  • 重要性：确保系统能够处理预期负载和峰值负载，防止停机和 性能下降。

  • 挑战：在不影响 实际用户的情况下，模拟真实的流量模式和流量量。

  • 策略：使用模拟真实用户行为和 流量模式的影子流量和负载测试工具。

• 持续质量用例 – 持续 质量改进：

  • 解释：利用持续的反馈和监控数据来推动系统的持续质量改进。

  • 重要性：确保系统持续演进，以满足用户需求和质量标准，提升满意度 和可靠性。

  • 挑战：在新功能开发和 运营任务中优先考虑质量改进。

  • 策略：采用结构化的质量改进过程，将反馈和监控见解整合到 产品路线图中。

• 持续安全使用案例 – 持续 漏洞管理：

  • 解释：在 生产环境中实施持续识别、评估和缓解漏洞的过程。

  • 重要性：通过确保及时解决漏洞，保护免受不断演变的安全威胁。 。

  • 挑战：跟上新漏洞，并有效地管理 补救过程。

  • 策略：利用自动化漏洞扫描工具，并将补丁管理集成到 运营工作流程中。

• 持续反馈使用案例 – 运营反馈和 事件分析：

  • 解释：分析 运营反馈和事件，以识别根本原因并实施 预防措施。

  • 重要性：通过从运营经验中学习和事件，提高系统的可靠性和运营效率。 。

  • 挑战：系统地捕捉和分析反馈和事件，以推导出补救措施和未来 缓解行动。

  • 策略：利用无责任的事后分析来确定 未来的缓解措施。

持续测试、持续质量、持续安全和持续反馈的整合进入 SRE 生命周期，体现了构建和维护可靠、安全和高质量系统的整体方法。 尽管每个阶段都面临着独特的挑战，但这些持续实践的战略应用使组织能够提升其运营效率、安全姿态和用户满意度。 通过培养持续改进和学习的文化，SRE 团队可以推动技术和运营的卓越性，确保其系统具有弹性、可扩展性，并与用户需求和 业务目标对齐。

SRE 的实际应用案例

一个真实的用例 将持续测试、质量、安全和反馈实践融入 SRE 实践中，可以在一家电子商务公司中看到，该公司旨在优化其在线购物平台的可靠性和用户体验。 该公司使用 Prometheus 和 Grafana 进行监控和警报，这在 SRE 中发挥着至关重要的作用，通过提供系统健康状况 和性能的实时洞察。

在这种情况下，持续测试使用 Google 的开源框架 Spinnaker 来处理，该框架支持高级部署策略，如金丝雀发布和蓝绿部署。 这使得 SRE 团队能够在实时环境中逐步测试新版本，从而最小化干扰并减少将有缺陷的软件部署到 所有用户的风险。

为了维护质量和安全，公司集成了 SonarQube 进行静态代码分析，以维持高代码标准并在开发过程中早期发现安全缺陷。 此外，使用如 HashiCorp Vault 等工具来增强安全性，该工具管理机密并保护跨应用程序 和基础设施的敏感数据。

反馈机制通过使用如 Elasticsearch, Logstash 和 Kibana (ELK) 堆栈 来聚合日志并促进用户交互和系统错误的详细分析。 这些数据对于 SRE 团队基于实际用户体验和 系统行为不断提升系统稳定性和性能至关重要。

通过将这些工具集成到其 SRE 实践中，电子商务公司确保其平台保持可靠、安全和高效，从而直接促进了更好的客户体验和更高的 业务连续性。

持续集成

有许多用于 DevOps、DevSecOps 和 SRE 的持续测试、持续质量、持续安全和持续反馈的用例。 实现和达到这些用例的有效解决方案需要大量投资，以便改进人（包括文化）、流程和技术的实践，正如在 图 9**.5中所示。

图 9.5 – 持续集成

然而，在成功的 转型之后，如果不实施可持续的实践以支持每个用例的人员、流程和工具，实践可能会逐渐消退，收益可能会受到影响。 本节描述了将维持收益与持续改进实践相结合的推荐实践。

通过将 DevOps、DevSecOps 和 SRE 实践转化为测试、质量、安全和反馈的持续方法论，持续维护通过转型获得的收益需要对培养人才、优化流程和有效利用技术做出持续承诺。 为了确保这些收益不仅能够维持而且还能随时间增强，组织必须采取促进持续改进、适应性和韧性文化的实践。 以下推荐措施旨在维持和进一步发展通过实施 这些实践所取得的成功：

• 培养人才 和文化:

  • 培养持续学习和改进的文化: 鼓励一种将失败视为成长机会的学习环境。 提供定期培训、研讨会和资源，使团队了解最新的实践、工具和 技术。

  • 提升所有权和责任感: 通过促进团队对工作的所有权感来赋能团队。 这包括对其开发和维护的系统的质量、安全性和可靠性负责。

  • 鼓励协作和跨职能团队: 打破开发、运营、安全等部门之间的壁垒，促进系统开发和维护的整体化方法。 利用跨职能团队培养一种重视不同视角的文化 并加以利用。

  • 认可和奖励贡献: 实施认可计划，以表彰个人和团队对持续改进工作的贡献。 这激励了持续参与和 实践。

• 优化流程:

  • 实施持续反馈循环：建立收集、分析和反馈所有利益相关者意见的机制，包括最终用户、开发团队、运营和安全部门。 这一机制应成为生命周期所有阶段的一个重要组成部分，从需求收集 到运营。

  • 定期审查和更新实践：定期审查实践和流程，以识别改进领域。 使用指标和 KPI 来衡量实践的有效性，并基于数据做出决策以 精炼它们。

  • 标准化并记录最佳实践：开发并维护最佳实践、指南和经验教训的资料库。 确保这些资源对所有团队成员易于访问，以促进跨项目的一致性和效率。

  • 规划适应性：设计灵活的流程，能够轻松适应技术、市场需求和组织目标的变化。 这包括采纳敏捷方法论，并在必要时调整实践 以应对变化。

• 利用技术：

  • 投资于合适的工具：选择与组织目标和实践相匹配的工具。 确保这些工具能与现有系统良好集成，并能够扩展以满足 未来的需求。

  • 尽可能实现自动化：自动化重复的手动任务，以提高效率并减少人为错误的可能性。 这包括测试、部署、监控和反馈收集等方面。 自动化使组织能够将资源集中在其他 高价值任务上。

  • 确保工具的兼容性和集成性：工具的选择不仅要基于 其独立功能，还要考虑它们如何与组织内其他工具和系统集成。 这有助于优化工作流程，提升跨团队的协作 效率。

  • 定期评估和更新工具：作为持续改进的一部分，定期评估工具和技术的有效性。 准备在更好的选项出现或组织需求变化时，替换或升级工具。 随着需求变化进行相应调整。

在 DevOps、DevSecOps 和 SRE 中实施持续测试、质量、安全和反馈实践后，保持这些成果需要采取积极的措施来管理人员、流程和技术。通过培育持续学习、协作和改进的文化，精炼可适应且高效的流程，精心选择和管理技术工具，组织不仅可以维持最初的成功，还能随着时间的推移持续改进其实践。持续的承诺确保组织即使在发展和适应新挑战与机会时，依然保持韧性、竞争力，并与其战略目标保持一致。

摘要

本章描述了 DevOps、DevSecOps 和 SRE 实践中持续测试、持续质量、持续安全和持续反馈的一系列综合用例。它解释了如何将这些持续实践整合进来，从而提升持续开发、交付和运营的效率、安全性和可靠性。通过深入探讨 DevOps、DevSecOps 和 SRE 流程每个阶段的具体用例，本章为这些方法论的实际应用、它们在实现卓越运营中的重要性以及组织在实施过程中可能面临的挑战提供了洞察。

本章解释了克服实施挑战的战略方法。讨论了像培育持续学习文化、鼓励跨职能协作、利用自动化和先进工具等策略，作为成功将这些实践嵌入组织工作流的关键推动力。

通过阐明每个用例中的实际好处和潜在陷阱，本章为从业者提供了必要的知识和工具，帮助他们应对将持续实践整合到运营中的复杂性。

随着组织从理解持续测试、质量、安全和反馈的用例过渡到实际实施，下一章提供了为此目的量身定制的战略路线图。

第十章：构建实施路线图

在本章中，我们解释如何为在您的组织内实施连续测试、质量、安全和反馈创建有效的路线图。 本章指导您完成定义量身定制的路线图所必需的基础步骤，确保您的数字转型旅程既具有战略性又与 组织目标保持一致。

通过本章结束时，您将获得宝贵的技能，包括如何精确定义适合组织独特挑战和目标的实施路线图；专注于连续测试、质量、安全和反馈的专用路线图策略——这些对于开发强大、可靠和用户中心的产品至关重要——以及实现路线图对齐的技术，确保每个团队成员都致力于愿景，并共同努力实现 共享目标。

本章不仅仅是学习如何创建文档；它还描绘了一个未来的愿景，即持续改进已融入到您组织的文化中。 通过实用见解和可操作的建议，它使您能够自信 和清晰地带领团队迈向卓越。

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

• 战略路线图 简介

• 创建 一份路线图

• 创建未来状态价值 流程图

• 连续测试 路线图

• 连续质量 路线图

• 连续安全 路线图

• 连续反馈 路线图

• 在 路线图上达成一致

让我们 开始吧！

战略路线图简介

在组织内掌握连续测试、质量、安全和反馈需要战略规划。 这一旅程标志着向更具敏捷性、响应性和以质量为中心的开发实践的转变，需要的不仅仅是愿景，还有战略路线图和计划，每一个都在组织 转型旅程中发挥着独特但互补的作用。

路线图与计划的区别

在其核心，路线图 是一个高层次的、视觉化的表示，概述了组织打算采取的主要步骤，以实现其战略目标，如与连续测试、质量、安全相关的目标， 以及反馈。

与详细计划不同，路线图提供了一个关于人员、流程和技术活动的全景视图，并且展示了实现转型目标的关键里程碑。 路线图具有灵活性，允许在环境变化时进行调整。 战略路线图提供了宏观视角，基于此可以 制定详细计划。

相比之下，计划 是一个详细的文档，概述了实现路线图中所识别的目标所需的具体行动、资源分配、时间表和职责，包括人员、流程和技术。 它深入探讨了操作层面，提供了执行的逐步指南。 计划是战术性的和详细的，为日常活动和 短期目标提供了清晰的蓝图。

路线图的好处

实施战略 路线图为正在转型的组织带来了多个好处：

• 对齐：首先，它通过清晰传达推动愿景、目标和战略优先事项的活动，确保组织各层级之间的对齐。 这种对齐对于争取支持并促进共同的 目标感至关重要。

• 灵活性：第二，路线图提供灵活性，帮助组织灵活应对技术进步和市场变化的不确定性。 它们作为指路明灯，保持组织专注于长期目标，同时适应 战略的调整。

• 资源分配：第三，路线图通过突出优先领域，帮助更好地分配资源，确保时间、人员和技术的投资 明智地投入并服务于 整体目标。

路线图的重要性

路线图至关重要，原因有几个：

• 清晰性与方向：它提供了清晰的愿景和方向，使各方利益相关者保持一致，并确保每个人都理解目标及 前进的路径。

• 资源分配：它有助于资源的高效分配，确保时间、金钱和精力的投资能够集中在 战略优先事项上。

• 风险管理：它使组织能够预见风险并制定缓解策略，从而减少 项目失败的可能性。

• 变革管理：它通过概述对流程、人员和技术的影响，支持有效的变革管理，并为组织 做好转型准备。

• 绩效跟踪：它使得 能够跟踪与目标的进展，并 关键绩效指标 (KPI)，并允许根据需要进行调整 修正 。

没有路线图的风险

没有战略路线图， 向持续测试和相关实践转型可能会带来重大风险。 没有明确的路线图，组织可能会发现自己没有连贯的战略方向，导致努力错位和资源浪费。 缺乏指导性战略愿景可能导致一些举措未能有效地促进整体目标，进而导致低效和潜在的挫折。 此外，缺少路线图可能会妨碍组织适应变化和挑战的能力，因为缺乏战略框架来指导决策 和调整。

没有路线图，组织可能会面临几个 负面后果：

• 缺乏一致性：没有明确的计划，组织的不同部门可能会追求相互冲突的优先事项，从而导致低效和 资源浪费。

• 资源错误配置：没有优先级排序和规划，资源可能会被过度分配或投入到 低影响的举措中。

• 增加的风险：缺乏风险管理计划可能使组织在面对无法预见的挑战时变得脆弱，可能导致 转型的失败。

• 抗拒变革：没有变革管理策略，组织可能会遇到员工和其他利益相关者的强烈抵制，阻碍新技术 和流程的采用。

• 无法衡量成功：没有明确的 KPI 和衡量标准，就很难衡量进展并展示数字化转型努力的价值。 转型的成果。

总之，虽然路线图和计划在转型过程中都扮演着至关重要的角色，但它们的目的各不相同。 路线图提供了战略概述和灵活性，指导组织朝着其长期愿景迈进，推动持续的测试、质量、安全性和反馈。 与此相比，计划则提供了实施所需的战术细节。 它们共同构成了组织转型的全面方法，路线图确保战略一致性和适应性，而计划则详细说明了执行路径。 采用战略路线图的好处不可过分强调，忽视路线图的风险同样不容忽视。 当组织在转型的复杂过程中航行时，战略路线图是一个不可或缺的工具 ，它确保成功。

表示路线图的最佳格式

表示数字化转型路线图的最佳格式可能会根据组织的需求和偏好有所不同。 然而，视觉表现形式，如甘特图、仪表板或信息图，通常是有效的。 这些格式可以帮助利益相关者快速了解时间表、依赖关系和进展。 工具如微软 Excel、Project、Trello 或专业的路线图软件可以促进路线图的创建、更新和共享。 路线图。

图 10**.1 是一个作为甘特图表示的示例路线图。 这种格式的优点在于，通过简单地添加水平线来表示 史诗 ，以及垂直线来表示 时间框架 和 主题，可以随时添加任何详细信息。

图 10.1 – 转型路线图模板

总之，一个结构良好的路线图对于引导大型组织通过复杂的数字化转型过程至关重要。 它确保了资源的高效利用、风险的减轻以及衡量成功的能力，从而提高了实现 预期成果的可能性。

创建路线图

创建数字化转型路线图涉及一系列结构化步骤，如图 10.2所示。它需要来自组织各个部门的各类利益相关者的参与。这个过程至关重要，确保转型能够成功解决三个关键领域：人员/文化、流程和技术（包括产品、工具和基础设施要素）。

图 10.2 – 定义实施路线图

让我们分解这些步骤，确定所需的参与者，讨论如何评估备选方案，并确定何时路线图是可接受的。

创建路线图的步骤

以下是步骤清单：

1. 定义愿景和目标：如在第五章中所述，建立清晰的数字化转型愿景和具体目标。这应与组织的战略目标对齐。例如，建立能力成熟度模型，如在第四章中所述，可以帮助确定能够识别当前水平和目标水平的能力水平。

2. 进行当前状态评估和差距分析：如在第六章中所述，评估人员（文化和能力）、流程和技术的当前状态。了解当前价值流的成熟度、能力和差距。通过当前状态调查、差距评估和当前状态价值流图（CSVSM）来完成此任务。识别当前状态与期望未来状态之间的差距。此分析应涵盖技能、技术、流程和文化方面。

3. 识别优先领域和工具：确定数字化转型的关键领域。 优先排序对先解决高影响领域至关重要。 在此步骤中，建议进行 未来状态价值流图 (FSVSM)，如本章后面所述。 对于每个优先领域，概述具体的计划或项目，包括目标、所需资源和预期成果。 建议使用本章中描述的选择工具平台和工具的方法论 第七章。

4. 规划时间线和里程碑：创建一个分阶段的时间线，并明确里程碑。 这应包括短期胜利、长期转型目标和能力成熟度模型，详见 第四章 和 第五章。

5. 识别风险和缓解策略：预见潜在风险并制定相应的应对策略。 解决这些问题。

6. 分配预算和资源：估算所需的投资，包括技术采购、培训和招聘的预算。 根据需要估算 投资回报率 (ROI)，以便为投资提供合理依据。

7. 定义成功指标和变更管理计划：制定管理组织变革的策略，重点关注沟通、培训和支持系统。 建立如何衡量成功，使用具体、可衡量的里程碑和 KPI。 参考 第十二章 了解建立指标的方法。

谁应当参与

以下利益相关者应当 参与并贡献于 路线图的制定：

• 高层领导：提供愿景和支持，并确保与 组织战略的一致性。

• 产品开发和质量保证领导：从产品开发和质量保证的角度提供见解。 保证的视角。

• IT 部门：提供当前技术基础设施和能力的见解。 与能力。

• 人力资源：促进人员和文化的转型，包括培训 和发展。

• 运营领导者：提供当前流程的洞察，并帮助设计 未来状态的流程。

• 数字化转型办公室或团队（如有）：负责领导和协调 转型工作。

• 财务部门：协助预算编制和 财务规划。

• 外部顾问（可选）：提供数字化转型的专业知识和外部视角。

评估路线图备选方案

在创建路线图时，考虑备选解决方案是 正常的，通常会在最终决定之前进行考虑。 以下是从一组备选方案中选择路线图时的考虑因素：

• 与战略目标的一致性：确保路线图与更广泛的 组织目标一致。

• 可行性和风险：评估每个备选方案的可行性及其 相关风险。

• 成本效益分析：评估预期收益与所需成本和 资源之间的对比。

• 利益相关者的影响：考虑对员工、客户和其他 关键利益相关者的影响。

• 灵活性：确保 路线图能够适应变化的环境 和技术。

确定可接受的路线图

一个可接受的 路线图是 如下所示：

• 与战略目标对齐：明确支持组织的战略目标 和愿景。

• 现实可行：可以在给定的时间、预算 和资源限制下现实地实施。

• 获得利益相关者的支持：得到组织内关键利益相关者的支持。

• 涵盖人员、流程和技术：在所有三个领域提供全面的转型。

• 包括明确的成功指标：具有明确的关键绩效指标（KPI），可以跟踪进度并 衡量成功。

一旦你拥有符合这些标准并已获得关键利益相关者审查和批准的路线图，你可以认为它是可接受的，并开始实施。 随着转型的推进，可能需要定期进行审查和调整，以确保路线图始终与组织目标保持一致，并适应外部环境或 组织优先事项的任何变化。

创建未来状态价值流图（FSVSM）

FSVSM 是一种 在精益管理中使用的视觉工具，概述了组织内部流程的理想未来状态，专注于从开始到结束的价值交付。 与传统的价值流图不同，传统的价值流图记录的是当前流程、低效和浪费，而 FSVSM 则描绘了在实施改进后，流程应该如何理想地运作。 它旨在简化操作，提升生产力，消除非增值活动，从而确保流程中的每一步都能直接贡献于最终 产出的价值。

FSVSM 在建立转型路线图中的重要性

以下是解释 为什么 FSVSM 对于建立转型路线图非常重要的原因：

• 愿景澄清：FSVSM 有助于阐明一个清晰且共享的理想未来运营状态的愿景。 通过可视化最终目标，组织可以确保所有利益相关者对 相同的目标达成一致并保持积极性。

• 差距识别：映射未来状态使组织能够识别当前流程与最佳未来操作之间的差距。 理解这些差距对于制定有针对性的策略以弥补差距至关重要，从而使转型路线图 更加有效。

• 优先级排序：FSVSMs 有助于识别需要改进的高影响领域。 组织可以利用这些信息来优先安排举措，合理配置资源，并专注于那些在价值交付和 减少浪费方面带来最大益处的变革。

• 增强的协作与沟通：FSVSM 的视觉化和协作性质促进了团队成员、部门和利益相关者之间更好的沟通。 这种改善的沟通对于协调努力、分享最佳实践并确保转型全面 且有凝聚力至关重要。

• 持续改进文化：通过定期更新 FSVSM 以反映已实现的改进并设定新目标，组织可以促进持续改进的文化。 这一迭代过程鼓励不断的评估和适应，在当今快速变化的商业环境中至关重要。 商业环境。

• 战略规划支持：FSVSM 通过概述实现所需未来状态的必要步骤，为战略规划提供了一种结构化的方法。 它们作为制定详细行动计划、设定现实时间表和 衡量变革目标进展的基础。 变革目标。

总之，FSVSM（价值流映射）是组织变革规划和执行中不可或缺的工具。 它们提供了一种战略视野，指导有效的变革路线图的制定，确保工作重点明确、方向一致，并且以价值为驱动。 通过利用 FSVSM，组织能够以清晰和精准的方式应对变革的复杂性，最终实现提高效率、质量和 客户满意度的目标。

FSVSM 工作坊

创建 FSVSM 进行数字化 转型需要几个关键步骤和准备工作，以确保映射过程既高效又有效。 以下是该过程的简要概述以及各个方面的重要性：

1. 为价值流设定具体目标：设定具体目标至关重要，因为它与数字化转型工作的重点保持一致。 它有助于识别需要改进的过程，并确保未来状态图的设计具备明确的目标，例如减少浪费、改善流程流动或提升 客户满意度。

2. 提前准备参与者：在进行 FSVSM 工作坊之前，必须提前准备参与者。 这包括选择一个跨职能团队，并为他们提供有关价值流映射、工作坊目标以及他们可能需要的任何预读材料或数据的背景信息。 充分准备确保参与者能够带着充分的信息参与并为映射过程作出有意义的贡献。 贡献。

3. 审查当前状态映射：首先审查价值流的当前状态，以了解现有的流程、信息流和痛点。 这一步骤包括记录步骤、延迟和低效，从而为改进奠定基准 。

4. 识别价值流中的瓶颈：通过当前状态映射，识别瓶颈和浪费的区域。 瓶颈至关重要，因为它们会减缓流程流动，并可能显著影响整体绩效。 识别这些瓶颈可以为未来状态设计中的有针对性的干预提供依据。 。

5. 设计未来状态图：通过利用当前状态分析的洞察力，并牢记具体目标，设计价值流的未来状态。 这涉及到 用数字技术重新构思流程，消除非增值步骤，并解决已识别的瓶颈，从而创建一个更高效、更有效的 价值流。

6. 制定实施路线图：制定一条路线图，以便从当前状态过渡到未来状态。 该路线图应包括具体的项目或倡议、所需资源、时间表和衡量成功的指标。 路线图应包括实现转型目标所需的人员、流程和技术方面的战略性变革。 。

7. 总结研讨会的输出结果：主要输出包括详细的 FSVSM、全面的实施路线图、确定的即时改进领域，以及待采用的潜在数字技术或解决方案列表。 此外，应有一套明确的绩效指标，用于跟踪向 未来状态的进展。

为数字化转型创建 FSVSM 的过程对于确保努力集中在最具影响力的领域至关重要。 通过设定具体目标、准备参与者、识别瓶颈并充分规划实施，组织可以显著提升其运营，增强客户价值，并在 数字时代获得竞争优势。

接下来，让我们将重点转向将持续测试融入软件开发 生命周期的具体内容。

持续测试的路线图

本节 概述了确保测试成为一个 持续进行的过程的策略，使得问题能够早期被发现，并确保质量从一开始就融入到产品中。

制定有效的持续测试路线图需要仔细考虑发现调查、能力成熟度评估、差距评估、工具评估和 CSVSM 的结果，如 前面的章节所述。

没有标准的路线图，因为每个组织和应用程序在持续测试的当前状态和未来状态的优先事项上都具有独特性。

图 10**.3 是持续测试路线图的示例。 在这个示例中，组织的持续测试当前状态被评估为能力水平 2（即持续集成），而该组织的目标是转变为 4 级（即 持续部署）。

图 10.3 – 持续测试路线图（示例）

路线图 有两个 项目主题：

• P1 主题，将持续测试实践从 2 级（持续集成）转变为 3 级， 持续交付。

• P2 主题，将从 3 级转变为 4 级， 持续部署。

P1 主题的路线图包括以下 Epics，旨在转变人员、流程、技术和 进度跟踪：

• 人员：召开启动会议，以确保团队对实施、培训以及 CI/CD 测试自动化的角色和责任矩阵（即 RACI）达成一致。

• 流程：设计活动、测试环境自动化、持续交付的测试自动化以及持续交付（CD）测试覆盖率的验证。

• 技术：工具选择、新工具的调试和所选工具在 CD 自动化中的使用。

• 进度跟踪：定义仪表盘指标和里程碑，并审查持续测试的检查点。

P2 主题的路线图包括以下 Epics，旨在转变人员、流程、技术和 进度跟踪：

• 人员：召开启动会议，以确保团队对实施、培训以及 CI/CD 测试自动化的角色和 RACI 的更新达成一致。

• 流程：流程设计活动、蓝绿环境流程自动化及验证 和试运行。

• 技术：部署工具选择、新工具的启用，以及选择的工具用于 部署自动化。

• 进展跟踪：更新 仪表板指标和里程碑，并审查 持续测试检查点，用于 部署自动化。

此路线图是一个高层次的框架，基于此可以制定详细的持续测试实施计划，包括故事 和任务。

持续质量路线图

持续质量 不仅仅是测试，涵盖了产品生命周期的各个方面，以确保卓越。 本节讨论了如何创造一个质量文化，让每个团队成员都成为卓越的倡导者，利用工具、流程和指标来维持 高标准。

没有标准的路线图，因为每个组织和应用都有独特的当前状态和未来状态的优先事项，以实现 持续质量。

图 10**.4 是持续质量路线图的一个示例。 在这个示例中，组织的当前持续质量状态被评估为第 2 级能力，持续集成，组织期望的目标是转变为第 4 级， 持续部署。

图 10.4 – 持续质量路线图（示例）

该 路线图有两个 项目主题：

• 主题 P1：将持续质量实践从第 2 级，持续集成，转变为第 3 级， 持续交付。

• 主题 P2：将持续质量实践从第 3 级转变为第 4 级， 持续部署。

主题 P1 的路线图包括以下 Epic，以转变人员、流程、技术和 进展跟踪：

• 人员：启动会议，以使团队对实施、培训、角色以及 CI/CD 质量计划的 RACI 达成一致。 质量计划。

• 流程：设计活动、持续交付的持续质量检查自动化，以及持续交付质量检查的验证。 质量检查。

• 技术：选择用于持续交付的质量检查工具，委托新工具的使用，并使用选定的工具进行持续交付 质量自动化。

• 进度跟踪：定义仪表盘指标和里程碑，审查连续质量的检查点。

P2 主题的路线图包括以下 Epics，以转变人员、流程、技术和 进度跟踪：

• 人员：启动会议以便团队就实施、培训以及 CI/CD 质量自动化的角色和 RACI 进行对齐。

• 流程：流程设计活动，P2 流程自动化、验证， 以及试行。

• 技术：选择用于部署的质量检查工具，委托新工具的使用，并使用选定的质量检查工具进行 部署自动化。

• 进度跟踪：更新仪表盘指标和里程碑，并 审查部署的持续质量检查点。

这份路线图是实现持续质量的高层次方法，基于此可以制定详细的实施计划，包括故事 和任务。

持续安全的路线图

随着 网络安全威胁的增加，本节突出了将安全实践融入每个开发阶段的必要性。 它为主动的安全态势提供了蓝图，确保产品不仅具备功能性，还能抵御 潜在威胁。

没有标准的路线图，因为每个组织和应用的当前状态及未来优先级都独特， 需要定制持续安全的路线图。

图 10**.5 是一个 持续安全的路线图示例。 在这个 示例中，组织的当前持续安全状态被评估为 2 级能力，即持续集成，目标是将组织转变为 4 级能力，即 持续部署。

图 10.5 – 持续安全的路线图（示例）

路线图有两个 项目主题：

• 主题 P1，将连续安全实践从第 2 级——持续集成，转变为第 3 级—— 持续交付。

• 主题 P2，将连续安全实践从第 3 级转变为第 4 级—— 持续部署。

主题 P1 的路线图包括以下 Epic 以转变人员、流程、技术和 进度跟踪：

• 人员：启动会议以使团队就 实施、培训以及 CI/CD 安全策略的角色和 RACI 达成一致。

• 流程：设计活动，自动化持续质量检查用于持续交付，以及验证持续交付 的安全检查。

• 技术：选择用于持续交付的质量检查工具，委托新工具的使用，并将选定的工具应用于持续交付的安全自动化。

• 进度跟踪：定义仪表板指标和里程碑，并审查持续安全的检查点。

主题 P2 的路线图包括以下 Epic 以转变人员、流程、技术和 进度跟踪：

• 人员：启动会议以使团队就实施、培训以及安全自动化的更新角色和 RACI 达成一致。

• 流程：流程设计活动，P2 流程自动化、验证， 以及试验。

• 技术：选择用于部署的安全检查工具，委托新工具的使用，并将选定的质量检查工具应用于 部署自动化。

• 进度跟踪：更新仪表板指标和里程碑，审查持续安全的检查点以支持 部署。

这份路线图是一个高层次的连续安全方法，其上可以构建详细的实施计划，包括故事 和任务。

持续反馈的路线图

这一部分 强调了反馈在迭代开发过程中的价值。 它展示了如何建立从用户和利益相关者处获取持续反馈的渠道，从而便于快速调整和改进，以有效满足他们的 需求。

没有标准的路线图，因为每个组织和应用程序在当前状态和未来状态上都有独特的优先级，适用于 持续反馈。

图 10**.6 是持续反馈的路线图示例。 在此示例中，组织当前的持续反馈状态被评估为第 2 级能力，持续集成，组织期望的 目标是转变为 第 4 级， 持续部署。

图 10.6 – 持续反馈的路线图（示例）

路线图有两个 项目主题：

• 主题 P1，将持续反馈实践从第 2 级，持续集成，转变为第 3 级， 持续交付。

• 主题 P2，将持续反馈实践从第 3 级转变为第 4 级， 持续部署。

主题 P1 的 路线图包括以下 Epics，以转变 人员、流程、技术和 进度跟踪：

• 人员：启动会议，帮助团队就实施、培训、角色和 RACI 以及 反馈策略达成一致。

• 流程：设计活动，持续交付的持续反馈自动化，以及对 持续交付反馈的验证。

• 技术：为持续交付选择反馈工具，启动新工具的使用，并利用选定的工具进行持续交付的反馈自动化。

• 进度跟踪：定义仪表盘指标和里程碑，并审查持续反馈的检查点。

主题 P2 的路线图包括以下 Epics，以便转变人员、流程、技术和 进度跟踪：

• 人员：启动会议，用于团队对实施、培训以及更新的角色和 RACI 达成一致，以便进行 CI/CD 反馈。

• 流程：流程设计活动，P2 流程自动化，验证， 和试验。

• 技术：选择用于部署的反馈工具，启动新工具的使用，并利用选定的反馈工具进行 部署自动化。

• 进度跟踪：更新仪表盘指标和里程碑，审查部署的持续 反馈 检查点。

此路线图是一个高层次的持续反馈方法，详细的实施计划可以基于此制定，包括故事 和任务。

路线图的一致性

本节讨论了路线图实施中最关键的方面之一——确保全组织各层级之间的一致性。 它提供了有关如何与相关方进行互动、促进合作，并确保路线图获得所需支持以成功的实用建议。

建议为持续测试、质量、安全性和反馈分别制定独立的路线图，以确保考虑到每个目标的独特性。 重要的是，确保转型团队就所有主题和史诗达成共识。 一旦达成一致，建议制定一个综合的路线图，以简化整个主题 和史诗的项目跟踪。

识别风险与缓解策略

将一个 组织转型为更成熟的持续测试、质量、安全性和反馈能力，需要在流程、技术和文化方面进行重大变革。 认识到并减轻与这些变革相关的风险，对于成功过渡至关重要，如 图 10**.7所示：

图 10.7 – 风险与缓解

在这里， 风险和缓解 策略 被解释如下：

• 抗拒变革：员工可能会抵制新方法、新工具，以及日常工作中的变化，尤其是在他们认为这些变化威胁到现有职位 或技能时。

  • 缓解策略：

    • 沟通：定期与所有相关方沟通变革的益处和原因。

    • 培训与教育：提供全面的培训，帮助员工适应新工具 和新实践。

    • 包容性：通过反馈会议和试点项目让员工参与过渡过程。

• 技能和知识不足：当前的劳动力可能缺乏有效实施和维护新技术 和实践所需的技能：

  • 缓解策略：

    • 培训计划：投资培训计划和工作坊，提升员工 技能。

    • 招聘：引进具备必要技能或经验的人才，特别是在 DevOps、网络安全和 自动化测试等领域。

    • 合作伙伴关系：与专注于 数字化转型的外部顾问或公司合作。

• 工具和技术整合挑战：将新工具与现有系统整合可能复杂且具有破坏性，可能导致停机或数据 完整性问题：

  • 缓解策略：

    • 分阶段实施：逐步推出新工具 和流程，以管理 整合的复杂性。

    • 强健的测试：在受控环境中对新工具进行严格测试，确保其在 全面实施之前可靠。

    • 专家协助：对于复杂的整合，使用外部专家确保遵循最佳实践 。

• 安全漏洞：新工具和更频繁的部署可能会引入安全漏洞，特别是如果没有 妥善管理：

  • 缓解策略：

    • 安全审计：定期进行安全审计和 漏洞评估。

    • 安全优先的文化：培养安全意识文化，并确保安全实践从 一开始就融入开发过程。

    • 自动化安全工具：实施自动化安全测试工具，持续扫描 潜在漏洞。

• 缺乏足够的反馈机制：没有有效的反馈机制，质量和性能的持续改进 可能会停滞不前：

  • 缓解策略：

    • 反馈工具：实施能够促进来自最终用户 和利益相关者实时反馈的工具。

    • 定期评审：安排定期评审会议，讨论反馈并将其纳入 开发周期。

    • 指标和 KPI：定义并跟踪 KPI，以衡量反馈对产品质量和 团队绩效的影响。

• 预算超支：由于不可预见的挑战或 范围蔓延，转型可能比预期更昂贵：

  • 缓解策略：

    • 明确预算：为与转型相关的支出建立明确的预算限制和审批流程。

    • 持续监控：定期监控和审查费用及进展，确保与设定目标的对齐。

    • 范围管理：明确定义转型的范围和目标，以避免超出 原始意图。

• 项目管理不足：差的项目管理可能导致目标不一致、错过截止日期和 项目失败：

  • 缓解策略：

    • 专业项目管理：雇佣经验丰富、熟悉 IT 转型的项目经理。

    • 敏捷方法论：使用敏捷方法管理项目，允许灵活性并定期重新评估项目方向 和优先级。

    • 利益相关者参与：在整个项目生命周期内保持所有利益相关者的参与和知情，确保对齐并及时解决 问题。

通过仔细规划和解决这些风险，组织可以成功应对持续测试、质量、安全和反馈采纳的复杂性，从而实现更具弹性和高效的 运营模式。

分配预算和资源

确定实施预算并预测在持续测试、质量、安全和反馈方面的转型 ROI 需要一种综合方法。 以下是推荐的步骤，用于制定预算并估算 ROI，包括技术采购、培训、招聘和 流程自动化的考虑：

1. 明确范围 和目标：

   • 确定具体目标：清晰地定义转型计划的目标，包括质量、速度、安全性等方面的具体改进，以及 反馈机制。

   • 需求分析：评估当前能力，并识别转型需要解决的差距。 这包括技术、技能、流程和 文化方面。

2. 成本估算 费用：

   • 技术采购：估算购买新工具并与现有系统集成的成本。 这可能包括软件许可证、硬件和 云服务。

   • 培训：为当前员工培训新工具、方法论和 最佳实践分配预算。

   • 招聘：确定招聘具有必要专业知识的新员工的成本，若现有员工无法填补 所有职位。

   • 流程自动化：评估自动化流程的成本，这可能包括软件开发、购买现成的解决方案或定制 现有工具。

   • 基础设施升级：包括可能需要升级的基础设施，以支持新技术和 增加的负载。

   • 咨询和外部专家：如果需要专业知识来实施，预算中应考虑外部顾问的费用。 用于实施。

3. 计算 ROI：

   • 量化效益：估算 切实的效益，如减少市场推广时间、提高产品质量、减少停机时间和降低安全 事故成本。

   • 间接效益：考虑间接效益，如提高客户满意度、增强品牌声誉和增加 员工满意度。

   • 节省成本：计算减少错误率、减少安全漏洞和减少手动测试所带来的成本节省。

   • ROI 公式：使用 公式：

     • %ROI={(净收益−总成本)/(总成本)}×100%，其中净收益包括收入增长和 成本节省。

4. 分配 预算：

   • 基于优先级的资金分配：根据范围分析中确定的优先需求分配资金。 应优先考虑那些带来最大投资回报的关键领域。

   • 分阶段分配：考虑采用分阶段的预算分配方法，在特定里程碑完成时释放资金，以保持项目进度并 确保预算内完成。

   • 应急基金：将预算的一部分（通常为 5-10%）预留用于转型过程中无法预见的费用或调整。

5. 监控 和调整：

   • 绩效指标：设立 关键绩效指标（KPI）以监控在不同阶段实施的成功情况。

   • 反馈机制：整合反馈机制，持续改进并根据需要调整转型战略。 。

   • 预算审查：定期审查预算与实际支出，依据项目进展和 外部因素调整预测。

6. 报告 和沟通：

   • 利益相关者报告：通过定期更新预算使用情况、投资回报率（ROI）预测和 项目状态，保持所有利益相关者的知情。

   • 透明沟通：确保所有财务决策和调整都透明地传达给相关方，以维护信任 并 确保一致性。

这种战略方法不仅有助于为转型设定一个切实可行的预算，还能计算出可靠的投资回报率（ROI），以证明投资的合理性。 此外，持续的预算和资源监控与适应性管理将确保转型与组织目标及 市场需求保持一致。

定义成功指标和变更管理计划

为了成功实现向更成熟的持续测试、质量、安全和反馈能力的转型，定义明确的成功指标并建立健全的变更管理计划至关重要。 这将有助于确保转型得到有效管理，并与组织目标保持一致。 以下是 详细计划。

成功指标

最受欢迎的衡量成功的指标是行业标准的 DORA 指标。 以下列表提供了有关这些指标的更多细节，并包含一些附加指标的信息：

• DORA 指标：

  • 部署频率：衡量部署发生的频率。 更高的频率通常表示更成熟的持续测试和 部署实践。

  • 变更提前期：跟踪从代码提交到代码成功运行在生产环境中的时间。 更短的提前期是 高效流程的标志。

  • 变更失败率：监控在生产环境中部署失败的百分比。 更低的失败率通常意味着更高的质量和 更好的测试。

  • 恢复服务时间：衡量从生产环境中的故障中恢复所需的时间。 更快的恢复时间表明更好的事件管理 和可靠性。

• 附加指标：

  • 自动化测试覆盖率：自动化测试覆盖的代码百分比，目标是实现高覆盖率，以 确保质量。

  • Bug 检测率：在开发阶段检测并修复 Bug 的比率。

  • 安全事件率：跟踪安全事件的频率和严重性，以评估安全措施的改进。 安全事件的减少表明安全性得到了提高。

  • 用户反馈响应时间：响应并解决用户反馈所需的时间，反映反馈 循环的有效性。

  • 员工满意度：衡量员工对新流程和工具的满意度变化，因为这影响到采纳情况 和生产力。

变更管理计划

以下是管理 变革的良好实践：

• 沟通计划：

  • 启动会议：通过启动会议概述目标、期望和时间表，正式启动变革，确保所有利益相关者知情。

  • 定期更新：通过电子邮件、新闻通讯或专门的内联网部分提供持续更新，以保持所有相关方了解进展 和变更。

  • 反馈渠道：建立开放的渠道（如调查、论坛和会议），供员工表达关切并提供对 转型过程的反馈。

• 培训计划：

  • 初步培训课程：在转型开始时，为所有受影响的员工提供关于新工具、流程和最佳实践的全面培训。

  • 持续教育：通过研讨会、网络研讨会和电子学习课程提供 持续学习机会，以适应不断发展的工具 和方法。

  • 跨职能培训：促进不同角色和部门之间的理解，以促进协作并全面理解整个 生命周期。

• 支持系统：

  • 服务台与资源中心：设立服务台以解决技术问题，并设立资源中心，让员工可以查找文档 和工具包。

  • 变革推动者与倡导者：识别并赋能团队中的变革倡导者，他们可以提供同行支持，并推动 新实践的好处。

• 衡量成功：

  • 里程碑评审：设定具体的里程碑，如“在六个月内将自动化工具部署到所有开发团队”或“在一年内实现 75%的自动化测试覆盖率”。在 里程碑会议中回顾进展。

  • 绩效仪表盘：使用仪表盘实时监控 KPI 和指标，提供高层次和详细的持续绩效视图。

  • 持续改进会议：定期安排会议，回顾成功与失败，并根据需要规划调整策略或关注点。

建立关键绩效指标（KPI）

以下是推荐的实践，用于 建立 KPI：

• 部署频率：目标是实现 每日部署。

• 变更前置时间：目标是将变更前置时间从几个月缩短至几周，或从几周缩短至几天。

• 变更失败率：在 第一年内将失败率从基准降低 50%。

• 恢复服务时间：力争在 第一年内将恢复时间缩短 75%。

• 自动化测试覆盖率：在前 六个月内提高覆盖率 25%。

• 安全事件率：在 第一年内将事件减少 50%。

明确定义的度量标准、全面的变更管理计划以及持续的评估相结合，将引导组织实现成功的实施和 可持续的转型。

总结

本章为希望在数字转型计划中实施持续测试、质量、安全性和反馈的组织提供了关键指南。 本章首先概述了制定清晰、定制化路线图的重要性，强调了路线图与组织战略目标的对齐。 它涵盖了制定可执行计划所需的基础步骤，该计划不仅指导实施，还确保与现有组织结构 和目标的顺利融合。

本章的中间部分分为四个具体的关注领域：持续测试、持续质量、持续安全和持续反馈。 每个部分提供了将这些元素整合到软件开发生命周期中的详细策略和框架。 这包括关于培养质量和安全文化、利用工具和流程维持高标准，并建立用户和利益相关者的持续反馈渠道，以不断改进 开发过程的建议。

在本章的结尾，重点讨论了组织内部的一致性，这对于路线图的成功实施至关重要。 这包括关于如何获得利益相关者支持的实际建议，并促进组织各级之间的协作环境。 本章强调了沟通、培训和适当的支持系统的重要性，以帮助员工适应新技术 和方法。

最后，本章总结了如何通过使用具体的、可衡量的 KPI 和 DORA 指标（如部署频率和变更失败率）来衡量实施的成功。 这些指标有助于跟踪进展，确保转型与预期结果对齐，并提供实时的路线图有效性清晰视图。 这种结构化的方法不仅促进了平稳过渡，还最大化了实现数字 转型目标的机会。

下一章将探讨组织实施模式，以便向更成熟的持续测试、质量、安全性 和反馈能力转型。

第十一章：理解转型实施模式

随着组织寻求精简项目和优化团队结构，选择有效的实施模式变得至关重要。 本章深入探讨了实施模式，它是经过验证的结构化方法，旨在提高战略路线图的部署和成功，特别是对于那些希望提高持续测试、质量、安全性和反馈能力的组织。 理解这些模式使项目经理和团队负责人能够掌握选择最适合其具体目标和挑战的策略的知识。 我们将在本章中探讨什么是实施模式，并详细介绍四种不同且成功的模式。 在深入探讨这些模式时，我们还将讨论哪些策略在历史上未曾成功以及为何这些模式应当避免。 最后，我们将提供有关选择最合适的实施模式的指导，帮助您将实际标准和考虑因素应用于决策过程。

本章结束时，您不仅能够识别和理解各种实施模式，还将具备选择和有效应用这些模式的技能，以确保在组织环境中更强大、更成功的 路线图实施。

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

• 什么是转型 实施模式？

• 理解转型 实施模式

• 实施过程中需要避免的 模式

• 选择一个 实施模式

让我们 开始吧！

什么是转型实施模式？

我们将从 定义实施模式的确切含义以及它为何对成功的项目执行至关重要开始。 实施模式可以视为一种蓝图或公式，遵循它可以显著提高顺利、高效地实现项目目标的可能性。 这一基础知识为深入了解每个模式的具体特点 和优点奠定了基础。

转型实施模式是一种结构化方法，组织用它从当前的操作方法演变到更先进的状态，特别是在持续测试、质量、安全和反馈等领域。 这些模式作为详细的指南或框架，旨在帮助组织系统地改进其流程和工具，从而提高整体效率和性能。 这些模式的目标不仅仅是实施新工具或新实践，而是从根本上改变团队的协作和运作方式，确保持续改进成为 组织文化的核心部分。

转型实施模式的本质在于其结构化的变革方法。 它将转型过程分解为可管理、可执行的步骤，提供了一条清晰的路线图，组织可以按照该路线图进行操作。 这一点在处理复杂领域（如持续测试和安全）时尤为重要，因为这些领域涉及多个变量，包括技术集成、流程更新和人员培训，这些变量必须和谐统一。 通过遵循转型实施模式，组织能够以系统化的方式应对这些挑战，降低风险，避免常见的陷阱，这些陷阱可能会阻碍 他们的进展。

有效实施模式的关键组成部分

一种有效的 转型实施模式通常包括几个关键组件，如下所示 图 11**.1。

图 11.1 – 转型实施模式的组成部分

让我们来看一看 具体内容： 。

1. 利益相关者协议：成功的转型需要获得组织各级的支持。 这一组件专注于与利益相关者进行沟通，解释转型的好处，解决疑虑，并收集反馈。 有效的利益相关者参与确保转型与商业目标对齐，并获得 广泛的支持。

2. 评估与规划：此阶段涉及对组织当前的测试、质量、安全和反馈机制进行全面评估。 评估结果将用于制定详细的计划，明确转型的具体目标和实现这些目标所需的步骤。 。

3. 培训与发展：随着流程和工具的更新，员工不仅要接受新系统的培训，还要学习持续改进的原则。 这种培训确保团队成员能够有效使用新工具和新方法，并为持续的 流程优化做出贡献。

4. 迭代实现：与其一次性尝试全面改革系统，不如采用迭代方法，这也是最佳的实现模式。 这种方法使组织能够在小范围内测试新方法，根据现实反馈进行改进，并逐步将成功的做法扩展到整个 组织。

5. 持续评估与反馈：任何实现模式的重要组成部分就是持续评估转型进展情况。 这包括定期检查、指标分析和反馈会议，帮助团队了解哪些措施有效，哪些 需要调整。

虽然所有转型 模式都包含类似的组成部分，如本节所述，但不同的模式适用于不同的组织和产品。 下一节将描述如何选择适合特定组织的最佳模式。

选择正确的模式

选择正确的 转型实现模式至关重要，因为每个组织都有独特的挑战、目标和资源。 有些模式可能更侧重于技术集成，而其他模式则可能优先考虑文化变革或流程再造。 选择模式应基于对组织特定需求的深入分析，并考虑该模式在类似环境中的 proven 效果。 有效性。

例如，拥有强大 IT 基础设施但流程纪律薄弱的组织，可能更适合采用强调流程标准化和培训的模式。 相反，一个拥有强大运营流程但技术过时的公司，可能更需要关注 技术转型的模式。

选择正确模式的重要性

转型倡议的最终结果可能会因选择的实施模式而有显著差异。 选择正确的模式可以带来更顺畅的转型、更高的团队采纳率，以及测试、质量、安全和反馈机制的更大改善。 另一方面，选择不匹配的模式可能导致资源浪费、士气低落以及有限的改进，可能使组织的状况与之前无异，甚至可能变得更糟。

因此，考虑组织当前的能力、转型的具体目标以及可用模式的验证效果至关重要。 通过谨慎选择和实施，组织可以实现更高水平的运营成熟度，确保它们更好地应对日益复杂和快速发展的 商业环境。

理解转型实施模式

本章的后续部分将专门探讨四种有效的 实施模式。

专注平台团队

该 专注平台团队 结构 强调 拥有一个专注于平台开发和维护的集中的团队所带来的好处。

一个 专注平台团队，如 图 11**.2所示，由软件开发、测试、安全和运维领域的专家组成，负责平台基础设施的持续改进。

图 11.2 – 专注平台团队结构

该团队负责新技术的集成、现有流程的优化以及平台的整体维护和提升。 通过专注于平台，团队可以确保平台不仅满足当前组织的需求，而且足够可扩展和强大，能够支持 未来的需求。

团队通常与其他部门密切协调，以收集需求和反馈，确保平台在不断发展的过程中始终与更广泛的组织目标保持一致。 团队的活动可能包括自动化测试过程、加强 数据安全 措施、实施先进的分析以实现更好的反馈循环，并确保平台与各种工具 和技术兼容。

优点

• 专注和专业知识：拥有一个完全专注于平台的团队确保了高水平的专业知识，这能够带来更具创新性的解决方案和 先进的实施。

• 提升的质量和性能：团队专注于平台，可以导致更高的质量和性能，因为持续的改进和优化得以 系统性地实施。

• 更快的响应时间：团队的专门性质使得能更快地响应与技术相关的问题，减少停机时间，并提高整体的 运营效率。

• 与业务目标的更好对齐：专门的团队可以更有效地将平台开发与战略性业务目标对齐，确保技术在 各个层面支持组织需求。

• 可扩展性提高：随着组织的发展，平台能够扩展以适应新的需求，而不会干扰其他流程，这要归功于专门平台团队的集中努力。 平台团队。

缺点

• 资源密集型：组建和 维持一个专门的团队需要大量资源，包括人员和预算。 小型组织可能会发现 这具有挑战性。

• 潜在的孤立：有风险，专门的团队可能会与组织的其他部分脱节，导致理解和 目标不一致。

• 依赖性和瓶颈：其他部门可能会过度依赖专门的团队，如果团队因工作量过大或优先事项与即时 业务需求不完全对接，可能会造成瓶颈。

• 适应性挑战：平台可能会发展得过于专门化并与当前实践高度契合，以至于它对市场上引入的新技术或流程的适应性变差。 市场。

专门平台团队模式对于需要持续关注和专业知识的组织，尤其是在测试和运营需求复杂的情况下，具有特别的优势。 虽然它确实涉及 大量的投资和协调，但拥有一个强大、维护良好并持续发展的平台，其带来的好处可能远远超过其弊端。 然而，对于考虑采用这种模式的组织来说， 在专门平台团队与其他部门之间实施强有力的沟通渠道至关重要，以避免孤立，并确保平台始终与组织的整体战略目标保持一致。 组织的战略目标。

嵌入式团队

嵌入式团队 探索 同时运行多个团队的动态 和成果，每个团队负责项目的不同部分，但所有团队都朝着一个 统一的目标 努力。

嵌入式团队转型实施模式，如 图 11**.3所示，代表了一种战略方法，旨在将专门的技能和能力直接整合到运营团队中，促进敏捷性、增强协作，并在测试、质量、安全性和反馈流程的持续改进背景下，立即应用专业知识。 这一模式在动态环境中越来越受到青睐，其中快速适应和不同职能之间的紧密合作 至关重要。

图 11.3 – 嵌入式团队转型实施模式

嵌入式团队由专门的专业人员（如质量保证工程师、安全专家和反馈分析师）组成，他们直接融入功能性项目团队，而不是被划分到单独的部门中。 这些专家与开发人员、项目经理和运营人员一起，贯穿整个项目生命周期。 这种安排的主要目标是促进跨学科的项目挑战解决方法，确保测试、质量和安全的专业知识不仅仅是事后考虑，而是持续且不可或缺的 开发过程的一部分。

这种模式在采用敏捷方法论的组织中尤其有效， 因为开发和迭代速度非常快。 嵌入式专家可以立即将其技能应用于当前任务，确保从项目开始时就遵循最佳实践。

优势

• 协作改善：将专家嵌入团队内部促进了协作和知识共享的文化。 这种设置有助于打破部门之间的壁垒，促进更顺畅的沟通和 更快速的决策。

• 增强项目成果：随着质量、安全性和反馈专家的加入，项目从一开始就能享有高标准，减少了昂贵的返工或部署后安全性 漏洞的可能性。

• 更快速的响应问题：立即获得专业知识使团队能够迅速识别和解决潜在问题，防止问题升级，从而提升项目管理过程的整体敏捷性。 管理过程。

• 持续学习和改进：专家与其他团队成员的持续互动提升了整个团队的学习曲线。 非专家能够更好地理解质量、安全性和反馈方面的考虑，扩展了他们的 技能范围。

• 与业务目标的更大契合：由于专家是核心项目团队的一部分，他们更能将战略行动与整体业务目标对齐，确保所有努力直接有助于 组织目标。

劣势

• 资源密集型：保持每个项目团队内部的高水平专业知识可能需要大量资源。 较小的组织可能会面临缺乏足够专家来覆盖 所有团队的困难。

• 倦怠的潜在风险：嵌入多个团队或项目的专家可能面临时间和专业知识的高需求，从而导致倦怠和 效率降低。

• 知识孤岛的风险：尽管该模型旨在整合知识，但仍然存在嵌入式专家成为专业知识的守门人而非传播者的风险，这可能导致团队内部出现新的孤岛。 孤岛现象。

• 协调复杂性：在多个项目中管理多个嵌入式专家可能会导致协调问题，尤其是在大型组织中，存在众多 进行中的 项目。

嵌入式团队模式为将专业知识直接融入项目团队提供了一个强有力的框架，促进了合作环境的形成，并能立即应用关键技能。 这种模式在重视敏捷性和快速迭代的环境中尤其有效，例如使用敏捷方法的环境。 然而，这种方法需要谨慎管理，以避免资源过度扩展，并确保紧密整合的优势不会转化为新的 挑战。 考虑这种模式的组织应权衡增强合作和项目成果的优势，与资源管理和 专家疲劳的潜在挑战。

外包团队

第三种模式 是 外包团队，该模式利用外部专业知识和资源来加速 项目完成。

外包团队转型实施模式，如图所示，图 11**.4，是一种将某些职能或项目委托给外部组织或团队，而不是内部处理的方法。 这种模式通常在需要特定专业知识或在利用外部资源可能更加具备成本效益的情况下采用。 在增强组织在持续测试、质量、安全性和反馈方面的能力的背景下，外包团队可以通过带来新的见解和专业技能提供战略优势，这些技能在内部可能无法获得。

图 11.4 – 外包团队转型实施模式

外包团队通常由第三方服务提供商或顾问组成，他们被聘请负责管理和执行项目或运营职能中的特定任务。 这可能包括软件测试、网络安全措施、质量保证以及收集和分析用户反馈。 根据组织的需求，这种安排可以设定为临时的项目合同或长期的服务协议。

组织选择这种模式是为了利用供应商的专业知识，这些供应商在各自的领域中处于领先地位，并卸载非核心活动，使内部团队能够专注于战略 目标。 这些 外包团队与内部团队并行工作，通常由项目经理或协调员监督，确保所交付的服务符合组织的标准 和期望。

优势

• 访问专业知识：外包 让组织能够接触到一群 能够提供高水平技能和知识的专家，这些知识或技能在内部缺乏，或者在经济上不具备开发的可行性。

• 成本效益：外包团队在短期项目或高度专业化任务中，往往比雇佣全职员工或为现有员工投入大量培训更具成本效益。

• 可扩展性：外包团队可以根据业务当前的需求进行扩展或缩减，提供了特别在需求波动的环境中 具有价值的灵活性。

• 专注于核心竞争力：通过外包非核心活动，组织可以将资源和精力集中在那些提供最大战略价值和 竞争优势的领域。

• 风险缓解：利用经验丰富的外包团队可以帮助缓解风险，尤其是在 IT 安全等复杂领域，因为错误的代价可能 非常高。

劣势

• 控制和协调挑战：管理外包团队，特别是那些位于不同的时区或有不同文化背景的团队，可能会导致沟通 和协调方面的挑战。

• 质量风险：根据外包提供商的承诺和能力，可能会存在与工作质量相关的风险，这可能导致额外的监督和 管理成本。

• 安全问题：与外包团队共享敏感信息或关键基础设施组件可能带来安全风险，特别是当外包公司没有严格遵守 安全协议时。

• 依赖性：过度依赖外包团队可能会导致依赖性问题，如果外包关系突然结束，或者服务提供商的 情况发生变化，可能会带来问题。

• 文化和组织的不一致性：雇佣公司与外包服务提供商之间的工作文化和组织目标的差异，可能导致误解和 产出不一致。

外包团队模式为那些希望提升特定领域能力的组织提供了一个实用的方案，无需在内部开发这些能力。 它提供了对专业技能的访问、潜在的成本节省和灵活性。 然而，这种模式的成功在很大程度上取决于外包伙伴的选择，以及合同协议和管理监督的强度。 选择正确的模式需要仔细评估组织的需求、风险和战略目标。 当外包得当时，它可以成为组织转型战略的重要组成部分，特别是在快速高效地扩展操作，如持续测试、质量 和安全性等领域。

混合专属/外包团队

第四种也是最后一种 模式， 混合专属/外包团队结合了 专属内部团队与外包支持的元素，以平衡控制、创新、 以及可扩展性。

混合专属/外包团队转型实施模式，如图 11**.5所示，融合了内部专业知识与外部资源的优势，以促进全面的项目管理与执行方法。 该模式在不断测试、质量保证、安全性和客户反馈等复杂领域日益流行，尤其是在那些力求提升能力，同时管理成本并保持对 关键流程控制的组织中。

图 11.5 – 混合专属/外包团队转型实施模式

混合专职/外包团队由核心内部成员组成，他们与外部专家紧密合作，以满足特定项目要求。 内部团队通常由具备关键组织知识和技能的员工组成，并与公司文化和长期目标保持一致。 该团队由外部专家补充，外部专家提供的专业技能、创新技术或成本效益可能是 内部无法获得的。

这一模式使组织能够保持一支强大的专职员工队伍，同时根据需要战略性地利用 外部 资源来提升产能或能力。 它有效地平衡了专职团队的控制和熟悉度，以及 外包服务的可扩展性和专业化。

优点

• 平衡控制和专业知识：这种模式在通过 专职团队保持对关键流程的控制和通过 外包合作伙伴获取专业技能和新技术之间提供了平衡。

• 成本效益：通过外包非核心或高度专业化的任务，组织可以优化成本，而不影响工作质量或内部团队的战略重点。

• 灵活性和可扩展性：混合模型使组织能够根据项目需求灵活地扩大或缩小运营规模，而无需长期承诺雇佣全职员工或承担完全外包 关键职能的风险。

• 增强创新：接触外部专家可以带来新的视角和创新的解决方案，这些可能是组织内部无法产生的，从而促进创造力 和问题解决。

• 风险管理：将任务分配给专职团队和外包团队有助于降低风险。 如果外包提供商未能交付，内部团队可以介入管理或解决问题，确保持续性 和稳定性。

缺点

• 复杂的协调：管理一个混合团队需要强有力的协调和沟通策略，以确保内部和外部团队成员达成一致并 协同工作。

• 文化差异：将外部资源与内部团队整合可能会导致工作文化上的冲突，这可能会影响团队的动态和项目结果。

• 质量可变性：外包可以带来专业技能，但也可能导致质量的可变性，这取决于外部供应商的标准以及内部团队提供的监督。

• 依赖外部合作伙伴：过度依赖外部供应商，特别是对于专业技能的依赖，可能会带来风险，特别是在外包关系被中断时。

• 安全性和保密性风险：共享敏感信息并授予访问内部系统的权限可能会使组织面临更高的安全性和保密性风险。

混合专用/外包团队模式为那些希望提升运营能力，同时在关键过程中保持战略控制的组织提供了务实的解决方案。它结合了专用团队的深度和外包的广度，提供了灵活性、成本效益以及对专业技能的访问。然而，这种模式的成功在很大程度上取决于有效的整合策略、强有力的管理实践以及谨慎选择外包合作伙伴。

总结来说，虽然某些实施模式比其他模式更为理想，但选择正确模式的重要性不容忽视。它确保了组织的转型不仅高效进行，而且能够有效地与组织的更广泛目标对接并支持这些目标。

在实施过程中需要避免的模式

在提升组织能力的过程中，特别是在持续测试、质量、安全性和反馈等领域，如图 11.6所示，某些实施模式已被证明持续效果较差，甚至有害。识别并避免这些不利的实施模式，与采纳有效模式同样重要。

图 11.6 – 需要避免的模式

以下是一些常见的模式以及它们的缺点的详细解释：

• 孤岛式部门团队：孤岛式的部门团队独立运作，部门间互动和沟通很少。 每个部门仅专注于自己的职能，未将活动与更广泛的组织目标相结合。 其缺点如下：

  • 沟通不足：部门之间的孤岛现象会造成沟通障碍，导致各部门目标不一致。 这会妨碍信息流动，影响 有效的决策制定。

  • 低效：可能会出现重复工作和重新发明其他部门已经开发过的解决方案，导致低效和 资源浪费。

  • 响应延迟：当出现需要跨部门合作的问题时，响应可能会迟缓且繁琐，影响组织整体的敏捷性。

• 过度依赖外包团队：这种现象出现在组织过度依赖外部实体处理关键职能和流程，而未保持足够的 内部专业知识。 其缺点如下：

  • 失去控制：过度依赖外包团队可能导致对关键业务流程失去控制，进而可能削弱组织做出 敏捷决策的能力。

  • 知识流失：组织可能会失去内部的能力和制度化知识。 长期来看，尤其是在外包合约结束时，这可能会带来严重后果。

  • 安全风险：将敏感数据和流程委托给第三方提供商会增加数据泄露和 安全漏洞的风险。

• 自上而下的等级式实施：这种模式的特点是决策和实施流程自组织高层向下流动，缺乏来自低层员工的充分意见或参与。 其缺点如下：

  • 抗拒变革：从上而下强行施行变革而不考虑执行者的参与，往往会遭遇抗拒，进而降低 实施效果。

  • 缺乏创新：低层员工通常更接近日常运营，可能会有创新的想法，但因为缺乏向上沟通的机制而被忽视。 在自上而下的组织结构中，可能会存在提出新想法的恐惧。 在自上而下的组织结构中，提出新想法可能会存在恐惧。

  • 适应性缓慢：自上而下的方法的僵化可能会阻碍组织迅速适应市场变化或 内部 挑战。

• 固定团队且无交叉培训：这种模式下的团队在固定角色中工作，承担特定任务， 几乎没有任何交叉培训成员的努力，尤其是在团队内其他职能或角色的培训方面。 其缺点如下： 缺点如下： 缺点如下：

  • 脆弱性：缺乏交叉培训可能导致脆弱性，尤其是当关键团队成员不可用时，其他人无法有效地代替 他们的角色。

  • 团队灵活性下降：团队技能的缺乏多样性可能限制团队适应新挑战或项目范围变化的能力。

  • 技能发展的停滞：如果员工被限制在单一角色或任务范围内，可能会觉得自己的成长和学习受到压制，从而导致工作满意度下降和 员工流失率上升。

• 项目孤立：在这种模式下，项目彼此独立管理，未共享经验、资源或协同效应 。其缺点如下： 缺点如下：

  • 重复造轮子：每个项目团队可能最终会解决已经被其他人处理过的问题，浪费时间 和资源。

  • 错失协同效应机会：孤立的项目无法利用组织的集体知识和资源，错失潜在的效率提升。 这可能导致瓶颈，限制组织的能力和流动性。 这可能导致瓶颈，限制组织的容量和流动性。

  • 标准和质量的不一致：缺乏统一的方法，不同项目可能采用不同的标准和实践，导致组织内 的质量和表现不一致。 导致组织内的质量和绩效不一致。

避免这些不利的实施模式对于构建一个有韧性和适应性的组织至关重要。 通过促进开放的沟通，保持平衡的外包策略，鼓励跨职能团队合作，并推动项目之间的整合，组织可以提高其运营效率，并能更快速地适应新的挑战和机遇。 这些模式突出了战略决策在组织变革中的重要性，强调了需要仔细设计和管理决定团队和项目结构及执行方式的流程。 并加以执行。

选择实施模式

选择正确的实施模式对于旨在提高运营能力的组织至关重要，特别是在持续测试、质量、安全性和反馈流程的领域。 该过程如图 11**.7所示，涉及对组织需求、现有能力和 战略目标的仔细考虑。

图 11.7 – 选择实施模式

以下是一个详细的推荐过程，旨在指导组织选择与其特定情况和目标相一致的有效实施模式：

1. 评估组织需求 和能力：

   • 客观评估：从 对组织当前状态的全面评估开始。 这包括评估现有的流程、资源和 技术。 识别 优势、劣势、机会和威胁 (SWOT 分析) 以了解组织的现状以及它需要改进的地方。

   • 识别目标：清晰定义组织在变革过程中希望实现的目标。 目标应当是 具体、可衡量、可实现、相关且有时限 (SMART)。 这可能包括加快发布周期、提高产品质量、增强安全措施或优化 反馈机制。

   • 技能和资源清单：列出可用的技能和资源。 这有助于确定组织是否具备所需的内部能力，或是否需要寻求外部支持来填补空白。

2. 理解不同的 实施模式：

   • 研究模式：收集关于在类似组织或行业中成功的各种实施模式的详细信息。 这项研究应包括案例研究、最佳实践，甚至是从较少成功的实施中总结的经验教训。

   • 咨询利益相关者：与各方利益相关者进行沟通，包括 IT 人员、项目经理、部门负责人，甚至可能包括客户。 他们的见解可以为什么最适合组织提供宝贵的视角。

   • 专家咨询：咨询专注于组织转型的外部专家或顾问可能会很有帮助。 他们可以提供公正的建议，并分享来自各种项目的经验。

3. 评估适用性 和契合度：

   • 与目标对齐：将每个实施模式与组织预定义的目标相匹配。 评估每个模式在当前和未来的组织状态下，如何有效地实现这些目标。

   • 可行性研究：对每个潜在模式进行可行性研究。 分析实施这些模式的后勤、财务和技术方面。 此研究还应考虑每个模式的潜在风险及其缓解策略。

   • 试点测试：如果可能，为最有前景的模式进行试点测试。 试点测试可以提供关于模式在组织中如何运作的实际见解，并揭示在全面推广前需要进行的调整。

4. 决策制定：

   • 集体决策：利用一个包含所有相关利益相关方代表的决策机构或委员会。 该小组可以审查可行性研究和试点测试的结果，以做出明智的决策。

   • 使用决策矩阵：使用决策支持工具，如决策矩阵，权衡成本、影响、风险及与战略目标的一致性等因素。 这些工具有助于做出 客观决策。

   • 反馈循环：在决策过程中建立反馈机制，确保所有问题和见解得到充分考虑 并加以解决。

5. 计划实施：

   • 详细规划：一旦选定了实施模式，制定详细的实施计划。 该计划应列出所有必要的步骤、时间表、资源分配， 以及责任分工。

   • 变更管理：制定变更管理策略以帮助管理过渡。 这应包括沟通计划、培训项目和支持结构，确保所有 相关方的顺利过渡。

   • 风险管理：识别与实施相关的潜在风险，并制定应对策略以减少这些风险。 这可能涉及应急计划的制定，并为处理问题设立升级路径， 以应对问题的出现。

6. 持续监控 与适应：

   • 进度监控：定期监控实施进度，并与设定的目标和时间表进行对比。 使用 关键绩效指标 (KPI) 来衡量成功并识别需要改进的领域。

   • 迭代改进：根据反馈和持续评估的结果，准备进行迭代改进。 这种适应性方法有助于优化实施过程，并使其更好地与 组织需求对接。

选择合适的实施模式需要一种系统化和深入的方式，考虑到组织的独特背景和目标。 通过仔细评估需求，理解现有模式，评估其契合度，并为实施做好周密规划，组织可以显著提高转型成功的机会。 这一结构化的选择过程不仅有助于选择最合适的模式，还能确保其在 组织内部的有效整合与可持续性。

总结

第十一章 提供了一个全面的实施模式探索，旨在帮助那些希望在持续测试、质量、安全性和反馈方面提升能力的组织。 本章首先定义了什么是实施模式——它本质上是一种蓝图，遵循它可以有效且高效地提高项目目标的实现可能性。 讨论强调了这些模式在确保项目成功执行中的关键作用，并为深入审视各种有效模式及那些应当避免的模式奠定了基础。

本章突出了四种主要的成功实施模式：专门的平台团队、嵌入式团队、外包团队和混合的专门/外包团队。 每种模式都进行了详细描述，提供了它们独特优势的洞见，并说明了它们如何促进组织项目的成功。 例如，本章解释了专门平台团队模式专注于平台开发的集中管理，确保高质量和高性能，而嵌入式团队则促进了项目中不同职能之间的敏捷性和紧密协作。 外包团队带来了外部专业知识和灵活性，而混合团队则结合了内部和外包资源的优势，以优化 项目执行。

本章还讨论了组织应当避免的实施模式，如孤立的部门团队、过度依赖外包团队、自上而下的层级实施、固定团队无跨部门培训以及项目孤立等。 每种模式都分析了其缺点，如低效、风险增加以及在动态商业环境中的挑战。 重点是理解这些模式为什么会妨碍进展，以及它们如何对组织的适应能力和创新能力产生负面影响。

本章提供了关于如何根据组织的具体需求、目标和资源选择最合适的实施模式的实用指导。 这一指导对决策者至关重要，确保所选择的模式能够与战略目标和运营需求良好对接。 下一章将以此为基础，探讨如何有效衡量进展和成果，确保组织能够监控实施模式的成功，并根据需要做出调整，以实现其转型目标。

第十二章：衡量进展和结果

本章重点介绍了在组织实施和改进其持续测试、质量、安全性和反馈能力时，测量进展和结果的重要方法和框架。 随着企业和项目变得更加复杂，能够衡量事物进展如何以及预测未来结果变得至关重要。 本章解释了如何创建、选择和使用能够准确显示进展并为管理层和 持续改进提供有用见解的衡量标准。

第一部分概述了持续测试、质量、安全性和反馈的不同类型的衡量标准。 然后，我们将讨论如何选择适用于结果和进展的正确衡量标准。 接下来，我们将进入实施这些衡量标准的部分，并探讨如何设置既能提供信息又能激励行动的指标和仪表盘。 它们不仅仅是告知 —— 它们 激励行动。

我们将通过讨论如何确保这些衡量标准在时间上保持有效，提供更新和维护它们的策略，使其在组织成长和变化时持续提供支持，来结束本章。 本章将帮助你掌握不仅能选择有效的衡量标准，还能应用和维护它们的技巧，持续为 你的工作增值。

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

• 进展的衡量 和结果

• 选择衡量标准

• 设计衡量标准 和仪表盘的实践

• 持续进展的衡量 和结果

让我们 开始吧！

进展和结果的衡量标准

在本节中，我们 将了解什么使得一个衡量标准有效，并且如何使其与组织的目标保持一致。 通过探索不同的衡量标准，你将为后续讨论如何选择和使用 这些指标奠定坚实基础。

经历持续测试、质量、安全性和反馈的转型过程的组织，需要跟踪两种关键的衡量标准 —— 进展 和 结果。这些衡量标准对于理解组织如何适应和改进其过程至关重要，并且有助于确保这些变化能积极地促进其 整体目标的实现。

图 12**.1 展示了这两种类型的衡量标准，以 图表形式呈现。

图 12.1 – 进展与结果指标图表

进展指标通常以燃尽图的形式表示，其中下降的趋势是可取的，因为它们表示剩余的项目单位数量。 结果指标通常以趋势线的形式表示，其中上升的趋势是可取的，因为 它们表明绩效的提高。

下一节将解释进展和结果衡量的重要性。 以及成果衡量。

为何进展和结果衡量重要

进展和结果衡量之所以重要，有几个原因，包括战略对齐与决策、绩效监控、展示价值以及帮助打造 学习型组织。

• 战略对齐与决策：了解转型项目和举措的进展有助于公司做出更好的决策，决定将资源集中在哪里。 这确保了每一项努力都为 组织的更广泛目标做出贡献。

• 绩效监控：组织需要定期检查是否走在正确的轨道上，以实现其目标。 进展衡量通过展示 已完成多少工作以及剩余多少工作来提供帮助。 这在更新和改进不断进行的环境中尤为重要，例如软件开发 或网络安全。

• 展示价值：结果指标可以告知公司所做的任何变化是否达到了预期效果。 这不仅对内部记录很重要，还能向外部利益相关者（如客户或投资者）展示公司在不断改进，值得 投资。

• 组织学习：这两类衡量指标提供了宝贵的反馈。 这些反馈帮助公司从成功与失败中吸取教训，进而进行更好的规划和更有效的风险管理 。

接下来，我们将解释如何将绩效和进展衡量与 组织的能力成熟度挂钩。

将衡量标准与能力成熟度联系起来

组织中的能力成熟度概念，如在第四章中所述，关系到其持续交付预期结果的能力。进度和结果措施是这一点的重要组成部分，因为它们帮助组织了解当前的成熟度水平，如在第四章中所描述，并识别改进领域。例如，随着组织的成熟，它应当看到来自其流程的更可预测和积极的结果，这些结果应在其跟踪的措施中有所体现。随着时间推移跟踪这些措施，可以显示组织能力成熟度的演变。图 12 .2 描述了进度和结果措施的重要因素及利益相关者。

图 12.2 – 测量对利益相关者的重要性

以下内容解释了为什么这些措施对于各方利益相关者至关重要：

• 业务经理：这些经理查看结果措施，以了解变革是否对企业的底线产生积极影响。他们使用进度措施来确保战略项目按计划进行。

• 技术经理和开发人员：他们依赖进度措施来规划和调整工作负载和时间表。结果措施帮助他们了解技术解决方案是否有效地解决了他们需要解决的问题。

• 质量保证（QA）工程师：QA 团队使用这些措施来跟踪和改进测试流程。他们需要知道产品质量是否符合设定标准，而这直接与结果措施相关。

• 安全运营人员：对于这些团队，结果措施可能包括减少安全事件的数量等指标。进度措施帮助他们衡量安全协议和培训的实施情况。

• DevOps 和 SRE 工程师：这些工程师使用两种类型的措施来优化软件的部署和运行。进度措施帮助他们监控持续交付管道，而结果措施则评估生产环境中软件的稳定性和性能。

总结来说， 进度和结果的衡量标准提供了一种结构化的方法来跟踪组织实施变更和取得成果的效果。 它们为各种利益相关者提供了至关重要的见解，帮助从业务经理到技术团队的各方做出推动组织前进的明智决策。 有效理解和利用这些衡量标准，可以带来更好的战略对齐、提升的绩效，以及能够交付一致结果的成熟能力。 成熟的交付能力。

结果指标示例

结果指标 是软件开发、交付和运维中的重要工具。 它们帮助团队跟踪在构建和维护软件的各个阶段的表现。 这些指标关注测试、质量、安全和反馈等领域，以确保从规划到运维的每个阶段都达到设定标准，并不断改进。 随着时间的推移不断提升。

所有阶段通用的结果指标

DevOps 研究与评估小组 创建了一套被称为 DORA 的指标，它 是四个关键绩效指标的集合，已成为衡量软件开发和运维团队效果的行业标准。

这些由 DORA 推荐的指标具有广泛适用性，并为开发过程的整体健康和效率提供了深刻见解： 开发过程的健康度：

• 部署频率（DORA）：计算软件部署到生产环境的频率。 软件部署频率。

• 变更周期时间（DORA）：衡量从代码提交到部署的时间。 代码提交到部署时间。

• 变更失败率（DORA）：计算失败的部署占总部署的百分比。 部署失败率。

• 恢复平均时间（MTTR）（DORA）：衡量从故障中恢复所需的平均时间。 失败恢复时间。

• 可用性：跟踪应用程序在没有问题的情况下的可用时间百分比。 无故障运行时间。

图 12**.3 展示了结果指标在价值流的每个阶段都有应用。 每个阶段的价值流。

图 12.3 – 所有阶段通用的结果指标

DORA 指标的重要性 DORA 指标的重要性

DORA 指标 很重要，因为它们 提供了一个客观的结果衡量标准，包括 DevOps 性能指标、改进基准和与业务目标的对接， 如下所示：

• DevOps 性能的客观衡量：DORA 指标提供了定量数据，组织可以用来客观评估其 DevOps 实践的表现。 这些指标在各类组织中得到了验证，并显示出与更高的软件交付表现和 组织表现的相关性。

• 改进基准：通过基于这些指标建立基准，组织可以评估当前的表现，并识别需要改进的领域。 这将有助于更有针对性地投资于技术、流程和培训，最终提升开发 和 运营实践的效率与效果。

• 与业务目标的对接：在 DORA 指标上表现优秀通常与更高的组织效率、更好的产品质量、更快的市场发布速度以及更高的客户满意度相关。 这些方面对于实现更广泛的业务目标至关重要，如增长、盈利能力和 竞争优势。

DORA 指标在软件价值 流阶段

DORA 指标，经过 一些调整后，可以应用于整个端到端价值流和价值流中的每个阶段， 如下所示：

• 需求阶段：虽然 DORA 指标通常与软件开发生命周期中的部署阶段更为对接，但它们通过确保后续流程的流畅和高效，间接影响需求阶段，从而实现更快速、更可靠的需求变更 和部署。

• 开发和持续集成阶段：如前所述，DORA 指标通常与软件开发生命周期中的部署阶段更为对接。 通过一些逻辑调整，DORA 指标可以用于衡量开发和持续集成阶段的效果，例如 以下内容：

  • 变更的提前时间 反映了开发过程的效率，包括代码更改的集成、测试和准备 发布的速度。

  • 部署频率 在这些阶段中可以指示 CI/CD 管道的健康状况，显示持续测试实践的成熟度，以及集成和潜在发布的频率，即使它们仅限于预发布环境而非生产环境。

• 持续交付与 部署阶段：

  • 部署频率 直接衡量部署发生的频率，这在这些阶段至关重要。

  • 变更失败率 提供了 SDLC（软件开发生命周期）实践和部署过程的成熟度与质量的洞察，表明部署导致需要快速修复的操作中断的频率。

  • MTTR（平均修复时间）在这里至关重要，因为它显示了团队在代码部署到生产环境或 预发布环境后迅速解决问题的能力。

• 运营阶段：

  • MTTR 在运营阶段表现突出，通过衡量操作弹性和在事件发生后迅速恢复服务的能力。

  • 变更失败率 还帮助评估生产环境的稳定性，因为频繁的失败可能表明来自价值流早期阶段的系统性问题。

通过提供这些关键方面的清晰图景，DORA 指标帮助组织不仅衡量结果，还理解价值在整个软件开发生命周期中的流动。 它们使团队能够对实践进行迭代和改进，推动与技术和 业务结果一致的持续改进周期。

持续测试结果指标

持续测试确保 软件的每个部分在开发的每个阶段都经过测试，以便尽早发现并修复问题。 这些指标的示例在 图 12**.4 中说明，并按以下方式描述：

图 12.4 – 按阶段划分的持续测试结果指标

• 需求阶段： 测试用例创建速度 – 衡量为新需求创建测试用例的速度。

• 开发阶段： 代码覆盖率 – 计算自动化测试覆盖的代码库百分比。

• CI 阶段： 构建通过率 – 跟踪通过所有测试的构建百分比。

• 连续交付阶段： 测试自动化率 – 衡量自动化测试的比例。

• 连续部署阶段： 部署健康检查 – 基于自动化的部署后健康检查评估部署的成功。

• 连续运维阶段： 部署后测试速度 – 衡量部署后测试的执行速度和结果返回的速度。

如您 从 图 12**.4中所见，某些连续测试指标最适合在软件价值流的特定阶段应用。 在下一部分，我们将看到这一点同样适用于连续 质量指标。

连续质量结果指标

如 图 12**.5所示，连续质量指标专注于在 软件的生命周期中维持高标准。

图 12.5 – 按阶段划分的连续质量结果指标

• 需求阶段： 需求清晰度指数 – 评估项目需求的清晰度和可理解性。

• 开发阶段： 缺陷发现率 – 跟踪开发过程中发现缺陷的速度。

• 连续集成阶段： 集成错误率 – 衡量集成阶段期间错误的发生频率。

• 连续交付阶段： 发布质量评分 – 根据预定义标准评估软件发布的质量。

• 连续部署阶段： 用户体验评分 – 跟踪部署后影响用户体验的活动。

• 持续运营阶段： 系统停机时间 – 衡量由于质量问题导致的系统非操作时间总时长。

正如您所看到的，在每个价值流阶段有一个持续质量指标是一种良好的做法。 持续安全指标同样适用。

持续安全结果指标

安全指标，如 图 12**.6所示，确保在每个阶段，软件都能抵御威胁。

图 12.6 – 各阶段的持续安全结果指标

• 需求阶段： 安全需求完成度 – 跟踪安全需求在 规划阶段的完成情况。

• 开发阶段： 每行代码的漏洞数量 – 衡量与代码库规模相关的安全漏洞数量。

• 持续集成阶段： 安全扫描通过率 – 衡量在集成过程中常规安全扫描的通过百分比。

• 持续交付阶段： 关键安全问题率 – 跟踪交付前发现的关键安全问题的比例。

• 持续部署阶段： 安全事件响应时间 – 衡量在部署后处理安全事件的速度。

• 持续运营阶段： 持续安全合规率 – 衡量持续符合安全标准 和规定的程度。

如本节所述，推荐在每个 价值流阶段 使用持续安全指标。 下一节将展示这同样适用于持续 反馈指标。

持续反馈结果指标

反馈指标，如 图 12**.7所示，用于评估组织在整个 开发过程中，收集和实施用户反馈的效果。

图 12.7 – 按阶段划分的持续反馈结果指标

• 需求阶段: 反馈整合效果 – 衡量用户反馈在需求中整合的效果。

• 开发阶段: 开发者对反馈的响应时间 – 跟踪开发者在开发过程中，如何迅速回应反馈。

• 持续集成阶段: 反馈解决率 – 衡量在集成过程中，反馈问题的解决率。

• 持续交付阶段: 反馈影响得分 – 评估实施反馈后对软件质量的影响。

• 持续部署阶段: 部署后的客户满意度 – 衡量在部署新功能或修复后，客户的满意度水平 。

• 持续运营阶段: 长期反馈趋势 – 分析用户反馈在运营阶段的趋势，以指导 未来的改进。

总体而言，结果指标 帮助团队从头到尾监控并提升软件的效率、安全性和质量，确保价值流的每个阶段都能被衡量，并能够优化以满足用户需求和 商业目标。

进度指标示例

进度指标 对于跟踪转型和软件开发项目的进展至关重要。 它们 帮助团队在软件生命周期的不同阶段，监控其工作的效率和效果。 这些指标特别设计用于衡量项目在测试、质量、安全性等方面，如何按照计划的时间表、目标和基准进行推进。 以及反馈。

所有阶段的常见进度指标

进度指标 在软件开发中扮演着至关重要的角色，为团队提供实时的项目进展和效率洞察。 这些指标帮助跟踪软件生命周期各个阶段的进展，包括测试、质量、安全性和反馈，确保项目能够按时完成并达到 既定的基准。

这些指标，包括关键流程指标（如在 图 12**.8中所示），帮助团队监控整体项目健康状况和进展，确保时间表和生产力目标 得到实现。

图 12.8 – 价值流各阶段相关的进度指标

以下是一些有用的进度指标和 可视化工具示例：

• 冲刺燃尽图：显示冲刺中的剩余工作与时间的关系，指示团队是否 按计划进行。

• 发布燃尽图：衡量与发布计划时间线相比，剩余工作的量。

• 累积流量图（流程指标）：可视化不同开发阶段中的工作量，帮助识别瓶颈并理解工作平衡和流动情况。 通过系统实现这一目标。

• 速度：评估团队在一次冲刺中完成的工作量，这对于未来的 冲刺规划非常有用。

• 进行中的工作（WIP）限制（流程指标）：设置任何时刻可以进行的最大任务数量，帮助团队管理工作负载并 减少瓶颈。

• 周期时间（流程指标）：衡量工作从开始到完成所需的时间，提供有关 过程效率的洞察。

流程指标是用来衡量工作项在软件开发生命周期中各个阶段流动的关键指标。 这些指标侧重于软件交付过程的效率、效果和可预测性。

流程指标的重要性

流程指标 帮助组织了解工作如何从初步构想到交付阶段进行，以一种可衡量和 可操作的方式：

• 增强可见性：流程指标提供了当前工作过程状态的清晰可见性。 通过跟踪工作项的进展，团队可以识别瓶颈或延迟发生的地方，并了解其 根本原因。

• 提高效率：通过流程指标获得的洞察，组织可以简化流程、消除低效环节，并优化资源分配。 这将有助于更快速的开发周期和更高效地使用时间 与资源。

• 提高可预测性: 流程指标使团队能够根据历史数据预测未来表现。 这种可预测性有助于更好地计划和预测，减少在 交付时间表中的不确定性。

• 促进持续改进: 定期测量和分析流程指标，鼓励持续改进的文化。 团队可以根据可量化的数据逐步完善其流程，追求更精益和更 高效的工作流程。

• 与业务目标的对齐: 通过提高效率和可预测性，流程指标有助于确保软件交付与更广泛的业务目标对齐，如增加客户满意度、缩短上市时间和提高 产品质量。

在软件价值流程各阶段中流程指标的推荐应用的详细信息

以下详细介绍了在 软件 价值流程中每个阶段推荐应用流程指标的细节：

• 需求阶段:

  • 工作项年龄: 衡量一个需求在被批准之前讨论的时间长短。 这一指标有助于识别价值流程的早期阶段的延迟。

  • 流程效率: 活动工作时间与总经过时间的比率。 在这个阶段低效率可能表明需求定义过程中等待时间过长或者决策不明确。

• 开发阶段:

  • WIP: 限制同时进行的任务数量，以减少上下文切换，并专注于更快地完成 任务。

  • 周期时间: 衡量从开发开始到完成工作所需的时间。 监控周期时间有助于识别减速因素，并提高 开发人员的生产力。

• CI/CD 阶段:

  • 吞吐量: 跟踪在给定周期内通过 CI/CD 管道的工作项数量。 高吞吐量表示一个健康的 CI/CD 管道。

  • 交付时间: 从工作项启动到交付的时间。 它包括周期时间和所有形式的延迟。 在这个阶段缩短交付时间对于 更快的发布至关重要。

• 部署与 运维阶段：

  • 发布频率：衡量新版本发布到生产环境的频率。 频繁的发布可能表明从开发到部署的流程顺畅。

  • MTTR：虽然传统上是 DORA 度量指标，MTTR 在 流程度量的背景下有助于衡量团队从生产环境故障中恢复的速度，反映了 运营灵活性。

在所有阶段，流程度量的应用提供了清晰、数据驱动的视角，帮助了解任务进展、问题出现的地方以及需要改进的方面。 这种深度洞察对任何正在进行转型并致力于持续提升软件交付和运营能力的组织来说都是无价的。 通过衡量和优化软件价值流的每个阶段，组织可以实现价值流向客户的更顺畅、更快速、更可靠。

持续测试进度度量

持续测试中的进度度量，如 图 12**.9所示，跟踪测试的开发与执行，确保及时的质量评估。

图 12.9 – 持续测试进度度量

• 需求阶段： 测试用例准备进度 – 跟踪已准备的测试用例百分比与计划总数之比。

• 开发阶段： 测试执行进度 – 衡量已执行测试的百分比与计划测试的总数之比。

• 持续集成阶段： 构建集成进度 – 跟踪成功集成的数量与计划集成的比率。

• 持续交付阶段： 测试自动化进度 – 监控已自动化测试的百分比与目标的比率。

• 持续部署阶段： 部署进度跟踪 – 衡量部署的频率和成功率与计划的比率。

• 持续运营阶段： 监控系统实施进展 – 跟踪系统监控工具的实施和微调。

在这里，我们 回顾了连续测试的推荐进展指标。 在下一节中，我们将对连续质量进展指标做同样的分析。

连续质量进展指标

连续质量进展指标，如图所示 图 12**.10，专注于跟踪确保和提升产品质量的努力进展 ，贯穿产品的整个生命周期。

图 12.10 – 连续质量进展指标

• 需求阶段： 需求审查完成度 – 跟踪项目需求的审查和批准百分比。

• 开发阶段： 代码审查覆盖率 – 跟踪已审查的新代码百分比。

• CI 阶段： 代码质量提升 – 衡量代码质量指标随时间的改进情况。

• 持续交付阶段： 发布前测试完成度 – 跟踪发布前计划测试的完成百分比。

• 持续部署阶段： 部署后质量检查 – 跟踪每次部署后的质量检查完成情况。

• 持续运营阶段： 质量指标监控 – 跟踪按照计划监控的运营质量指标百分比。

在这里，我们 回顾了跟踪连续质量进展的指标。 接下来，我们将讨论用于展示持续安全进展的指标。

连续安全进展指标

连续安全进展指标，如图所示 图 12**.11，专注于监控安全措施在整个 开发过程中整合和改进的进展。

图 12.11 – 连续安全进展指标

• 需求阶段: 安全计划完成度 – 衡量安全计划的完成程度。

• 开发阶段: 安全集成进度 – 跟踪安全功能集成到产品中的进展。

• 持续集成阶段: 安全测试执行 – 衡量计划的安全测试已执行的百分比。

• 持续交付阶段: 安全审计完成度 – 衡量交付前安全审计的完成情况。

• 持续部署阶段: 安全部署检查 – 跟踪部署过程中安全检查的完成情况。

• 持续运营阶段: 安全更新实施 – 衡量安全更新和补丁的实施率。

在这里，我们 查看了用于展示持续安全进展的度量标准。 接下来的部分将建议用于展示持续反馈进展的度量标准。

持续反馈进度度量

如图所示，持续反馈进度度量，如 图 12**.12，评估了在整个开发过程中，反馈收集和处理的效率。

图 12.12 – 持续反馈进度度量

• 需求阶段: 反馈收集完成度 – 跟踪计划的反馈收集活动的完成百分比。

• 开发阶段: 反馈实施进度 – 衡量将反馈融入 开发过程的进展。

• CI 阶段: 反馈集成率 – 跟踪反馈在集成测试期间的集成速率。

• 持续交付阶段: 反馈审查完成度 – 衡量交付前完成的反馈审查任务的百分比。

• 持续部署阶段： 客户反馈分析 – 衡量部署后客户反馈分析的完成情况。

• 持续运营阶段： 持续反馈监控 – 跟踪用户反馈的持续监控和分析。

这些进展度量标准为团队提供了必要的工具，确保他们有效地朝着项目目标推进，从而在策略和执行上及时做出调整，以实现 预期的成果。

选择度量标准

在这里 我们应用所学的知识；你将看到如何区分那些仅提供信息的度量和那些能够真正改变你流程的度量。 我们将专注于确保你选择的度量标准相关、可靠，并能驱动 显著的变化。

在选择和优先排序项目或组织的成果或进展度量标准时，遵循系统化的过程至关重要，以确保所选择的度量标准能够有效衡量成功，并与业务目标保持一致。 图 12**.13 展示了一种推荐的方法来 实现这一目标。

图 12.13 – 选择成果和进展度量标准

以下是 选择成果和进展度量标准的推荐过程。

• 定义业务和项目目标：首先要清晰地定义业务目标。 理解组织通过其项目或流程希望实现的目标至关重要。 无论是提高客户满意度、增加软件部署频率、增强安全措施，还是降低运营成本，拥有一套清晰的目标将帮助选择 相关的度量标准。

• 识别指标：一旦明确了业务或项目目标，识别直接反映成功的关键指标。 这些指标应当具有可操作性，意味着它们能够指导决策并影响结果。 例如，如果目标是提高客户满意度，一个可能的关键绩效指标（KPI）可以是 净推荐值 （NPS）。 本章早些时候描述的指标为你提供了包括结果和进展指标在内的建议，你可以从中进行选择。

• 确保指标是可衡量和可达成的：选择那些不仅与业务目标一致，而且也是可衡量和可实现的指标。 每个指标都应当有明确的衡量方法，并且基于可以一致且准确收集的数据。 避免使用模糊不清、容易被不同解读的指标，因为这可能导致结果 和决策的不一致。

• 根据影响和相关性优先排序指标：并非所有指标都是平等的。 一些指标对业务成果的影响比其他指标更大。 根据指标对业务目标的潜在影响以及与当前项目或策略的相关性来优先排序指标。 那些能够提供客户行为、产品表现和运营效率的洞察的指标通常优先考虑，因为它们与 业务成功直接相关。

• 考虑利益相关者的意见：与组织中不同部门的利益相关者进行沟通，了解他们认为哪些指标最为重要。 这不仅能确保全面的视角，还能促进整个组织的认同。 利益相关者可以提供有关指标跟踪的实际方面的见解，以及一些在 战略层面可能不明显的影响。

• 定期审查和完善：结果指标不应当是静态的。 随着业务目标的变化、技术的演进和市场的变动，不同指标的相关性也会有所不同。 定期审查指标，确保它们与业务目标保持一致，并根据需要进行调整。 这可能意味着要完善指标的衡量方式，或用更符合当前 商业环境的指标替换那些不再相关的指标。

通过遵循 这些步骤，组织可以有效地选择和优先考虑结果指标，这些指标不仅提供清晰的性能指示，还能推动与战略目标一致的有意义的改进。 这组指标应该是相关的 且平衡的。

选择结果和进展指标的领导和团队

选择 项目的结果和进展指标涉及战略决策，并应包括来自组织内部各角色的意见。 拥有一个平衡的领导团队和成员团队非常重要，以确保所选择的指标与商业目标、项目目标以及实际实施考虑因素保持一致。 以下是关于谁应该主导并参与选择这两类指标的指南： 指标的选择领导和团队

• 领导层：

  • 项目或计划经理 通常是主导选择结果和进展指标的前沿人物。 他们对项目的目标、范围、时间表和资源有全面的了解，这使他们能够清楚地知道哪些指标最相关，以及如何有效地实施 和跟踪这些指标。

• 团队 成员参与：

  • 执行赞助人：他们的参与确保所选指标与组织的战略目标保持一致。 高层管理人员可以提供必要的支持和资源，帮助将这些指标整合进更广泛的业务 绩效评估中。

  • 商业分析师：这些专业人员帮助将商业目标转化为可衡量的指标。 他们确保结果和进展指标能够反映项目应为 业务带来的价值和影响。

  • 技术负责人和架构师：对于技术驱动的项目，他们的技术专长在确定捕捉特定指标的可行性方面至关重要。 他们可以就跟踪这些 指标所需的工具和系统提供建议。

  • 质量保证经理：参与质量保证经理对于定义与产品或服务质量相关的指标至关重要。 他们有助于选择进展指标 来监控持续的质量控制，以及反映最终 质量标准的结果指标。

  • 财务代表：他们能够提供项目成果和进展与财务目标对齐的洞察，提供可能与成本效益、 投资回报率 (ROI) 和 预算遵守相关的指标。

  • 市场营销和销售团队：对于影响产品供应的项目，涉及这些团队有助于将指标与客户满意度、市场反应和销售业绩对齐。 这确保所选的指标将有助于衡量市场成功和 客户参与度。

  • 运营经理：尤其是对于影响运营的项目，这些经理确保指标能够反映运营效率、流程改进和服务 交付标准。

  • IT 和数据分析师：他们的角色在定义和设置数据收集、分析和报告选定指标的系统中至关重要。 他们帮助确保数据驱动的指标准确、及时 且相关。

选择指标的协作方法有助于全面覆盖，从战略对齐到实际测量以及日常影响。 这种多元化的视角确保所选指标是全面的，并能为项目进展及其 最终成果提供有意义的洞察。

设计指标和仪表盘的实践

本节将为你提供有关如何有效呈现数据的实用建议，以便所有利益相关者能够快速做出 明智的决策。

为了有效地跟踪和可视化在持续测试、质量、安全性和反馈等领域的结果和进展指标，组织需要在设计这些指标及其显示仪表盘时采用深思熟虑的方法。 图 12**.14 展示了推荐的选择指标的过程。

图 12.14 – 设计指标和仪表盘

以下是设计这些指标的过程的详细说明，以及不同仪表盘架构的探索。

设计结果和进展指标

以下是 设计指标的 过程：

1. 定义测量标准：一旦根据战略目标选择了指标，定义具体的测量标准和标准。 这包括为每个指标设定明确的定义，数据如何收集，以及测量的频率。 例如，如果指标是“检测安全事件的时间”，则需要确定是从事件发生时开始计算，还是从系统 或人员首次注意到时开始。

2. 建立基准和目标：对于每个指标，建立一个反映当前绩效的基准，并设定实际的改进目标。 这为衡量进展提供了起点 并设定了一个推动行动的明确目标。 基准可以是历史数据、行业标准 或基准测试。

3. 选择数据源和收集方法：确定每个指标的数据收集位置和方法。 对于持续测试，数据可能来自测试工具和 CI/CD 管道；对于安全指标，数据可能来自安全监控和事件 管理系统。

4. 实施数据收集：确保自动数据收集所需的基础设施和工具已到位。 这可能涉及配置软件工具、设置 API，并确保数据的准确性 和一致性。

5. 验证和完善指标：定期审查指标，确保它们提供有价值的洞察，并根据反馈和变化的目标进行完善。 这可能涉及调整数据源、收集频率，甚至是指标 定义本身。

展示指标的仪表板架构

替代 仪表板架构，如在 图 12**.14中所示， 如下：

• 集成开发环境（IDE）嵌入式仪表板：对于与开发活动相关的指标，如持续测试或代码质量，可以将仪表板直接集成到 IDE 中。 这使得开发人员可以在他们的工作环境中实时查看指标，从而增强了即时性 和相关性。

• 独立的商业智能（BI）工具：如 Tableau、Power BI 或定制的仪表盘解决方案等工具，可以将来自多个来源的数据汇集到一个中央仪表盘中。 这些工具提供强大的数据可视化功能，并能够将来自多个领域的数据（如测试、安全性和客户反馈）合并为一个 综合概览。

• 基于 Web 的仪表盘：使用 Django（Python）、Flask、Angular 等框架，甚至是 JavaScript 库如 React，实现基于 Web 的仪表盘，能够提供高度可定制和易于访问的仪表盘。 这些仪表盘可以通过任何 Web 浏览器访问，为组织内各利益相关者提供灵活性和集中访问。

• 实时监控仪表盘：对于需要实时监控的度量标准，例如安全事件检测或实时反馈收集，可以使用基于 Grafana 或 Kibana 等平台构建的仪表盘。 这些工具可以与数据库和监控系统集成，提供实时更新 和警报。

• 基于云的仪表盘：云平台如 Amazon CloudWatch、Google Cloud 的操作套件或 Azure Monitor 提供内置工具，可以创建可扩展并且随时随地可访问的仪表盘。 这些对于采用云优先战略的组织特别有用，提供集成的安全性 和维护。

通过遵循这些过程，并考虑不同的仪表盘架构方法，组织可以确保拥有有效且高效的方式，来监控、分析和应对各个领域的结果和进展度量标准。 这将增强决策制定，提高战略对齐，并推动 运营效率。

维持进展和结果的衡量标准

维持 组织内结果和进展的衡量标准是一个持续的过程，需要定期评估和调整，确保度量标准保持相关性和有效性。 以下是一些推荐的方法，用于维护、评估、更新和验证 这些度量标准：

评估和淘汰度量标准

• 定期审查周期：建立定期的审查间隔（例如每季度或每半年）， 以审查每个度量标准的有效性和相关性。 这些审查应评估度量标准是否 仍与当前的业务目标 和战略保持一致。

• 绩效分析: 根据度量标准对决策和业务结果的影响评估其有效性。 如果某个度量标准始终未能提供可操作的见解或推动改进，它可能需要进行修订 或弃用。

• 利益相关者反馈: 收集度量标准使用者的反馈，如管理者、团队负责人和分析师，以了解它们的实际效用以及使用中遇到的挑战。 如果发现度量标准混乱、不一致或冗余，考虑修改或 删除它们。

• 弃用触发事件: 定义特定的标准或触发事件，以确定何时应弃用某个度量标准。 这可能包括业务流程的重大变化、战略重点的转移，或是新技术的引入，这些变化使得旧的 度量标准过时。

引入新度量标准

• 差距分析: 定期进行差距分析，以识别现有度量标准未能完全覆盖的关键绩效领域。 这有助于发现 需要 新度量标准。

• 试点测试: 在全面实施新度量标准之前，进行试点测试以评估其相关性和有效性。 这可以在组织的一个受控部门进行，以最小化干扰，并收集有关度量标准表现的有价值数据。

• 利益相关者认同: 确保利益相关者理解新度量标准的价值，以及它们如何 有助于组织目标的实现。 这包括培训课程、演示和关于这些度量标准如何帮助决策过程的讨论。

验证度量标准实施

• 版本管理: 将度量标准及其定义视为任何软件资产。 使用版本控制系统来管理随时间变化的更改。 这确保了对度量标准的任何修改都有充分的文档记录 并且可追溯。

• 回归测试: 每次更新度量标准或引入新度量标准时，都需要进行回归测试，以确保这些更改不会对其他度量标准的准确性和可靠性，或对数据收集过程本身产生负面影响。 这对保持 数据分析的完整性至关重要。

• 持续验证：实施持续验证机制，监控指标的表现。 这可能包括自动化警报，通知利益相关者当数据模式显著偏离历史趋势时，提示指标实施可能出现问题。

• 文档和透明度：为每个指标保持全面的文档，包括其定义、目的、计算方法、数据来源以及随时间变化的任何修改。 这种透明度有助于建立对指标的信任，并促进新团队成员的更容易入职和培训。 团队成员。

通过遵循这些方法，组织可以确保其结果和进展指标保持相关性、可靠性，并与战略目标保持一致。 这种动态的指标管理方法帮助组织适应变化的环境，并通过做出明智的、基于数据的决策保持竞争优势。 数据驱动的决策。

总结

本章解释了在组织内部衡量进展和结果的关键作用，重点关注持续测试、质量、安全性和反馈。 它首先强调了建立有效的衡量标准以跟踪组织在成长过程中如何表现和适应的必要性。 本章解释了不同类型衡量标准的基础，提供了理解有效指标的构成以及如何使指标与 组织目标相一致的基础。

随着章节的深入，它提供了关于如何选择适当的指标来衡量结果和进展的详细指导。 本节强调了区分单纯提供数据的指标与那些能够真正推动变革的指标的重要性 在流程中的作用。

随后，我们提供了通过设计良好的指标系统和仪表盘来实施这些指标的实际建议。 这包括如何以可操作且易于所有利益相关者获取的方式呈现数据，使他们能够迅速做出明智的 决策。

本章最后讨论了这些衡量标准的可持续性。 它概述了保持这些衡量标准随着时间推移仍然相关且有用的策略，确保它们继续支持组织不断发展的需求。 下一章将在此基础上展开，探讨持续测试、质量、安全性和反馈的新兴趋势，提供关于这些领域可能如何发展以及组织如何适应 这些变化的见解。

第四部分：探索未来趋势与持续学习

第四部分 深入探讨了软件开发中持续实践的不断演变。 本节首先确定了正在重塑持续测试、质量、安全和反馈如何融入软件开发框架中的新兴趋势。 它提供了最新进展的洞察，以及如何利用这些进展来提升组织的运营成熟度。 。

在讨论新兴趋势后，本书将重点转向持续改进和学习的重要性。 它概述了在测试、质量、安全和反馈领域内促进持续发展和完善的有效策略。 本部分强调了组织需要不断适应和发展，以跟上技术变革的步伐，并保持在各自行业中的竞争优势。 。

本部分包括以下章节： ：

• 第十三章, 新兴趋势

• 第十四章, 探索持续学习与改进

第十三章：新兴趋势

本章描述了正在重新塑造软件开发中持续测试、质量、安全性和反馈领域的最新趋势。 随着技术的发展和数字化转型步伐的加快，组织面临新的挑战和机会，这些都需要创新的应对方式。 本章将探讨采纳率变化、先进框架的整合以及如可观察性、价值流管理、平台工程以及人工智能（AI）/机器学习（ML）等新方法的兴起如何影响这些领域。 这些趋势不仅重新塑造了工具和流程，还重新定义了团队的协作方式和 价值交付。

本章结构旨在提供五个关键领域的全面概述，涵盖 DevOps、DevSecOps 和 SRE 的宏观趋势；可测试性和可观察性；平台工程；价值流管理；以及 AI/ML。 每个部分将详细描述这些趋势在现实世界中的体现，提供关于它们实际影响的洞察，并介绍它们带来的好处。 例如，将安全实践整合到 DevOps 中，形成 DevSecOps，可以在不影响开发周期速度的情况下增强安全措施。

除了理解这些趋势外，本章还旨在为您提供有效准备和适应这些变化的知识。 对于行业专业人士来说，掌握这些趋势的理论方面固然重要，但更重要的是理解如何实施它们，从而提高项目的效率、质量和安全性。 本章将包括关于战略调整、技能提升以及采用与这些新兴趋势相符合的新工具和技术的讨论。 新兴趋势。

在本章结束时，您将对当前在持续测试、质量、安全性和反馈领域中塑造重要趋势有一个扎实的理解。 您将学习如何利用这些趋势，在快速发展的技术领域中保持领先，确保您的技能和方法与时俱进，并有效应对当前和未来在软件开发中的挑战。 这些知识对于您提升能力和调整策略，以适应现代软件交付实践的需求，将是至关重要的。 交付实践。

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

• DevOps、DevSecOps 和 SRE 的宏观趋势 及其在 SRE 中的作用

• 可测试性和 可观察性趋势

• 平台 工程趋势

• 价值流 管理趋势

• AI/ML 趋势

开始吧！ 让我们

DevOps、DevSecOps 和 SRE 的宏观趋势

软件开发 和运营的格局 在不断演变，受到技术进步、市场需求变化以及对更快速、更安全交付周期需求的影响。 当我们展望 DevOps、DevSecOps 和 站点可靠性工程 (SRE) 框架内持续测试、质量、安全性和反馈的未来时，几个宏观趋势突出，如 图 13**.1所示。

图 13.1 – 持续测试、质量、安全性和反馈的最新趋势

以下解释了这些趋势如何与持续测试、质量、安全性和反馈的演变相关：

• 向 DevSecOps 转变：将安全实践集成到 DevOps 流水线中 – 被称为 DevSecOps – 正成为一个重要趋势。 随着网络威胁日益复杂，组织认识到将安全性早期并贯穿整个软件开发生命周期的重要性，而不是将其视为事后考虑。 这一趋势强调自动化安全扫描工具、安全编码实践和持续合规性监控，旨在减少漏洞而不降低开发速度。 这一趋势推动了自动化安全扫描工具、安全编码实践和持续合规监控的采用，旨在在不拖慢开发进度的情况下减少漏洞。

• 微服务和容器化的日益普及：微服务架构和容器化促进了大规模复杂应用程序的快速、可靠交付。 这一趋势影响了持续测试、质量和反馈，要求工具和实践能够应对更加动态、分布式和可扩展的环境。 像 Docker 和 Kubernetes 这样的工具已经成为标准，推动了可以在大规模和实时环境中运行的测试框架的发展，以确保微服务环境中的质量和性能。

• AI 和 ML 的增长: AI 和 ML 被越来越多地应用于增强 DevOps 各个方面，特别是持续测试和反馈机制。 AI 驱动的预测分析可以预测潜在的瓶颈和故障，而 ML 算法则用于优化测试流程、自动化错误诊断和完善反馈循环。 这些技术使团队能够预防性地解决问题，提升交付速度和质量 。

• 强调可观察性和监控: 随着系统复杂性的增加，对复杂监控和可观察性的需求也在增加。 这一趋势 涉及从传统监控向更全面的可观察性方法的转变，重点在于通过分析外部输出来理解系统的内部状态。 这在持续反馈和运营弹性中尤为重要，使 SRE 团队能够预测和缓解影响服务质量的干扰。

• 价值流管理的兴起: 价值流管理 (VSM) 正在获得组织的认可，他们致力于优化端到端的软件交付流程，以实现最大价值的交付。 VSM 工具和实践帮助绘制整个软件交付生命周期，识别低效，并衡量改进的影响。 这种整体视角支持持续测试、质量保证、安全实践和反馈周期中更好的决策，确保工作与 业务目标保持一致。

• 平台工程: 针对微服务和云原生技术管理复杂性的回应，平台工程趋势日益增长。 这种方法包括为开发人员创建自助服务平台，抽象出大部分基础设施管理的复杂性。 这使开发人员可以更专注于编码，同时依赖平台处理测试、安全性和操作等方面。

这些趋势突显了软件开发和运营的动态特性，指向一个未来，在这个未来中，适应性、安全性和效率比以往任何时候都更加紧密地相互关联。 对于组织 和 DevOps、DevSecOps 以及 SRE 专业人士来说，跟上这些趋势 对于保持竞争优势和确保交付高质量、安全的 软件产品至关重要。

可测试性和可观察性趋势

对改进可测试性 和可观察性需求的上升正在改变 DevOps、DevSecOps 和 SRE 领域中的持续测试、质量、安全性和反馈实践。 这两个方面对于创建更具韧性、高效且安全的应用和系统至关重要。 以下是它们日益重要的影响：

• 对持续测试 和质量的影响：

  • 增强的测试覆盖率和效率：改进的可测试性意味着系统从一开始就进行了设计，更容易进行测试。 这可能涉及有利于模块化设计的架构决策，或是集成促进自动化测试的工具。 因此，测试可以更加彻底、节省时间并且更深入地融入开发过程，从而提高整体 软件质量。

  • 更快的 反馈循环：可观察性提供了对软件在生产环境中行为的更深层次洞察，这些信息反馈到测试阶段。 通过通过度量、日志和追踪更好地理解系统的内部状态，团队可以识别出不仅仅是发生了什么问题，还能了解原因。 这使得调试更快，测试更精确，迭代更迅速，所有这些都增强了 开发周期的速度和效果。

• 对 DevSecOps 中 安全性的影响：

  • 主动安全措施：可观察性工具允许实时监控 安全威胁，使团队能够在问题发生时立即发现并响应，而不是事后处理。 从反应式安全到主动安全的转变在维护系统的完整性和安全性方面至关重要，尤其是在日益复杂的 网络威胁环境中。

  • 安全是共同责任：随着可测试性的提高，安全测试可以更加融入常规测试流程，模糊开发人员、测试人员和安全专家之间的界限。 这种集成有助于培养“安全即代码”的文化，使安全措施从一开始就被融入软件开发 生命周期。

• 对 SRE 的影响 ：

  • 提高的可靠性和 正常运行时间：可观察性是 SRE 的基石，因为它提供了实现可靠性目标所需的数据， 以及服务水平目标 （SLOs）。 增强的可观察性意味着更好的操作可见性，这有助于预先解决潜在的停机和故障，从而提高系统的可靠性 和正常运行时间。

  • 数据驱动的运维：通过更好的可观察性工具，SRE（站点可靠性工程师）可以利用大量数据集自动化处理常见场景，预测系统在不同条件下的行为，并优化资源使用。 这不仅减少了手动监督的负担，还使 SRE 能够将精力集中在更具战略意义的工作上， 从而创造价值。

• 对 DevOps、DevSecOps 和 SRE 的更广泛影响 ：

  • 向数据驱动决策文化的转变：随着可观察性和可测试性的提升，组织可以转向一种重视数据驱动决策的文化。 这种转变不仅改善了技术流程，还增强了战略规划和 资源分配。

  • AI 和 ML 的更广泛应用 ：通过 AI 和 ML，利用改进的可测试性和可观察性所生成的大量数据，可以进一步自动化测试、威胁检测、异常检测和问题解决过程。 这可以显著加速开发周期，提高 安全态势，并 增强 系统的韧性。

总之，专注于提高可测试性和可观察性，对于应对现代软件开发和运维的复杂性至关重要。 随着这些趋势的不断发展，它们可能会在测试、质量保证、安全性和运维可靠性方面带来显著提升，从根本上改变团队对待 DevOps、DevSecOps 和 SRE 实践的方式。

平台工程趋势

平台工程解决方案日益增长的需求 从根本上改变了 DevOps、DevSecOps 和 SRE 的格局，通过提供强大、可扩展和高效的基础设施，支持持续测试、质量保证、安全性和反馈机制。 平台工程专注于为开发人员和运维人员创建共享的、自服务的平台，抽象掉底层基础设施的复杂性，使团队能够更多地专注于应用程序开发，减少对操作细节的关注。 以下是这一转变可能对关键领域的影响： 关键领域：

• 持续测试 和质量：

  • 简化的测试流程：平台工程 解决方案通常集成并标准化测试工具和环境，这可以大大简化测试过程。 通过提供预配置的环境和自动化流水线，这些平台能够实现一致的测试流程，减少设置时间，并消除“在我的机器上可以运行”的问题，从而提升 软件质量 。

  • 增强的测试自动化：借助平台工程，组织可以实施更复杂的测试自动化策略，这些策略在各种开发项目中具有可扩展性和可重复性。 这不仅加快了测试周期，还提高了测试的覆盖率和可靠性，从而提高了 软件质量 。

• DevSecOps 中的安全性 ：：

  • 集成的 安全实践：平台工程促进了 将安全工具直接集成到开发和部署流水线中。 通过将安全性作为平台的核心组件，它确保在整个软件开发生命周期中自动应用安全检查和控制，从而提高安全性而不会增加开发人员的负担。 开发人员的负担。

  • 一致性和合规性：由于平台工程标准化了开发和部署工作流，它也标准化了安全实践。 这种一致性对于维护所有应用程序和服务的安全合规性至关重要，尤其是在监管行业中，安全实施的一致性可以简化 合规审计 。

• SRE 团队：

  • 提高操作效率：平台工程通过自动化与部署、监控和扩展相关的许多操作任务，赋能 SRE 团队。 这种自动化解放了 SRE，使其能够专注于更高价值的活动，如改善系统架构和优化性能，而不是陷入日常 操作问题的困扰。

  • 主动监控和 可靠性：考虑到可观察性设计的工程平台为 SRE 团队提供了主动监控应用程序和基础设施的工具。 这种能力使得问题能在影响用户之前被更快地检测和解决，从而提高了服务的整体可靠性 和运行时间 。

• 反馈机制：

  • 更快的反馈循环：通过标准化和自动化 收集和分析来自用户及内部监控工具的反馈，平台工程解决方案可以显著缩短反馈循环。 这种快速反馈对迭代开发和持续改进实践至关重要 ，尤其是在 DevOps 中。

  • 数据驱动的决策制定：平台工程解决方案的集中化特性使得在整个软件生命周期内进行更全面的数据收集成为可能。 这一数据的丰富性使得决策更为明智，帮助团队根据真实的用户反馈和系统 性能数据优先考虑变更和改进。

• 更广泛的影响：

  • 向自动化和自助服务的文化转变：平台工程鼓励 向自动化和自助服务能力的转变。 这种转变不仅减少了开发人员和运维人员的认知负担，还通过使新想法能够以可控且 可重复的方式进行测试，促进了创新和实验的文化。

  • 增强的协作：通过减少与开发和操作过程相关的摩擦，平台工程可以促进开发、运维和安全团队之间的更好协作。 这种增强的协作是 DevOps 理念的核心，并对快速交付 高质量软件至关重要。

总之，平台工程解决方案日益增长的需求可能会在 DevOps、DevSecOps 和 SRE 中带来显著的效率、质量、安全性和操作可靠性方面的好处。 随着这些平台变得越来越复杂，它们将继续推动软件开发和运营实践的演进，使其变得更加灵活、安全， 并以用户为中心。

VSM 趋势

VSM 解决方案需求的增长正在对 DevOps、DevSecOps 和 SRE 框架中的持续测试、质量、安全性和反馈产生重大影响。 VSM 着眼于从构想到交付的价值流可视化和优化，提供了一种系统化的方法，以提高整个软件开发生命周期的效率和效果。 以下是 VSM 如何增强 这些领域：

• 持续测试：

  • 增强的测试阶段可见性：VSM 提供了开发过程每个阶段的清晰可视化，包括所有测试阶段。 通过绘制出测试在价值流中的何时以及如何发生，团队可以识别测试过程中的瓶颈或低效。 这种可见性使得可以有针对性地进行改进，比如在关键点集成自动化测试工具，以加快工作流程，同时不 牺牲质量。

  • 优化资源分配：通过对 VSM 的测试过程有更好的理解，组织可以更有效地分配资源——包括人力和技术资源——以确保测试不会成为瓶颈。 这可以带来任务分配的更均衡，减少测试环境或 必要审批的等待时间。

• 质量：

  • 质量保证的改进反馈：VSM 工具通常集成 可以跟踪整个软件生命周期质量指标的反馈机制。 这种集成允许对质量问题提供即时反馈，这些问题可以更快速、更精确地得到解决。 实时数据促进了质量的持续改进，有助于不断优化 过程。

  • 价值流中的一致性：VSM 鼓励流程的标准化，从而有助于在整个流中保持一致的质量水平。 通过了解流中某一部分的变化如何影响下游结果，团队可以在战略节点实施质量检查，以确保最终产品符合 预期的标准。

• DevSecOps 中的 安全性：

  • 主动的 安全集成：VSM 提供了一个框架 用于在整个开发生命周期中集成安全实践，而不仅仅是在最后阶段。 通过将安全作为价值流的一部分，它成为产品开发的一个不可或缺的组成部分，确保安全考虑在早期和频繁地进行。 这种早期集成有助于更早发现漏洞，并减少修复的成本和复杂性 。

  • 增强的可追溯性：VSM 解决方案提高了整个价值流的可追溯性。 这一能力对安全性至关重要，因为它使团队能够快速识别安全问题的来源，并了解其对整个流的影响。 有效的可追溯性支持更好的风险管理和合规性跟踪，这些都是安全 软件交付的关键方面。

• 反馈：

  • 加速的反馈循环：VSM 工具简化了来自开发过程各个阶段的反馈的收集 和利用。 通过将反馈直接与价值流中的特定阶段联系起来，团队可以更快、更准确地进行调整，从而提高产品对用户的价值。 这种反馈的快速集成对于敏捷开发实践至关重要，并有助于确保最终产品与用户需求 和期望保持一致。

  • 数据驱动的改进：VSM 的分析能力使组织能够从价值流中收集数据，并利用这些数据做出关于改进需求的明智决策。 这种数据驱动的反馈管理方法有助于根据影响的大小来优先考虑工作，确保资源 集中在能够带来最大效益的领域。

总之，VSM（价值流管理）解决方案的实施正在彻底改变组织应对持续测试、质量、安全和反馈的方式。 通过提供对价值创造过程的整体视角，VSM 使得战略决策更加高效，提升了运营效率，并改善了软件产品的整体质量和安全性。 对于 DevOps、DevSecOps 和 SRE 团队来说，拥抱 VSM 能够显著提高生产力、安全性和 客户满意度。

人工智能/机器学习趋势

人工智能与机器学习的融合 正在迅速改变团队如何应对持续测试、质量、安全和反馈的方式。 对人工智能/机器学习解决方案需求的增加，源于系统复杂性提升、数据量激增以及对更快、更高效交付周期的需求。 以下是人工智能/机器学习可能对这些关键领域产生的影响：

• 持续测试:

  • 自动化测试创建与优化：人工智能/机器学习能够分析 应用数据和用户交互，自动生成和优化测试用例，从而减少测试创建中的人工工作量。 这将带来更广泛的测试覆盖面和更高效的测试流程，确保所有相关的应用场景都被 考虑在内。

  • 用于缺陷检测的预测分析：机器学习算法可以基于历史数据预测潜在的缺陷，从而使团队能够在缺陷显现之前，集中测试工作于最需要的地方。 这种主动的方法不仅节省了 时间，还减少了与后期 修复漏洞相关的成本。

• 质量:

  • 增强的错误检测：人工智能算法擅长 识别模式和异常。 在质量保证中，这些能力可以用于检测与预期结果的偏差或识别可能指示潜在质量问题的异常系统行为。 这种早期检测有助于在 整个开发周期中保持高质量。

  • 动态适应变化：人工智能驱动的系统可以根据代码库和操作环境的持续变化动态调整测试和质量保证过程。 这种响应性确保了即使项目不断发展，质量检查仍然保持相关性和有效性。

• DevSecOps 中的安全性 :

  • 智能威胁 检测与响应：AI/ML 模型可以实时分析 大量安全数据，以识别传统安全工具可能忽略的潜在威胁。 这些模型从新数据中学习，不断提高其检测能力。 此外，AI 还可以自动响应常见威胁，从而加速缓解过程，减少 安全团队的工作负担。

  • 安全即代码：AI 增强了安全即代码的概念，其中安全策略和检查被集成到开发流程中。 AI 可以通过学习系统行为和威胁模式来帮助微调这些策略，确保随威胁变化而进化的强大 安全协议。

• 反馈：

  • 实时反馈分析：AI/ML 可以实时处理和分析 来自用户和系统的反馈，更快地提供可操作的洞察。 这一能力使开发团队能够快速做出明智决策，并以一种紧密贴合用户需求 和期望的方式迭代产品。

  • 情感分析和用户 体验：ML 模型可以对用户反馈进行情感分析，以评估情感基调，提供对用户满意度和潜在痛点的更深入见解。 这种分析有助于根据对 用户体验的影响来优先安排开发工作。

• 对 DevOps、DevSecOps 和 SRE 的整体影响：

  • 自动化决策：AI 通过在软件开发生命周期的各个阶段提供数据驱动的洞察，增强了决策过程。 这一能力支持在测试、部署、运营和 资源分配方面做出更准确、更快速的决策。

  • 提升效率和创新：通过自动化日常任务和分析，AI/ML 释放了人力资源，使其可以专注于更复杂和富有创新性的工作。 这种转变不仅提高了效率，还促进了团队内的创造力，推动了更具创新性的解决方案 和进展。

  • 可扩展性与处理复杂性：AI/ML 解决方案本身具有可扩展性，能够应对现代软件环境日益增加的复杂性。 这种可扩展性对于在系统增长 和演变的过程中，保持性能和质量至关重要。 。

总之，AI/ML 在 DevOps、DevSecOps 和 SRE 中的崛起将深刻影响持续测试、质量保证、安全实践和反馈机制。 随着这些技术越来越多地融入日常实践，它们有望提升软件开发和运营的速度、效率和效果，最终带来更强大、更安全、以及更符合用户需求的产品。

总结

本章探讨了影响 DevOps、DevSecOps 和 SRE 领域内持续测试、质量、安全性和反馈的最新趋势。 本章首先详细介绍了宏观趋势，例如向 DevSecOps 的转变、微服务和容器化的采用、AI 和 ML 的增长、对可观察性和监控的重视，以及 VSM 的崛起。 每个趋势都从其对软件开发过程的影响进行分析，强调这些进展如何促进更快、更安全的交付周期，帮助组织更好地满足现代 数字化环境的需求。

接下来，讨论深入探讨了这些趋势影响的具体领域，包括可测试性和可观察性、VSM、平台工程以及 AI/ML 的集成。 本章解释了如何通过提高可测试性和可观察性，增强持续测试和反馈机制的效率和效果，从而加快迭代速度，并提供更可靠的软件输出。 它还介绍了平台工程如何通过创建稳健、可扩展的基础设施来重塑团队处理现代软件开发复杂性的方式，从而实现自动化并 简化操作。

此外，本章还讨论了 AI 和 ML 技术的融合，这些技术正在改变测试、质量保证和安全协议。 AI/ML 可以实现缺陷检测的预测分析、自动化测试用例生成以及增强的实时监控和反馈分析。 这些能力使得开发环境变得更加智能和主动，其中持续改进已深深融入 工作流程中。

总之，本章为你提供了理解和实施这些新兴趋势的知识，从而帮助你适应不断发展的技术环境。 下一章将基于此，重点介绍持续学习如何支持持续测试、质量、安全性和反馈，适用于 DevOps、DevSecOps 和 SRE，旨在进一步提升在这些 动态领域中取得成功所必需的技能。

第十四章：探索持续学习与改进

如图所示， 图 14**.1，本章专注于如何在 DevOps、DevSecOps 和 SRE 中参与的团队能够不断改进和学习，这对于快速变化的技术环境至关重要。 本章探讨了在软件开发和运维中至关重要的持续学习和改进的有效策略。 目标是帮助团队不仅跟上技术变化的步伐，还能将其作为 进步的机会。

图 14.1 – 持续实验与学习

本章围绕DevOps 的第三种方式这一原则展开，该原则通过实验促进持续学习。 它讨论了团队可以通过共享、外展、实验、处理失败以及应用混沌工程等方式进行学习。 每个部分都涵盖了学习的不同方面，提供了如何将这些实践整合到日常工作中的实用建议。 工作常规中。

通过涵盖这些主题，本章旨在为你提供进行实验和应用混沌工程的技能 以进行测试。

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

• DevOps 的第三种方式 之一

• 从 共享中学习

• 从 外展中学习

• 从 实验中学习

• 从 失败中学习

• 从 混沌工程中学习

让我们 开始吧！

DevOps 的第三种方式

DevOps 的第三种方式 侧重于持续实验和学习的原则，以增强软件开发和运维中的工作流。 这种方法不仅鼓励创新，还强调从成功和失败中学习的重要性。 它在持续测试、质量、安全和反馈等领域尤为重要，因为技术的快速发展和变化要求适应性和持续的 技能提升。

DevOps 中的持续改进

持续改进 在 DevOps 中意味着定期评估和改进软件开发与部署过程中使用的流程、工具和方法。 这种做法确保团队不会保持现状，而是积极寻找提高效率、效果和安全性的方式。 关键方面包括 以下内容：

• 迭代过程改进：鼓励 DevOps 团队不断寻找工作流程中的小而渐进的变化，这些变化随着时间的推移可能带来显著的改进。 这可能是自动化日常手动流程、优化现有脚本，或者采用能够加速部署的新工具。

• 反馈循环：创建快速有效的反馈循环在 DevOps 中至关重要。 这些反馈循环帮助团队实时了解其变更的结果 并据此进行调整，而不需要等待漫长项目周期的结束。 反馈可以来自自动化系统、同行评审或实时监控工具，且应直接影响 未来的改进。

在 DevOps 中的学习

在 DevOps 中的学习不仅仅是获取新知识；它还涉及如何将这些知识实际应用并与整个团队共享。 第三种方式的这一方面对于培养集体智慧的文化至关重要，在这种文化中，每个人的成长都能惠及 整个团队。

• 从失败中：DevOps 文化不回避失败，而是将其视为学习的机会。 当部署失败或发现新 Bug 时，团队会进行无责事后复盘，了解出错原因，并探讨如何在未来避免类似问题。 记录这些经验教训并与团队共享，确保同样的错误不会 重复发生。

• 从成功中：同样地，分析哪些做得好以及为什么做得好可以提供宝贵的见解。 成功案例应当以与失败相同的严格性进行剖析，以便在 未来项目中复制这些成功的做法。

持续测试、质量和安全

第三种方式在持续测试、质量和安全中的应用涉及 若干实践：

• 持续测试：自动化测试是 DevOps 的基石，提供有关变更影响的即时反馈。 通过从开发过程初期开始持续测试软件，团队可以更早发现和解决问题，从而降低成本并加快 交付时间。

• 质量保证：质量 不是事后考虑的，而是贯穿于整个开发过程中的。 团队利用过去项目中的洞察来不断提升质量检查点和 标准。

• 安全集成：将 安全性从一开始就集成到 DevOps 流程中，即 DevSecOps，确保安全考虑是内建的，而不是附加的。 从过去的安全事件中学习有助于增强未来项目对 类似漏洞的防范能力。

DevOps 的第三条方法提倡一种文化，在这种文化中，持续改进和学习是日常工作的一部分。 通过采纳这种方法，DevOps 团队增强了在持续测试、质量、安全和反馈方面的能力。 这不仅能带来更强大和更有韧性的软体解决方案，还能确保团队保持技术创新的前沿，随时准备应对出现的新挑战。 通过整合这些实践，组织能够在软件 开发工作中保持长期增长和持续改进。

共享中的学习

共享中的学习 是 DevOps 中的一个基本概念，强调团队之间及团队内部知识交流的好处。 在持续改进和学习的背景下，持续测试、质量、安全和反馈，分享成为提升团队能力和加速开发周期的关键驱动力。 本节探讨了如何通过结构化的共享实践促进一个合作的环境，在这个环境中 创新蓬勃发展。

建立开放沟通的文化

对于 DevOps 团队来说，创建一个安全文化，让成员感到舒适地分享见解、成功和失败至关重要。 这种文化促进了透明度和信任，这是 有效协作的基础。

• 定期知识共享会议：实施定期会议，如每日站立会议、每周回顾或每月回顾会议，让团队成员讨论他们的工作内容、遇到的挑战以及所学到的经验教训，可以显著提升集体的理解能力和 问题解决能力。

• 文档管理：维护一个包含流程、事件和解决方案详细文档的知识库，不仅作为参考，还帮助新加入的团队成员迅速上手。 Wiki、共享驱动器和内部博客是实现这一目的的有效工具。

分享最佳实践和工具

DevOps 团队 通常在快速变化的环境中工作，新工具和新实践不断出现。 在团队或组织内部分享最佳实践和工具可以提高工作流程的效率和 效果：

• 工具演示：定期展示团队成员发现有用的新工具或功能的会议，可以促进工具在团队中的广泛采用和标准化。 。

• 最佳实践研讨会：专注于持续测试、质量和安全的最佳实践研讨会有助于标准化团队内部的方法，减少变异性并提高结果的可靠性 。

跨团队合作与外部参与

将分享文化 扩展到其他部门，甚至组织外部，可以引入新的视角和解决方案，这些是内部团队可能忽视的。

• 跨部门会议：鼓励团队举办跨部门会议有助于打破信息孤岛，分享可能对多个领域有益的见解，从开发到运营 再到安全。

• 社区参与：参与外部论坛、会议和研讨会不仅能让团队成员从行业领导者那里获得见解，还能分享自己的经验和解决方案，在更广泛的 社区中建立影响力。

利用反馈推动持续改进

反馈机制 是软件过程的核心，跨团队分享反馈对持续改进至关重要。 结构化的反馈可以促进更好的实践，并突出需要关注的领域：

• 反馈循环：将反馈循环融入共享过程确保所有团队成员都能了解他们行动的结果，并据此调整他们的实践。 这些循环应当及时且具有建设性，关注哪些做得好以及哪些可以 改进。

• 可操作的见解：反馈应当是可操作的。 团队需要讨论可以采取的实际步骤，以实现通过共享获得的见解。 这可能涉及调整测试协议、更新安全措施或改进质量 保证流程。

在 DevOps 中，共享学习不仅仅是信息的传递，更是在创造一个生态系统，使得持续学习和改进成为日常过程的一部分。 通过促进开放、沟通和协作的文化，团队可以显著提高在持续测试、质量、安全性和反馈方面的有效性和效率。 这不仅提升了项目成果，还促进了 一个更加参与和创新的团队环境。 随着团队在共享和应用集体知识方面变得更加熟练，他们为持续增长和在其 DevOps 实践中的持续进步奠定了基础。

通过外联学习

DevOps 中的外联 涉及与外部社区和行业团体互动，带入新的想法和实践，以增强内部流程。 本节探讨了如何通过外联学习显著促进 DevOps、DevSecOps 和 SRE 框架中的持续改进，特别是在持续测试、质量、安全性和反馈方面。

外部互动在持续改进中的作用

外部互动 使团队能够超越其当前组织环境的局限，从更广泛的行业中学习。 这可以包括参与行业会议、贡献开源项目或参与专业 网络群体：

• 参加会议和工作坊：参加行业会议和工作坊为团队提供了接触前沿实践和技术的机会。 这些活动对于学习新工具、方法和在类似环境中有效的策略非常有价值。 团队可以将这些见解带回，并评估它们对自己 流程的适用性。

• 与在线社区互动：GitHub、Stack Overflow 或特定的 DevOps 论坛等在线社区是解决问题和创新的丰富资源。 通过积极参与这些社区，团队成员可以提问、获取对自己方法的反馈，并从面临类似挑战的其他人经验中学习。

行业合作的好处

与 行业同行的合作带来了若干优势，直接转化为测试、质量、安全和 反馈机制的改进：

• 跨行业学习：通过与来自不同行业的专业人士互动，DevOps 团队可以了解在不同背景下是如何解决各种挑战的。 这种跨行业学习能够激发创新的解决方案，团队可能之前没有考虑过的 方案。

• 与行业标准对标：外展活动使团队能够将其流程和表现与行业标准和最佳实践进行对比。 这一对标可以突出改进的领域，并为未来的 发展努力提供清晰的目标。

在 DevOps 实践中实施外展学习

为了有效地 将外展活动中的学习融入工作，团队需要遵循一种结构化的吸收 和应用方法。

• 结构化汇报会议：在参与外部活动或接触后，团队成员应举行汇报会议，与同事分享关键的学习经验。 这些会议应专注于新信息的潜在应用以及确定可执行的步骤 以便实施。

• 试点项目：通过小规模的试点项目实施新想法，团队可以在不危及更大系统稳定性的情况下评估其有效性。 这些项目作为新概念的实际测试，并允许在更广泛推广之前进行迭代优化。

外部学习是 DevOps 环境中持续改进的重要组成部分。 通过积极与外部知识源进行互动，并将这些见解带入组织，团队可以增强在持续测试、质量、安全性和反馈方面的能力。 这不仅使团队能够了解最新的行业发展，还促进了学习文化和开放接受变革的氛围。 因此，DevOps 团队更有能力应对新挑战，并持续优化实践，以在 项目中实现更高的效率和效果。

从实验中学习

实验 是 DevOps 哲学的核心元素，倡导一种鼓励尝试新方法的环境，以发现更高效、更有效的工作方式。 本节内容重点介绍了实验如何推动 DevOps、DevSecOps、 和 SRE 中持续测试、质量、安全性和反馈过程的持续改进。

实验在 DevOps 中的重要性

实验 使团队能够在真实场景中测试假设，提供宝贵的见解，从而推动软件开发和运营过程中的重要改进。 在 DevOps 中，实验不仅仅是技术创新，还涉及找到改善团队动态、工作流程和 整体效率的新方法：

• 迭代测试：在持续测试中，实验可能包括尝试新的自动化测试工具或技术，以查看它们是否能提高测试的速度和准确性。 例如，团队可能会尝试不同类型的自动化回归测试，以确定哪一种在速度 和全面性之间提供最佳平衡。

• 质量改进试验：质量保障可以通过尝试新的质量指标或收集和分析质量数据的新方法来受益。 通过在项目的小部分上测试这些不同的方法，团队可以收集有关它们有效性的数据，而不会影响整个项目。

在 DevOps 中进行安全实验

为了 确保实验能够带来学习而非干扰，至关重要的是以受控且 可衡量的方式进行实验：

• 特性开关的使用：实施特性开关可以让团队在生产环境中以最低风险测试新功能或更改。 特性开关可以仅对少部分用户发布更改，从而收集反馈和性能数据，而不影响 所有用户。

• 金丝雀发布：类似于特性开关，金丝雀发布涉及在全面发布前，将新功能或更改仅发布给少数用户。 这种方法特别适用于在生产环境中进行测试，并能提供有价值的反馈，了解更改在 实际环境中的表现。

从实验结果中学习

成功实验的关键 不仅仅是进行实验，还要从中学习，无论实验是成功 还是失败：

• 分析结果：每个实验之后都应进行详细的结果分析。 这包括回顾性能指标、用户反馈和任何其他相关数据，以判断实验是否成功 或失败。

• 分享学习成果：从每次实验中获得的洞察应被记录并与整个团队分享。 这一做法有助于传播知识，确保所有团队成员都能从实验中学习，即使他们没有直接参与 其中。

• 将反馈融入过程：实验周期的最后一步是利用反馈和学习来改进现有流程或开发新流程。 这可能涉及调整测试协议、更新质量标准或修改 安全措施。

从实验中学习是 DevOps 中持续改进的强大工具。 通过营造鼓励实验并安全管理的环境，团队可以不断演化其实践和流程。 这种持续的改进带来了 更高的效率、更好的质量、增强的安全性和更有效的反馈机制，确保组织在面对变化的技术和 市场环境时，保持适应性和创新力。

从失败中学习

在 DevOps 中，从失败中学习 是推动软件开发和运维各个阶段持续改进的关键实践。 这一理念源于这样一种信念：失败提供了宝贵的教训，经过正确的分析和理解，可以带来在过程中的显著改进，包括持续测试、质量、安全和 反馈机制。

拥抱无责文化

从失败中学习的一个关键元素是建立无责文化。 这种环境鼓励团队成员公开讨论错误和失败，而无需担心报复 或批评：

• 无责事后分析：在失败发生后，进行无责事后分析至关重要。 其目的是理解发生了什么，为什么会发生，以及如何防止未来再次发生，而不指责任何个人。 这种方法有助于识别系统层面的改进，而不是专注于 个体错误。

• 透明度：鼓励团队成员记录并分享关于失败及其根本原因的详细信息。 这种透明度不仅促进学习，还帮助建立团队内部的信任与合作。

分析失败的实际步骤

有效地分析失败 需要一种结构化的方法来揭示根本原因并理解其对 持续改进的广泛影响：

• 根本原因分析 (RCA)：如“五个为什么”（https://www.mindtools.com/a3mi00v/5-whys）或鱼骨图（https://www.techtarget.com/whatis/definition/fishbone-diagram）等技术可以用于 深入挖掘导致失败的根本原因。 目标是超越表面答案，理解需要解决的系统性问题。

• 可操作的教训：每次分析应得出可操作的结论，这些结论可以付诸实践以改善流程。 无论是调整测试协议、优化部署实践，还是改进监控工具，关键是将洞察转化为 切实的改进。

将失败融入持续改进周期

从失败中学习应该是 DevOps 实践中持续改进周期的一个重要组成部分：

• 基于反馈的迭代：失败的洞察应直接反馈到 DevOps 生命周期中。 这可能意味着对代码的更改、对安全措施的更新，或是在持续测试 和运营过程中改进监控策略。

• 定期评审会议：应定期举行评审会议，评估近期的失败以及基于之前失败实施的变更的状态。 这确保了教训不仅被学习，而且 得到了有效应用。

从失败中学习的好处

从 失败中学习具有多重好处，直接影响到 DevOps 实践的效果和效率：

• 提高韧性和可靠性：通过不断从过去的失败中学习，团队可以构建更加坚韧和可靠的系统。 每一次失败都为加强系统防范 未来问题提供了独特的机会。

• 增强创新：一个不畏惧失败的文化是鼓励创新的文化。 当团队知道失败被视为学习机会而非挫折时，他们会更愿意尝试新的想法。

从失败中学习是 DevOps 持续改进的基石，直接影响持续测试、质量、安全性和反馈流程。 通过培养将失败视为学习和改进机会的文化，组织可以提升其运营流程，并更迅速地适应新的挑战。 这种方法不仅能最小化类似失败的再发生，还能推动在持续发展的 技术环境中创新和提高效率。

从混沌工程中学习

混沌工程 是一种有纪律的方法，通过在问题变成故障之前识别出潜在的失败。 通过故意向系统注入故障，DevOps 团队可以观察系统在压力下的表现，并学习如何构建更强大的系统。 这种前瞻性的方法对于持续测试、提升质量、增强安全性以及改进软件开发 和运营中的反馈机制至关重要。

实施混沌工程

混沌工程的实践 包括几个计划的步骤，以确保它能够增加价值而不对 生产服务造成不必要的干扰：

1. 定义明确的目标: 在启动混沌实验之前，定义明确的目标非常重要。 无论是测试系统如何从数据库故障中恢复，还是 了解流量突然增加的影响，定义这些目标有助于有效地定制 实验。

2. 从受控环境开始: 最初在暂存环境中进行混沌实验，帮助团队学习和迭代他们的过程，而不影响实时用户。 这种受控环境让你可以调整变量并理解结果，而无需担心立即的 业务影响。

3. 渐进式升级: 一旦在受控环境中建立了信心，逐步将混沌实验扩展到生产环境中，确保系统在实际条件下具有韧性。 这种循序渐进的方法有助于减少风险，同时仍能获得 宝贵的洞察。

从混沌工程中学习与改进

混沌工程 提供了关键的学习，这些学习可以直接影响 DevOps 流程的各个方面：

• 增强的系统韧性: 通过故意破坏系统，团队可以在问题影响用户之前识别并修复问题。 这种主动的故障查找有助于提高系统的韧性，减少停机时间，这对于维持高质量的 用户体验至关重要。

• 改进的恢复过程: 混沌实验通常揭示系统在故障后恢复得如何（或如何不恢复）。 通过从这些结果中学习，团队可以简化并加强其恢复程序，例如改进自动回滚或增强 警报机制。

• 安全态势评估: 引入与安全相关的混沌实验，例如测试对模拟攻击的响应，可以帮助揭示安全态势中的漏洞。 这些洞察推动了安全协议和 防御策略的改进。

将混沌工程整合到持续反馈循环中

要充分 利用混沌工程的好处，必须将这些发现整合到 DevOps 实践的持续反馈循环中：

• 文档和分析：每次混沌实验后，记录发现并进行详细分析以提取可操作的见解至关重要。 这些文档应该对所有团队成员可访问，以确保每个人都能从 实验中学习。

• 反馈机制：将混沌工程的发现整合到现有的反馈机制中，有助于让所有利益相关者了解系统中潜在和现有的弱点。 这种持续的沟通对于 持续改进至关重要。

• 常规实践：将混沌工程作为开发生命周期的常规部分，有助于将从失败中学习的实践常态化。 定期安排混沌实验可以确保持续学习和系统强化，这对适应新挑战 和技术至关重要。

混沌工程是 DevOps、DevSecOps 和 SRE 工具包中的一种强大工具，提供了一种独特的方式来主动测试和改进系统。 通过故意引入故障，团队可以确保他们的软件和基础设施能够承受意外的中断。 这种学习方法不仅增强了系统的可靠性和安全性，还在组织内部培养了应对能力和准备文化。 随着团队越来越习惯于混沌实验，他们可以不断突破系统的承载极限，从而在软件交付 和运营的各个方面实现持续改进。

总结

本书的最后一章探讨了在 DevOps、DevSecOps 和 SRE 的背景下，持续学习和改进的关键实践。 这一章节强调了拥抱持续学习文化的重要性，强调了它如何支撑在快速发展的技术环境中取得成功。 叙述围绕几种关键方法论展开，促进了这一持续改进，包括 DevOps 的第三种方式，该方法提倡反馈文化、从实验中学习以及从失败中恢复的关键角色。 从失败中恢复。

我们深入探讨了促进学习和改进的具体策略，从 DevOps 的第三种方法开始。 该方法在促进鼓励实验和从成功与失败中学习的环境的背景下进行了讨论。 它提出了将这种理念在团队中实施的具体步骤，确保学习被嵌入到日常工作流程中，并直接促成 操作成功。

章节的后续部分集中讨论了通过不同视角进行学习——分享、外展、实验、失败和混沌工程。 每个部分提供了具体的示例，展示了如何将这些元素融入到 DevOps 实践中，以提升成果。 例如，从分享中学习强调了团队内部和与外部社区之间知识交流的重要性，而从失败和混沌工程中学习则强调了系统性和有意的测试以及破坏系统来提高其稳健性 和安全性的价值。

此外，还强调了外展和实验的重要性，展示了如何通过与更广泛的社区互动和积极的实验，能带来流程和系统的显著改进。 这些部分共同描绘了一个全面的画面，说明了持续学习和适应不仅有益，而且对于在技术和 市场需求变化面前保持相关性和效率是必不可少的。

感谢您花时间通过本书探索 DevOps、DevSecOps 和 SRE 的持续测试、质量、安全性和反馈。 我们希望各章节中呈现的讨论和方法论，能为您提供有价值的见解和实践知识，帮助您提升自己的实践。 您的参与和学习承诺是推动该领域改进和创新的动力。 我们感谢您在提升理解和技能方面的投入，并祝愿您在未来的持续学习和改进旅程中取得成功。

术语表和参考资料

术语表

这里是一个扩展的相关术语表，重点关注持续测试、质量、安全性和反馈， 按字母顺序组织：

A

验收测试：验证系统在开发过程结束时并在发布之前，是否符合商定的要求。

自动化构建：将软件代码编译和构建为可执行软件的自动化过程。

B

行为驱动开发（BDD）：一种软件开发和测试的协作方法，通过使用共享的工具 和流程，将业务需求与技术解决方案对齐。

无责事后分析：一种在 DevOps 中用于分析和学习失败的方式，重点关注过程和 系统改进，而非个人责任。

C

变更管理：通过流程、工具和技术管理变更的人员方面，以实现所需的 业务成果。

配置管理（CM）：涉及工作范围的创建、维护、控制变更和质量控制的技术和行政活动。 。

持续交付（CD）：一种软件工程方法，团队以短周期生产软件，确保软件可以在任何时刻可靠地发布。

持续部署：将软件发布到生产环境的实践，前提是它已经通过了 自动化测试。

持续改进：不断努力改善产品、服务或流程。 这些努力可以追求“渐进性”改进，也可以追求“突破性”改进， 一次性实现。

持续集成（CI）：一种开发实践，开发人员将代码频繁地集成到共享代码库中，每次提交都通过自动化构建进行验证，从而让团队能及早发现 问题。

持续安全：将安全实践和工具集成到开发和部署管道中，持续识别和缓解 风险。

持续测试：作为软件交付管道的一部分，执行自动化测试的过程，目的是及时获得关于软件发布候选版本的业务风险反馈。

D

DevOps：一组结合了软件 开发 （Dev）和 IT 运维 （Ops）的实践，旨在缩短系统开发生命周期并提供具有高 软件质量的持续交付（CD）。

DevSecOps：DevOps 的扩展，集成了安全实践和原则，融入到 DevOps 流程中。

F

反馈回路：一种系统，其中输出被反馈并作为输入使用，是持续开发、交付和 改进过程的核心。

I

事件管理：管理所有事件生命周期的过程，确保尽快恢复正常服务操作并将业务影响 降到最低。

M

监控：观察和检查系统及其组件行为和输出的活动，持续一段时间。

突变测试：一种软件测试方法，通过小幅修改程序的源代码或字节码，来测试现有测试无法发现的代码部分。

P

性能测试：测试系统在特定工作负载下的响应性和稳定性表现。

事后分析：事件或项目完成后的过程，调查并为未来改进总结经验教训。

问

质量保证（QA）：确保软件产品在发布到生产环境之前满足所需的质量标准。

质量控制（QC）：质量管理的一部分，专注于满足质量要求的操作技术和活动。

R

回归测试：一种软件测试，验证在修改或与其他软件接口之后，先前开发和测试的软 件是否仍能正确执行。

风险管理：对金融风险的预测与评估，并识别避免或最小化其影响的程序。

S

安全信息与事件管理（SIEM）：一种安全管理方法，旨在提供对组织信息安全的整体视图。

软件测试：执行程序或应用程序的过程，目的是发现软件缺陷。

T

测试自动化：使用特殊软件控制测试执行并将实际结果与预测结果进行比较。

威胁建模：一种通过识别目标和漏洞，进而定义对策来防止或缓解威胁对系统影响的网络安全优化程序。

U

可用性测试：通过在用户上进行测试，直接观察他们如何与产品互动，从而评估产品的测试方法。

V

漏洞评估：识别、量化并优先处理系统中的漏洞的过程。

书籍参考

• 加速：精益软件与 DevOps 的科学：构建和扩展高性能技术组织 作者：Nicole Forsgren、Jez Humble 和 Gene Kim。 本书提供了实证研究，支持 DevOps 实践的有效性，以及文化和自动化在实现技术组织高性能中的重要性，支持本章关于 DevOps、DevSecOps 中持续实践的讨论， 站点可靠性 工程 (SRE)。

• 人工智能：思考型人类的指南 作者：Melanie Mitchell。 本书深入探讨了当前 AI 技术的能力和局限性，包括它们在软件开发等各个领域的应用。 它提供了一个基础性的理解，帮助了解如何利用 AI 和机器学习进行持续测试、质量保证、安全性和反馈，这与本书第八章中讨论的主题非常契合。 第八章。

• 持续交付：通过构建、测试和部署自动化实现可靠的软件发布 作者：Jez Humble 和 David Farley。 本书重点讲解了 CD（持续交付）的原则，这些原则与本书第三章中讨论的持续测试和反馈机制紧密相关。 第三章提供了一个框架，支持本章强调从过去经验中学习，以改进未来实践。

• 持续安全测试：将保护措施集成到 DevOps 中 作者：Kualitatem。 这篇博客文章探讨了将持续安全措施集成到 DevOps 管道中的方法，支持本章关于 DevSecOps 中持续安全实践的讨论。

• 《商业数据科学：你需要了解的数据挖掘和数据分析思维》 作者：Foster Provost 和 Tom Fawcett。 本书深入探讨了如何将数据驱动的方法应用于商业挑战，包括软件开发和运维。 它涵盖了数据科学的基础原则，这些原则对理解如何有效地在持续过程中实施 AI/ML 至关重要。

• 《DevOps 入门指南》 作者：Emily Freeman。 本书面向 DevOps 的初学者和早期采用者，描述了 DevOps 作为一种协作、责任和学习的工程文化，支持本章强调的 DevOps 实践中的持续改进。

• 《工程化 DevOps：从混乱到持续改进》 作者：Marc Hornbeek。 这本书是任何希望实施或改进 DevOps 实践的人的优秀参考指南。 它涵盖了实现持续改进及更高水平所需的工程实践，使其与本书所附章节关于持续学习和改进的重点高度相关。

• 《精益分析：用数据更快地构建更好的初创公司》 作者：Alistair Croll 和 Benjamin Yoskovitz。 本书提供了关于如何有效利用数据来衡量和推动商业成功的全面指南。 它与第十二章中的主题高度契合，特别是在衡量组织转型中的进展和结果时。

• 《机器学习的渴望》 作者：Andrew Ng。 作为该领域的先驱之一，本书专注于如何构建机器学习（ML）项目。 Andrew Ng 提供了关于如何将机器学习应用于复杂系统的实际见解，这些见解可以直接应用于增强软件开发流程，如本书所述。

• 《从项目到产品：如何在数字化变革时代借助 Flow 框架生存与发展》 作者：Mik Kersten。 Kersten 的这本书介绍了 Flow 框架，这是一种为创新构建基础设施的新方法，专注于组织到客户之间的价值流动。 该框架与实施持续实践的战略规划和路线图开发高度契合，如本书第10 章所讨论的那样。

• 《站点可靠性工程：谷歌如何运行生产系统》 作者：尼尔·理查德·墨菲、贝琪·贝耶、克里斯·琼斯、詹妮弗·佩托夫。 本书介绍了 SRE 的原则和实践，深入探讨了谷歌如何确保其系统的可靠性和可扩展性，与章节中聚焦的持续运营实践 SRE 相辅相成。

• 《DevOps 手册：如何在技术组织中创造世界级的敏捷性、可靠性和安全性》 作者：吉恩·金、帕特里克·德博伊斯、约翰·威利斯、杰兹·汉布尔。 本书深入探讨了如何将持续测试、安全性和反馈融入到 DevOps 实践中，这与第3 章 中关于这些概念演变和实际应用的经验和教训相契合。

• 《持续反馈在软件测试中的重要性》 作者：GeeksforGeeks。 本文强调了持续反馈在软件测试中的作用，与本章对敏捷、DevOps 和 SRE 方法中持续反馈机制的重视相一致。

• 《持续测试在软件开发中的重要性》 作者：Synopsys。 本文讨论了在 DevOps 中战略性地实施持续测试，符合本章在数字化转型中将持续测试作为软件开发的一部分的重点。

• 《精益创业：当今的企业家如何利用持续创新创建具有革命性成功的企业》 作者：埃里克·里斯。 埃里克·里斯介绍了诸如构建-测量-学习反馈循环等概念，这对于衡量任何创新过程中的进展和成果至关重要，包括涉及持续测试、质量、安全和反馈的过程。

• 《凤凰项目：关于 IT、DevOps 和帮助你的企业获胜的小说 作者：吉恩·金、凯文·贝尔、乔治·斯帕福德。 这本小说提供了对 DevOps 理念的深入了解，并展示了它在改善业务成果方面的影响。 它强调了协作、自动化以及从失败中学习的重要性，与附带章节的主题相契合。

• 如何衡量一切：在商业中找到“无形资产”的价值 由道格拉斯·W. 哈伯德。 本书挑战了某些事物不可度量的观念，并提供了量化商业背景中不同类型风险和价值的方法和最佳实践，直接支持章节中讨论的衡量策略。 第十二章。

互联网参考资料

• 通俗的 AI 解释 英语： https://medium.com/ai-in-plain-english 这篇 Medium 文章将复杂的 AI 概念分解成易于理解的文章，通常侧重于实际应用。 它包括讨论 AI 如何通过自动化任务、提高质量和增强 安全措施来改变各行各业，包括软件开发。

• DevOps.com 上的博客文章，作者： 马克·霍恩比克 马克·霍恩比克定期向 DevOps.com贡献文章，讨论 DevOps 实践的各个方面，包括持续测试、质量、安全性和反馈。 这些文章提供了实际的见解，并补充了本书中的讨论。

• 云原生计算基金会 (CNCF) 博客： https://www.cncf.io/blog/ 这些关于云原生技术和实践的见解与更新，支持数字技术在业务流程中的整合，如数字化转型战略章节中所述。

• 比较 SRE 与 DevOps：它们有什么 不同之处？ StrongDM。 本文详细比较了 SRE 和 DevOps，突出了它们的起源、原则和实践。 它支持附录章节中关于团队如何通过实验、处理失败和应用 混沌工程等方式学习和改进的讨论。

• 持续反馈使用案例：利益相关者对需求的反馈 需求收集 从利益相关者收集和整合对定义需求和质量标准的反馈。 确保项目与利益相关者的期望和 业务目标保持一致。

• 持续安全测试：将保护集成到 DevOps. Kualitatem. 这篇博客文章探讨了将持续安全措施集成到 DevOps 流水线中的方法，支持本章关于 DevSecOps 中持续安全实践的讨论。 在 DevSecOps 中的持续安全实践。

• DevOps Institute: https://devopsinstitute.com/ DevOps Institute 提供有关 DevOps 实践的资源、认证和教育材料，包括持续测试、质量、安全性和反馈。 它是了解 DevOps 最新趋势和进展、以及寻找有效实施这些实践策略的宝贵资源。

• DevOps.com: https://devops.com/ 一个领先的 DevOps 相关文章、新闻和分析来源，涵盖了持续测试、安全性和反馈等主题。 该网站提供了与本章讨论的概念相关的实践见解和案例研究。 第四章。

• DZone: https://dzone.com/ DZone 提供了广泛的关于软件开发和 DevOps 各个方面的文章和教程，包括持续测试和安全性。 它是理解转型目标在 实际场景中应用的宝贵资源。

• Google AI Blog: https://ai.googleblog.com/ 这个博客提供了来自 Google AI 研究和项目的最新动态和见解。 它是一个很好的资源，帮助你随时了解 AI 和机器学习技术的最新进展，包括它们在软件工程和 DevOps 实践中的应用。

• Google Analytics: https://analytics.google.com Google Analytics 提供了用于衡量网站和活动表现的工具，可以类比为衡量项目结果和进展。 它提供了有关如何有效追踪和解释用户数据的见解，这对于数字化转型的相关业务至关重要。 业务转型。

• InfoQ: https://www.infoq.com/ InfoQ 提供有关软件开发领域的最新趋势和创新的更新与深入分析，包括持续交付和 DevOps 实践。 它帮助读者了解影响转型目标的最新策略和技术。

• 将安全性整合进 DevOps：弥合速度与安全之间的差距。 Security Boulevard。 本文探讨了在 DevOps 工作流中整合安全实践，支持本章节讨论 DevSecOps 发展的内容，以及在整个开发 生命周期中嵌入安全性的实际挑战。

• CloudNativeNow.com 上的访谈 与 Marc Hornbeek 在访谈中，Marc Hornbeek 经常讨论他在 DevOps 和持续实践中的经验和见解，提供了支持本书内容的实际例子和策略。

• Kissmetrics 博客: https://blog.kissmetrics.com/ 这个博客提供有关分析、营销和测试的文章，提供了关于数据如何驱动决策并改善业务流程的有价值的见解，这与本书第12 章中持续改进和衡量的主题相一致。

• 从生产中学习：实时监控和反馈如何提升软件 开发. DevOps.com。 本文讨论了实时监控和反馈在软件开发中的重要性，这与本章节着重从实际经验中学习以优化测试和 安全实践的主题相契合。

• Security Boulevard: https://securityboulevard.com/ 专注于 IT 领域的安全性，提供符合本章节中能力成熟度模型持续安全方面的文章和专家意见。 。

• SRE 与 DevOps：有什么 不同？ TechTarget。 本文探讨了 SRE 和 DevOps 之间的区别，强调通过适当的监控工具和实践实现持续改进。 它与附加章节强调的在软件开发和运维中的持续学习和改进相一致。

• Tableau： https://www.tableau.com/ Tableau 提供强大的数据可视化工具，帮助组织将海量数据转化为可操作的洞察。 这对于可视化进度和结果度量尤其有用，正如 第十二章中讨论的那样。

• 软件 测试中持续反馈的重要性。GeeksforGeeks。 本文强调了持续反馈在软件测试中的作用，与章节中对持续反馈机制在敏捷、DevOps 和 SRE 方法论中的应用强调相符。

• 新 技术堆栈： https://thenewstack.io/ 该网站聚焦于软件开发中的趋势分析，包括 DevOps 和云原生技术。 The New Stack 提供了文章，探索新兴趋势如何在 行业中得到应用。

• 敏捷开发中反馈的重要性：持续反馈如何推动改进。 敏捷联盟。 本文强调了持续反馈在敏捷开发过程中的作用，与章节中强调的使用反馈来提升软件项目的质量和安全性相辅相成。 。

• 走向数据 科学： https://towardsdatascience.com/ 这是一个平台，数据科学专业人士和爱好者分享见解和教程，涵盖 AI 和 ML 在各行各业的应用。 该网站上的文章经常探讨将 AI/ML 创新性地应用于软件开发的方法，使其成为理解类似于 第八章中讨论的实际应用的宝贵资源。

• 将您的 DevOps、DevSecOps 和 SRE 转向云原生 原生。CloudNativeNow.com。 本文讨论了在 DevOps、DevSecOps 和 SRE 实践中采用云原生原则的战略举措。 它突出了提升敏捷性、可扩展性和韧性的好处，支持附加章节的重点，即将技术变革视为进步的机会。 。

• 网络研讨会邀请 Marc Hornbeek Marc Hornbeek 参与了多个专注于 DevOps、持续测试和安全的网络研讨会。 这些网络研讨会通常 有主题安排。

• 什么是 DevOps 中的持续测试？ (策略 + 工具). TestRail. 本文讨论了在 DevOps 中战略性地实施持续测试，与本章聚焦于作为数字化转型一部分的软件开发中的持续测试相一致。