第5章爆炸半径控制

限制实验的影响范围

章节导读

混沌工程有一个无法回避的悖论：为了发现真实故障下才会暴露的问题，实验必须足够「真」；但实验发生在生产系统上，任何失控都可能变成真实事故，伤害真实用户、损失真实收入、摧毁组织对混沌工程的信任。化解这个悖论的核心机制就是爆炸半径（blast radius）控制——这个词借自军事与爆破工程，指爆炸冲击波影响的最大范围。在混沌工程语境中，爆炸半径是实验在最坏情况下可能影响的边界：多少用户、多少请求、多少数据、多少收入、多长时间。原则五「最小化爆炸半径」的完整表述其实包含两层含义：一是把半径压到足够小，让实验的最坏结果也在可接受范围内；二是随着信心积累渐进扩大半径，因为小半径实验无法覆盖某些只在大范围下出现的问题（涌现行为、级联效应、容量临界）。爆炸半径控制不是「越小越好」的静态约束，而是「与信心匹配」的动态过程。

为什么爆炸半径控制如此关键？因为它决定了混沌工程在组织中的生死。一次失控的实验足以让管理层永久叫停整个项目——这不是假设，业界有真实案例：某公司团队在未充分评估的情况下对生产数据库注入 IO 延迟，触发主从复制积压与连接风暴，导致核心业务中断 40 分钟，事后混沌工程项目被冻结两年。相反，Netflix 之所以能在生产环境常态化运行数百个实验、甚至演练「干掉整个区域」，正是因为十年间建立了一套精密的爆炸半径控制体系：从 Chaos Monkey 的单实例开始，每一步扩大都建立在前一步数千次成功运行的统计信心上。爆炸半径控制是混沌工程获得「生产实验许可证」的技术基础，也是向管理层论证安全性的核心语言——当你说「这个实验最坏情况影响 0.5% 用户的支付功能 5 分钟，且成功率跌破红线 30 秒内自动中止」，与说「我们要在生产环境注入故障」，获得的审批结果完全不同。

爆炸半径的量化维度有五个。用户维度：多少用户可能受影响（绝对数与百分比）；请求维度：多少请求可能失败或劣化；功能维度：哪些功能可能受损（核心交易 vs 边缘功能）；数据维度：是否可能造成数据损坏或不一致（这是最危险的维度——服务中断可以恢复，数据损坏可能永久）；时间维度：影响可能持续多久（从故障注入到完全恢复的时间，包括检测延迟、中止延迟、恢复延迟）。完整的爆炸半径评估必须覆盖五个维度，尤其不能遗漏数据维度：杀 Pod 的实验数据风险为零（无状态服务），但数据库故障注入、消息队列实验、缓存一致性实验都可能触碰数据——对这类实验，半径控制的严格程度应当提高一个量级，且必须有数据备份与一致性校验预案。

控制手段的技术工具箱按粒度从细到粗排列。流量维度：按百分比随机分流（1% 请求承受故障）、按用户属性定向（内部员工账号、特定地域、特定客户端版本）、按请求特征过滤（特定 API 路径、特定 header 标记）。实例维度：单 Pod、单节点、特定标签的实例子集。区域维度：单可用区、单区域、特定边缘节点。功能维度：功能开关（feature flag）包裹实验影响面，可瞬间关闭。时间维度：低峰窗口执行、限制实验时长、设置自动恢复。这些手段可以组合出极其精细的半径控制：「工作日凌晨 2-4 点，对打了 canary 标记的 0.5% 流量，在单个 AZ 的 order-service 上注入依赖延迟，持续 5 分钟，成功率跌破动态红线连续 3 次即自动中止并回滚」——这样的实验描述里，每个短语都是一个半径控制维度。

中止条件（halt conditions）是爆炸半径的最后一道防线，它回答「实验失控时多快能停下来」。完整的中止体系包含三层：自动中止（护栏系统监测稳态指标，越界立即终止故障注入——响应时间秒级，是主力防线）、手动中止（实验负责人或值班工程师一键停止——用于自动护栏未覆盖的异常，如观察到未预期的行为）、超时中止（实验定义中的 duration 到期自动恢复——防止护栏与人工同时失效的极端情况，是兜底防线）。三层防线的独立性很重要：自动中止依赖监控系统，而监控系统本身可能受实验影响（注入的故障恰好打挂了 Prometheus 怎么办？）——因此超时中止必须独立于监控系统实现（工具内置的定时器），手动中止必须有独立于实验系统的通信通道。设计中止条件时的常见错误：阈值设置基于「实验前拍脑袋」而非历史波动数据（导致频繁误中止或永不中止）、只监控全局指标而实验只影响 1% 流量（全局指标对 1% 的劣化不敏感，中止条件形同虚设——正确做法是监控实验组切片指标）、中止后没有验证恢复（中止了故障注入，但系统需要时间排空积压、重建连接，「中止」不等于「恢复」）。

渐进式扩大（gradual rollout）是半径控制的动态策略。标准阶梯：开发环境 → 类生产的镜像环境 → 生产的 1% 流量 → 5% → 25% → 100%；实例维度：单实例 → 单 AZ 的部分实例 → 单 AZ 全部 → 多 AZ。每一级的晋升条件应当明确：当前级别连续 N 次实验通过（建议 N ≥ 10，覆盖不同时段的业务模式）、无未解释的异常、团队对结果的信心经评审确认。降级的触发同样明确：任何一次实验发现严重弱点或意外行为，立即回退到上一级，修复并复验后再重新晋升。这个「晋升-降级」机制把爆炸半径与团队信心绑定，让半径的扩大成为可审计的工程决策而非个人胆量的体现。Netflix 从 Chaos Monkey（单实例，2011）到 Chaos Gorilla（单 AZ，2014 前后）再到 Chaos Kong（单区域，2016 后常态化）用了五年多，每一步都有海量的小半径实验数据支撑——这种耐心正是成熟度的标志。

