第 6 章：混沌工程与服务可靠性
复杂的现代系统本质上是脆弱的。即使是看似微小的中断，或单一的薄弱环节，也可能导致问题螺旋式上升，造成灾难性后果。
考虑以下场景：一个著名的电商平台在类似黑色星期五的销售高峰期遭遇了严重的服务中断。随着流量的增加，平台的结账服务变得异常缓慢，最终导致彻底崩溃。数千名顾客无法完成购买，这不仅导致了直接的收入损失，还损害了声誉，侵蚀了信任和品牌忠诚度。事后分析显示，根本原因是结账服务与关键定价数据缓存之间的网络延迟。在高流量的压力下，当缓存响应变慢时，系统的重试机制不堪重负，导致请求级联失败，最终使数据库过载。
像这样的场景以及不断上升的故障成本，催生了服务可靠性作为一门学科的出现，以及混沌工程（有时称为故障注入测试）的实践。混沌工程的目标是帮助我们理解系统在异常（混沌）压力下如何表现。新工具、新技术和新实践的发展推动了这些实践的日益普及。
混沌工程一词可以追溯到 2010 年的 Netflix。当时该公司正在将其基础设施迁移到云端，这引入了新的复杂性，数百个微服务以不可预测的方式相互作用。为了测试其系统的韧性，Netflix 的工程师开发了 Chaos Monkey，这是一款旨在随机终止生产环境中虚拟机实例的工具。这模拟了真实世界的故障，迫使工程师构建能够优雅处理意外中断的系统。
使用“混沌”一词以及一只猴子被放出在生产环境中随机终止软件的形象，确实会让人联想到混乱。鉴于这些先入之见，将混沌工程引入组织可能会遇到阻力。不止一位老板曾疑惑：“我们这里还不够乱吗？”
在本章中，我们将通过将现代混沌工程理解为一种严谨的实验实施方法来反驳这些观念。作为一种方法论，我们利用这种受控的中断来测试我们系统的韧性。除了测试我们当前的状况，混沌工程还为我们提供了一种强大的方法，可以系统地提高韧性。
我们进行的实验让我们对软件在压力下的行为有了更深入的理解。这些知识使我们能够设计有针对性的改进。然后我们进行测试，以验证其在实现目标方面的有效性。
服务可靠性与服务韧性
服务可靠性和服务韧性是相关概念。前者是指服务在指定条件下，在特定时间内无故障地执行其预期功能的概率。后者是指服务承受并从硬件故障、软件错误、网络中断乃至网络攻击等中断中恢复的能力。它关乎服务从逆境中恢复的良好程度。
尽管它们是不同的，但它们相互关联。高度可靠的服务不太可能发生故障，但即使是最可靠的系统也可能遇到意想不到的问题。这就是韧性发挥作用的地方。它确保即使发生故障，服务也能快速恢复，并将对用户的中断降至最低。
我们还将探讨如何使用服务级别目标（SLO）来设定我们的韧性目标。我们将研究如何使用错误预算来允许在该目标范围内达到可接受的故障水平。我们将看到混沌工程如何与这些机制协同工作，帮助我们验证即使面对意外中断，我们的系统是否也能在其错误预算内运行并仍能达到我们的目标。
在本章中，我们还将超越静态混沌实验，了解一种更现代和动态的方法，它涉及将混沌工程整合到我们的 CI/CD 流水线中，使我们能够持续评估和改进系统韧性，作为我们日常开发工作流程的一部分。
在本章中，我们将探讨先进的混沌工程工具如何利用 AI/ML 驱动的洞察力来推荐和指导这些实验的执行，从而提高韧性测试的效率和效果，同时降低风险。我们还将看到智能体 AI、生成式 AI 和 MCP 如何通过自动化实验设计、实现动态风险检测和提供智能补救措施来解决混沌工程中关键的可扩展性和精度挑战。这些技术将混沌工程从一种被动的实践转变为一种主动的、自我优化的系统韧性策略。
混沌工程入门
虽然许多混沌工程实验都采用随机性（例如，随机选择一台服务器或服务来关闭），但混沌工程的实践就像实验室科学一样有条不紊。在本节中，我们将深入探讨混沌工程的核心原则，并探讨在进行实验时降低导致服务中断风险的最佳实践。
混沌工程原则
Netflix 定义了一系列核心原则，为探索系统在压力下的行为提供了一个有用的框架。结构化的方法确保您的混沌实验不仅仅是破坏性事件，而是结构化的调查，生成有价值的数据，您可以利用这些数据来推动系统韧性的改进。这些原则是：
定义表征正常系统行为的“稳态”
可观测性是这里的关键。您必须拥有所需的指标，以了解表示系统健康并按预期运行的正常值范围。这可能包括请求延迟、错误率、吞吐量或特定于应用程序的指标。务必考虑可能影响指标的外部因素，例如一天中的时间、一周中的某天，或可能导致流量激增的营销活动。
将预期转化为假设
根据您对系统架构和依赖关系的理解，针对当引入特定故障时系统应该如何表现，提出一个假设。以能够使用所选指标进行客观测试的方式构建您的假设。例如，“如果我们将流量增加 20%，平均响应时间应保持在三秒以下，错误率不应超过 0.5%。”
通过模拟真实世界事件执行实验
使用混沌工程工具自动化故障注入。模拟服务器崩溃或变得不可用、关键第三方服务中断，或用户请求突然激增。
根据假设评估结果
将实验期间系统的行为与您建立的基线和您的假设结果进行比较。指标是否保持在可接受的范围内？系统是否按预期恢复？是否观察到任何意外的副作用？如果系统偏离预期行为，请调查根本原因。根据实验结果，完善您的假设并调整您的系统设计或操作流程以增强韧性。
从小处着手并逐步扩展
模拟故障以故意关闭系统当然会带来风险。我们以这种受控的方式故意承担风险，以验证我们定义的假设。降低风险的一个重要策略是先从小规模实验开始。
为了说明从小处着手并逐步扩展实验，我们来看一个专注于测试电商系统中结账服务的例子。该服务是处理用户购买的关键微服务。预期结果很简单：客户将商品添加到购物车，进行结账，并完成支付。客户期望获得流畅、快速和可靠的体验。
在幕后，这种直接的操作依赖于一系列复杂的流程。结账服务依赖多个 API 和外部服务才能正常运行，包括库存系统、支付网关和缓存层（如 Redis），以快速检索重要的价格、折扣和可用性数据。结账服务从缓存中获取定价数据以实现快速访问。如果缓存缓慢或失败，结账服务仍应通过故障转移到另一个缓存实例，甚至作为备份转移到数据库来提供正确的信息，尽管这可能会更慢。
生成式 AI 可以将混沌工程从手动假设测试转化为自适应、自优化的韧性验证系统。这种方法在结账服务等关键电商工作流中尤其有价值，因为它需要在风险缓解与实际故障模拟之间取得平衡。
开发人员通常会配置重试逻辑、超时和熔断器来处理网络问题或故障。让我们分别看看它们：
重试逻辑
这确保了如果对缓存的请求失败或遇到网络问题，系统将在放弃之前自动重试几次。这有助于处理瞬时故障。例如，系统可能会重试多达三次，每次重试之间延迟 100 毫秒。
超时
超时设置定义了服务在决定尝试失败之前应等待响应多长时间。这可以防止服务在缓存缓慢或无响应时无限期挂起。系统可能会配置为对缓存的每个请求在 200 毫秒后超时。
熔断器
熔断器在一定数量的失败尝试后，会阻止进一步调用故障服务。如果缓存持续失败或速度过慢，熔断器会“跳闸”并将流量路由到备用系统（例如，另一个缓存或数据库）。熔断器可以在设定的一段时间后自动重置，以测试原始服务是否已恢复。例如，熔断器可能配置为在五次连续重试失败后跳闸。
我们将通过引入少量延迟来开始测试结账服务，以确保重试逻辑和超时设置正常运行，然后再逐步升级，引入更严重的问题，最终触发熔断器。如果一切顺利，我们期望系统能够故障转移到备用数据源。以下是我们的步骤。
步骤 1：进行简单的延迟实验
我们首先测试我们的重试逻辑。我们希望确保系统在网络问题（例如高延迟或临时连接丢失）出现时具有韧性。我们的稳态是一个响应迅速的服务，在可接受的时间限制内作出响应。
我们的假设是，如果网络在尝试访问缓存时出现显著延迟，系统应使用其重试逻辑和超时设置来优雅地处理问题，最终触发熔断器以防止服务进一步退化。
我们从小处着手，在结账服务和缓存之间注入少量网络延迟（例如 200 毫秒）。
我们观察重试逻辑是否启动，以及服务是否在可接受的时间限制内处理延迟而未对用户造成影响。我们持续监控系统是否在延迟后继续按预期运行，并从缓存中拉取数据。
步骤 2：测试针对更显著网络问题的韧性
一旦我们用少量延迟测试了重试逻辑，我们就可以增加实验的范围和强度，以模拟更显著的网络问题。这测试了我们的超时设置。我们增加网络延迟（例如从 500 毫秒增加到 1 秒），以查看服务在更重负载或网络拥堵下的行为。我们测试重试逻辑如何处理延长延迟。服务是否重试对缓存的调用，
并且它是否遵守超时设置？如果是，我们将通过在一定数量的重试后导致缓存 API 完全失败来增加问题的严重性。
步骤 3：验证熔断器是否故障转移到备用方案
接下来，我们设置实验条件，使缓存无法访问。在重试后，熔断器机制应该被触发。当熔断器跳闸时，结账服务会故障转移到备用数据源，例如不同数据中心中的另一个缓存实例（在本例中是我们的 Postgres 数据库）。虽然 Postgres 数据库可能比缓存慢，但目标是保持服务运行，尽管性能略有下降。
AI 代理可以通过使用强化学习动态调整故障注入参数来使这个过程变得更简单。例如：
- 从 200 毫秒延迟开始，然后根据实时性能遥测数据自主扩展到 500 毫秒至 1 秒。
- 最初将实验影响限制在 0.5% 的交易，仅在验证安全机制后才扩展。
- 通过历史成功模式分析优化跳闸阈值（例如，五次失败到四次）。
您可以进一步扩展实验，通过在结账服务和 Postgres 数据库之间引入类似的网络问题来测试故障转移的韧性，以查看系统在增加的故障条件下如何继续适应。通过遵循这个过程，我们逐渐增加实验的复杂性，以验证系统的韧性机制，而不是立即跳入重大的中断。
值得注意的是，韧性机制的初始设置通常基于有根据的猜测而非精确数据。这也是通过混沌工程实验进行测试如此重要的另一个原因。
注入网络延迟只是我们可以在混沌实验中扩展的一种条件。我们将在本节后面讨论其他条件。
在类似生产环境的条件中开始
在混沌工程中，另一个重要的最佳实践是在投入生产之前，先在预生产环境中测试实验。这使我们能够在不影响真实用户的情况下安全地进行实验。我们可以快速迭代、调整参数并观察结果，不受生产约束。一旦我们确认系统在这些设置中的韧性，我们就会将实验推广到下一个环境，最终达到生产环境。每次推广都伴随着风险，因此我们必须谨慎行事。环境之间的配置漂移可能导致实验结果不一致。在环境之间移动时，坚持“从小处着手并逐步扩展”的方法至关重要，以防遇到问题。在预生产中彻底审查我们的实验可确保我们的实验设计良好且富有洞察力，而不会产生意外后果。
利用现代工具
我们广泛地探讨了在混沌实验中测试网络延迟的例子。还有许多其他类型的条件值得测试。现代工具（例如 Harness Chaos Engineering、Chaos Monkey 和 LitmusChaos）可以通过提供丰富的预定义实验目录来提供帮助。现代工具通常会提供跨类别和常见故障模式的混沌工程实验，包括：
资源耗尽
CPU 耗尽
强制高 CPU 利用率以模拟进程消耗过多处理能力。
内存耗尽
消耗所有可用内存，测试应用程序如何处理内存压力和潜在的内存不足错误。
磁盘 I/O 耗尽
生成大量磁盘读/写操作以模拟存储瓶颈。
网络带宽耗尽
饱和网络带宽，测试应用程序在网络拥堵下的性能。
网络中断
网络延迟
在服务之间或与外部依赖项之间引入网络通信延迟。
丢包
模拟网络数据包丢失，测试应用程序如何处理不可靠的连接。
网络分区
隔离网络部分以模拟服务之间的连接问题或可用区中断。
DNS 故障
模拟 DNS 解析问题，测试应用程序如何处理 DNS 中断或不正确的响应。
基础设施故障
节点故障
终止或关闭虚拟机或容器以模拟硬件故障。
Pod 故障 (Kubernetes)
杀死或驱逐 Pod，测试 Kubernetes 部署的自愈能力。
可用区中断
模拟整个可用区故障，测试您的灾难恢复计划和多区域部署。
推理层攻击
在 ML 模型服务期间模拟 GPU 内存耗尽。
应用程序级别故障
服务故障
停止或崩溃应用程序内的特定服务，测试容错和服务降级。
功能故障
在特定函数或方法中引入错误或异常，测试错误处理和恢复机制。
数据损坏
损坏数据库或存储系统中的数据，测试数据完整性和恢复过程。
状态管理
时间旅行
操纵系统时钟以模拟时间偏移，测试应用程序如何处理时间敏感操作或计划任务。
状态注入
将特定数据或状态注入到您的应用程序中，以测试其在异常条件下的行为。使用生成式 AI 创建符合模式约束的合理损坏数据条目。
使用 AI 动态生成场景
架构建模
使用 AI 分析服务依赖关系（例如，Redis 缓存 → 支付网关 → 数据库），创建镜像生产环境的故障链。
生成对抗网络
通过让 AI 模型相互对抗来发现未探索的漏洞组合，从而创建新颖的故障模式。
我们尝试的实验类型越多，我们就能越多地了解系统中的弱点以及如何增强其韧性。
更新的工具除了提供目录之外，还可以分析您的系统架构，以建议针对您特定设置的、暴露潜在弱点的实验。例如，对于使用微服务架构构建的软件，混沌工程工具可能会分析网络流量和依赖关系，以识别关键服务并建议专门针对这些服务的实验。现代工具还可能建议在服务之间的 API 调用中注入延迟或错误，以测试通信中断的韧性。
对于使用 Kubernetes 部署的应用程序，该工具可以分析您的 Kubernetes 部署并建议针对特定 Pod、部署或命名空间的实验，以测试副本扩缩、资源限制和健康检查。像 Red Hat 的 Krkn 这样的工具使用 AI 来分析 Kubernetes Pod，以优先处理网络密集型服务进行分区测试。在多区域部署的情况下，现代工具可能会分析您的多区域设置并建议模拟区域故障或网络分区的实验，以测试您的灾难恢复计划以及应用程序故障转移到另一个区域的能力。
从他人经验中学习
密切关注行业范围内的事件，特别是那些影响使用类似技术栈的公司的事件，对于主动的风险缓解至关重要。例如，OpenAI 在 2024 年 12 月 11 日发生的服务中断，就清楚地提醒我们，看似微不足道的部署也可能产生连锁反应。
在此事件中，一个新的遥测服务压垮了该公司的 Kubernetes 控制平面，触发了 DNS 故障，导致其 API、ChatGPT 和 Sora 平台停机数小时。影响是广泛而持久的：数小时内，开发人员和用户无法访问他们所依赖的服务。工程师们在几分钟内识别出根本原因，但面临一个主要障碍——无法访问 Kubernetes 控制平面，回滚或修复部署变得极其困难。
让我们看几个有针对性的混沌工程实验，以了解这些级联故障可能如何被阻止。
实验 1：控制平面过载模拟
首先，我们设计一个实验来测试 Kubernetes API 服务器的韧性。在这个实验中，我们将故意用大量的读/写操作来淹没 Kubernetes API 服务器，以模拟新的遥测服务在生产环境中所做的事情。通过在具有类似生产规模的预演环境中运行此测试，我们可以发现 API 服务器开始失效的精确阈值。这种早期检测将有助于更好地限制负载、改进警报，并可能制定更安全的阶段性发布策略。
实验 2：DNS 故障测试
该实验将涉及在 DNS 解析过程中引入延迟或故障——特别是针对负责服务发现的组件。运行此实验有助于确认即使 DNS 中断，基本服务也能继续运行。我们将发现我们的缓存、回退机制或替代路由策略是否足够。如果不足，我们就会知道在真正的中断发生之前投资于这些领域。
示例 3：紧急访问演练
最后一个实验（或演练）涉及模拟工程师在重负载下被锁定在 Kubernetes API 之外的情况。通过实践紧急访问方法——例如拥有专用的带外通道或专业工具——团队可以在标准控制平面不可访问时快速回滚或禁用有问题的部署。如果事先进行了这项演练，团队就会知道如何在几分钟内准确地移除有故障的遥测服务，从而最大限度地缩短停机时间。
服务级别目标与服务韧性
我们看到了混沌工程如何帮助我们发现弱点并构建更具韧性的系统。但我们如何定义“韧性”？我们如何衡量和跟踪我们的系统是否达到了可靠性目标？这就是 SLO（服务级别目标）和 SLI（服务级别指标）发挥作用的地方。它们共同为定义和衡量服务可靠性提供了框架，为我们提供了明确的目标和跟踪进展的方法。
SLO 是我们为服务可靠性设定的目标。SLI 是我们用来衡量是否达到这些目标的具体指标。SLO 通常表示为必须满足定义的 SLI 标准的时间百分比或请求数量。例如，99.9% 的请求延迟应低于 200
毫秒。SLI 是具体的、可衡量的指标，反映从用户角度看服务的性能。它们量化了可用性、延迟、错误率、吞吐量以及其他相关因素。
本质上，SLI 是您衡量的内容，而 SLO 是您为这些测量设定的目标。
建立可靠性目标
在建立可靠性目标时，务必使其与总体业务需求保持一致。监控和可观测性解决方案提供了许多 SLI 指标，但重要的是要优先选择那些能准确反映客户应用体验的指标。目标不是跟踪每个单独的服务，而是专注于那些对客户体验至关重要的服务。
常见的 SLI 包括“四大黄金信号”：
请求延迟 处理用户请求所需的时间
吞吐量
每秒处理的请求数量
错误率
失败请求的百分比
饱和度
系统利用率百分比
仔细考虑如何在您的系统中实现这些指标。例如，在测量延迟（响应时间）时，您可以选择跟踪所有交易，或专注于最重要的交易子集，例如登录、支付提交或将商品添加到购物车。再次强调，选择一个能有意义地代表客户体验的指标。
系统可靠性的共同所有权
在 第 1 章中，我们介绍了 DevOps 作为结合了软件开发 (Dev) 和 IT 运维 (Ops) 关注点的实践。在确保系统可靠性方面，共同所有权和协作的重要性无处不在。SLO 是这种共同责任的一个极佳示例。开发、运维和可靠性团队应该协同工作来定义 SLO。这种协作建立了对可接受系统性能的理解，并为每个人设定了共同努力的目标。SLO 进而成为指导决策的指南，以平衡快速开发（速度）与稳定可靠系统之间的需求。
有了这种共同理解，开发人员可以优先考虑维护可靠性的功能，了解他们的工作如何影响整体系统性能。同时，运维团队获得了有效支持应用程序所需的背景信息。如果 SLO 被违反，它将触发活动，鼓励工程团队在发布新功能之前稳定服务。这有助于防止不稳定循环，并确保可靠性始终是首要任务。
以协作方式设计、优先排序和执行混沌工程实验本身就能将团队凝聚在一起。所有团队都受益于从这些实验中获得的洞察力，以及在发现故障时共同解决问题的过程。
现代工具促进了这种协作式的系统可靠性方法。监控平台、事件管理系统和通信工具提供了对系统性能和潜在问题的共享可见性。实时数据和自动化警报使开发和运维团队都能快速响应事件。更重要的是，这些工具培养了一种积极主动解决问题的文化（例如，数据驱动的优先级排序、实时协作分诊等），团队可以在问题影响用户之前识别并解决潜在问题。
错误预算及其在可靠性和创新中的作用
我们已经了解了混沌工程如何帮助我们主动发现系统弱点，以及 SLO 和 SLI 如何为定义可靠性目标和衡量系统是否达到这些目标提供清晰的框架。错误预算 则作为安全网介入。
错误预算代表了服务在仍能满足其 SLO 的前提下，可以承受的最大不可靠性或停机时间。通过在追求快速创新时容忍小的故障，错误预算承认完美是无法实现的，而是帮助我们达到可接受的可靠性水平，以平衡这两个相互竞争的优先级。
让我们通过电商示例来看看它是如何运作的。假设我们设定了一个 SLO：99.9% 的网站登录时间少于 300 毫秒。在一周内，这转化为最大允许的 SLO 违反时间为 10.08 分钟。这就是我们的错误预算。这会如何影响我们？如果错误预算耗尽，我们将停止或减缓新软件的部署，并专注于稳定系统，直到错误预算得到补充。错误预算的状态不仅影响我们的部署优先级，还影响混沌测试的优先级。
通过监控为混沌测试实验提供信息
密切关注您的 SLI 不仅仅是向您发出即时问题的警报，它还会揭示您系统中潜在的弱点。例如，如果您注意到您的系统不断触及延迟限制，耗尽您的错误预算，那么您的系统可能在高流量场景中难以跟上。这表明了一个值得您重点进行混沌实验的领域。通过模拟那些高流量、高延迟的情况，您可以看到您的系统在压力下的表现，并确保它在高峰使用期间仍能满足其 SLO。
借助现代化工具，您可以根据这些模式自动触发混沌测试，从而实现自动化，无需动手即可持续测试和改进系统的韧性。现代平台可以使用 AI 将 SLI 趋势与混沌测试建议相关联，从而显著提高测试覆盖率。
错误预算在混沌测试实验中的战略性使用
错误预算不仅仅是偶然故障的安全网；它们是管理风险的工具。以我们的电商网站为例，我们将 10.08 分钟的错误预算视为一项需要明智使用的资源。在本节中，我们将探讨如何主动利用此预算进行混沌实验。
根据您的可用错误预算确定混沌实验的优先级
有效的混沌工程需要考虑您的可用错误预算。当您的错误预算充足时，您的运行空间就很长。您可以更自由地进行激进的实验，模拟大规模故障或将关键系统组件推到极限。这可能涉及测试故障转移机制、注入网络延迟，甚至模拟核心服务的完全中断。
随着错误预算的减少，将重点转向风险较小的较小规模实验至关重要。这可能涉及隔离测试单个组件、模拟轻微网络问题或验证最近更改的韧性。以这种方式确定实验的优先级可确保您可以在不危及整体系统稳定性的情况下继续学习和改进。
现代自动化工具可以提供帮助。通过实时分析您的错误预算，这些工具可以根据您的可用“容错空间”推荐适当的实验。这使您能够在主动测试和服务可靠性之间保持平衡，确保您的混沌工程工作既富有洞察力又负责任。
利用 AI 增强的试运行和模拟保护您的错误预算
首先进行模拟是最大限度降低混沌实验期间意外后果风险的另一种策略。当错误预算 dwindling 时，这一点尤为重要。AI 增强的“试运行”混沌实验实践涉及在受控环境中，使用系统模型或副本模拟实验，以在生产中执行之前评估其潜在影响，并使用 AI 修复代理在异常检测阈值超出预定义限制时回滚实验。通过事先识别潜在问题并完善实验参数，团队可以降低导致可能耗尽错误预算并造成重大中断的可能性。
将混沌工程和 SLOs 集成到 CI/CD 流水线中
可靠性问题主要由变化驱动，包括我们应用程序的变化或基础设施的变化。Google DevOps 研究与评估 (DORA) 定义了变更失败率 (CFR) 指标，这为我们提供了挑战的另一个视角。CFR 描述了我们的变更（例如新代码部署或基础设施更新）在生产环境中引入问题并需要热修复或回滚的频率。DORA 2024 年 DevOps 状态报告显示，80% 的受访团队平均 CFR 为其发布量的 20%。事实上，25% 的团队平均 CFR 甚至高达 40%。
此外，我们必须考虑修复每个变更失败所需的时间和成本。故障部署恢复时间指标（取代了类似的平均恢复时间 [MTTR] 指标）侧重于组织从故障中恢复的速度。这让我们了解团队在这方面面临的挑战。虽然许多团队能够在不到一天的时间内修复，但 25% 的团队需要一周到一个月的时间来替换有缺陷的软件。
在前面的章节中，我们研究了防止缺陷进入生产环境的策略。我们在交付流水线的每个阶段进行测试，执行各种类型的测试。我们小心翼翼地管理我们的环境。我们通过 GitOps 等实践结合 IaC 来防止配置漂移。我们还在预生产和生产环境中进行混沌工程测试，以帮助我们发现系统中的弱点。然而，尽管我们尽了最大努力，偶尔需要快速修复的缺陷是不可避免的。这就是持续韧性的用武之地。
正如持续集成和持续交付是关于使用自动化来构建、测试和部署我们的代码一样，持续韧性是关于通过将混沌工程实验添加到我们的 CI/CD 流水线中来自动化我们的韧性实践。这样做意味着我们不仅测试功能，而且积极持续地
评估变更将如何影响我们系统的稳定性。利用 AI 代理进行 DevOps，混沌实验可以智能地集成到 CI/CD 流水线中。
在“扩展您的混沌工程实践”中，我们将探讨如何在现代工具的帮助下，将混沌工程实践集成到我们的交付流水线中，从而扩展它。我们将研究如何优先考虑要添加到流水线中的实验，以及在流水线中保护和管理混沌实验的最佳实践。
扩展您的混沌工程实践
组织开始其混沌工程之旅的方式各不相同。通常，一个或两个团队会采用开源工具并在组织的某个小范围内引入实验。一个组织可能会定期举办混沌工程“游戏日”。这些是全体参与的、有计划的活动，团队故意向系统注入一系列故障，以在受控环境中练习事件响应并识别弱点。这些活动通常不频繁，并且响应是对发现问题的被动反应。
在整个组织范围内大规模实施持续韧性的诀窍在于选择合适的工具。虽然开源和专有解决方案都提供有价值的功能，但组织应仔细评估其需求。某些企业环境可能需要特定功能，如高级安全控制、全面的审计跟踪和 RBAC——这些功能在开源解决方案中的可用性和成熟度可能有所不同。
一家领先的金融科技公司对此挑战深有体会，该公司每天处理超过 10 亿笔支付交易。面对高峰需求期间日益增加的交易失败，它寻求一种解决方案来提高其支持 20 多种金融产品的复杂平台的可靠性。
该公司选择现代混沌工程工具，对于克服扩展混沌工程实践的障碍至关重要。它所选择的工具（在本例中为 Harness Chaos Engineering）包含一个广泛的预构建实验库，简化了自动化和编排众多混沌实验的工作。此外，全面的分析和报告功能使该公司能够快速洞察其系统的韧性。
该公司首先将重心放在一个关键服务上，该服务每日处理九百万笔支付请求。它在复杂的底层基础设施中找出了容错目标，为韧性测试的受控推广奠定了基础。通过优先将混沌实验自动化到交付流水线和生产环境中，它解决了交易失败的根本原因，并为持续韧性建立了基础。
通过其自动化的韧性测试平台，该公司能够扩大测试范围，以发现服务恢复中的漏洞，优化应用程序设计模式，并微调配置。结果是显著的：失败交易减少了 16 倍，MTTR 减少到 10 分钟，客户满意度提高了 10 倍。如果没有提供安全性、模板、自动化和编排的现代工具，就不可能在如此短的时间内在整个组织中推广混沌工程并取得这些成果。
将混沌工程实验和 SLOs 添加到您的 CI/CD 流水线
为了巩固您的韧性策略，将 SLO 作为可靠性护栏集成到您的 CI/CD 流水线中。将 SLO 视为赛车上的刹车——对于在追求最高速度时保持控制至关重要。开发团队，就像赛车手一样，努力实现快速部署，但如果没有健全的 SLO，他们可能会因未经检查的变更而使系统崩溃。通过监控关键指标，您可以自动阻止违反这些阈值或耗尽错误预算的部署。这种方法可以在不牺牲稳定性的前提下加速您的开发速度。
在将混沌工程实验添加到 CI/CD 流水线时，请记住两个衡量标准来指导您的进展：韧性得分和韧性覆盖率。韧性得分只是您的服务在 QA 和生产中针对您应用的实验表现如何。韧性覆盖率，类似于代码覆盖率，评估还需要多少实验才能全面评估系统韧性，指导创建实际数量的测试。这些指标共同提供了对韧性的整体视图，使所有团队都能为持续韧性目标做出贡献并衡量进展。
首先添加针对已知韧性条件进行测试的实验，确保您的韧性分数在每次新部署时保持稳定。通过添加测试新条件的实验来缓慢增加您的韧性覆盖率。如果增加韧性覆盖率意味着韧性分数降低，请确定失败的混沌实验是否需要停止流水线，或者是否可以并行采取行动。
接下来，添加解决目标部署运行平台变化的实验。例如，在升级底层平台（如 Kubernetes）时，将混沌实验纳入您的 CI/CD 流水线，以主动识别潜在的弱点和兼容性问题。这有助于防止潜在问题在未来影响应用程序，并确保平台更新期间的平稳过渡。通过及早发现这些问题，您可以避免代价高昂的事件并保持持续的韧性。
将实验添加到流水线中，以根据以前的生产事件和警报在事件发生时验证部署。最后，添加实验以根据目标基础设施的配置更改验证部署。这是另一种情况，其中之前通过的韧性测试将开始失败，因为目标环境因更高或更低的配置而发生变化。
当您投入创建和微调您的实验时，像对待其他任何软件一样对待它们：版本化它们、测试它们并在存储库中管理它们的生命周期。这确保您的混沌工程实践保持有效并适应系统变化。集中式存储库促进了这些实验的协作和共享，促进了跨团队的一致性和最佳实践。
混沌工程的安全与治理
显然，混沌工程是一种强大的方法，但粗心大意的实验可能会对系统韧性和对混沌工程项目的信任造成严重损害。通过将其与您的安全和治理框架相结合，您可以定义所需的护栏，以确保实验负责任地进行。
就像技术债一样，韧性债也可能在您的生产服务中积累。每一次警报、事件、热修复或权宜之计——例如简单地向问题投入更多资源——都促成了这种债务。这些快速修复往往掩盖了潜在问题，并营造了一种虚假的稳定性，而不是解决根本原因。
现代混沌工程工具可以帮助您建立和执行政策来对抗这种情况。例如，我们可以设定一项政策，规定对于每一个与组件行为异常、网络问题、API 故障或意外负载相关的生产事件，都必须有一个相应的混沌实验。这个实验，集成到您的 CI/CD 流水线中，需要在特定的时间范围内进行验证，比如说，在事件发生后的 60 天内。这样的政策不仅能强制执行解决韧性债的纪律，还能鼓励开发人员和质量保证团队优先修复生产代码，而不是推送可能进一步加剧问题的新功能。
除了使用策略来管理韧性债务之外，您还可以使用安全治理策略来防止未经授权的实验，限制对关键系统的访问，并按环境、时间窗口、人员甚至故障类型限制测试。通过自动化监督并将这些策略集成到 CI/CD 流水线中，您可以提高韧性覆盖率，同时降低风险。
AI 原生混沌工程在服务可靠性中的未来
混沌工程的未来预示着在服务可靠性实践中将变得更加复杂和集成。Harness Chaos Engineering 和 Chaos Monkey 等工具不仅将自动化实验，还将利用 AI/ML 预测其影响，分析系统在压力下的行为，并推荐最佳缓解策略。这种智能自动化将最大限度地降低风险，使团队能够以更高的信心和效率进行更复杂的实验。可观测性和追踪方面的进步将提供对系统动态更深入的洞察，从而更精确地识别漏洞并更快地从中断中恢复。
随着系统日益复杂，分布式架构和微服务变得无处不在，混沌工程将在确保其韧性方面发挥关键作用。即使是基于大型语言模型的多智能体系统也可以通过混沌工程进行增强。通过将混沌测试与 AI 驱动的分析和自动化修复（例如，ChaosEater）相结合，我们将能够更快、更精确地解决潜在故障，最大限度地减少停机时间并保持高水平的服务可靠性。
总结
在本章中，我们探讨了混沌工程作为构建和验证系统韧性的系统方法。我们学习了如何负责任地设计和执行实验，利用 SLO 和错误预算来平衡创新与稳定性。通过将混沌工程集成到 CI/CD 流水线并利用现代工具，组织可以主动识别弱点，从故障中学习，并持续提高韧性。最终，混沌工程使我们能够创建更健壮的系统，以满足当今复杂数字世界的需求。有了这些原则，下一步就是将它们无缝地应用于您的部署流程。让我们探讨如何在生产发布期间确保稳定性。