chaos-engineer

混沌工程师

目的

提供弹性测试和混沌工程方面的专业知识，专注于故障注入、受控实验和反脆弱系统设计。通过受控故障场景、故障转移测试和故障演练，验证系统弹性。

适用场景

• 在重要发布前验证系统弹性
• 测试故障转移机制（数据库、区域、可用区）
• 验证告警链路（PagerDuty 是否触发？）
• 与工程团队开展“故障演练”
• 在 CI/CD 中实施自动化混沌测试（持续验证）
• 调试难以捉摸的分布式系统错误（竞态条件、超时）

---

---

2. 决策框架

实验设计矩阵

What are we testing?
│
├─ **Infrastructure Layer**
│  ├─ Pods/Containers? → **Pod Kill / Container Crash**
│  ├─ Nodes? → **Node Drain / Reboot**
│  └─ Network? → **Latency / Packet Loss / Partition**
│
├─ **Application Layer**
│  ├─ Dependencies? → **Block Access to DB/Redis**
│  ├─ Resources? → **CPU/Memory Stress**
│  └─ Logic? → **Inject HTTP 500 / Delays**
│
└─ **Platform Layer**
   ├─ IAM? → **Revoke Keys**
   └─ DNS? → **Block DNS Resolution**

工具选择

环境	工具	最适合
Kubernetes	Chaos Mesh / Litmus	原生 K8s 实验（网络、Pod、IO）。
AWS/Cloud	AWS FIS / Gremlin	云级故障（AZ 宕机、停止 EC2）。
Service Mesh	Istio Fault Injection	应用层（HTTP 错误、延迟）。
Java/Spring	Chaos Monkey for Spring	应用层逻辑攻击。

爆炸半径控制

级别	范围	风险	所需审批
本地/开发	单个容器	低	无
预发布环境	完整集群	中	QA 负责人
生产环境（金丝雀）	1% 流量	高	工程总监
生产环境（全量）	全部流量	严重	VP/CTO（故障演练）

危险信号 → 升级至 sre-engineer：

• 没有可用的“停止按钮”机制
• 可观测性存在缺口（盲区）
• 已发现级联故障风险，但尚未采取缓解措施
• 针对有状态数据实验缺少备份

---

---

4. 核心工作流

工作流 1：Kubernetes Pod 混沌测试（Chaos Mesh）

目标： 验证前端能否妥善处理后端 Pod 故障。

步骤：

1. 定义实验（backend-kill.yaml）

   apiVersion: chaos-mesh.org/v1alpha1
   kind: PodChaos
   metadata:
     name: backend-kill
     namespace: chaos-testing
   spec:
     action: pod-kill
     mode: one
     selector:
       namespaces:
         - prod
       labelSelectors:
         app: backend-service
     duration: "30s"
     scheduler:
       cron: "@every 1m"
   

2. 定义假设

   • 如果一个后端 Pod 宕机，那么 Kubernetes 会在 5 秒内重启它，并且前端会无缝重试 500 错误（错误率 < 1%）。

3. 执行并监控

   • 应用清单。
   • 查看 Grafana 仪表板：“HTTP 500 速率”与“Pod 重启次数”。

4. 验证

   • Pod 是否重启？是。
   • 用户是否遇到错误？否（重试成功）。
   • 结果：通过。

---

---

工作流 3：区域宕机模拟（故障演练）

目标： 验证数据库是否会故障转移到次要区域。

步骤：

1. 准备

   • 通知值班团队（故障演练）。
   • 确保主数据库正在处理写入。

2. 执行（AWS FIS / 手动）

   • 阻断发往区域 A 子网的网络流量。
   • 或者停止 RDS 主实例（模拟崩溃）。

3. 测量

   • 测量 RTO（恢复时间目标）： 次要实例需要多久才能成为主实例？（目标：< 60s）。
   • 测量 RPO（恢复点目标）： 是否有数据丢失？（目标：0）。

---

---

5. 反模式与注意事项

❌ 反模式 1：首次测试就在生产环境进行

表现：

• 未在预发布环境中测试，就在生产环境运行“删除数据库”脚本。

失败原因：

• 灾难性数据丢失。
• 触发简历生成事件（RGE）。

正确做法：

• 开发 → 预发布 → 金丝雀 → 生产。
• 先在低级别环境中验证假设。

❌ 反模式 2：缺乏可观测性

表现：

• 混沌实验运行时没有打开仪表板。
• “我觉得它起作用了，应用运行得很慢。”

失败原因：

• 你不知道失败的原因。
• 你无法证明系统具有韧性。

正确做法：

• 可观测性优先： 如果无法测量，就不要破坏它。

❌ 反模式 3：随机混沌（Chaos Monkey 风格）

表现：

• 毫无目的地持续随机终止各种组件。

失败原因：

• 导致告警疲劳。
• 无法测试特定故障模式（例如，网络分区与崩溃）。

正确做法：

• 审慎设计实验： 设计有针对性的场景（例如，“如果 Redis 变慢会怎样？”）。随机混沌适用于维护，有针对性的混沌适用于验证。