本章还将讨论生产实验的完整安全保障体系：实验前的评审与审批流程（谁有权批准什么半径的实验）、实验中的作战室机制（大半径实验需要实时值守）、实验后的恢复验证与报告。以及爆炸半径与实验价值的深层权衡：半径越小，实验越安全，但发现的问题越「温和」——某些系统性风险（全局配置错误、共享依赖失效、区域级故障）只有大半径实验才能验证，这就是为什么游戏日（第 8 章）作为「有计划、有值守、低频大半径」的演练形式不可替代。学完本章，你应当能够为任何实验设计出量化的爆炸半径评估、多层中止防线与渐进扩大计划——这是把混沌工程从「勇敢者的游戏」变成「可审批的工程实践」的关键一步。

核心概念

爆炸半径
中止条件
渐进式实验
安全保障

要点精析

爆炸半径的五维量化框架：用户、请求、功能、数据、时间。每个实验在设计阶段必须填写这五个维度的最坏情况估计，且估计要基于实测而非乐观假设。用户维度：1% 流量实验在日活 100 万的产品上影响 1 万用户——这个数字要让审批者直观感受；注意用户分布的不均匀性，如果实验定向在某地域，影响的是该地域的全部用户而非均匀散布。请求维度：结合实验时长计算总受影响请求数（1% 流量 × 5 分钟 × 800 RPS ≈ 2400 个请求），其中多少会失败、多少只是变慢。功能维度：明确列出受损功能清单——「支付功能降级为异步」与「全站不可用」是完全不同性质的半径，功能开关与依赖隔离决定了故障是否会被限制在单一功能内。数据维度：最危险的维度，评估三个问题——实验是否可能导致写入丢失（进程被杀时未刷盘的数据）？是否可能导致不一致（主从切换期间的双写）？是否可能导致损坏（文件系统故障注入）？无状态服务的实验数据半径为零，涉及存储的实验必须有备份与校验预案。时间维度：最坏情况的影响时长 = 故障检测时间 + 中止执行时间 + 系统恢复时间，三段都要实测——很多团队的「5 分钟实验」实际最坏影响时长是 25 分钟，因为检测靠人工巡检（10 分钟）、中止靠手动操作（5 分钟）、恢复要排空积压（10 分钟）。

流量百分比控制是小半径生产实验的核心技术，实现方式按架构层次分为三种。网关层分流：入口网关（Nginx/Envoy/API Gateway）按用户 ID 哈希或随机数为请求打实验标记，标记随调用链透传，混沌工具只对带标记的请求注入故障——优点是控制精确、与应用代码解耦，缺点是需要网关与追踪体系支持 header 透传。服务网格分流：Istio/Linkerd 的流量管理原生支持按权重分流与故障注入（Envoy 的 fault injection filter 可以在 mesh 层直接对特定比例的请求注入延迟/中止）——优点是零代码侵入、粒度到服务间调用，缺点是依赖 mesh 基础设施。应用层分流：应用代码或 SDK 根据配置决定哪些请求走「实验路径」——Netflix FIT 的方式，故障注入规则由中心服务下发，应用内嵌的注入点按流量标记生效——优点是能注入应用内部故障（特定方法抛异常），缺点是需要代码侵入。选择建议：有服务网格的团队优先用网格层（运维成本最低）；无网格但有统一网关的用网关层；需要方法级注入的用应用层 SDK。无论哪种方式，都要验证「标记透传的完整性」——如果标记在异步调用、消息队列、批处理任务中丢失，实验组与对照组的边界就模糊了，判定与半径控制同时失效。

中止条件的设计要点：灵敏度、特异性、独立性的三角平衡。灵敏度（不漏报）：真实的稳态破坏必须被捕获——要求中止条件监控的指标切片与实验影响面匹配：1% 流量的实验必须监控实验组切片指标而非全局指标（全局成功率对 1% 流量的完全失败只有 0.01 的敏感度，几乎不可见）；同时阈值要基于历史波动统计（3σ 或对照组差异）而非拍脑袋。特异性（不误报）：正常波动不应触发中止——每次误中止都在消耗团队对实验体系的信任，还浪费实验窗口；对策是连续越界计数（连续 3 次采样越界才中止）、对照组基线（排除全局性业务波动的干扰）、白名单窗口（已知的营销活动时段提高阈值或暂停实验）。独立性（防线不共 fate）：中止系统的各个组件不能共享故障域——护栏依赖 Prometheus，而实验可能影响 Prometheus（比如注入的故障打挂了监控组件的依赖）；对策：超时中止用混沌工具内置定时器（不依赖外部监控）、手动中止通道用独立通信（电话/短信而非依赖内部 IM）、护栏系统部署在与实验目标隔离的基础设施上。三者的权衡没有普适答案：高危实验（大半径、数据风险）偏向灵敏度（宁可误停），低危回归实验偏向特异性（减少打扰），所有实验都必须保证独立性底线。

