本文目录导读：
混沌工程（Chaos Engineering）的核心目的是主动发现系统中的脆弱点，而不是制造破坏。安全开展是混沌工程的第一原则，一旦操作不当，可能会引发真实的、大面积的线上生产故障。
以下是一套经过业界验证的、安全开展混沌工程的完整流程和守则：
第一阶段：前提准备与风险控制（最关键的步骤）
在动手注入任何故障前,必须完成以下安全基线的搭建：
-
明确爆炸半径（Blast Radius）：
- 初始实验必须限制在最小单元：如一台实例、一个进程、一个微服务实例，而不是整个集群。
- 使用标签选择器或实例白名单，避免误伤核心服务。
-
建立可观测性与告警体系：
- 指标：监控CPU、内存、延迟、错误率（4个黄金信号）。
- 链路追踪：确保能看到请求流经的每一个节点。
- 业务告警：必须与业务方确认关键阈值（如：支付成功率低于99.9%即为事故）。
-
设置“熔断”与“自动回滚”机制：
- 手动急停：必须有且仅有一个“一键停止所有实验”的按钮，且权限仅授予运维负责人。
- 自动熔断：配置防守规则（Guardrails）。
- 如果全局错误率上升超过 ( X\% )，立即停止。
- 如果P99延迟超过 ( Y \text{ms} )，自动回滚。
- 如果某个核心依赖（如数据库）的故障持续时间超过 ( Z ) 秒，自动恢复。
-
渐进式实验策略：
- 第一阶段：在预发布环境或影子环境执行，验证实验工具本身不会导致系统崩溃。
- 第二阶段：在生产环境的低流量时段（如凌晨3点），对非核心、可降级的服务执行。
- 第三阶段：才考虑在核心服务上进行。
第二阶段：制定标准实验流程
每次混沌实验都应遵循“假设-实验-验证”的科学方法，以控制风险：
- Step 1: 定义稳态（Steady State）：
实验前,系统正常运行时，关键指标是多少？（正常流量下支付成功率99.99%）。
- Step 2: 提出假设：
假设：当A服务宕机时，由于有缓存和熔断机制，B服务仍能正常返回降级数据，支付成功率维持在99.9%。
- Step 3: 注入故障：
注入预定义的故障（网络延迟、资源耗尽、服务中断等）。
- Step 4: 观察与对比：
- 实时对比实际指标与稳态指标。
- 如果实际指标偏离了假设（例如支付成功率暴跌至50%），立即终止实验，这代表存在未知盲区。
- Step 5: 恢复与复盘：
- 不要忘记恢复：确保实验结束后，所有注入的故障被彻底清除（使用Terraform或脚本自动化检查）。
- 必须复盘：无论成功还是失败，都要产出改进项（如增加重试机制、优化限流参数）。
第三阶段：安全开展的关键守则（红线）
以下行为在混沌工程中通常是不被允许的,除非经过极其严格的审批：
- 禁止在“周末/重大促销/高峰期”进行首次实验。
- 禁止对“有状态服务”进行破坏性实验（如：主数据库的kill -9、Redis主库的强制主从切换）——除非你有完备的容灾和全量备份恢复方案。
- 避免直接破坏“无损”的业务逻辑：例如要测试“修改用户余额”是否健壮，应先测试“查询余额接口超时”，而不是直接去修改余额数据。
- 永远保留“人肉审批”环节：自动化工具不能完全取代人的判断，任何涉及核心链路（支付、登录、下单）的实验，必须由架构师或业务责任人签字确认。
- 不要追求100%的故障覆盖率：实验是为了发现重要问题，而不是证明系统完美。
第四阶段：推荐的工具与技术选型
选择成熟的混沌工程平台可以显著提升安全性：
- 企业级平台（自带熔断、观察、报告）：Chaos Mesh（K8s原生）、LitmusChaos、Gremlin。
- 底层故障注入能力：iostat（磁盘）、tc（网络）、stress-ng（CPU/内存）。
- 安全实践：所有实验代码应以GitHub/GitLab的Pull Request形式提交，且必须包含：
- 实验目标
- 假设的稳态
- 爆炸半径范围
- 熔断条件
- 审批人列表
安全开展的三句话
- 先做小，后做大：从一台机器开始，从只读接口开始，从预发环境开始。
- 先有哨兵，再有故障：监控、告警、熔断（Guardrails）不完善，绝对不动手。
- 先假设，后破坏：如果没有明确的假设“系统会如何表现”，就不要开始实验。
一个极简的安全检查清单：
- [ ] 实验环境是否隔离？（是 -> 生产环境是否有熔断规则？）
- [ ] 是否有应急恢复脚本？
- [ ] 监控面板是否已打开？
- [ ] 是否通知了值班人员？
- [ ] 实验是否在非核心时段？
遵循以上原则,混沌工程可以帮助你安全地“在演习中找问题”，而不是“在事故中找原因”。
