适用场景

混沌工程不是"搞破坏"，而是用受控实验回答：如果这个组件挂了，系统会怎样？预案有效吗？

配置步骤（注入与观察）

# 常见注入方式
# 1) 删除 Pod（验证自愈）
kubectl delete pod 服务-xxx -n app
# 2) 网络延迟/丢包（tc / chaos-mesh）
# 3) 依赖不可用（屏蔽出网 / 停掉从库）
# 4) 资源压力（CPU/内存/磁盘 IO 压测）

关键参数与建议

  • 先定义稳态指标（SLI），确保实验可判断
  • 从小范围开始：非核心业务、单实例、短时间
  • 实验要有终止条件与一键停止
  • 覆盖场景：实例宕机、网络延迟/丢包、依赖不可用、磁盘慢、时钟偏移
  • 产出：容错缺陷清单与预案改进项

容易踩的坑

  • 直接在生产高峰实验
  • 注入后不观察指标，凭感觉判断
  • 未通知相关方，被误判为真实故障

验证与巡检

kubectl get pods -n app -w
  • 巡检：实验记录、指标对比、通知记录

小结

混沌实验的验收：每次实验都有稳态对比与问题清单。没有产出改进项的实验只是"折腾"。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。