渐进式扩大的晋升机制需要明确的量化标准，否则「渐进」会退化为「随意」。推荐的晋升规则模板：级别定义（L1 开发环境 / L2 镜像环境 / L3 生产 1% / L4 生产 10% / L5 生产全量小功能域 / L6 生产 AZ 级 / L7 生产区域级）；晋升条件（当前级别连续 10 次实验通过且覆盖至少一个完整业务周期——包含高峰与低谷、工作日与周末；无未解释异常；实验报告经评审）；降级触发（任何一次实验造成超出预期的影响、发现严重弱点、或护栏系统本身出现故障）；每级别的审批权限（L1-L2 团队自主、L3-L4 团队负责人 + SRE 代表、L5-L6 工程总监 + 值班经理、L7 高管层 + 完整游戏日流程）。两个实践细节：（1）「连续通过」中如果发现弱点并修复，计数是否重置？建议重置——修复改变了系统，之前的信心数据部分失效，需要重新积累；但同一弱点的修复验证实验可以直接在原级别运行。（2）不同变量类型独立晋升——网络延迟实验到了 L4 不代表杀实例实验也自动到 L4，每类变量的风险特征不同，晋升轨迹独立。Netflix 的五年演进（Monkey → Gorilla → Kong）本质上就是这个机制的宏观版本。

数据维度的爆炸半径需要专门的防护体系，因为数据损坏是唯一不可逆的实验风险。分级策略：（1）只读实验优先——大多数故障注入（延迟、错误、实例终止）不直接写坏数据，风险在于应用层的数据处理逻辑（重试导致重复写入、超时导致部分提交）；对这类实验，防护是幂等性验证：实验前确认目标写路径有幂等键，实验中监控重复数据指标，实验后运行一致性校验任务。（2）涉及存储层的实验（磁盘故障、数据库主从切换、缓存清空）必须有事前备份与恢复预案：备份的新鲜度要验证（备份任务是成功还是静默失败？）、恢复流程要演练过（恢复 1TB 数据需要多久？这个时间是否超过业务容忍度？）。（3）绝对禁区清单——某些实验在任何半径下都不做：对生产数据库注入写路径损坏（文件系统级 corruption）、清空未经确认有完整备份的存储、对账务/资金类数据的一致性做「破坏性验证」（用影子账本代替）。真实教训：某团队做「数据库磁盘满」实验时未注意从库复制也依赖同一存储集群，磁盘满导致主从同时不可写，备份比预期陈旧 6 小时——数据半径的评估必须包含「共享基础设施的隐式耦合」，这正是依赖图谱分析（第 4 章）的价值所在。

实验审批与授权体系：把半径控制从技术实践升级为组织制度。分级审批矩阵的核心思想是「审批严格度与爆炸半径成正比」：L1-L2 级实验（非生产环境）团队自主执行，只需在实验日历登记；L3-L4 级（生产小半径）需要二人评审——实验设计者 + 一名不熟悉该实验的工程师（新鲜眼睛发现设计盲区），评审检查单包括五维半径评估、中止条件、回滚预案、值守安排；L5 级以上需要跨团队审批——受影响的兄弟团队、值班经理、必要时管理层，大半径实验还应当提前公告（内部渠道通知「周三凌晨 2 点支付功能混沌实验，影响面 0.5%」），让客服与运营团队有预期。授权体系的另一个要素是「实验执照」：完成混沌工程培训、独立设计并通过评审 3 个 L3 实验的工程师获得 L4 设计资格，以此类推——把资格与经验绑定，防止新手直接操作大半径实验。审批不是官僚主义：它的价值除了风险控制，还有知识扩散——评审过程本身就是跨团队的混沌工程教育，被评审的实验设计成为组织的公共知识。警惕审批体系的两个退化形态：橡皮图章（评审走过场，没人真看设计）与过度审批（L2 实验也要总监签字，扼杀实践活力）——定期统计各级实验的审批时长与驳回率，保持制度的张力。

作战室（war room）机制是大半径实验的标配运行模式。触发条件：L5 级以上实验、任何涉及数据维度的实验、游戏日演练。角色配置：实验指挥官（experiment commander，唯一有权推进/中止实验的人，避免多头指挥）、故障注入操作员（执行注入与中止命令）、稳态观测员（盯业务指标仪表盘，实时播报）、系统观测员（盯组件指标与日志，负责根因线索）、值班联络人（与 on-call 体系对接，处理实验触发的真实告警）、记录员（时间线记录，为复盘提供素材）。运行流程：实验前 15 分钟集合，指挥官确认检查清单（护栏已启动、回滚已就绪、监控面板已打开、通信频道已建立）；实验中每 5 分钟观测员播报稳态状态（「实验组成功率 99.6%，对照组 99.7%，差异正常」）；任何异常按「播报 → 指挥官决策 → 执行」的单一指挥链处理；实验结束后不立即解散——恢复验证窗口（确认所有指标回归基线、无残留故障注入、无积压任务）完成后，指挥官宣布实验关闭。作战室的通信纪律：专用频道（Slack/电话桥）、实验相关通信加前缀标记、关键决策口头复述确认。这套机制看似 heavyweight，但它同时是训练：值班工程师在作战室里第一次见到「数据库主从切换时指标的真实形态」，这种经验在真实故障时价值千金——大半径实验的组织韧性收益常常超过系统韧性收益。