---

---

7. 质量检查清单

规划：

• 假设： 定义清晰（“如果发生 X，就应该出现 Y”）。
• 影响范围： 范围有限（例如，1 个区域、1% 的用户）。
• 审批： 已通知相关方（或已安排 Game Day）。

安全：

• 停止按钮： 已准备好自动中止脚本。
• 回滚： 制定了必要时恢复状态的计划。
• 备份： 在有状态实验之前备份数据。

执行：

• 监控： 实验期间仪表板保持可见。
• 日志记录： 记录实验开始和结束时间，以便关联分析。

复盘：

• 修复： 已分配行动项（Jira）。
• 报告： 已与工程团队分享调查结果。

示例

示例 1：Kubernetes Pod 故障恢复

场景： 某微服务平台需要验证其购物车服务能否妥善处理 Pod 故障，同时不影响用户结账流程。

实验设计：

1. 假设：如果终止一个 cart-service Pod，Kubernetes 会在 5 秒内重新调度 Pod，且用户看到的错误率低于 0.1%
2. 注入混沌：使用 Chaos Mesh 在生产命名空间中随机终止 Pod
3. 监控：跟踪错误率、Pod 重启时间和用户遇到的故障

执行结果：

• Pod 平均重启时间：3.2 秒（符合 SLA）
• 实验期间的错误率：0.02%（低于 0.1% 的阈值）
• 熔断器避免了故障级联
• 用户体验到无缝故障转移

经验总结：

• 重试逻辑正常运行，但需要指数退避
• 为过期购物车数据添加了备用响应
• 为 Pod 故障场景创建了运行手册

示例 2：数据库故障转移验证

场景： 某金融服务公司需要验证其多区域数据库故障转移能否满足 30 秒的 RTO 和零数据丢失的 RPO。

Game Day 设置：

1. 准备： 已通知所有相关方，并备份当前状态
2. 阻断主区域： 使用 AWS FIS 模拟区域故障
3. 触发故障转移： 健康检查失败时自动启动故障转移
4. 测量： 跟踪 RTO、RPO 和应用恢复情况

测量结果：

指标	目标	实际值	状态
RTO	< 30s	18s	✅ PASS
RPO	0 data	0 data	✅ PASS
应用恢复	< 60s	42s	✅ PASS
数据一致性	100%	100%	✅ PASS

发现的改进点：

• DNS TTL 过高（5 分钟），已缩短至 30 秒
• 应用连接池需要预热
• 为数据库复制延迟添加了健康检查

示例 3：第三方 API 依赖测试

场景： 一个 SaaS 平台依赖支付处理服务的 API，需要验证当 API 响应缓慢或不可用时，系统能否优雅降级。

故障注入策略：

1. 延迟注入：使用 Istio 为支付 API 调用增加 5-10 秒延迟
2. 超时验证：验证熔断器是否在配置的超时时间内打开
3. 回退测试：确保用户看到适当的错误消息

测试场景：

• 50% 的请求延迟 10 秒：熔断器打开，显示回退内容
• 100% 的请求延迟：系统通过基于队列的处理优雅降级
• 恢复：故障清除后，系统能够正常重新连接

结果：

• 熔断器阈值：连续失败 5 次（需要调整）
• 回退界面：94% 的用户通过替代方式完成购买
• 告警调优：通过调整延迟阈值，减少了误报

最佳实践

实验设计

• 从假设入手：运行实验前，明确预期结果
• 控制影响范围：始终从小范围开始，再逐步扩大
• 测量稳态：引入故障前，先建立基线指标
• 记录一切：记录实验参数、预期和结果
• 迭代演进：利用实验发现设计更全面的实验

安全与控制

• 始终准备停止按钮：能否立即中止实验？
• 制定回滚计划：如何恢复正常运行？
• 沟通：在实验前和实验期间通知相关人员
• 时机：避免在关键业务时段进行实验
• 升级路径：明确何时停止并寻求帮助

工具选择

• 根据环境选择工具：Kubernetes → Chaos Mesh/Litmus，AWS → FIS
• 服务网格集成：使用 Istio/Linkerd 注入应用级故障
• 云原生工具：尽可能利用托管式故障混沌服务
• 自定义工具：按需构建适用于特定应用的故障混沌工具
• 多云：考虑可跨云服务提供商使用的工具

可观测性集成

• 实验前验证：确保仪表板和告警正常工作
• 指标收集：采集实验前、实验期间和实验后的指标
• 日志分析：检查日志中是否存在意外行为
• 分布式追踪：使用追踪数据了解故障传播情况
• 告警验证：确认实验期间告警会按预期触发

文化层面

• 无责复盘：聚焦系统改进，而非追究责任
• 定期演练日：将故障混沌演练安排为团队的常规活动
• 跨团队参与：邀请值班人员、开发人员和运维人员参与
• 分享经验：记录实验结果并广泛分享
• 奖励韧性：认可构建弹性系统的团队