混沌工程实践

# 目录页

背景与挑战
混沌工程概念
混沌工程的原则
实验方法论体系
混沌演练（实践）

# 背景与挑战

## 数字化转型现状（页1）

**系统规模扩大：** 随着互联网技术发展，软件系统从单体架构转向微服务与分布式架构，部署规模从少量服务器扩展至成百上千物理节点，集群规模指数级增长以支撑高并发业务需求。
**复杂度激增：** 分布式架构带来硬件扰动风险倍增、多环境一致性难以保障、测试体系复杂度攀升（预生产/集成/回归/端到端/故障注入测试难度升级），同时敏捷开发与云原生实践加剧了业务敏捷性与系统稳定性之间的矛盾，传统灾备手段难以应对快速迭代下的高可用性挑战。
典型故障案例：
| 故障平台 | 时间 | 影响 | 原因 | 行业 |
| ---- | ---- | ---- | ---- | ---- |
| 京东外卖 | 2025年4月 | 外卖下单量暴增，导致系统出现短暂故障 | 流量爆增导致系统异常 | 零售科技 |
| 阿里云上海地域网络异常 | 2024年7月 | B站视频加载失败、小红书功能受限，波及300+企业客户 | 机房光缆中断导致网络分区 | 云计算 |
| 腾讯云控制台故障 | 2024年4月 | 云API服务中断87分钟，1957家企业业务停滞 | 版本兼容性缺陷导致灰度发布失败 | 云计算 |

## 传统运维 VS 混沌工程（页2）

| 对比维度 | 传统运维 | 混沌工程 |
| ---- | ---- | ---- |
| 稳定性保障理念 | **被动防御：** 侧重防范已知缺陷，通过监控、告警、容灾等手段应对已识别风险。 | **主动探索：** 通过主动注入故障（如网络延迟、节点宕机），提前发现未知的系统脆弱点。 |
| 故障应对方式 | **事后响应：** 仅在故障发生后被动修复，依赖人工排查和应急预案，进度与成本不可控。 | **事前验证：** 主动模拟故障场景，验证系统韧性，提前优化架构和运维策略，降低故障实际发生时的影响。|
| 测试覆盖范围 | **已知场景测试：** 依赖预生产环境模拟常规故障（如单点故障），难以覆盖复杂环境下的异常扰动（如多节点级联故障）。 | **未知场景探索：** 通过随机或定向注入异常（如混沌实验），触发传统测试难以发现的潜在缺陷（如分布式一致性风险）。 |
| 系统韧性验证 | **静态评估：** 基于历史数据和经验评估系统稳定性，缺乏动态压力测试和实时反馈机制。 | **动态验证：** 通过持续注入扰动（如流量突增、硬件故障），实时观察系统恢复能力并迭代优化。 |
| 运维成本与效率 | **高成本被动投入：** 依赖高可用架构（如多活部署）和灾备演练，成本高昂且无法覆盖所有异常场景。 | **高效主动优化：** 以低成本模拟真实故障，快速定位系统短板，减少实际故障发生概率和修复成本。 |
| 适用场景 | **已知风险防控：** 适用于常规运维和已知缺陷管理，但对复杂分布式系统中的“黑天鹅”事件应对不足。 | **未知风险探索：** 适用于云原生、微服务等分布式系统，主动发现架构设计或运维策略中的潜在脆弱点。|
| 局限性 | **盲区大：** 无法识别未被预见的故障模式，依赖人工经验制定应急预案，存在响应滞后风险。 | **实验设计复杂：** 需平衡实验范围与业务影响，过度注入可能引发真实故障，需结合可观测性工具精准控制。|

# 混沌工程概念

## 混沌工程是什么（页1）

**混沌工程（Chaos Engineering）** 是系统可靠性工程的核心实践方法，其基于控制论原理构建了系统性稳定性保障体系。该方法论通过在分布式系统实施可观测的、***可控的*** 故障注入机制，以科学实验范式主动构造极端场景下的压力测试环境，实现对业务系统的受控失效验证。具体表现为：通过 ***预设的*** 故障注入策略，对软硬件架构施加 ***可控的*** 异常载荷，观察系统在异常工况下的弹性响应特征，从而建立韧性评估模型。这种持续迭代的实验过程既能验证架构容错能力边界、识别潜在失效风险点，又能揭示故障传播规律与系统脆弱性，最终形成防御态势优化闭环——通过分析实验数据迭代改进容灾策略，构建具备抗脆弱性的系统架构，同时为制定事件响应预案和故障自愈机制提供实证依据。
**关键概念解释：**
- 分布式系统：由多个通过网络连接的独立组件组成的系统，组件间相互协作提供服务，但因组件众多、依赖复杂，容易出现故障。例如电商系统，包含订单、支付、库存等多个微服务组件。
- 故障注入：混沌工程核心手段，通过人为制造硬件故障、软件错误、网络问题等，测试系统应对能力。如模拟服务器磁盘故障、网络延迟、服务崩溃等场景。