回滚与恢复预案：中止实验不等于系统恢复，恢复路径本身需要设计与验证。恢复的三个层次：（1）故障注入的停止——删除混沌资源、关闭注入开关，这是秒级操作，但要注意「注入停止的完整性」：分布式注入（多个节点上的 chaos daemon）是否有部分失败？残留的 tc 规则、iptables 规则、代理配置要能被巡检脚本发现并清理。（2）系统状态的恢复——故障期间积累的状态需要排空：重试队列的积压消息、断开连接的重新建立、缓存的重新预热、熔断器从打开到半开再到关闭的周期。这个阶段的时长经常被严重低估：5 分钟的缓存失效实验，恢复期可能长达 30 分钟（缓存重建期间数据库承受穿透压力，如果重建逻辑有惊群问题，恢复期本身可能引发二次故障）。（3）数据一致性的修复——如果实验触发了不一致（部分提交、重复写入），需要明确修复手段：自动对账任务、人工修复流程、或「可接受的最终一致」的等待窗口。预案的验证方式：每次实验的恢复观察窗口纳入实验报告（恢复用了多久？与预期一致吗？）；每季度做一次「恢复失败演练」——假设自动恢复失效，人工执行完整恢复流程，计时并找出卡点。恢复预案的质量是爆炸半径评估中「时间维度」的决定因素：最坏影响时长 = 检测 + 中止 + 恢复，第三段往往最长。

爆炸半径与实验价值的权衡曲线：半径不是越小越好，而是「与目标风险匹配」。小半径实验（1% 流量、单实例）能验证的：单点依赖的存在性、错误处理路径的正确性、超时与重试配置的合理性、优雅降级的行为。小半径实验验证不了的：涌现行为（重试风暴需要足够多的客户端同时重试才会出现——1% 流量可能低于风暴的临界密度）、级联效应（上游的容量冗余在小流量下永远够用）、共享资源的竞争（连接池、线程池在 1% 负载下毫无压力）、区域级故障的真实形态（AZ 失效不只是「一半实例没了」，还包括流量转移引发的容量问题、跨 AZ 依赖的延迟变化）。因此完整的实验组合是金字塔结构：底座是高频小半径的自动化回归实验（每日运行，验证已知韧性属性不回归）；中层是定期中半径的定向实验（每周/每月，验证特定风险场景）；顶层是低频大半径的游戏日演练（每季度，验证系统级与组织级的承受力）。三层各自回答不同的问题，用同一套稳态假设与变量库，但审批流程、值守强度、中止阈值逐级严格。评估你的实验组合：如果只有底座，你对系统性风险是盲的；如果只有顶层，你的知识衰减速度超过验证频率。

共享基础设施的隐式爆炸半径：实验目标之外的「连带影响面」是半径评估最容易遗漏的部分。你的实验定向在 order-service 的 1% 流量上，但 order-service 与另外 30 个服务共享同一个 Kubernetes 集群、同一套 CoreDNS、同一个 Prometheus、同一条网络骨干、同一个云账号的 API 配额。故障注入可能通过共享层扩散：杀 Pod 实验触发大量 Pod 重建，消耗集群的调度与镜像拉取带宽，拖慢其他团队的部署；网络延迟实验打满节点的 conntrack 表，影响同节点所有容器；压力实验耗尽云账号的 API 配额，让其他团队的自动化任务失败。评估方法：（1）基础设施依赖图谱——不仅画应用依赖，还要画「应用 → 共享基础设施」的依赖，标注每个共享层的容量与隔离机制（namespace quota、node selector、资源 limit）；（2）历史事故学习——检索业界因共享层引发的实验/测试事故（Kubernetes 社区有大量「一个 namespace 打挂整个集群」的案例）；（3）预实验影响面扫描——实验设计评审时的固定问题：「这个实验会消耗哪些共享资源？峰值消耗多少？其他租户的余量够吗？」。防护手段：资源配额隔离（实验 namespace 有独立的 resource quota）、节点隔离（大半径实验定向到专用节点池）、时间隔离（共享资源紧张时段避开实验）、以及最重要的——把共享层本身纳入实验变量（CoreDNS 挂了会怎样？这个问题迟早要回答，与其被动回答不如主动实验）。

常见误区清单：爆炸半径控制的八个失败模式。（1）乐观估计——「这个实验最多影响几个请求」基于对系统行为的假设，而实验的目的恰恰是检验假设；对策：最坏情况估计用「故障完全生效 + 护栏完全失效」的双重悲观假设。（2）全局指标监控小实验——1% 流量的实验用全局成功率做中止条件，灵敏度不足；对策：中止条件必须监控实验组切片。（3）护栏与被试系统共 fate——护栏依赖的监控链路与实验目标共享基础设施；对策：护栏独立性检查纳入评审清单。（4）忘记恢复期——实验 duration 5 分钟，宣布「影响时长 5 分钟」，实际恢复用了 40 分钟；对策：影响时长 = 注入 + 检测 + 中止 + 恢复，四段实测。（5）半径 creep——「上次 1% 没问题，这次直接 20% 吧」跳过渐进阶梯；对策：晋升规则量化，破例需要显式审批记录。（6）只控流量不控数据——流量半径 1% 但实验触发的数据写入影响 100% 的用户（如缓存清空）；对策：数据维度独立评估。（7）低峰期迷信——「凌晨做实验影响小」，但凌晨值班力量也最弱、且批处理任务在跑，故障叠加批处理可能更糟；对策：时间窗选择综合考虑流量、值守、批任务三因素。（8）中止后不复盘误报——频繁误中止被当作「护栏灵敏」而不调整；对策：误中止率纳入实验体系的健康度指标。

