【系统架构设计百科】混沌工程：主动验证系统的韧性

2011 年 4 月 21 日，Amazon Web Services 的美东区域（US-EAST-1）发生大规模故障，持续超过 48 小时。Reddit、Quora、Foursquare 等知名网站全部瘫痪——它们都跑在 AWS 上，且没有跨区域部署。而 Netflix 几乎没受影响。

原因不是 Netflix 的代码质量更高，而是 Netflix 在 2010 年就已经在生产环境中运行一个叫做 Chaos Monkey（混沌猴子）的工具——它随机终止生产环境中的虚拟机实例，迫使工程团队必须构建能容忍任意节点故障的系统。当 AWS 真的出故障时，Netflix 的系统已经”习惯了”节点丢失。

这个实践后来被 Netflix 的工程师总结为一套方法论，称为混沌工程（Chaos Engineering）。它的核心理念是：不要等故障来找你，而是主动制造故障来找系统的弱点。

但”随机杀进程”不是混沌工程的全部，甚至不是它最重要的部分。混沌工程是一套严谨的实验方法——有假设、有控制组、有明确的成功/失败判定标准。这篇文章要回答三个问题：

1. 混沌工程的核心原则是什么？它和”测试”有什么区别？
2. 故障注入有哪些类型？怎么控制爆炸半径？
3. 主流工具（LitmusChaos、ChaosBlade、Chaos Mesh、Gremlin）的架构和适用场景有什么区别？

在上一篇中，我们讨论了容量规划——如何预测和准备未来的资源需求。混沌工程是容量规划的补充：容量规划回答”资源够不够”，混沌工程回答”出了问题能不能扛住”。

一、混沌工程不是”随机搞破坏”

很多人第一次听说混沌工程的反应是：“在生产环境里随机杀进程？疯了吧？”这个反应暴露了一个误解：混沌工程不是随机破坏，而是受控的科学实验。

混沌工程 vs. 测试

测试是验证已知的行为——给定输入 X，系统应该输出 Y。如果输出是 Y，测试通过。

混沌工程是探索未知的行为——在异常条件下，系统会怎样？我们不知道确切的答案，但我们有一个假设，实验的目的是验证或推翻这个假设。

五条核心原则

混沌工程社区（principlesofchaos.org）总结了五条核心原则：

原则一：建立稳态行为的假设。 在注入故障之前，你必须知道系统的”正常状态”是什么样的。这些稳态指标（Steady-State Metrics）通常包括：请求成功率、延迟分布、错误率、关键业务指标（如每分钟的订单量）。如果你不知道”正常”是什么，你就无法判断故障注入后系统是否”异常”。

原则二：用真实世界的事件来构造变量。 故障注入应该模拟真实会发生的事件——服务器宕机、网络延迟增加、磁盘写满、DNS 解析失败——而不是构造人为的、不可能在真实环境中出现的极端条件。

原则三：在生产环境中运行实验。 系统在测试环境和生产环境中的行为可能完全不同——流量模式不同、数据量不同、依赖方的行为不同。最有价值的混沌实验是在生产环境中执行的。

原则四：自动化实验以持续运行。 混沌实验不应该是偶尔的一次性活动，而是持续运行的自动化流程。系统每天都在变化（新代码、新配置、新依赖），昨天能扛住的故障今天可能就扛不住了。

原则五：最小化爆炸半径。 虽然混沌实验要在生产环境运行，但必须严格控制影响范围。从小规模开始（一个 Pod、一个实例、一小部分流量），确认安全后再逐步扩大。如果实验导致了不可接受的影响，必须能立即停止。

二、混沌实验设计

一个合格的混沌实验包含以下要素：

实验模板

1. 假设（Hypothesis）
   "当 [具体故障] 发生时，系统应该 [预期行为]。"
   例如："当支付服务的 1/3 Pod 被终止时，支付成功率应该保持在 99.9% 以上。"

2. 稳态指标（Steady-State Metrics）
   实验前后用于对比的指标。
   例如：支付成功率、支付 API p99 延迟、错误日志数量。

3. 故障类型（Fault Type）
   具体注入什么故障。
   例如：随机终止 Pod。

4. 爆炸半径（Blast Radius）
   影响范围的上限。
   例如：仅影响支付服务集群中 3 个 Pod 中的 1 个。