## 混沌工程的起源（页2）

- 2010年 Netflix 内部开发了 AWS 云上随机终止 EC2 实例的混沌实验工具 Chaos Monkey
- 2012年 Netflix 向社区开源由Java构建Simian Army, 其中包括Chaos Monkey V1版本
- 2014年 Netflix 提出了故障注入测试FIT, 利用微服务架构的特性，控制混沌实验的爆炸半径
- 2016年 Kolton Andrus 创立了Gremlin, 正式将混沌实验工具商用化
- 2019年 阿里开源chaosblade工具
- 2020年 PingCap开源chaos mesh工具

## 混沌工程核心价值（页3）

- **提升系统可靠性：** 通过提前发现并解决潜在问题，增强系统对故障的容错和恢复能力，减少因系统故障导致的业务中断时间。例如，金融交易系统通过混沌工程发现并修复漏洞，避免交易高峰期因小故障引发的大规模交易失败。
- **增强团队信心：** 让开发、运维、测试等团队在可控环境中经历故障处理，积累经验，提高应对真实故障时的信心和能力，减少故障发生时的恐慌和混乱。
- **优化架构设计：** 验证系统架构的容错能力，发现架构中的薄弱环节，为架构优化提供依据，推动面向失败设计的系统架构发展。例如，微服务架构中通过混沌工程确定服务间合理的容错机制和降级策略。
- **降低成本：** 在故障发生前解决问题，避免因故障导致的业务损失、修复成本以及声誉损害，从长远看降低企业运营成本。如在线零售平台避免因系统故障造成的订单丢失和客户流失。

## 混沌工程目标（页4）

混沌工程旨在构建具备韧性的系统与组织，以应对复杂环境中的不确定性和故障。
- 在系统层面，通过实现冗余性、扩展性、采用不可变基础设施与无状态应用，以及基础设施即代码等方式，同时运用转移切换、重试退避、超时机制、幂等操作、降级熔断等手段，避免级联故障，提升系统稳定性。
- 在组织层面，借助高效交付效率、面向失败设计和应急响应机制等，增强整体应对风险的能力，保障业务在面对各类扰动时能够持续、稳定运行。

## 混沌工程的收益（页5）
1. 人
- **架构师、开发人员：** 加深对系统的理解，验证系统架构的容错能力。
- **运维人员：** 提高故障的应急效率，实现故障告警、定位、恢复的有效应对
- **测试人员：** 弥补传统测试方法留下的空白，更主动的方式探究系统问题，提早暴露线上问题，降低故障复发率
- **产品和设计人员：** 了解产品在突发情况下的表现，提升客户在突发情况下的产品使用体验
2. 流程
- 故障治理体系：完善了故障治理体系，从被动发现转为主动发现
- 故障应急：验证报警有效性与及时性，预案的可行性
3. 系统
- 韧性：提升系统容错、容灾能力
- 基础能力：可监控、可灰度、可回滚、可降级

# 混沌工程的原则

## 混沌工程五大原则（页1）

- 01 建立一个围绕稳定状态行为的假说
- 02 多样化真实世界的事件
- 03 在生产环境中运行实验
- 04 持续自动化运行实验
- 05 最小化爆炸半径

## 1. 假设稳定的状态（页2）

定义能直接反映业务服务的监控指标，如电商系统的订单成功率、支付成功率等，而非单纯的CPU、内存等系统资源指标；假设故障触发时系统行为和监控指标的预期变化，以此判断实验结果是否符合预期。
- 关注可以测量的结果，而不是系统内部属性
- 短时间内的度量结果，代表了系统的稳定状态
- 验证系统是否工作，而不是如何工作

## 2. 多样化真实世界的事件（页3）

实验中引入的故障应是生产环境中真实可能发生的，如网络延迟、服务器硬件故障、进程崩溃等，使实验结果更具实际参考价值。
- 混沌变量反映了现实世界中的事件
- 通过潜在影响或预估频率确定事件的优先级
- 任何能够破坏稳态的事件都是混沌实验的一个潜在变量

## 3. 在生产环境中运行实验（页4）

