name: 混沌工程基础 description: 当实施混沌工程、设计故障注入实验或构建韧性测试实践时使用。涵盖混沌工程原则和实验设计。 allowed-tools: 读取, 全局搜索, 文本搜索
混沌工程基础
混沌工程的原则和实践——通过受控实验主动发现系统弱点。
何时使用此技能
- 实施混沌工程实践
- 设计故障注入实验
- 构建系统韧性信心
- 发现隐藏故障模式
- 验证灾难恢复
什么是混沌工程？
混沌工程 = 主动韧性测试
传统测试："当一切正常时，它能工作吗？"
混沌工程："当事情出错时，它能工作吗？"
原则：
在生产环境中建立对系统承受动荡条件能力的信心。
不是随机破坏事物。
是关于受控实验以学习。
混沌工程循环
┌─────────────────────────────────────────────────────────┐
│ 混沌工程循环 │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ 定义 │────►│ 注入 │────►│ 观察 │ │
│ │ 稳态 │ │ 混沌 │ │ 结果 │ │
│ │ 状态 │ │ │ │ │ │
│ └─────────┘ └─────────┘ └────┬────┘ │
│ ▲ │ │
│ │ │ │
│ │ ┌─────────┐ │ │
│ └──────────│ 改进 │◄─────────┘ │
│ │ 系统 │ │
│ └─────────┘ │
└─────────────────────────────────────────────────────────┘
核心原则
1. 围绕稳态建立假设
稳态 = 正常系统行为
定义可度量的指标：
- 请求成功率：99.9%
- 延迟p99：< 200ms
- 订单处理/分钟：> 100
- 活跃用户会话：> 10,000
假设格式：
"当[故障条件]发生时，系统将
保持[稳态指标]在[可接受范围]内"
示例：
"当一个数据库副本失败时，请求成功率
将保持在99.5%以上，延迟低于500ms"
2. 变化现实世界事件
注入现实故障：
基础设施：
- 服务器崩溃
- 网络分区
- 磁盘满
- CPU耗尽
- 时钟偏差
应用：
- 服务不可用
- 慢响应
- 数据损坏
- 证书过期
- 资源耗尽
依赖项：
- 数据库故障
- 缓存不可用
- 第三方API宕机
- 消息队列积压
3. 在生产环境中运行实验
为什么生产？
- 真实流量模式
- 真实基础设施
- 真实依赖项
- 真实监控
安全开始：
1. 从非生产开始
2. 过渡到金丝雀
3. 进步到生产
4. 逐渐扩大影响范围
安全网：
- 准备紧急停止开关
- 回滚计划
- 有限影响范围
- 监控到位
4. 自动化实验以连续运行
一次性实验找到一次性bug。
连续实验捕获回归问题。
自动化目标：
- 定期运行实验
- 集成到CI/CD
- 捕获新故障模式
- 验证变更
示例计划：
- 关键路径：每日
- 核心服务：每周
- 完整系统：每月
5. 最小化影响范围
控制实验影响：
范围限制：
- 单个实例
- 流量百分比
- 特定区域
- 仅测试账户
持续时间限制：
- 秒到分钟
- 自动终止
- 预定窗口
中止条件：
- 错误率超过阈值
- 检测到客户影响
- 手动紧急停止开关
实验设计
实验结构
实验：[名称]
日期：[何时]
团队：[谁]
## 假设
当[注入故障]时，系统将[预期行为]
因为[推理]。
## 稳态指标
- [指标1]：[预期值]
- [指标2]：[预期值]
## 实验细节
故障类型：[我们注入什么]
目标：[我们注入哪里]
严重性：[多严重]
持续时间：[多久]
## 影响范围
- 受影响服务：[列表]
- 受影响用户：[百分比/数量]
- 区域/区：[范围]
## 中止条件
- [条件1] → 中止
- [条件2] → 中止
## 回滚计划
1. [步骤1]
2. [步骤2]
## 结果
假设：[确认/证伪]
观察：[我们看到什么]
行动项：[需要修复什么]
常见实验类型
1. 服务故障
└── 杀死实例，返回错误
2. 网络故障
└── 延迟注入，丢包，分区
3. 资源耗尽
└── CPU压力，内存压力，磁盘满
4. 依赖项故障
└── 数据库宕机，缓存未命中，API超时
5. 状态损坏
└── 时钟偏差，数据不一致
6. 流量激增
└── 突然负载增加
故障注入模式
基础设施故障
实例终止：
- 杀死随机实例
- 验证自动扩展/恢复
- Netflix Chaos Monkey风格
区/区域故障：
- 模拟完整区域中断
- 测试故障转移到其他区域
- 验证数据一致性
网络分区：
- 脑裂场景
- 跨区域通信故障
- 共识算法行为
应用故障
延迟注入：
- 添加人工延迟
- 测试超时处理
- 验证断路器
错误注入：
- 返回500错误
- 抛出异常
- 测试错误处理路径
资源泄漏：
- 内存泄漏
- 连接池耗尽
- 文件句柄耗尽
依赖项故障
数据库故障：
- 主节点故障转移
- 副本滞后
- 连接池耗尽
缓存故障：
- 缓存未命中场景
- 缓存集群故障
- 防踩踏保护
外部API故障：
- 超时
- 速率限制
- 格式错误响应
混沌工程工具
开源工具
Chaos Monkey（Netflix）
- 随机实例终止
- 专注于AWS
- Simian Army一部分
Gremlin
- 综合混沌平台
- 多种攻击类型
- 企业功能
Litmus
- Kubernetes原生
- ChaosHub实验库
- GitOps友好
Chaos Mesh
- Kubernetes原生
- 多种故障类型
- 包含仪表板
Pumba
- Docker混沌测试
- 容器级故障
- CI/CD集成
云提供商工具
AWS：
- 故障注入模拟器
- 原生集成
Azure：
- Chaos Studio
- Azure原生实验
GCP：
- 无原生工具（使用Gremlin/Litmus）
实施策略
成熟度模型
级别0：临时
- 手动测试
- 无混沌实践
- 对故障反应
级别1：开始
- 首次实验
- 仅非生产环境
- 手动执行
级别2：中级
- 定期实验
- 生产实验
- 部分自动化
级别3：高级
- 连续混沌
- 自动化实验
- 广泛覆盖
级别4：专家
- 混沌即代码
- 集成到CI/CD
- 常规GameDays
入门步骤
第1-2周：基础
- 识别关键路径
- 定义稳态指标
- 设置监控
第3-4周：首次实验
- 从已知故障开始
- 在非生产环境运行
- 记录学习成果
第2个月：扩展
- 添加更多实验类型
- 谨慎移动到生产
- 自动化基本实验
第3个月以上：成熟
- 常规GameDays
- 连续实验
- 集成到CI/CD
GameDays
什么是GameDay？
GameDay = 计划混沌演练
系统消防演习：
- 提前安排
- 多种故障场景
- 练习事件响应
- 学习并改进
GameDay结构
之前：
- 定义目标
- 计划场景
- 通知利益相关者
- 准备运行手册
- 设置监控
期间：
- 运行场景
- 观察系统行为
- 练习事件响应
- 记录发现
之后：
- 复盘会议
- 记录学习成果
- 创建行动项
- 计划下次GameDay
GameDay场景
场景类别：
1. 基础设施
- 区域故障
- 网络分区
- 扩展限制
2. 应用
- 服务中断
- 部署失败
- 配置错误
3. 数据
- 数据库损坏
- 备份恢复
- 数据中心切换
4. 安全
- 凭证轮换
- 证书过期
- 访问撤销
安全和防护措施
实验安全
运行混沌之前：
1. 有假设
知道你在测试什么
2. 限制影响范围
从小开始，逐渐扩大
3. 有中止条件
自动停止
4. 有回滚计划
知道如何撤销
5. 监控一切
看不到就无法学习
6. 沟通
团队知道实验在运行
紧急停止开关
每个实验需要：
手动紧急停止开关：
- 立即终止
- 多个人可访问
- 实验前测试
自动中止：
- 错误率阈值
- 延迟阈值
- 客户影响检测
通知：
- 触发中止时警报
- 记录中止原因
衡量成功
混沌工程成功指标：
1. 运行的实验
我们是否定期做混沌？
2. 发现的问题
我们是否找到问题？
3. MTTR改进
我们恢复更快吗？
4. 事件预防
混沌是否预防了生产事件？
5. 信心水平
团队是否更信任系统？
最佳实践
1. 从小开始
从简单实验开始
2. 假设优先
知道你在测试什么
3. 逐渐自动化
先手动，后自动化
4. 最终生产
那里有真实混沌
5. 无责文化
发现是学习，不是失败
6. 常规GameDays
熟能生巧
7. 分享学习成果
跨团队传播知识
相关技能
韧性模式- 构建韧性系统GameDay规划- 详细GameDay规划事件响应- 处理发现的问题