5. 持续时间（Duration）
   故障注入持续多长时间。
   例如：5 分钟。

6. 终止条件（Abort Conditions）
   什么情况下立即停止实验。
   例如：支付成功率低于 99%，或 p99 延迟超过 5 秒。

7. 观察与记录
   实验过程中需要观察的指标和记录的现象。

实验流程

flowchart TD
    A["定义假设"] --> B["确认稳态指标基线"]
    B --> C["配置故障注入<br/>设定爆炸半径"]
    C --> D["执行故障注入"]
    D --> E{"稳态指标是否偏离?"}
    E -->|否| F["假设成立<br/>系统韧性验证通过"]
    E -->|是| G{"是否触达终止条件?"}
    G -->|是| H["立即停止实验<br/>恢复系统"]
    G -->|否| I["继续观察<br/>记录偏离程度"]
    I --> E
    H --> J["分析根因<br/>输出改进建议"]
    F --> K["记录实验结果<br/>归档"]
    J --> K

爆炸半径控制

爆炸半径控制是混沌工程中最关键的安全机制。常用的控制手段：

1. 范围限制：从单个 Pod/实例开始，逐步扩大到服务级别、机房级别。
2. 流量限制：只对一部分流量注入故障（例如 1% 的请求增加 500 毫秒延迟）。
3. 时间限制：设定最长实验时间，超时自动恢复。
4. 自动终止：监控稳态指标，一旦偏离超过阈值（如错误率超过 1%），自动停止故障注入并恢复。
5. 人工看护：关键实验期间必须有工程师在场监控，能随时手动终止。

三、故障注入的分类学

故障注入（Fault Injection）是混沌工程的核心操作。按照故障发生的层级，可以分为以下几类：

基础设施层故障

网络层故障

应用层故障

平台层故障

四、Netflix：从 Chaos Monkey 到 Chaos Kong

Netflix 是混沌工程的发源地，其工具链的演进过程就是混沌工程方法论从雏形到成熟的历史。

Chaos Monkey（2010）

Netflix 在 2010 年迁移到 AWS 后，开始面对一个新现实：云上的虚拟机不像物理服务器那样”稳定”，它们可能因为底层硬件故障、维护迁移等原因在任何时候被终止。

Chaos Monkey 的设计极其简单：在工作日的上班时间（这很重要——确保出问题时有人可以响应），随机选择一个 AWS 实例并终止它。

Chaos Monkey 的核心逻辑：
1. 枚举所有正在运行的实例。
2. 按服务分组。
3. 对每个服务组，以一定概率选择一个实例。
4. 终止该实例。
5. 记录日志。

Chaos Monkey 的价值不在于代码本身，而在于它产生的文化效应：每个工程师都知道自己的服务随时可能丢失一个实例。这迫使所有团队在设计时就考虑单点故障的容错——无状态设计、健康检查、自动重启、负载均衡。

Simian Army（2011-2012）

Chaos Monkey 成功后，Netflix 把这个思路扩展到了一系列工具，统称 Simian Army（猴子军团）：

• Chaos Monkey：终止单个实例。
• Chaos Gorilla：模拟整个可用区（Availability Zone，AZ）不可用。
• Latency Monkey：在服务间通信中注入延迟。
• Conformity Monkey：检查实例是否符合最佳实践（如是否加入了自动扩展组）。
• Security Monkey：检查安全配置问题。
• Janitor Monkey：清理闲置资源。

Chaos Kong（2015）

Chaos Gorilla 模拟的是单个可用区故障，但 Netflix 的用户遍布全球，如果一整个 AWS Region（例如 US-EAST-1）不可用呢？

Chaos Kong 就是为了测试这个场景而设计的。它模拟整个 AWS Region 的流量被切走（Evacuation），所有请求重新路由到另一个 Region。

Chaos Kong 演练的流程：

1. 选择目标 Region（例如 US-EAST-1）。
2. 把该 Region 的所有流量通过 DNS 和路由配置切换到其他 Region。
3. 观察系统行为——其他 Region 能否承受增加的流量？跨 Region 的数据同步是否正常？
4. 演练结束后，恢复原始流量配置。