虽然有风险，但生产环境实验能获取最真实的系统反应。若在预生产环境实验，需确保其与生产环境高度相似，否则实验结果可能有偏差。例如，在电商大促前在生产环境小范围进行混沌实验，验证系统在高并发下的稳定性。
- 系统的行为会根据环境和流量模式而变化
- 为了保证系统行为的真实性与当前部署系统的相关性，混沌工程强烈推荐在生产环境中进行实验

## 4. 持续自动化运行实验（页5）

借助自动化工具持续开展实验，提高效率，减轻人工负担，同时能及时发现系统因代码更新、环境变化等产生的新问题。如利用自动化脚本定时执行混沌实验，并自动收集和分析实验数据。
- 手工运行实验是不可持续的工作，所以需要把实验变为自动化且持续的执行
- 混沌工程要在系统中像持续集成一样构建自动化的编排和分析
- 降低实验成本

## 5. 最小化爆炸半径（页6）

控制实验影响范围，避免对整个系统造成严重破坏。通过瞄准服务子集、设置实验时间、避开业务高峰期以及在开发环境优先实验等方式，减少对客户和业务的影响。如在实验中只针对部分地区用户或特定业务模块进行故障注入。
- 在生产环境中进行实验可能会引发真实的故障发生，所以在执行试验时需要确保影响范围最小化且可控
- 提高异常检测、故障自愈能力

# 实验方法论体系

## 混沌工程实验设计（页1）

1. 建立期望假设
2. 实验场景设计
3. 系统评估指标设计
4. 故障类型设计、故障注入模式设计
5. 实验结果预期

## 混沌工程期望假设（页2）

1. 假设的本质
- 假设是实验的基础，用于验证系统是否存在稳定性缺陷。
- 假设通常反映系统潜在的脆弱性（如故障模式、异常场景）。
2. 假设的来源
- 用户反馈：基于历史用户报告的异常或投诉。
- 测试记录：从过往测试（如压力测试、容灾演练）中发现的问题。
- 架构分析：结合系统架构设计（如单点依赖、网络分区）推断可能的缺陷。
3. 假设的优先级评估
- 概率分析：缺陷发生的可能性高低。
- 影响范围：缺陷触发后波及的系统模块或用户群体规模。
- 严重程度：缺陷对业务、数据或用户体验造成的损害等级。
4. 优先级排序原则
- 历史故障优先：曾引发经济损失的已知缺陷应作为最高优先级实验目标。
- 同类风险扩展：同类架构或链路中可能复现的同类型故障需重点关注。
5. 实验目标
- 通过主动注入故障验证假设是否成立（缺陷是否存在）。
- 验证系统对缺陷的容忍能力，并推动修复或优化措施落地。

## 混沌工程实验场景设计（页3）

1. 实验环境要求
- 业务状态要求：被测系统必须处于正常业务运行状态，确保实验结果反映真实场景下的系统行为。
- 环境选择优先级：
- 生产环境（最优）：直接观察真实用户影响，但需严格风险控制。
- 测试/模拟环境（替代）：需尽可能还原生产环境的真实流量、数据和用户行为。
2. 场景复杂度设计
- 避免简单场景：实验需包含多样化任务（如不同用户操作、服务调用链路），确保覆盖系统关键路径和潜在风险点。
- 全面性验证：覆盖用户操作的典型和非典型场景（如高峰流量、异常输入），避免遗漏边缘情况。
3. 风险控制策略
- 生产环境实验防护措施：
- 金丝雀发布：仅对少量用户开放实验，快速验证影响范围。
- 流量分支：隔离实验流量，确保故障仅影响特定用户群体（如1%流量）。
- 测试环境可靠性保障：通过录制生产环境变量（如流量模式、请求频率）并重放，或使用生产数据模拟，提升测试环境真实性。
4. 数据与流量还原
- 生产环境数据复用：
- 录制真实流量、服务请求频率等变量，在测试环境中精准复现。
- 使用脱敏后的生产数据构建实验场景，避免因数据差异导致结果偏差。
5. 实验目标导向
- 验证系统韧性：通过注入扰动观察系统在真实业务负载下的恢复能力（如故障传播、自动修复机制）。
- 风险暴露优先：聚焦高风险模块（如支付、数据库）和历史故障链路，确保关键环节被充分测试。

## 混沌工程系统评估指标设计（页4）