代码示例

/* 示例 1：五维爆炸半径评估表——实验设计文档的必备章节 */
/* blast-radius-assessment.md（实验：payment-service 依赖延迟注入） */

| 维度 | 最坏情况估计 | 估计依据 | 缓解措施 |
|------|-------------|---------|---------|
| 用户 | ≤ 5,000 用户（0.5% 日活） | canary 分流按 user_id 哈希 0.5% | 分流在网关层，可秒级归零 |
| 请求 | ≤ 12,000 请求受影响，其中约 3,600 失败 | 0.5% × 400 RPS × 60s × 30% 失败率 | duration 60s 硬上限 + 护栏提前中止 |
| 功能 | 仅「即时支付」降级为「排队支付」，浏览/下单/查询不受影响 | 支付路径有独立线程池（ENG-4521 修复后） | 功能开关 pay-async-fallback 已就绪 |
| 数据 | 无数据损坏风险；可能产生 ≤ 3,600 条待对账的异步支付记录 | 支付写入有幂等键，异步队列持久化 | 实验后运行对账任务 verify-payment-consistency |
| 时间 | 最坏 4 分 30 秒 = 检测 30s + 中止 10s + 恢复排空 3m30s | 护栏采样 10s×3 次；恢复时长来自 6 月实验实测 | 超时中止 60s 独立于护栏；作战室值守 |

/* 综合评级：L3（生产小半径），审批要求：二人评审 + 实验日历登记 */

这份评估表展示了爆炸半径量化的完整形态，每个数字都有依据、每个风险都有缓解。几个值得学习的细节：请求维度的计算链条（0.5% × 400 RPS × 60s × 30%）把「大概影响一些请求」变成了可审计的算术，其中 30% 失败率来自故障参数（toxicity 0.3）——半径估计必须与实验参数联动，改参数就要重算半径。功能维度引用了具体的修复工单（ENG-4521）作为「独立线程池存在」的证据——功能隔离的声明要有出处，不能凭印象。数据维度区分了「损坏」（不可逆，零容忍）与「待对账记录」（可逆，有修复手段）——这种区分让审批者能理性决策而非一律拒绝。时间维度的恢复时长来自历史实验实测而非猜测，并诚实标注了数据来源。综合评级 L3 直接映射到审批流程，评估表成为审批的输入而非事后补的文档。建议把这个表格做成实验设计模板的强制章节：没有填写完整的五维评估，实验不允许进入评审——制度化的强制是半径控制文化落地的最快路径。

/* 示例 2：Envoy 服务网格层的精细故障注入——按流量百分比控制半径 */
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: payment-service-chaos
spec:
  hosts: [payment-service.production.svc.cluster.local]
  http:
    /* 规则 1：带实验标记的请求，30% 注入 3 秒延迟，10% 直接中止 */
    - match:
        - headers:
            x-chaos-experiment:
              exact: "payment-slow-2024q4"
      route:
        - destination: { host: payment-service }
      fault:
        delay:
          percentage: { value: 30 }
          fixedDelay: 3s
        abort:
          percentage: { value: 10 }
          httpStatus: 503
    /* 规则 2：无标记请求完全不受影响——这就是半径边界 */
    - route:
        - destination: { host: payment-service }
---
/* 配合网关侧打标：0.5% 用户获得实验标记 */
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ingress-canary-tagging
spec:
  hosts: [shop.example.com]
  gateways: [mesh]
  http:
    - match:
        - headers:
            x-user-bucket:
              regex: "^[0-7]$"     /* user_id 哈希 16 桶中的 0 号桶 ≈ 0.5% 流量 */
      headers:
        request:
          set:
            x-chaos-experiment: "payment-slow-2024q4"
      route:
        - destination: { host: frontend }

这组 Istio VirtualService 配置实现了「标记分流 + 定向注入」的两段式半径控制，是服务网格环境下小半径生产实验的标准方案。第一段（ingress-canary-tagging）在入口层给 0.5% 的用户打实验标记：x-user-bucket 是网关根据 user_id 哈希计算的桶号（0-15），只有 0 号桶的请求被加上 x-chaos-experiment 头。第二段（payment-service-chaos）在目标服务入口按标记匹配：带标记的请求 30% 遭遇 3 秒延迟、10% 遭遇 503 中止、60% 正常；不带标记的请求走完全正常的路由。两段组合的净效果：全站 0.5% 用户中的一部分请求经历支付劣化——爆炸半径被精确锁定。这个方案的优势：（1）零代码侵入——应用完全不知道实验存在，注入与分流都在网格层完成；（2）半径的实时可调——把 regex 从 ^[0-7]$ 改成 ^[0-3]$ 就把半径减半，改配置即生效，这是「中止」之外的第二层控制（降级而非停止）；（3）标记透传依赖分布式追踪的 header 传播机制，实验组流量在追踪系统中天然可识别，观测与判定都有了切片依据。注意事项：header 匹配要求标记在整条调用链中透传，异步路径（消息队列）会丢失标记——涉及异步的实验需要额外的标记传递机制。

/* 示例 3：三层独立中止防线的完整实现 */
/* 防线 1：自动护栏（独立部署的守护进程，监控实验组切片指标） */
apiVersion: apps/v1
kind: Deployment
metadata:
  name: chaos-halt-guard
  namespace: chaos-control-plane   /* 与实验目标隔离的命名空间与节点池 */