Chaos Kong 的关键发现：第一次演练时，US-WEST-2 Region 在接收了 US-EAST-1 的全部流量后，Auto Scaling 无法足够快地扩展容量，导致短暂的服务降级。这个发现促使 Netflix 优化了跨 Region 的容量预留策略。

FIT：故障注入测试框架（2014）

随着混沌实验的复杂度增加，Netflix 开发了 FIT（Failure Injection Testing）框架，提供了更细粒度的故障注入能力：

• 可以针对特定服务、特定 API、特定用户群体注入故障。
• 支持注入延迟、错误响应、超时等多种故障类型。
• 通过元数据传播（Request Context）实现故障的定向注入——只有携带特定标记的请求会触发故障。

Netflix 混沌工程演进时间线：

2010    2011    2012    2013    2014    2015    2016+
  |       |       |       |       |       |       |
  Chaos   Simian  Chaos   --      FIT     Chaos   ChAP
  Monkey  Army    Gorilla         框架    Kong    (自动化)
  |               |               |       |
  单实例故障       AZ 故障          细粒度    Region 故障
                                  注入

关键经验

Netflix 十年混沌工程实践的核心经验：

1. 从小到大。先从单实例故障开始，团队积累经验后再挑战 AZ 和 Region 级别的故障。
2. 工作时间做实验。确保出问题时有人在场可以响应。
3. 文化比工具重要。混沌工程最大的阻力不是技术，是人——工程师害怕在生产环境制造故障。需要管理层的明确支持和团队文化的转变。
4. 不是所有服务都需要。Netflix 按服务的关键程度分层，核心服务（登录、播放、搜索）是混沌实验的重点，辅助服务（推荐、评分）的实验频率较低。

五、主流工具对比

LitmusChaos

LitmusChaos 是一个开源的、云原生的混沌工程平台，由 ChaosNative（后被 Harness 收购）开发，已捐赠给 CNCF（Cloud Native Computing Foundation，云原生计算基金会），是 CNCF 的孵化项目。

架构：

graph TB
    subgraph 控制平面
        Portal["Litmus Portal<br/>(Web UI)"]
        API["API Server"]
        DB["MongoDB"]
    end

    subgraph 执行平面
        Subscriber["Subscriber<br/>(Agent)"]
        Workflow["Argo Workflow<br/>(编排引擎)"]
        Runner["Chaos Runner"]
        Exp["Chaos Experiment<br/>(ChaosEngine CR)"]
    end

    subgraph 目标集群
        Target["目标 Pod / Node"]
    end

    Portal --> API
    API --> DB
    API --> Subscriber
    Subscriber --> Workflow
    Workflow --> Runner
    Runner --> Exp
    Exp --> Target

核心概念：

• ChaosExperiment：定义故障注入的类型和参数（Kubernetes CRD）。
• ChaosEngine：把 ChaosExperiment 绑定到目标应用，触发执行。
• ChaosResult：记录实验的执行结果（通过/失败）。
• ChaosHub：实验库，提供预定义的实验模板。

优势：与 Kubernetes 深度集成、CRD 驱动的声明式 API、丰富的实验库、CNCF 生态支持。

局限：主要面向 Kubernetes 环境，对非容器化环境的支持有限。

ChaosBlade

ChaosBlade（混沌之刃）是阿里巴巴开源的混沌实验工具，也是 CNCF Sandbox 项目。

核心特点：

1. 统一的 CLI 接口。所有故障注入操作通过一个统一的命令行接口执行。
2. 多环境支持。支持物理机、虚拟机、容器、Kubernetes、JVM 等多种环境。
3. JVM 字节码注入。通过 Java Agent 机制在运行时修改 Java 应用的行为，无需修改源码。

# ChaosBlade 命令示例

# 注入网络延迟
blade create network delay --time 3000 --interface eth0

# 注入 CPU 压力
blade create cpu fullload --cpu-percent 80

# 注入 JVM 方法延迟
blade create jvm delay --time 3000 --classname com.example.PaymentService --methodname processPayment

# 销毁实验
blade destroy <experiment-id>

优势：多环境支持（不限于 Kubernetes）、JVM 级别的精细故障注入、阿里双十一实战验证。

局限：社区规模和生态丰富度不如 LitmusChaos、文档以中文为主。

Chaos Mesh

Chaos Mesh 是 PingCAP（TiDB 的开发公司）开源的混沌工程平台，也是 CNCF 孵化项目。

