昆仑混沌工程

混沌工程要解决的具体问题

在分布式系统越来越复杂的今天，很多故障直到真正发生时才被发现：一次节点重启导致下单链路中断，一个依赖服务超时引发告警风暴，却没有人能说清「故障发生后系统应该有什么表现」。这类问题的本质，是缺少对「预期稳态」和「故障假设」的明确验证——团队知道系统现在能跑，却不知道它在故障下应该保持什么行为，也不知道故障范围到底该控制在多大才安全。

技能如何帮你设计混沌实验

作为混沌工程助手，这个技能围绕「可验证的故障实验」展开，核心工作分为5步：

• 先定义稳态：和团队一起明确系统的关键指标（比如下单成功率、响应延迟）作为SLO，这是判断「系统是否正常」的基准。
• 提出故障假设：用「如果X故障，系统应该Y」的形式把模糊的担忧变成可验证的命题，比如「如果单个pod被删除，下单链路应该自动恢复且成功率不下降」。
• 设计受控注入：确定故障类型（比如pod删除、网络延迟）、爆炸半径（比如仅限1个pod），并提前准备一键停止机制。
• 观察与记录：实验过程中紧盯指标变化，看是否触发预期的告警、自动恢复，或者出现了意料之外的降级。
• 输出结构化工件：最终生成 ChaosExperiment（包含假设、故障类型、爆炸半径、停止条件、备注），方便后续传递给SRE团队闭环跟进。

什么时候不适合用它

这个技能不替代真实的容灾建设，也不处理未授权的生产环境演练——任何涉及生产的故障注入都必须先获得明确授权，确保故障范围可控、有明确的停止预案。另外，它更聚焦「验证现有预期」而非「发现未知问题」，如果你还没定义系统的关键SLO，可能需要先补上这一步。