spec:
  replicas: 2
  template:
    spec:
      nodeSelector: { pool: control-plane }   /* 不与业务共享节点 */
      containers:
        - name: guard
          image: registry.internal/chaos-halt-guard:v2
          env:
            - name: WATCH_QUERY
              value: "orders:success_rate:canary_5m < (orders:success_rate:control_5m * 0.98)"
            - name: HALT_ACTION
              value: "kubectl delete virtualservice payment-service-chaos -n production"
            - name: CONSECUTIVE_BREACHES
              value: "3"
---
/* 防线 2：工具内置超时（不依赖任何外部系统） */
/* VirtualService 实验通过 Chaos Mesh Schedule 包装，强制 maxDuration */
apiVersion: chaos-mesh.org/v1alpha1
kind: Schedule
metadata:
  name: payment-chaos-with-deadline
spec:
  schedule: "0 2 * * 3"          /* 每周三凌晨 2 点 */
  concurrencyPolicy: Forbid
  historyLimit: 10
  type: NetworkChaos
  networkChaos:
    duration: "60s"              /* 硬上限：60 秒后注入自动失效，即使护栏与人工都失灵 */
---
/* 防线 3：手动急停（独立通信通道的一键脚本，值班手机可触发） */
/* emergency-stop.sh - 通过带外管理通道执行，不依赖集群内网络 */
/* 触发方式：PagerDuty 按钮 → webhook → 堡垒机执行 */

这个配置展示了中止防线的「独立性工程」：三层防线部署在三个不同的故障域，任何单点失效都有下一层兜底。防线 1（自动护栏）的关键设计是隔离部署：chaos-halt-guard 运行在专用控制面节点池，与实验目标不共享节点、不共享命名空间——如果实验注入的故障打挂了业务节点，护栏依然存活。它监控的是实验组切片指标（canary_5m 对比 control_5m 的相对下跌 2%），而非全局指标，保证对 0.5% 流量实验的灵敏度。HALT_ACTION 直接删除 VirtualService——移除注入规则比「暂停」更彻底，且删除操作幂等。防线 2（工具内置超时）是纯本地机制：duration: 60s 由 Chaos Mesh 控制器执行，不依赖 Prometheus、不依赖护栏进程——即使整个监控系统瘫痪，60 秒后注入必然失效。Schedule 的 concurrencyPolicy: Forbid 防止上次实验未结束又启动新实验的叠加风险。防线 3（手动急停）走完全独立的通道：PagerDuty 按钮 → webhook → 堡垒机 → kubectl，这条链路不经过集群内网络与内部 IM——当实验把内部通信系统打挂时（真实发生过），带外通道是最后的手段。三层防线的响应时间分别是 30 秒（3 次采样）、60 秒（硬超时）、人工判断时间——设计实验时把这三个数字填入五维评估表的时间维度。

/* 示例 4：渐进扩大的自动化门禁——晋升条件代码化 */
/* promotion-gate.py - 检查实验是否满足从 L3 晋升到 L4 的条件 */
import json
from datetime import datetime, timedelta

REQUIRED_CONSECUTIVE_PASSES = 10
REQUIRED_COVERAGE = {"peak_hours": 3, "off_peak_hours": 3, "weekend": 2}

def load_experiment_history(experiment_family):
    with open(f"reports/{experiment_family}/history.json") as f:
        return json.load(f)

def check_promotion(experiment_family, current_level, target_level):
    history = load_experiment_history(experiment_family)
    recent = [e for e in history if e["level"] == current_level]

    /* 条件 1：最近 N 次连续通过（发现弱点后计数重置） */
    consecutive = 0
    for e in reversed(recent):
        if e["verdict"] == "pass":
            consecutive += 1
        else:
            break
    if consecutive < REQUIRED_CONSECUTIVE_PASSES:
        return False, f"连续通过 {consecutive}/{REQUIRED_CONSECUTIVE_PASSES} 次"

    /* 条件 2：覆盖完整业务周期（高峰/低谷/周末） */
    coverage = {"peak_hours": 0, "off_peak_hours": 0, "weekend": 0}
    for e in recent[-REQUIRED_CONSECUTIVE_PASSES:]:
        ts = datetime.fromisoformat(e["timestamp"])
        if ts.weekday() >= 5:
            coverage["weekend"] += 1
        elif 10 <= ts.hour <= 22:
            coverage["peak_hours"] += 1
        else:
            coverage["off_peak_hours"] += 1
    for k, v in REQUIRED_COVERAGE.items():
        if coverage[k] < v:
            return False, f"业务周期覆盖不足：{k} {coverage[k]}/{v}"

    /* 条件 3：无未解释异常 */
    unexplained = [e for e in recent[-REQUIRED_CONSECUTIVE_PASSES:] if e.get("unexplained_anomaly")]
    if unexplained:
        return False, f"存在 {len(unexplained)} 次未解释异常"

    return True, "满足晋升条件，提交 L4 审批流程"