1. 指标设计原则
- 全面性：指标需覆盖系统功能、性能及稳定性，确保能反映扰动对系统的真实影响。
- 敏感性：指标应在系统受损时产生显著变化（如响应时间突增、错误率飙升）。
- 可观测性：基于现有监控手段（如日志、链路追踪、APM工具）可实时采集。
2. 指标分类与采集策略
- 多维度指标收集：
- 整体指标：系统级指标（如吞吐量、可用性、错误率）。
- 子任务指标：支撑功能或依赖服务的指标（如数据库查询延迟、缓存命中率）。
- 极值分析：同时记录指标的平均值、最优值、最差值，识别异常波动（如99分位延迟突增）。
- 止损指标设计：
- 定义关键阈值（如错误率>5%、延迟>500ms），超限时自动终止实验，避免级联故障。
- 止损指标需覆盖核心业务场景（如支付成功率、订单创建延迟）。
3. 指标与业务场景的关联性
- 业务指标优先：如电商场景关注订单成功率、支付成功率；社交平台关注消息发送延迟。
- 技术指标补充：如资源利用率（CPU、内存）、服务依赖拓扑的健康状态。
4. 指标验证与调优
- 实验前校验：通过历史数据或模拟测试验证指标的合理性和敏感性。
- 动态调整：根据实验结果优化指标集合（如新增未覆盖的风险点指标）。

## 混沌工程实验系统指标类别（页5）

| 指标类别 | 指标描述 | 案例 |
| ---- | ---- | ---- |
| 时间类指标 | 系统完成实验场景单个或批量任务所需的时间 | 服务器端响应时间、网络响应时间、客户端响应时间，任务完成耗时等 |
| 效率类指标 | 系统在实验场景中的工作效率 | 吞吐量，TPS（Transaction Per Second，每秒钟完成的业务数）、QPS（Query Per Second，每秒钟完成的查询数）等|
| 失效率类指标 | 系统执行功能失败的比例 | 接口响应失败率、服务自动隔离或下线时间占比等 |
| 资源类指标 | 系统使用资源的情况 | CPU 使用率、内存使用量，磁盘输入和输出量，网络输入和输出量等 |
| 综合业务类指标 | 用户对于业务的反馈情况 | 用户重试率、用户报错数量等 |

## 混沌工程故障类型设计（页6）

1. 故障类型设计原则
- 全面覆盖：故障类型需涵盖系统可能遇到的各类异常场景（如硬件、软件、网络、人为错误等）。
- 成本可控：避免模拟所有可能的扰动，通过筛选聚焦高价值故障类型。
- 相关性优先：优先选择与当前实验假设强相关的故障类型（如验证数据库容错时，优先注入节点宕机）。
2. 故障类型筛选标准
- 相关性原则：
- 与实验目标直接关联的故障（如测试服务降级时，注入依赖服务不可用）。
- 对业务影响最大的故障（如支付链路中断）。
- 高频与显著性原则：
- 历史数据中高频发生的故障（如网络抖动、磁盘IO瓶颈）。
- 典型场景下的代表性故障（如微服务超时、容器资源耗尽）。
- 影响范围广或后果严重的故障（如数据中心宕机、核心API错误）。

## 混沌工程实验故障类别（页7）

| 故障类别 | 故障描述 | 案例 |
| ---- | ---- | ---- |
| 基础硬件资源扰动 | 以各系统运行所需的硬件基础设备为目标的扰动，模拟硬件设备因老化、质量问题和环境因素而发生的故障 | 服务器宕机、CPU故障、内存损坏、磁盘写满、硬盘掉盘等 |
| 网络故障 | 作用于网络连接的扰动，模拟光纤、路由、DNS 的异常造成的网络问题 | 网络抖动、丢包、超时、网卡满、DNS 故障、断网等 |
| 系统和中间件故障 | 作用于系统和中间件资源的扰动，通常是系统或中间件的异常或资源限制 | 操作系统或中间件的崩溃、时钟错误、卡顿等，以及CPU、内存、磁盘空间等系统资源的占用 |
| 应用故障 | 作用于实验对象系统内部的故障 | 连接关闭、进程终止、API访问故障等 |
| 用户操作故障 | 用户群体的极端操作行为 | 服务请求激增、异常操作激增、异地访问量激增等 |

## 混沌工程故障注入模式选择（页8）

1. 随机 vs 固定
- 随机注入
- 时间/节点/强度随机化
- 覆盖突发情况
- 适用于低风险扰动（如短时网络抖动）
- 需自动化支持
- 固定注入
- 特定时间/场景执行
- 影响范围可控
- 适用于高风险扰动（如核心服务宕机）
- 便于根因分析
2. 有损 vs 无损
- 无损故障
- 不造成服务失效（如模拟日志延迟）
- 短期可恢复（如自动重启服务）
- 适合初期探索
- 有损扰动
- 服务失效且不可自动恢复（如数据损坏）
- 高风险高价值（如模拟硬件故障）
- 需严格风控
3. 单一 vs 复合
- 单一故障
- 影响范围小
- 精准定位单点问题
- 适合系统迭代初期或复杂系统拆解分析
- 复合故障
- 多扰动组合（如网络延迟+磁盘满）
- 发现级联故障
- 适合成熟系统的全局韧性验证

