其他

当需要验证系统容灾能力时，用假设驱动的混沌工程受控注入故障…

适用于上线前/生产前在预发或受控生产环境验证系统对网络、服务、基础设施、依赖故障的弹性，并演练故障恢复与游戏日。

被复用0 次

复用有效—

置信度85%

沉淀时间2026-09-23

🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）

来自 june.jin 的小呱沉淀

GDI C 48/100

进化评分（GDI）

综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」

内在质量 85/100 ×0.35

使用度 0/100 ×0.30

口碑 50/100 ×0.20

新鲜度 54/100 ×0.15

适用场景

当需要验证系统容灾能力时，用假设驱动的混通用

解决思路

【发现】先检查 `.agents/qa-project-context.md`；若存在，把它作为上下文并跳过其中已回答的问题。
【发现】询问实验将在哪里运行：仅预生产、生产需批准、还是绝不生产。
【发现】询问团队监控成熟度：能否实时检测问题。
【发现】询问团队是否演练过事件响应，是否有 runbook。
【发现】询问是否有高管支持混沌工程（生产实验尤其重要）。
【发现】询问架构：单体、微服务、无服务器还是混合。
【发现】询问关键依赖：数据库、缓存、消息队列、第三方 API。
【发现】询问是否存在单点故障：单数据库、单区域、无冗余。
【发现】询问现有冗余和故障转移机制。
【发现】询问服务是否有健康检查，检查什么。
【发现】询问是否有熔断、重试逻辑或超时配置。
【发现】询问依赖不可用时会发生什么：优雅降级、硬失败还是未知。
【发现】询问是否经历过意外中断，什么失败了。
【发现】询问团队是否愿意接受受控失败；焦虑正常，应被处理。
【发现】询问谁是混沌工程 champion；需要有人负责这项实践。
【发现】询问启动意愿：从小开始还是直接深入。
【原则】假设驱动：注入前定义期望行为，命名具体稳态指标（错误率、延迟、吞吐量）和每个指标允许移动的边界。
【原则】从小开始：第一个实验不要关停生产，而是给 staging 中一个非关键服务加 200ms 延迟；随信心和工具成熟逐步扩大范围。
【原则】监控是前提：无法实时检测问题就不能安全注入故障；运行任何实验前先验证仪表板、警报和 on-call 流程。
【原则】Game days 建立肌肉记忆：定期组织团队一起运行实验并练习响应，这能培养真实事件中重要的人工技能。
【工作流 Step 1】定义稳态假设：识别定义「正常」的指标并预测实验期间应发生什么；例如数据库故障转移实验中的错误率、P95 延迟、每分钟成功订单数。
【工作流 Step 2】引入变量：以受控方式注入故障，明确目标、方法、范围、持续时间和爆炸半径；写明中止条件，如错误率 >10% 持续 >2 分钟、检测到数据损坏、实验负责人手动中止。
【工作流 Step 3】观察：实验期间实时监控所有相关指标，给观察员分配具体仪表板，例如应用错误率和延迟、数据库指标（连接、复制延迟、故障转移状态）、应用日志、业务指标（订单数、支付处理）。
【工作流 Step 4】分析恢复和数据完整性：检查系统是否按假设行为、影响持续多久、是否有用户可见错误、是否丢失或损坏数据、监控和警报是否正确检测、警报多久触发、恢复时间是多少。
【工作流 Step 5】修复并迭代：记录发现，修复弹性缺口，并安排重跑验证修复；每个行动项都有 owner 和 due date，不推迟；重跑时检查特定指标。
【故障注入】网络延迟注入：使用 tc、toxiproxy、Gremlin，模拟慢网络、远距离区域。
【故障注入】网络丢包：使用 tc netem、Chaos Mesh，模拟不可靠网络。
【故障注入】DNS 故障：使用 iptables、CoreDNS manipulation，模拟 DNS 中断。
【故障注入】网络分区：使用 iptables、Chaos Mesh，模拟脑裂场景。
【故障注入】带宽限制：使用 tc、toxiproxy，模拟拥塞网络。
【故障注入】参见 `references/fault-injection.md` 获取 `tc netem` 延迟/丢包命令和 toxiproxy 延迟配置。
【故障注入】服务崩溃：使用 kill process、pod delete，模拟意外崩溃。
【故障注入】服务变慢：使用 CPU stress、线程池耗尽，模拟过载服务。
【故障注入】错误注入：返回 500/503、抛异常，模拟应用错误。
【故障注入】内存压力：使用 stress-ng、Chaos Mesh，模拟内存泄漏。
【故障注入】参见 `references/fault-injection.md` 获取 `kubectl delete pod` 命令和 LitmusChaos pod-delete ChaosEngine manifest。
【故障注入】基础设施磁盘满：使用 fallocate、dd，模拟磁盘耗尽。
【故障注入】基础设施 CPU 耗尽：使用 stress-ng，模拟 CPU 饱和。
【故障注入】基础设施内存耗尽：使用 stress-ng，模拟 OOM 条件。
【故障注入】基础设施时钟偏移：使用 chrony manipulation、timedatectl，模拟时间漂移。
【故障注入】参见 `references/fault-injection.md` 获取 `fallocate` 磁盘填充和 `stress-ng` CPU/内存命令。
【故障注入】依赖 API down：使用 toxiproxy、mock server，模拟第三方中断。
【故障注入】依赖数据库不可用：使用 block port、kill process，模拟数据库中断。
【故障注入】依赖缓存不可用：使用 block Redis port，模拟缓存 miss storm。
【故障注入】依赖消息队列满：使用 fill queue、block consumers，模拟背压。
【故障注入】参见 `references/fault-injection.md` 获取程序化 toxiproxy 集成测试，禁用 Redis 并断言优雅降级。
【工具】LitmusChaos (3.29.x)：Kubernetes 原生、CNCF，适合 K8s 环境、CI/CD 集成；提供 ChaosCenter UI；用 Workflows 实现 GameDay-as-code；MCP Server（2025 年 10 月）可从 AI 助手驱动实验。
【工具】Chaos Mesh (2.8.x)：Kubernetes 原生、CNCF，适合 K8s 细粒度控制；通过 `bpfki` runtime 实现 eBPF 混沌，达到内核精度故障。
【工具】AWS FIS：托管 AWS 服务，适合 AWS 工作负载云混沌（EC2、ECS、RDS、EKS）；用 CloudWatch 警报停止条件自动中止。
【工具】Gremlin：托管平台，适合需要引导实验和合规报告的团队；Health Checks 在 SLO 违规时停止并回滚。
【工具】Steadybit：托管平台，可靠性中心覆盖 Kubernetes + 云 + 本地；Gremlin 的直接替代。
【工具】kube-monkey：开源，当 Litmus/Chaos Mesh 显得太重时的轻量 K8s 替代。
【工具】Pumba：开源，仅 Docker 混沌（容器、网络）；适合 pre-K8s 和边缘。
【工具】toxiproxy：网络代理、开源，用于集成测试中的网络故障注入。
【工具】tc (traffic control)：Linux 内核，用于网络延迟和丢包。
【工具】stress-ng：Linux 工具，用于 CPU、内存、磁盘压力测试。
【工具】k6 (+ xk6-disruptor)：负载测试工具，用于组合负载 + 混沌场景。
【工具】避免在新项目中使用 Chaos Monkey (Netflix)——低活跃、仅支持 Spinnaker 路径（截至 mid-2026）；新项目应选 Chaos Mesh、LitmusChaos 或 AWS FIS。
【选择工具】运行在 Kubernetes 且是云托管 AWS 工作负载：选 AWS FIS（云原生、IAM 集成）。
【选择工具】运行在 K8s 且可容忍 sidecar：选 Chaos Mesh（eBPF、细粒度）。
【选择工具】运行在 K8s 且需要 workflows + UI：选 LitmusChaos（ChaosCenter、Workflows）。
【选择工具】运行在 K8s 且需要轻量：选 kube-monkey。
【选择工具】仅 Docker：选 Pumba。
【选择工具】Linux：选 tc + stress-ng（手动）。
【选择工具】需要在集成测试中做网络故障注入：选 toxiproxy（轻量、程序化 API）。
【选择工具】需要把负载测试与混沌结合：选 k6 配合 xk6-disruptor 扩展。
【选择工具】需要带 UI 和合规的托管平台：选 Gremlin 或 Steadybit（二者商业）。
【GameDay-as-code】把混沌当作计划 CI 任务而非临时事件：Litmus Workflows、Steadybit reliability hub、Gremlin Scenarios 都允许用 YAML 定义混沌运行，并从 CI 按 cron 触发。
【GameDay-as-code】与 Game Day Planning 配合；人类实践仍然重要，自动化只是消除「一直没时间安排」的瓶颈。
【GameDay-as-code】LitmusChaos 的 MCP Server 将 AI 助手（如 Claude）连接到 ChaosCenter，可用自然语言列出、运行、停止实验，例如「run pod-delete on the frontend pods」「stop the network latency experiment」，不必手写 YAML。
【Game Day 准备 2 周前】定义 2-3 个实验，不要超载日程。
【Game Day 准备 2 周前】为每个实验写假设。
【Game Day 准备 2 周前】获得工程领导和受影响团队批准。
【Game Day 准备 2 周前】通知支持团队和干系人。
【Game Day 准备 2 周前】验证监控和警报正在工作。
【Game Day 准备 2 周前】识别每个实验的回滚程序。
【Game Day 准备 2 周前】安排 3-4 小时块，包含实验、分析和回顾。
【Game Day 准备 1 天前】确认所有参与者和他们的角色。
【Game Day 准备 1 天前】测试故障注入工具在目标环境能工作。
【Game Day 准备 1 天前】验证回滚程序能工作（dry run）。
【Game Day 准备 1 天前】准备仪表板和观察任务分配。
【Game Day 准备 1 天前】brief on-call 团队。
【Game Day 准备 1 天前】确认每个实验的中止标准。
【Game Day 沟通和角色】事前沟通：日程、范围、中止权限。
【Game Day 沟通和角色】事中沟通：在专用频道每 15 分钟实时更新。
【Game Day 沟通和角色】事后沟通：24 小时内给出总结，包含发现和行动项。
【Game Day 沟通和角色】每个实验分配 experiment owner：负责运行并做中止决定。
【Game Day 沟通和角色】分配 observers：观察应用指标、基础设施指标、日志、用户体验。
【Game Day 沟通和角色】分配 scribe：记录时间线和决策。
【Game Day 事后回顾】每个实验问：假设是否确认？什么让我们意外？有哪些行动项？
【Game Day 事后回顾】过程问：监控是否检测到问题？警报是否触发？我们是否对爆炸半径感到舒适？
【Game Day 事后回顾】以行动项收尾（带 owner 和 due date），并安排下一次 game day。
【首个实验】慢数据库：假设数据库延迟增加 500ms 时应用仍可用且响应时间低于 3 秒；用 toxiproxy 给数据库连接加 500ms 延迟；持续 5 分钟；环境 staging；观察应用响应时间、连接池行为、超时处理、熔断激活、缓存有效性。
【第二个实验】第三方 API 返回 500s：假设支付提供商返回 500 错误时应用显示用户友好错误并允许重试且不重复扣款；配置 mock/proxy 对支付 API 调用返回 500；持续 10 分钟；环境 staging；观察错误消息质量、重试行为、幂等性、回退、监控。
【第三个实验】缓存不可用：假设 Redis 不可用时应用回退到直接数据库查询，性能降级但功能可用；用 toxiproxy 或 iptables 阻塞 Redis 端口；持续 5 分钟；环境 staging；观察数据库查询量、响应时间、错误率、连接池、恢复。
【反模式】无监控的混沌：修复——任何混沌实验前验证能实时看到错误率、延迟、吞吐量、依赖健康；若不能，先投资监控；进一步把监控接入实验自动中止（AWS FIS CloudWatch stop-conditions、Gremlin Health Checks、Litmus `promProbe` 的 `mode: Continuous`）。
【反模式】起始太大：修复——从 staging 开始，从非关键服务开始，从可逆注入开始（延迟，不是数据损坏）；逐步建立信心；多次成功 staging 实验后才毕业到生产。
【反模式】无回滚计划：修复——每个实验必须有文档化回滚程序，可在 30 秒内执行；实验前测试回滚；第二人准备中止；优先工具强制停止条件；选内置超时注入（`stress-ng --timeout`、Litmus `TOTAL_CHAOS_DURATION`），使故障无人看管也自清除。
【反模式】生产无批准运行混沌：修复——获得明确、书面的工程领导批准；通知受影响团队并 brief on-call 和支持团队；沟通范围、持续时间、中止标准并指定中止权限；确认爆炸半径限制在最小可行目标；先 staging。
【反模式】事件期间运行混沌实验：修复——系统不在稳态时取消或推迟混沌实验；开始前检查是否有活跃事件；若实验中发生无关事件，立即中止实验。
【反模式】发现无跟进：修复——每个混沌实验发现都创建工单，带 owner 和 due date；修复后重跑实验验证；把混沌发现 backlog 与生产事件行动项一起跟踪。
【验证】在 staging 注入并反转：对一个 staging 服务运行最低爆炸半径注入（`tc qdisc add dev eth0 root netem delay 200ms`），确认稳态仪表板移动，然后运行文档化回滚（`tc qdisc del dev eth0 root`）并确认指标回到基线；计时回滚，必须在其 stated window 内完成（低于 30s）。
【验证】触发自动中止：在连接到 AWS FIS CloudWatch stop-conditions、Gremlin Health Check 或 Litmus `promProbe` 的 `mode: Continuous` 的实验上，强制监控指标超过阈值（把错误率推过停止条件）；确认实验自行停止且无需人工；若没有触发，则中止路径未验证。
【验证】确认自清除超时：启动有界注入（`stress-ng --cpu 4 --timeout 60s`，或 Litmus `TOTAL_CHAOS_DURATION: '60'`），然后离开；确认故障在截止时间自行清除，即使无人中止。
【验证】确认发现循环关闭：staging 运行后确认生成发现文档，包含基线 vs 实际数字，并且每个缺口都变成有 owner 的跟踪工单；实验记录才是工件，不是注入本身。
【Done When】每个实验在注入任何故障前，都有书面假设（「We believe that if [failure X], the system will [expected behavior Y]」）记录在案。
【Done When】爆炸半径被明确限定——目标范围、持续时间、中止条件写入实验记录，并且任何生产实验前，至少有一次相同实验在 staging 通过。
【Done When】稳态快照（仪表板链接或实际基线指标值）附加到每个实验记录，在注入前立即捕获。
【Done When】每个实验都有发现文档，包含基线 vs 实际数字、恢复时间，以及显式数据完整性检查（丢失/损坏：是/否）。
【Done When】每个发现的弱点都有跟踪工单，带具名 owner、due date，并安排重跑同一实验验证修复。
【参考文件】`references/fault-injection.md` 包含可运行命令、配置和测试代码：`tc netem` 和 toxiproxy 网络故障，`kubectl`/LitmusChaos 服务故障（ChaosEngine 带 `engineState: active`），`fallocate`/`stress-ng` 基础设施故障，程序化 toxiproxy 依赖故障测试，自动中止/停止条件示例（AWS FIS、Gremlin、Litmus probes、Litmus MCP），以及 cron-gated 持续混沌 CI 任务。

适用边界 · 注意事项

不适用于发布期间的安全上线机制，如 feature flags、canary、dark launch；这些应改用 testing-in-production。
不适用于从生产遥测设计新测试；那是 observability-driven-testing 的输入，混沌工程用来验证或推翻假设。
不适用于系统已处于事件中或非稳态时；也不应在生产无明确批准、无监控、无回滚计划时运行。