这个脚本把「渐进扩大」从口头约定变成可执行的门禁，解决半径 creep（随意跳级）问题的工程化方案。三个晋升条件的设计逻辑：条件 1（连续 10 次通过）用「连续」而非「累计」——中途任何一次失败（发现弱点或误判）都重置计数，因为失败意味着系统或实验设计发生了变化，之前的信心数据部分失效；10 次的量级来自统计直觉：如果实验有 20% 的随机失败概率，连续 10 次通过的概率只有 11%，足以过滤「碰巧通过」。条件 2（业务周期覆盖）防止「只在舒适时段实验」的偏差——凌晨低峰的 10 次通过不能证明高峰期安全，周末的流量模式（爬虫比例、批任务、值守强度）与工作日不同，覆盖要求强制实验样本的多样性。条件 3（无未解释异常）是最容易被忽视也最重要的一条：实验「通过」但过程中出现了没人能解释的指标抖动，这种「通过的实验」可能掩盖着未被理解的系统行为——门禁强制要求所有异常有归因结论才能晋升。脚本输出的失败原因是具体数字（「连续通过 6/10 次」），让团队清楚知道距离晋升还差什么。把这个门禁集成到实验平台：晋升申请自动运行检查，不满足直接驳回，满足则进入人工审批——机器管客观条件，人管风险判断。

/* 示例 5：恢复验证清单——实验结束后的强制检查 */
#!/bin/bash
/* post-experiment-verification.sh - 中止/结束后运行，全部通过才能关闭实验 */
set -e
NS="production"
echo "=== 1. 故障注入残留检查 ==="
kubectl get networkchaos,podchaos,httpchaos,dnschaos,timechaos -A --no-headers 2>/dev/null | grep -v "chaos-testing" && {
  echo "[FAIL] 发现生产命名空间外的残留混沌资源"; exit 1; } || echo "[OK] 无残留混沌资源"

/* 检查节点上的 tc 规则残留（手动实验的常见遗留） */
for node in $(kubectl get nodes -o name); do
  kubectl debug $node -it --image=alpine -- nsenter -t 1 -n tc qdisc show dev eth0 | grep netem && {
    echo "[FAIL] $node 存在残留 netem 规则"; exit 1; }
done
echo "[OK] 无 tc 规则残留"

echo "=== 2. 稳态回归检查 ==="
VIOLATED=$(curl -s "http://prometheus:9090/api/v1/query?query=orders:steady_state:violated" | jq '.data.result | length')
[ "$VIOLATED" = "0" ] && echo "[OK] 稳态已回归" || { echo "[FAIL] 稳态仍偏离"; exit 1; }

echo "=== 3. 积压排空检查 ==="
QUEUE_DEPTH=$(curl -s "http://prometheus:9090/api/v1/query?query=payment_retry_queue_depth" | jq -r '.data.result[0].value[1]')
[ $(echo "$QUEUE_DEPTH < 100" | bc) -eq 1 ] && echo "[OK] 重试队列已排空（深度 $QUEUE_DEPTH）" || { echo "[WARN] 队列仍有积压 $QUEUE_DEPTH，继续观察"; }

echo "=== 4. 数据一致性校验 ==="
kubectl create job payment-consistency-check-$(date +%s) --from=cronjob/payment-consistency-check -n production
echo "[OK] 对账任务已触发，结果将推送至 #chaos-reports"

echo "=== 5. Pod/实例健康检查 ==="
NOT_READY=$(kubectl get pods -n $NS --no-headers | grep -cv "Running|Completed" || true)
[ "$NOT_READY" = "0" ] && echo "[OK] 全部实例健康" || { echo "[FAIL] $NOT_READY 个实例异常"; exit 1; }

这个恢复验证脚本对应爆炸半径「时间维度」中最被低估的环节：实验结束后的恢复确认。五项检查覆盖了恢复的三个层次。第一层（注入残留）：混沌资源的声明式清理通常可靠，但手动实验的 tc/iptables 规则、sidecar 代理的配置变更容易遗留——脚本同时检查声明式资源与节点级规则，任何残留都是「实验还在继续」的隐患。第二层（稳态回归 + 积压排空）：稳态指标回归基线只说明「当前正常」，重试队列深度检查揭示「恢复过程是否完成」——故障期间积压的重试、消息、异步任务需要时间排空，排空期间的系统仍处于脆弱状态（数据库承受补偿写入压力），此时启动下一个实验是危险的。第三层（数据一致性 + 实例健康）：对账任务用 Kubernetes Job 从既有 CronJob 模板创建，实验触发的异步支付记录与账务系统核对——这是数据维度半径的闭环验证。脚本的退出码设计（set -e + 显式 exit 1）让它可以直接嵌入实验平台的关闭流程：验证不通过，实验状态停留在「恢复中」，作战室不解散。建议把每次运行的输出归档到实验报告——恢复时长的实测数据积累起来，就是五维评估表中时间维度的依据来源。

/* 示例 6：实验日历与冲突检测——组织级的半径协调 */
/* experiment-calendar.yaml - 全组织实验登记（GitOps 管理） */
experiments:
  - id: EXP-2024-1120-01
    team: payments
    window: "2024-11-20T02:00:00+08:00/PT30M"
    level: L3
    target: payment-service
    shared_resources: ["prometheus-main", "istio-ingress"]
    blast_radius: { users_pct: 0.5, functions: ["instant-payment"] }
  - id: EXP-2024-1120-02
    team: infra
    window: "2024-11-20T02:15:00+08:00/PT20M"
    level: L4
    target: coredns
    shared_resources: ["prometheus-main", "coredns-cluster"]
    blast_radius: { users_pct: 5, functions: ["all-dns-resolution"] }