## 混沌工程故障注入模式关键决策原则（页9）

1. 风险控制优先
- 有损注入必须设置终止条件（如错误率阈值）
- 复合扰动需逐步叠加（单一→双因素→多因素）
2. 成本效益平衡
- 高频实验采用随机+无损模式
- 低频但高价值实验采用固定+有损模式

## 混沌工程故障注入模式系统成熟度适配（页10）

| 系统状态 | 推荐模式 | 理由 |
| ---- | ---- | ---- |
| 新上线系统 | 固定+无损+单一扰动 | 避免失控风险 |
| 稳定运行系统 | 随机+无损+复合扰动 | 发现隐藏缺陷 |
| 高可用系统 | 固定+可控有损+复合扰动 | 验证复杂故障场景 |

## 混沌工程实验结果预期（页11）

| 评估维度 | 具体内容 | 预期产出 |
| ---- | ---- | ---- |
| 功能表现 | 核心业务功能是否正常运行（如订单创建、支付流程） | 功能降级/中断的临界点识别 |
| 性能指标 | 响应时间、吞吐量、资源利用率（CPU/内存/网络） | 性能拐点数据（如延迟超过阈值的比例） |
| 容错能力 | 自动恢复机制触发情况（如熔断、重试、降级策略） | 容错机制有效性验证结果 |
| 依赖关系 | 第三方服务/中间件异常时的系统表现 | 关键依赖项的脆弱性暴露 |
| 数据一致性 | 分布式场景下的数据最终一致性状态 | 数据冲突/丢失的具体场景|

# 混沌演练（实践）

## 业内混沌工程工具（页1）

| 工具名称 | 最新版本 | 项目维护状态 | 主要构建语言 | 涉及场景 | 特定依赖 |
| ---- | ---- | ---- | ---- | ---- | ---- | ---- |
| Chaos Monkey | 2.0.2 | 停滞 | Go | 终止 EC2 实例 | Spinnaker |
| Simian Army | 2.5.3 | 废弃 | Java|终止 EC2 实例，阻断网络流量，卸载磁盘卷，CPU/IO/磁盘空间突发过高，终止进程，路由失败，网络丢包，DynamoDB故障 | 无 |
| Chaos Mesh | 2.7.1 | 活跃 | Go | 实验框架，支持系统资源、网络、应用层面等多种故障的注入 | 依赖于 K8s 集群 |
| Chaos Blade | 1.7.4 | 活跃 | Go | 实验框架，支持系统资源、网络、应用层面等多种故障的注入 | 无 |

## Chaos Mesh工具介绍（页2）

Chaos Mesh是一个开源的云原生混沌工程平台，具有强大的故障场景编排能力，方便用户在开发测试中以及生产环境中模拟现实世界中可能出现的各类异常，帮助用户发现系统潜在的问题。提供丰富的故障模拟类型包含：基础资源类型故障、平台类型故障和应用层故障三大类。
- 基础资源类型故障：
- PodChaos：模拟 Pod 故障，例如 Pod 节点重启、Pod 持续不可用，以及特定 Pod 中的某些容器故障
- NetworkChaos：模拟网络故障，例如网络延迟、网络丢包、包乱序、各类网络分区
- DNSChaos：模拟 DNS 故障，例如 DNS 域名解析失败、返回错误 IP 地址
- HTTPChaos：模拟 HTTP 通信故障，例如 HTTP 通信延迟
- StressChaos：模拟 CPU 抢占或内存抢占场景
- IOChaos：模拟具体某个应用的文件 I/O 故障，例如 I/O 延迟、读写失败
- TimeChaos：模拟时间跳动异常
- KernelChaos：模拟内核故障，例如应用内存分配异常
- 平台类型故障：
- AWSChaos：模拟 AWS 平台故障，例如 AWS 节点重启
- GCPChaos：模拟 GCP 平台故障，例如 GCP 节点重启
- 应用层故障：
- JVMChaos：模拟 JVM 应用故障，例如函数调用延迟

## chaosblade工具介绍（页3）