核心特点：

1. 基于 Kubernetes Operator 模式。所有混沌实验通过 CRD 定义和管理。
2. 丰富的故障类型。支持 PodChaos、NetworkChaos、IOChaos、StressChaos、TimeChaos、DNSChaos、HTTPChaos 等。
3. Dashboard 可视化。提供 Web UI 进行实验的创建、管理和监控。

# Chaos Mesh 实验定义示例 - 网络延迟
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: payment-network-delay
spec:
  action: delay
  mode: one
  selector:
    namespaces:
      - production
    labelSelectors:
      app: payment-service
  delay:
    latency: "500ms"
    correlation: "100"
    jitter: "50ms"
  duration: "5m"
  scheduler:
    cron: "@every 24h"

优势：CRD 原生、丰富的故障类型、可视化 Dashboard、与 TiDB 等分布式数据库的集成测试经验丰富。

局限：主要面向 Kubernetes 环境。

Gremlin

Gremlin 是一个商业化的混沌工程平台，提供 SaaS 服务。

核心特点：

1. 即用型平台。不需要自建基础设施，注册即用。
2. 多环境支持。支持裸金属服务器、虚拟机、容器、Kubernetes、云服务等。
3. 安全优先。提供精细的权限控制、审计日志、自动回滚。
4. 状态检查。实验执行前自动检查系统健康状态，不在不健康的系统上执行实验。

优势：开箱即用、企业级安全和合规、技术支持。

局限：收费、数据存储在第三方。

工具对比

六、在生产环境安全地运行混沌实验

在生产环境做混沌实验是混沌工程的理想状态，但也是风险最高的操作。以下是生产混沌实验的安全实践。

前提条件

在生产环境运行混沌实验之前，必须确保以下条件已满足：

1. 可观测性就位。完善的监控、日志和追踪系统已经部署，能实时反映系统状态。
2. 回滚能力就位。故障注入可以在秒级停止和回滚。
3. 告警就位。关键指标的告警已经配置并经过验证。
4. 事故响应流程就位。团队知道实验出问题时该联系谁、该做什么。
5. 管理层授权。生产混沌实验必须得到明确的管理层授权。

渐进式推进

阶段 1：非生产环境
  ├── 开发环境的手动实验
  ├── Staging 环境的自动化实验
  └── 验证工具的可控性和回滚能力

阶段 2：生产环境 - 低风险
  ├── 非核心服务的 Pod 终止
  ├── 非峰值时段执行
  └── 专人看护

阶段 3：生产环境 - 中风险
  ├── 核心服务的 Pod 终止
  ├── 网络延迟注入
  └── 自动化执行 + 自动回滚

阶段 4：生产环境 - 高风险
  ├── 可用区级别的故障模拟
  ├── 数据库故障转移测试
  └── 全链路 GameDay 演练

避雷指南

1. 不要在大促 / 重要活动期间做实验。
2. 不要在没人看护的情况下做生产实验。即使是自动化的实验，也应该有值班工程师监控。
3. 不要同时注入多种故障。一次只验证一个假设，注入一种故障。多种故障同时发生会让根因分析变得极其困难。
4. 不要跳过小规模验证。从 1 个 Pod 开始，不要一上来就终止一半的实例。
5. 不要忽略实验后的清理。确认所有故障注入都已经停止，系统已经恢复正常。

七、GameDay 演练

GameDay 是一种结构化的大规模混沌实验活动，通常涉及多个团队的协作，模拟真实的灾难场景并验证整个组织的响应能力。

GameDay 与日常混沌实验的区别

GameDay 流程

准备阶段（T-2 周到 T-1 天）：

1. 确定演练场景（例如：“模拟主数据中心网络分区”）。
2. 编写演练剧本（Runbook），详细描述故障注入步骤、预期行为、回滚步骤。
3. 通知所有相关团队，安排值班人员。
4. 确认监控、告警、回滚工具都已就绪。
5. 设定明确的终止条件——什么情况下立即停止演练。

执行阶段（T-0）：

1. 集合所有参与者（物理或虚拟会议室）。
2. 确认所有系统的当前状态正常。
3. 按照剧本逐步注入故障。
4. 观察系统行为和团队响应。
5. 记录关键时间点、决策和发现。
6. 如果触达终止条件，立即停止并恢复。

