混沌工程

第 16 章 持续验证 持续验证

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

持续验证是一门在软件中进行主动实验的学科，以验证系统行为的工具形式实施。

凯西-罗森塔尔

复杂系统带来的挑战促使从持续集成到持续交付再到持续验证的自然演进。后者是本章的主题，它描述了这一新兴领域和机遇空间，并以 Netflix 正在生产的一个名为 ChAP 的系统为例进行了阐述。业界对持续验证的发展方向尚无定论，但本章末尾将对未来发展的一般重点领域进行回顾。

简历从何而来

当 两个或更多工程师分别编写代码时存在期望差距，那么代码的交互可能会产生意想不到的不良结果。越快发现这种情况，下一次编写的代码就越有可能减少差距。反之，如果不能及早发现漏洞，那么下一次编写的代码很可能会出现更大的偏差，从而增加出现不良结果的机会。

发现期望差距的最有效方法之一就是将代码放在一起运行。作为XP 方法论的一部分 ，持续 集成（CI）作为实现这一目标的方法得到了大力推广。现在，CI 已成为一种普遍的行业规范。CI 管道鼓励开发集成测试，专门测试由不同开发人员或团队编写的代码的组合功能。

每次编辑代码并发布到共同的资源库时，CI 管道都会编译新的合并代码并运行集成测试套件，以确认没有引入破坏性更改。这种 反馈循环促进了软件的可逆性：能够快速推广代码、改变主意并恢复更改。可逆性¹是驾驭复杂软件系统的有利优化手段。

持续交付（CD）实践是在 CI 成功的基础上发展起来的，它将准备代码并将其部署到环境中的步骤自动化。CD 工具允许工程师选择已通过 CI 阶段的构建，并通过管道将其推广到生产环境中运行。这为开发人员提供了额外的反馈回路（新代码在生产环境中运行），并鼓励频繁部署。频繁的部署更不容易出错，因为它们更有可能捕捉到额外的期望差距。

在 CI/CD 的优势基础上，一种 新的实践正在出现。持续验证（CV）是一门积极主动的实验学科，作为验证系统行为的工具来实施。这与此前软件质量保证领域的常见做法形成鲜明对比，后者倾向于 被动测试、² 验证软件已知属性的方法。³软件的已知属性。这并不是说以前的通用实践是无效的或应该被淘汰。警报、测试、代码审查、监控、SRE 实践等等，这些都是很好的实践，应该得到鼓励。CV 以这些通用实践为基础，专门解决复杂系统特有的问题：

• 针对系统属性优化的前瞻性实践很少。

• 复杂的系统 需要采用有利于探索未知（实验）而非已知（测试）的方法。

• 为了扩大规模，需要使用工具，而方法论（Agile、DevOps、SRE 等）则需要进行数字化转型和文化变革，并对实施人员进行昂贵的投资。

• 验证 针对的是业务成果，与验证相比，验证更注重软件的正确性，而业务成果则是复杂系统运行时更务实的重点。

• 复杂系统的属性是开放的，处于不断变化的状态，因此需要采用与理解软件已知属性（如输出约束）不同的方法。

CV 并不旨在开发一种新的软件工程范例。相反，它是对各种开发工作和实践的一种认可，这些工作和实践都是为了解决具有许多共同点的问题。我们注意到，这一新类别的出现与我们迄今为止对软件开发和运行的普遍看法大相径庭（图 16-1）。

与混沌工程（Chaos Engineering）非常相似，CV 平台可以包含可用性或安全性（见第 20 章）组件，并通常将其表述为假设。与 CI/CD 一样，这种做法也是出于驾驭日益复杂系统的需要。组织没有时间或其他资源来验证系统的内部机制是否按预期运行，因此他们转而验证系统的输出是否符合预期。这就是复杂系统管理成功的标志--重验证轻确认。 ...