ChaosBlade 是阿里巴巴开源的一款遵循混沌工程原理和混沌实验模型的实验注入工具，帮助企业提升分布式系统的容错能力，并且在企业上云或往云原生系统迁移过程中业务连续性保障。
Chaosblade 是内部 MonkeyKing 对外开源的项目，其建立在阿里巴巴近十年故障测试和演练实践基础上，结合了集团各业务的最佳创意和实践。
ChaosBlade 不仅使用简单，而且支持丰富的实验场景，场景包括：
- 基础资源：比如 CPU、内存、网络、磁盘、进程等实验场景
- Java 应用：比如数据库、缓存、消息、JVM 本身、微服务等，还可以指定任意类方法注入各种复杂的实验场景
- C++ 应用：比如指定任意方法或某行代码注入延迟、变量和返回值篡改等实验场景
- Docker 容器：比如杀容器、容器内 CPU、内存、网络、磁盘、进程等实验场景
- 云原生平台：比如 Kubernetes 平台节点上 CPU、内存、网络、磁盘、进程实验场景，Pod 网络和 Pod 本身实验场景如杀 Pod，容器的实验场景如上述的 Docker 容器实验场景

## 混沌工程实验实施步骤（页4）

1. 准备工作，混沌工程实验开始前通常会进行一些准备工作，以确保实验在适当的环境中进行。
2. 故障注入，运行特定的程序或指令，占用系统资源，或者关闭、干扰特定的组件。在实际实施过程中通常会采用自动化的扰动注入工具。
3. 过程监控，实验运行期间要密切关注相关系统评估指标的变化，关注系统是否出现告警或业务异常。
4. 实验调整，在实验过程中，可以根据指标的波动情况，随时调整实验参数，改变扰动的影响范围和强度。
5. 实验终止，注入进程达到预定时间后需具备自行终止的能力，如发生较为严重的失效，也可由混沌工程执行人员提前终止扰动注入。
6. 恢复验证，要在故障移除后继续运行一段时间，收集指标并观查系统是否恢复正常工作。
7. 实验备案，形成实验报告并归档。需记录实验设计和相关数据，包括实验假设、评估指标变化、扰动注入流程和实验结果。

## 故障注入实验一：CPU负载实验（页5）

blade create cpu fullload
参数说明：
- --climb-time string：爬升时间
- --cpu-count string：指定 CPU 满载的个数
- --cpu-list string：指定 CPU 满载的具体核，核索引从 0 开始 (0-3 or 1,3)
- --cpu-percent string：指定 CPU 负载百分比，取值在 0-100
- --timeout string：设定运行时长，单位是秒，通用参数

例：指定1-3核在5秒左右使用率达60%，60秒后结束
blade create cpu fullload --cpu-list 1-3 --climb-time 5 --cpu-percent 60 --timeout 60

## 故障注入实验二：磁盘读写io负载实验（页6）

blade create disk burn
参数说明：
- --path string：指定提升磁盘 io 的目录，会作用于其所在的磁盘上，默认值是 /
- --read：触发提升磁盘读 IO 负载，会创建 600M 的文件用于读，销毁实验会自动删除
- --write：触发提升磁盘写 IO 负载，会根据块大小的值来写入一个文件，比如块大小是 10，则固定的块的数量是 100，则会创建 1000M 的文件，销毁实验会自动删除
- --size string：块大小, 单位是 M, 默认值是 10，一般不需要修改，除非想更大的提高 io 负载
- --timeout string 设定运行时长，单位是秒，通用参数

例：/Home目录进行读IO故障注入
blade create disk burn --read --path /home --size 10M --timeout 60

## 故障注入实验三：磁盘填充混沌实验（页7）

blade create disk fill
参数说明：
- --path string：需要填充的目录，默认值是 /
- --size string：需要填充的文件大小，单位是 M，取值是整数，例如 --size 1024
- --reserve string：保留磁盘大小，单位是MB。取值是不包含单位的正整数，例如 --reserve 1024。如果 size、percent、reserve 参数都存在，优先级是 - percent > reserve > size
- --percent string：指定磁盘使用率，取值是不带%号的正整数，例如 --percent 80
- --retain-handle：是否保留填充
- --timeout string：设定运行时长，单位是秒，通用参数

例：执行磁盘填充，填充40G，持续时长 60秒
blade create disk fill --path /home --size 40000 --timeout 60

## 故障注入实验四：磁盘填充混沌实验（页8）