复盘阶段（T+1 天到 T+1 周）：

1. 整理时间线——每个时间点发生了什么、谁做了什么决策。
2. 列出所有发现的问题，按严重程度排序。
3. 为每个问题分配责任人和修复期限。
4. 撰写 GameDay 报告，分享给全组织。

八、混沌成熟度模型

不同团队在混沌工程的实践上处于不同阶段。以下成熟度模型可以帮助评估当前状态和规划改进路径：

五级成熟度

Level 0：无意识。 团队没有听说过混沌工程，也没有任何故障演练实践。故障发现完全依赖用户反馈。

Level 1：初步实验。 团队开始在非生产环境做简单的故障注入实验（如手动终止一个实例）。实验是偶发的、非结构化的。

Level 2：结构化实验。 团队建立了混沌实验的标准流程——有假设、有稳态指标、有终止条件。实验在 Staging 环境或低风险的生产环境中定期执行。使用了专业工具（LitmusChaos / ChaosBlade 等）。

Level 3：自动化与 CI/CD 集成。 混沌实验被集成到 CI/CD 流水线中，每次部署后自动执行一组基础的韧性验证实验。实验结果作为发布的 Gate 之一。定期（每月/每季度）执行 GameDay 演练。

Level 4：持续混沌。 混沌实验在生产环境持续自动运行。团队对各种故障场景的响应已经高度自动化。混沌实验的发现被系统性地反馈到架构设计中——不只是修复问题，而是从根本上改进系统的韧性。组织文化已经把”主动制造故障”视为正常工程实践。

Level 4  ┃ 持续混沌 ──── 生产环境自动化 + 文化内化
Level 3  ┃ CI/CD 集成 ── 自动化验证 + 定期 GameDay
Level 2  ┃ 结构化实验 ── 标准流程 + 专业工具
Level 1  ┃ 初步实验 ──── 手动 + 非生产环境
Level 0  ┃ 无意识 ────── 被动等故障
         ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

九、工程案例：某金融科技公司的混沌工程落地

以下案例来自国内某金融科技公司的公开技术分享，展示了混沌工程从零到一的落地过程。

背景

• 业务规模：日均支付交易约 500 万笔，核心链路涉及 12 个微服务。
• 现状：没有混沌工程实践。过去一年发生过 3 次 P1 级别的生产事故，每次都是”事后才知道”。
• 目标：在 6 个月内建立混沌工程体系，把”从未验证过的容错机制”全部验证一遍。

第一阶段：工具选型和环境准备（第 1-4 周）

工具选型过程：

考虑到业务环境是 Kubernetes + Java 微服务的组合，且需要 JVM 级别的故障注入（模拟数据库连接超时、HTTP 调用延迟等），最终选择了 ChaosBlade。原因：

1. 多环境支持——部分遗留服务还跑在虚拟机上，不完全是 Kubernetes。
2. JVM 字节码注入——可以精确到方法级别注入延迟或异常。
3. 阿里双十一验证过——在金融场景的可靠性得到过大规模验证。

环境准备：

1. 在 Staging 环境部署 ChaosBlade Operator。
2. 配置 Prometheus + Grafana 的混沌实验 Dashboard，包含核心 SLI（成功率、延迟、错误率）。
3. 与 PagerDuty 集成，配置混沌实验的告警通道。

第二阶段：Staging 环境实验（第 5-10 周）

设计了 15 个实验场景，按优先级排序执行：

15 个实验中，6 个失败（40%）。失败意味着发现了之前不知道的脆弱点。

关键发现和修复：

• E2（数据库延迟）：发现数据库连接池的超时配置为 30 秒，远高于合理值。修复为 3 秒超时 + 重试 1 次。
• E4（DNS 故障）：发现支付网关的地址是硬编码的域名，没有降级逻辑。增加了备用网关的直连 IP 配置和自动切换逻辑。
• E6（配置中心不可用）：发现服务启动时强依赖配置中心。改为启动时拉取配置后本地缓存，配置中心不可用时使用缓存版本。

第三阶段：生产环境实验（第 11-20 周）

在 Staging 修复所有发现的问题后，开始在生产环境做低风险实验：

1. 非峰值时段（凌晨 2-4 点）执行。
2. 每次只影响一个服务的一个 Pod。
3. 专人看护 + 自动终止条件（成功率 < 99.5% 即停止）。