/* conflict-detector.py 核心逻辑 */
/* 规则 1：时间窗重叠 + 共享资源交集非空 → 冲突（上例中两个实验共享 prometheus-main 且时间重叠 15 分钟） */
/* 规则 2：同一功能域的实验时间窗重叠 → 冲突（判定污染：无法区分两个实验的效应） */
/* 规则 3：L5+ 实验窗口内禁止任何其他实验 → 独占（大半径实验需要干净的观测环境） */
/* 规则 4：实验窗口与冻结期（大促、重大发布）重叠 → 拒绝 */

这个实验日历系统解决的是「多团队并行实验」时代的半径协调问题——当组织里只有一支团队做混沌时不需要它，当五支团队都在做时没有它就是灾难。冲突检测的四条规则各有针对性：规则 1（共享资源冲突）防止实验间的物理干扰——两个实验同时给 Prometheus 增加查询负载可能导致监控系统本身劣化，进而让两个实验的护栏同时失灵；更隐蔽的是判定污染：CoreDNS 实验引发的指标异常会被支付实验的护栏误捕获，触发误中止，或者反过来掩盖真实问题。规则 2（功能域冲突）保证因果归因的清晰性——同一时间同一功能上跑两个实验，出了任何异常都无法确定是谁的效应。规则 3（大半径独占）体现「观测环境洁净度」要求：L5+ 实验的作战室需要解读复杂的指标形态，背景里其他实验的噪音会显著增加误判风险。规则 4（冻结期）对接组织的变更管理制度。实现上采用 GitOps：实验申请以 YAML PR 提交，冲突检测作为 CI 检查自动运行，冲突则 PR 无法合并——协调成本被自动化，日历本身成为可审计的实验历史。这个系统的副产品是组织级的实验节奏可视化：管理层能看到混沌工程的覆盖面与频率，团队能避开彼此的窗口，实验知识（谁在什么目标上做过什么）自然沉淀。

实验笔记

【实验目标】为一个真实感的实验场景完成爆炸半径控制的全套工程实践：五维评估、分流实现、三层中止防线、恢复验证、渐进晋升计划。演练在镜像环境进行，但所有产物按生产标准制作——半径控制的能力只能在「像真的一样」的演练中建立。

【环境准备】Kubernetes 集群（3 节点以上，其中一个节点打 pool: control-plane 标签模拟隔离节点池）+ Online Boutique + Prometheus/Grafana + Chaos Mesh + Istio（或 nginx ingress 模拟网关分流）。准备第 3 章的稳态假设体系与第 4 章的变量库。为 checkoutservice 配置一个功能开关（可用简单的环境变量 + 代码分支模拟「降级为异步下单」）。

【演练步骤】第一步（45 分钟），五维评估：选择变量「checkoutservice 依赖的 paymentservice 慢响应（3s 延迟 + 10% 超时）」，按示例 1 的表格完成五维爆炸半径评估——所有数字要有计算过程或实测依据，禁止拍脑袋；给出综合评级与所需审批级别。第二步（60 分钟），分流实现：配置网关层分流，把 5% 流量打上 x-chaos-experiment 标记（演示环境可以放大到 5%，生产建议 0.5%）；用 Istio VirtualService 或 Chaos Mesh HTTPChaos 实现「仅对带标记请求注入延迟」；验证分流正确性——用 curl 带/不带标记 header 各请求 10 次，确认只有带标记的请求变慢。第三步（60 分钟），三层防线：部署自动护栏（监控实验组切片成功率，相对对照组下跌 2% 连续 3 次即删除注入资源，部署在 control-plane 节点）；配置工具内置 duration 硬上限；编写手动急停脚本并实际演练一次「从发现异常到注入停止」的完整操作，计时。第四步（45 分钟），运行实验：启动负载（k6 恒定 200 RPS），执行注入，作战室模式运行——一人指挥、一人盯稳态面板、一人盯系统面板、一人记录时间线；实验 5 分钟后手动中止或等待自动结束。第五步（45 分钟），恢复验证：运行示例 5 的验证脚本，记录每项检查结果与总恢复时长；把实测恢复时长回填到五维评估表，对比事前估计的偏差并分析原因。第六步（30 分钟），晋升计划：参照示例 4 的门禁逻辑，为这个实验家族写出从当前级别到 L5 的晋升路线图——每级的半径参数、晋升条件、预计时间线。

【预期结果】完整的实验档案：五维评估表（含实测修正）、分流与注入配置（Git 管理）、护栏部署清单、作战室时间线记录、恢复验证报告、晋升路线图。验收标准：把档案交给一个不了解背景的工程师，他能独立复现整个实验并安全中止。

【进阶挑战】（1）护栏失灵演练：故意停掉护栏进程，验证工具内置超时是否兜底；再模拟「监控数据断流」（停掉 Prometheus 的一个 target），观察护栏的行为——它会误判还是失效？（2）半径动态调整：实验运行中把分流从 5% 降到 1%（改配置热生效），观察指标切片的响应，体验「降级而非停止」的控制手段。（3）共享资源冲突分析：为你的集群画出「实验目标 → 共享基础设施」图谱，找出三个潜在的隐式半径扩散路径，各设计一个探测实验。（4）恢复期二次故障实验：在缓存清空实验的恢复期（缓存重建、数据库压力高峰）注入第二个故障，验证「恢复期脆弱窗口」的真实风险——这是复合故障与半径控制的交叉地带，务必在镜像环境进行。（5）把冲突检测规则（示例 6）实现为可运行脚本，对一份包含 5 个实验的模拟日历做冲突分析。

第5章 爆炸半径控制