blade create mem load
参数说明：
--mem-percent string：内存使用率，取值是 0 到 100 的整数
--mode string：内存占用模式，有 ram 和 cache 两种，例如 --mode ram。ram 采用代码实现，可控制占用速率，优先推荐此模式；cache 是通过挂载tmpfs实现；默认值是 --mode cache
--reserve string：保留内存的大小，单位是MB，如果 mem-percent 参数存在，则优先使用 mem-percent 参数
--rate string：内存占用速率，单位是 MB/S，仅在 --mode ram 时生效
--timeout string：设定运行时长，单位是秒，通用参数

例：保留200M内存，持续60秒
blade create mem load --mode ram --reserve 200 --rate 100 --timeout 60

## 故障注入实验五：网络延迟实验场景（页9）

blade create network delay
参数说明：
- --destination-ip string：目标 IP. 支持通过子网掩码来指定一个网段的IP地址, 例如 192.168.1.0/24. 则 192.168.1.0~192.168.1.255 - 都生效。你也可以指定固定的 IP，如 192.168.1.1 或者 192.168.1.1/32，也可以通过都号分隔多个参数，例如 192.168.1.1,192.168.2.1。
- --exclude-port string：排除掉的端口，默认会忽略掉通信的对端端口，目的是保留通信可用。可以指定多个，使用逗号分隔或者连接符表示范围，例如 - 22,8000 或者 8000-8010。 这个参数不能与 --local-port 或者 --remote-port 参数一起使用
- --exclude-ip string：排除受影响的 IP，支持通过子网掩码来指定一个网段的IP地址, 例如 192.168.1.0/24. 则 192.168.1.0~192.168.1.255 - 都生效。你也可以指定固定的 IP，如 192.168.1.1 或者 192.168.1.1/32，也可以通过都号分隔多个参数，例如 192.168.1.1,192.168.2.1。
- --interface string：网卡设备，例如 eth0 (必要参数)
- --local-port string：本地端口，一般是本机暴露服务的端口。可以指定多个，使用逗号分隔或者连接符表示范围，例如 80,8000-8080
- --offset string：延迟时间上下浮动的值, 单位是毫秒
- --remote-port string：远程端口，一般是要访问的外部暴露服务的端口。可以指定多个，使用逗号分隔或者连接符表示范围，例如 80,8000-8080
- --time string：延迟时间，单位是毫秒 (必要参数)
- --force：强制覆盖已有的 tc 规则，请务必在明确之前的规则可覆盖的情况下使用
- --ignore-peer-port：针对添加 --exclude-port 参数，报 ss 命令找不到的情况下使用，忽略排除端口
- --timeout string：设定运行时长，单位是秒，通用参数

注：需要root用户执行或用户具有sudo权限
例：本机访问外部36.152.44.132机器（ping www.baidu.com 获取到的 IP）80端口延迟3秒，持续60秒
blade create network delay --time 3000 --interface eth0 --remote-port 80 --destination-ip 36.152.44.132 --timeout 60

## 故障注入实验六：篡改dns域名解析实验场景（页10）

blade create network dns
参数说明：
- --domain string：域名 (必要参数)
- --ip string：映射的 ip (必要参数)
- --timeout string：设定运行时长，单位是秒，通用参数

注：需要root用户执行或用户具有sudo权限
例：www.baidu.com 域名不可访问，持续60秒
blade create network dns --domain www.baidu.com --ip 10.0.0.0 --timeout 60

## 故障注入实验七：网络丢包实验场景（页11）

blade create network loss
参数说明：
- --destination-ip string：目标 IP. 支持通过子网掩码来指定一个网段的IP地址, 例如 192.168.1.0/24. 则 192.168.1.0~192.168.1.255 - 都生效。你也可以指定固定的 IP，如 192.168.1.1 或者 192.168.1.1/32，也可以通过都号分隔多个参数，例如 192.168.1.1,192.168.2.1。
- --exclude-port string：排除掉的端口，默认会忽略掉通信的对端端口，目的是保留通信可用。可以指定多个，使用逗号分隔或者连接符表示范围，例如 - 22,8000 或者 8000-8010。 这个参数不能与 --local-port 或者 --remote-port 参数一起使用
- --exclude-ip string：排除受影响的 IP，支持通过子网掩码来指定一个网段的IP地址, 例如 192.168.1.0/24. 则 192.168.1.0~192.168.1.255 - 都生效。你也可以指定固定的 IP，如 192.168.1.1 或者 192.168.1.1/32，也可以通过都号分隔多个参数，例如 192.168.1.1,192.168.2.1。
- --interface string：网卡设备，例如 eth0 (必要参数)
- --local-port string：本地端口，一般是本机暴露服务的端口。可以指定多个，使用逗号分隔或者连接符表示范围，例如 80,8000-8080
- --percent string：丢包百分比，取值在[0, 100]的正整数 (必要参数)
- --remote-port string：远程端口，一般是要访问的外部暴露服务的端口。可以指定多个，使用逗号分隔或者连接符表示范围，例如 80,8000-8080
- --force：强制覆盖已有的 tc 规则，请务必在明确之前的规则可覆盖的情况下使用
- --ignore-peer-port：针对添加 --exclude-port 参数，报 ss 命令找不到的情况下使用，忽略排除端口
- --timeout string：设定运行时长，单位是秒，通用参数