生产实验发现了 Staging 环境未能暴露的问题：

• 生产环境的连接池配置与 Staging 不一致（配置漂移）。
• 某些服务的健康检查端点在高负载下会超时，导致 Kubernetes 误判为不健康并重启 Pod，进一步加剧了负载。

第四阶段：GameDay（第 21-24 周）

组织了第一次 GameDay，模拟”核心数据库所在 AZ 不可用”的场景。

• 参与者：3 个研发团队 + DBA 团队 + 运维团队 + 管理层。
• 持续时间：2 小时。
• 主要发现：数据库的自动故障转移（Failover）机制工作正常，但应用层的连接池在主节点切换后没有及时刷新连接，导致了约 3 分钟的请求失败。

GameDay 后的改进：引入连接池的主动健康检查和快速失败机制——检测到连接不可用时立即丢弃并重建，而不是等待超时。

效果

6 个月后：

• 通过混沌实验共发现 23 个之前未知的脆弱点，全部修复。
• P1 事故从年均 3 次降到年均 0.5 次。
• 平均故障恢复时间（MTTR，Mean Time To Recovery）从 45 分钟降到 12 分钟。
• 团队对系统韧性的信心从”不确定”变为”有数据支撑”。

十、混沌工程的权衡

十一、结论

混沌工程的本质是一个认知工具——它帮助你发现你不知道自己不知道的问题（Unknown Unknowns）。

几个核心要点：

1. 混沌工程是实验，不是测试。它的价值在于发现未知的弱点，而不是验证已知的行为。
2. 先有假设，再注入故障。“随机杀进程看看会怎样”不是混沌工程，“终止 1/3 Pod 后支付成功率应该不低于 99.9%”才是。
3. 爆炸半径控制是底线。从小规模开始，自动终止条件必须就位，不能让实验变成真正的事故。
4. 从 Staging 开始，目标是生产。Staging 环境的实验价值有限，但它是建立信心和验证工具的必经之路。
5. 文化比工具重要。最大的阻力不是技术，是”在生产环境制造故障”这件事本身带来的心理恐惧。需要管理层的明确支持和安全的实验机制来打消团队的顾虑。

混沌工程不会让你的系统永远不出故障。但它会让你在故障真正发生之前，就知道系统会怎样——以及应该做什么来改进。

导航

上一篇：容量规划：从拍脑袋到数据驱动

下一篇：性能建模：从理论到实测

参考资料

书籍

• Casey Rosenthal, Nora Jones, “Chaos Engineering: System Resiliency in Practice”, O’Reilly, 2020. 混沌工程领域的权威著作，涵盖原理、工具和组织实践。
• Russ Miles, “Learning Chaos Engineering”, O’Reilly, 2019. 面向初学者的混沌工程入门书籍。

论文与博客

• Principles of Chaos Engineering, principlesofchaos.org. 混沌工程五条核心原则的官方定义。
• Ali Basiri, et al., “Chaos Engineering”, IEEE Software, 2016. Netflix 混沌工程实践的学术论文。
• Netflix Technology Blog, “The Netflix Simian Army”, 2011. Simian Army 工具族的官方介绍。
• Netflix Technology Blog, “Chaos Engineering Upgraded”, 2015. FIT 框架和 Chaos Kong 的工程细节。

工具文档

• LitmusChaos 官方文档, litmuschaos.io. 安装、配置和实验设计的完整指南。
• ChaosBlade 官方文档, chaosblade.io. 命令行用法和各场景的注入方式。
• Chaos Mesh 官方文档, chaos-mesh.org. CRD 定义、Dashboard 使用和实验编排。
• Gremlin 官方文档, gremlin.com/docs. 商业混沌工程平台的使用指南。

工业实践

• 阿里巴巴技术博客, “ChaosBlade: 阿里巴巴混沌工程实践”, 2019. ChaosBlade 在双十一中的应用。
• PingCAP Engineering Blog, “Chaos Mesh: Chaos Engineering for TiDB”, 2020. Chaos Mesh 的设计动机和在分布式数据库测试中的应用。
• Gremlin Blog, “Chaos Engineering Adoption Guide”, 2021. 混沌工程从零开始的组织级推广指南。