注：需要root用户执行或用户具有sudo权限
例：本机访问外部36.152.44.132机器（ping www.baidu.com 获取到的 IP）80 端口丢包率 100%，持续60秒
blade create network loss --percent 100 --interface eth0 --remote-port 80 --destination-ip 36.152.44.132 --timeout 60

## 故障注入实验八：杀/暂停进程（页12）

blade create process kill/stop
参数说明：
- --process string：进程关键词，会在整个命令行中查找
- --process-cmd string：进程命令，只会在命令中查找
- --local-port string：进程占用端口
- --pid string：进程id
- --count string：限制杀掉进程的数量，0 表示无限制
- --signal string：指定杀进程的信号量，默认是 9，例如 --signal 15
- --timeout string：设定运行时长，单位是秒，通用参数

例1：删除包含 SimpleHTTPServer 关键词的进程
blade create process kill --process SimpleHTTPServer
例2：指定信号量和本地端口杀进程
blade c process kill --local-port 8080 --signal 9

## 故障注入实验九：容器内CPU负载实验场景（页13）

blade create cri cpu fullload
参数说明：
- --climb-time string：持续爬升时间
- --container-id string：容器id，当与container-name一起使用时，首选container-id
- --container-label-selector string：容器标签选择器，当与container-id或container-name一起使用时，首选container-id或container-name
- --container-name string：容器名称，当与container-id连用时，首选container-id
- --container-namespace string：如果container-runtime是containerd，它将被使用，默认值是-k8s.io
- --container-runtime string：容器运行时，支持cri和containerd，默认值为docker
- --cpu-count string：指定 CPU 满载的个数
- --cpu-list string：指定 CPU 满载的具体核，核索引从 0 开始 (0-3 or 1,3)
- --cpu-percent string：指定 CPU 负载百分比，取值在 0-100
- --cri-endpoint string：容器套接字端点
- --timeout string：设定运行时长，单位是秒，通用参数

例：对 container id 是 5239e26f6329 的做 CPU 使用率 80% 的实验场景，持续60秒
blade create cri cpu fullload --cpu-percent 80 --chaosblade-release /root/chaosblade-0.6.0.tar.gz --container-id 5239e26f6329 --time-out 60

## 故障注入实验十：kubernetes 节点 CPU 负载实验场景（页14）

blade create k8s node-cpu fullload
参数说明：
- --evict-count string：限制实验生效的数量
- --evict-percent string：限制实验生效数量的百分比，不包含%
- --labels string：节点资源标签
- --names string：节点资源名，多个资源名之间使用逗号分隔
- --kubeconfig string：kubeconfig 文件全路径（仅限使用 blade 命令调用时使用）
- --waiting-time string：实验结果等待时间，默认为 20s，参数值要包含单位，例如 10s，1m

例：指定一台节点，做 CPU 负载 80%
yaml 配置方式：
```
apiVersion: chaosblade.io/v1alpha1
kind: ChaosBlade
metadata:
name: cpu-load
spec:
experiments:
- scope: node
target: cpu
action: fullload
desc: "increase node cpu load by names"
matchers:
- name: names
value:
- "cn-hangzhou.192.168.0.205"
- name: cpu-percent
value:
- "80"
```
kubectl apply -f chaosblade_cpu_load.yaml
blade 命令执行方式：
blade create k8s node-cpu fullload --names cn-hangzhou.192.168.0.205 --cpu-percent 80 --kubeconfig ~/.kube/config


## 故障注入实验十一：指定 java 进程full-gc（页15）

blade create jvm full-gc
参数说明：
- --effect-count string：限制影响数量
- --interval string：full-gc间隔（毫秒）
- --javaHome string：jdk位置
- --pid string：进程id
- --process string：进程名称
- --refresh：刷新java agent时间
- --timeout string：设定运行时长，单位是秒，通用参数

例：对包含springboot.jar关键字的进程注入full gc
blade c jvm full-gc --effect-count 100 --interval 1000 --timeout 300 --process springboot.jar --javaHome /usr/java/jdk