混沌工程平台化与持续验证

• 故障注入类别的风险排序
• 风险排序的依据（影响范围、可逆性）
• 沉淀为可复用故障库

混沌实验的故障注入类别按「风险从小到大」排序，便于「先低风险后高风险」渐进验证。常见排序：① 进程故障（kill 进程）——风险低，影响单实例，可逆（可重启）；② 内存/CPU 压力——风险中低，影响性能，可逆（停止压力）；③ 网络故障（延迟、丢包）——风险中，影响范围较大，可逆（移除故障）；④ 磁盘故障（磁盘满、IO 延迟）——风险中高，可能影响数据，部分可逆；⑤ 时钟故障（时间偏移）——风险中高，影响依赖时间的逻辑，较难立即恢复；⑥ 状态损坏（数据损坏、状态异常）——风险最高，可能造成数据丢失，最难恢复。风险排序依据：① 影响范围（单实例 vs 全局）；② 可逆性（能否快速恢复）；③ 数据/状态影响（是否损坏数据）；④ 恢复复杂度。沉淀故障库：把「验证过的、参数化的故障实验」沉淀为「可复用故障库」（如 Chaos Hub、Litmus 实验模板），按「风险等级」分类，标注「触发条件、参数、影响、回滚」，供团队按需复用。故障库让「实验标准化、可复用、风险可控」。

故障注入有风险梯度——进程故障低危、数据/状态损坏高危。排序依据「影响范围、可逆性、数据影响」。沉淀故障库按「风险分级 + 参数化」复用，是「平台化混沌工程」的基础。

• 生产混沌实验的审批与窗口
• 止血自动化（自动回滚、阈值中止、人工停止）
• 止血的三层保障

生产环境混沌实验是「高风险」操作，需「审批 + 窗口 + 止血自动化」三层保障。① 审批——实验发起需审批（发起人、审批人、风险确认），审批留痕；② 窗口——选择「低峰期/维护窗口」执行，避开业务高峰；③ 止血自动化——① 自动回滚：实验故障自动回滚（如实验超时自动移除故障、恢复到基线）；② 监控阈值触发中止（halt）：实验期间实时监控稳态指标（错误率、延迟、SLO 预算），一旦超过「安全阈值」自动中止实验并恢复；③ 人工紧急停止：预留「一键停止」通道，值班/IC 可随时人工终止实验。落地：混沌平台（Chaos Mesh/Litmus/Gremlin）集成「审批流 + 时间窗口 + 监控门禁 + halt 机制」；实验录制「稳态基线」，止血时「恢复基线」。止血自动化是「生产混沌实验的安全底线」——保证「验证韧性」但不「造成事故」。三层保障「自动回滚、阈值中止、人工停止」构成「止血安全网」。

生产混沌实验的关键是「审批控制入口 + 窗口控制时机 + 三层止血兜底」。止血自动化（自动回滚、阈值中止、人工停止）是「安全底线」，保证「实验可控、可停、可恢复」。这是「生产混沌工程」与「破坏」的区别。

• 稳态假设的量化（SLO/SLI 探针）
• 实验期间实时指标对比
• 自动判定实验通过/失败

稳态假设是混沌实验的「判定基准」，需量化并自动化校验。① 稳态假设量化——把「系统正常」表达为「可量化的 SLO/SLI 探针」：如「错误率 < 0.1%」「P95 延迟 < 500ms」「可用性 > 99.9%」，作为实验的「预期基准」；② 探针设计——建立「探针（probe）」持续采集稳态指标，探针定义「阈值与判定条件」（如错误率探针、延迟探针、可用性探针）；③ 实验期间实时对比——实验期间「实时采集指标」与「稳态基线」对比，观察「指标是否偏离预期」；④ 自动判定——实验结束后，根据「探针结果」自动判定「通过/失败」：若探针显示「系统在故障下仍守住稳态（如错误率未超阈值、可用性达标）」→ 实验通过（Pass）；若「系统偏离稳态（如错误率飙升、SLO 跌破）」→ 实验失败（Fail），暴露弱点。落地：Litmus 的「probe」机制、Chaos Mesh 的「稳态检查」、Gremlin 的「check」都支持「自动化探针 + 判定」。核心是「用探针量化稳态，自动判定系统韧性」。

稳态假设校验的核心是「把系统正常量化为 SLO/SLI 探针，实验期间实时对比，自动判定通过/失败」。探针定义「阈值」，判定「系统是否守住稳态」。这使混沌实验「可量化、可自动化、可判定」，而非「主观观察」。

• 混沌工程成熟度的度量维度
• 各指标的含义
• 用指标驱动成熟度提升

混沌工程成熟度用「多维度指标」度量，反映「实验的深度与广度」。指标：① 实验覆盖率——已验证「故障模式/关键路径」占「全部关键故障模式」的比例；覆盖率越高，说明「系统弱点被验证得越全面」；② 已验证故障模式数——已通过混沌实验验证的故障模式数量，反映「验证广度」；③ MTTR 改善——混沌实验发现并修复弱点后，MTTR 是否下降，反映「混沌工程对可靠性提升的实际贡献」；④ 实验频率——每周/每月实验次数，反映「持续验证」的活跃度；⑤ 团队参与度——参与混沌实验的团队/人员比例，反映「文化渗透」；⑥ 通过率——实验「通过（系统守住稳态）」的比例，反映「系统韧性提升」。用这些指标「驱动成熟度提升」：覆盖率低 → 增加关键路径实验；MTTR 改善小 → 关注弱点修复；参与度低 → 加强文化推广。成熟度度量让「混沌工程」从「活动」变为「可量化的可靠性工程」。

成熟度度量是多维的——覆盖率反映「广度」、故障模式数反映「验证」、MTTR 反映「价值」、频率反映「持续」、参与度反映「文化」。指标驱动「扩大覆盖、提升价值、加深文化」，是「混沌工程平台化」的评估。

• 混沌实验作为发布门禁的意义
• 与 Litmus/Argo Workflows 的集成
• 实验失败时阻断流水线

把混沌实验嵌入 CI/CD 作为发布门禁，让「新版本在发布前通过韧性验证」，防止「发布弱化系统韧性」。集成方式：① Litmus——用 Litmus 的 CLI/litmusctl 或 Helm chart 在流水线中运行混沌实验，通过「ChaosResult 的 verdict」判断是否通过；② Argo Workflows——用 Argo 编排「混沌实验 + 稳态检查」步骤，把混沌实验作为工作流中的「门禁步骤」；③ CI 集成——在 GitLab CI/GitHub Actions 中调用「混沌实验」job，传入目标版本，执行后检查结果。阻断策略：① 实验失败（verdict=Fail 或探针未通过）→ 流水线阻断（exit 非零、中止发布）；② 稳态未达标 → 阻断并报警；③ 设计「异常恢复」——实验失败时自动回滚/中止；④ 门禁位置——在「发布前」执行，验证「新版本在故障下的韧性」；失败的阻断让「弱版本无法发布」。落地：流水线中「先跑混沌实验 → 验证 → 通过才继续发布」，把「韧性验证」变成「强制门禁」。

混沌实验作发布门禁的意义是「把韧性验证前置到发布前」。集成靠「Litmus/Argo/CI 调用混沌实验 + 检查 verdict」，失败时「阻断流水线」。这让「新版本通过韧性验证」成为「发布的前提条件」。

• 实验即代码的概念（CRD 声明式）
• Git 存储与版本管理
• 代码评审与变更审批

实验即代码（Experiment as Code）把混沌实验「声明式定义、纳入版本管理」，像代码一样管理。① CRD 定义——用 Kubernetes CRD（Chaos Mesh/Litmus 的 YAML）声明实验（目标、故障、参数、探针），实现「声明式、可复现」；② Git 存储——实验 YAML 存入 Git 仓库，纳入版本控制，可追溯、可回滚、可审计；③ 代码评审——实验变更走「代码评审」（PR 评审），由相关专家评审「故障类型、参数、影响范围、探针设置」是否合理；④ 变更审批——实验「创建/修改」需审批（尤其生产环境），审批留痕；⑤ 自动化——CI 校验实验 YAML 合法性，实验「纳入 GitOps」由 operator 自动部署。价值：① 实验「可复现、可追溯」——每次实验有版本记录；② 实验「可评审、可审批」——风险可控；③ 实验「可共享、可审计」——满足合规。落地：用「Git 仓库 + PR 评审 + 审批流」管理实验，实验变更像代码变更一样「评审、审批、留痕」。实验即代码是「混沌工程平台化」的核心实践。

实验即代码的核心是「CRD 声明式 + Git 版本管理 + 评审审批」。它把实验「像代码一样」管理——可复现、可评审、可审计、可回滚。这是「混沌工程规范化、平台化」的基础。

• 实验期间的可观测性（稳态指标、爆炸半径）
• 受影响服务的展示
• 可观测性驱动实验监控

混沌实验期间的可观测性用于「实时监控实验影响、及时发现异常」。展示内容：① 稳态指标——实时展示「稳态指标」与「基线」对比（错误率、延迟、可用性），观察实验是否导致稳态偏离；② 爆炸半径——展示「实验影响的范围」：受影响的服务/实例数、是否影响关键路径、是否波及下游；③ 受影响服务——展示「哪些服务受影响」，用「服务拓扑/依赖图」可视化「故障传播」；④ 告警/探针状态——实时显示「探针是否通过、是否触发告警、SLO 是否守住」。实现：① 混沌平台（Litmus/Chaos Mesh Dashboard）集成「监控面板」展示实验期间的指标；② 用 Prometheus/Grafana 实时采集并展示「实验维度」指标；③ 记录「实验开始/结束」事件，关联监控时间线。可观测性价值：① 实验期间「实时监控」，指标异常立即止血；② 实验后「评估爆炸半径」，判断影响是否可控；③ 关联「受影响服务」，辅助根因与改进。可观测性是「混沌实验安全与价值」的保障。

实验可观测性的核心是「实时展示稳态指标、爆炸半径、受影响服务」。它让「实验影响可见、可监控、可评估」——异常时立即止血，结束后评估影响。与监控/拓扑集成实现「故障传播可视化」。

• 复原验证（证明系统恢复正常）
• 解除告警（确认故障消除）
• 结论回写实验报告

混沌实验失败后的复原是「关键收尾」，需验证「系统真正恢复」。流程：① 移除故障——实验结束后移除注入的故障（如停止压力、移除延迟、恢复被杀进程）；② 复原验证——用「探针/稳态指标」验证系统恢复正常：错误率回落、延迟恢复正常、可用性达标、服务自愈完成；用「监控指标」确认「无残留异常」；③ 解除告警——确认故障消除后，解除实验触发的告警（关闭/确认告警），避免「告警噪音」残留；④ 验证数据/状态——确认受影响的服务、数据、状态「完整恢复」（如数据一致性、副本同步）；⑤ 结论回写——把实验结论（通过/失败、弱点、影响、恢复情况）回写「实验报告」，记录「复原验证结果」，作为「实验全程」的凭证。落地：用「探针 + 监控」自动验证复原，用「告警确认」解除噪音，用「实验报告」沉淀结论。核心是「完整闭环」——实验结束 ≠ 完成，必须「复原验证 + 解除告警 + 回写报告」才算完整。

复原验证的核心是「证明系统真正恢复才算实验完成」。移除故障 → 探针验证 → 解除告警 → 回写报告。这防止「实验后残留故障/告警」与「结论丢失」。是「实验闭环」的收尾。

• Game Day 的场景设计
• 参与角色与分工
• 观察指标与事后复盘

Game Day（游戏日）是「有组织的混沌演练活动」，把「验证系统韧性」设计成「有剧本、有角色、有指标、有复盘」的活动。① 场景设计——预先设计「演练场景」：选择故障类型（如核心库宕机、网络分区、依赖故障）、确定注入参数、设定「预期表现」；场景要「贴近真实高发事故」且有「学习价值」。② 参与角色——IC（指挥）、执行工程师（注入故障）、观察员（记录与评估）、各团队代表（受影响的业务方）、记录员；角色分工让「演练有序」。③ 观察指标——观测「系统韧性指标」（稳态指标、探针、是否守住 SLO）与「团队响应指标」（MTTA、MTTR、操作准确性）；标注「演练标识」避免误判真实事故。④ 事后复盘——演练后复盘：系统是否守住稳态、团队是否按预案响应、预案是否有效、暴露了哪些弱点；形成「行动项」落地改进。Game Day 的价值：用「低风险、有组织」的方式验证「系统 + 团队」的韧性，把「混沌工程」变成「可重复、可学习、可改进」的常态化活动。

Game Day 的核心是「有剧本、有角色、有指标、有复盘」的组织化演练。场景设计定「验证什么」，角色分工保「有序」，观察指标检「表现」，复盘驱动「改进」。它把「混沌验证」变为「团队学习活动」。

• 场景编排（多故障组合）
• 调度（时间、频率、触发）
• 范围控制（目标、爆炸半径）

混沌实验的编排指「把多个实验组织成有计划的执行」，包括场景、调度、范围。① 场景编排——把「多个故障」组合成「场景（scenario）」，按序或并行执行，模拟「真实事故的组合」（如先网络延迟再 CPU 压力，或「核心库宕机 + 依赖雪崩」）；场景让「验证更贴近真实复杂故障」。② 调度——控制「实验执行时机」：按「时间计划」（定时/定期）、按「事件触发」（发布后、变更后）、按「频率」（持续验证）；调度让「验证常态化」。③ 范围控制——控制「实验影响范围」：限定目标（selector）、限定故障类型、限定爆炸半径、限定影响服务；范围控制「实验风险」。落地：混沌平台（Gremlin scenario、Chaos Mesh 编排、Litmus 多实验）支持「场景编排 + 调度 + 范围控制」。编排的价值：把「单点实验」升级为「场景化、常态化、可控范围」的「持续韧性验证」。

混沌编排的核心是「场景（组合故障）+ 调度（时机频率）+ 范围（风险控制）」。场景贴近真实、调度实现常态化、范围控制风险。编排让混沌工程「从单次实验」走向「平台化持续验证」。

• 混沌实验对错误预算的影响
• 实验导致的消耗如何计入（排除 vs 计入）
• 实验失败与 SLO 考核的关系

混沌工程与 SLO 的联动，核心是「实验消耗的预算如何统计、实验失败如何考核」。通常做法：① 实验窗口排除——混沌实验「人为制造错误」，应把「实验运行窗口」从 SLO/错误预算统计中「排除」（用维护窗口/标记），避免「实验造成的临时故障」被计为「服务不可用」，从而保护「真实 SLO 考核」；② 实验失败的处理——实验失败「不应惩罚」，而应视为「发现系统弱点」的改进信号，把「实验暴露的弱点」转为「改进项」，驱动系统修复；③ 实验的价值——混沌实验「验证系统能否守住 SLO」，是「SLO 的主动检验」，与「SLO 考核」互补而非冲突。落地：实验窗口打标记排除 SLO 计算，实验失败转「改进项」而非「考核扣分」，让「混沌工程」与「SLO」良性互动。

混沌与 SLO 联动的关键是「实验窗口排除计算 + 实验失败作为改进信号」。实验人为制造错误，排除窗口避免「误伤考核」；实验失败反映弱点，应驱动改进而非惩罚。这样「实验验证 SLO」与「SLO 考核」互补。

• 混沌工程的合规要求（记录、审批、边界）
• 平台层的审计落地
• 多团队执行边界控制

混沌工程的合规与审计需在「平台层」落地，实现「记录、审批、边界」的统一管控。落地：① 实验记录——平台自动记录每次实验的「发起人、时间、目标、故障、参数、结果」，作为合规凭证；② 审批留痕——平台集成「审批流」，实验「创建/执行」需审批，审批人、时间、意见留痕；③ 多团队执行边界——平台用「RBAC 权限」控制「谁能发起、谁能审批、谁能执行」，按团队/环境隔离「执行边界」：如「生产环境实验」仅限授权团队、「测试环境实验」全员可用；④ 审计日志——实验操作写入「审计日志」，接入 SIEM，不可篡改、可检索、保留期限；⑤ 风险标识——对「高风险实验」强制「审批 + 窗口 + 止血」。落地：混沌平台（Chaos Mesh/Litmus/Gremlin）集成「RBAC + 审批流 + 审计日志 + 环境隔离」，实现「合规的统一承载」。合规的价值：实验「可追溯、可追责、可证明」，多团队「边界清晰、风险可控」，满足「生产实验的合规要求」。

混沌工程合规的核心是「平台统一承载记录、审批、边界」。实验记录留痕、审批流程留痕、RBAC 控制多团队边界、审计日志可追溯。平台落地让「混沌实验」从「个人行为」变为「受控、合规、可审计」的工程活动。

• 混沌演练常态化的意义
• 纳入 CI/CD 的方式
• 常态化与门禁的平衡

混沌与演练常态化指「把混沌实验从『偶发活动』变成『持续性验证』」，纳入 CI/CD 是关键。常态化方式：① 发布门禁——把混沌实验作为「发布前门禁」，新版本发布前跑「韧性实验」，防止「发布弱化韧性」；② 定期巡检——把「已验证的故障模式」固化为「定期巡检」，系统演进后验证「旧故障是否复发」；③ 持续集成——在 CI 流水线中运行「类生产环境的混沌实验」，快速反馈；④ 变更驱动——重大变更后自动触发「相关混沌实验」。纳入 CI/CD 的实现：在「发布流水线」的「门禁步骤」调用混沌实验（Litmus/Argo），验证新版本韧性；在「测试环境」持续跑混沌实验。常态化价值：① 韧性「持续验证」而非「偶尔验证」；② 与新版本「绑定」——每次发布都验证韧性；③ 系统演进「防退化」——旧故障不复发。平衡：常态化需「控制成本与风险」——生产环境实验「低频、审批」，测试环境实验「高频、自动」；避免「过度实验」造成负担。常态化的本质是「把韧性验证嵌入开发运维流程」。

混沌常态化核心是「持续验证 + 嵌入流程」。纳入 CI/CD（发布门禁 + 定期巡检 + 变更驱动）让「韧性验证」成为「日常」，防系统演进退化。关键是「按环境分层」——生产低频、测试高频，平衡成本与风险。

• 爆炸半径的控制（范围、目标、参数）
• 审批流程（风险分级）
• 爆炸半径与审批的关系

混沌实验的爆炸半径（blast radius）指「实验影响的范围」，需控制；审批是「对高风险的授权」。① 爆炸半径控制——通过「限定目标（selector）、限定故障类型、限定参数（低影响）、限定影响服务」控制实验影响范围；优先「小范围、低风险」实验，关键服务用「测试环境或副本」。② 审批——按「风险分级」审批：低风险（测试环境、小范围）可「自动审批/免审」；高风险（生产环境、大范围、关键服务）需「显式审批」；审批内容包括「故障类型、目标、影响范围、止血方案」。③ 爆炸半径与审批的关系——爆炸半径越大、风险越高，审批越严格；「低爆炸半径」实验可快速执行，「高爆炸半径」实验需「审批 + 窗口 + 止血」。落地：混沌平台按「爆炸半径」打分级，触发相应「审批流」；记录「爆炸半径评估」供审批参考。核心是「爆炸半径越大，审批越严」，把「实验风险」与「授权控制」绑定。

爆炸半径是「实验影响范围」，审批是「风险授权」。两者绑定——「爆炸半径越大、审批越严」。控制爆炸半径（范围/目标/参数）从源头降低风险，审批从流程控制风险。这是「混沌实验安全」的两个维度。

• 自动化回归的意义（防退化）
• 把验证过的故障模式固化为定期巡检
• 回归与系统演进的联动

混沌实验的自动化回归指「把已验证的故障模式固化为定期执行的巡检」，防止「系统演进后旧故障复发」。原理：系统会「演进」（改代码、换架构、加依赖），可能「重新引入」已修复的弱点；定期重跑「已验证的混沌实验」能「验证旧故障是否复发」。做法：① 沉淀已验证故障模式——把「验证通过（系统能扛住）」的故障实验沉淀为「回归用例」；② 固化定期巡检——把回归用例「定时执行」（如每周/每月），或用「CI/CD 触发」；③ 验证防退化——每次巡检重跑实验，若「系统已能守住稳态」→ 通过（防退化成功）；若「实验失败」→ 说明「系统演进后旧故障复发」，触发修复；④ 与 GitOps 联动——系统变更时自动触发相关回归实验。价值：① 防退化——系统演进不破坏已有韧性；② 持续验证——不用等「真实事故」才发现；③ 信心——关键韧性「始终被验证」。落地：用「回归实验套件 + 定时调度 + 告警」实现「自动化回归」。核心是「把混沌验证变成持续的回归测试」。

自动化回归的核心是「把已验证的故障模式固化为定期巡检，防系统演进后旧故障复发」。它把「混沌实验」从「一次性验证」变为「持续回归」，与系统演进联动，防止「韧性退化」。是「平台化混沌工程」的持续验证。

• 各平台的定位与适用场景
• 开源 vs 商业 vs 云厂商
• 选型依据

混沌工程平台选型需按「环境与需求」选择。① LitmusChaos——开源 K8s 原生，支持 ChaosExperiment/Engine、Chaos Hub、丰富的 K8s 故障；适合「K8s 环境、需开源、自托管」；与 GitOps/CI 集成好。② Chaos Mesh——开源 K8s 原生，支持丰富的混沌类型（Pod/网络/内存/磁盘/IO/时间）、Dashboard、与 Prometheus 集成；适合「K8s 环境、需可视化、开源」；GraphQL API 强大。③ Gremlin——商业 SaaS 平台，支持「K8s/主机/云」多环境、多种攻击、编排、安全控制（halt/审批）、开箱即用；适合「跨环境、需商业支持、安全便捷」；成本高。④ AWS FIS（Fault Injection Simulator）——AWS 云厂商原生，支持对 AWS 资源（EC2、RDS、ECS）注入故障，与 AWS 生态集成；适合「AWS 云环境、需云原生故障注入」。⑤ Azure Chaos Studio——Azure 云厂商原生，支持对 Azure 资源注入故障，与 Azure 生态集成；适合「Azure 云环境」。选型依据：环境（K8s/云/混合）、成本（开源/商业）、集成（云厂商/监控）、自动化程度。开源（Litmus/Chaos Mesh）省成本适 K8s，商业（Gremlin）跨环境便捷，云厂商（FIS/Chaos Studio）云原生对接。

平台选型核心是「环境匹配 + 成本 + 集成」。K8s 环境用开源（Litmus/Chaos Mesh），跨环境/需便捷用商业（Gremlin），云环境用云厂商（AWS FIS/Azure Chaos Studio）。选型结合「环境、成本、自动化」。

• 两者的定位与架构
• 功能差异（故障类型、Dashboard、集成）
• 选型考虑

Chaos Mesh 与 Litmus 都是「K8s 原生开源混沌平台」，但有差异。① 架构——Chaos Mesh 用「Operator + CRD + Controller」管理多种 Chaos（PodChaos、NetworkChaos、MemoryChaos、TimeChaos、IOChaos 等），支持 Dashboard 与 GraphQL API；Litmus 用「ChaosExperiment + ChaosEngine + ChaosResult」分层，Chaos Hub 提供实验模板，支持 litmusctl 与 Dashboard。② 故障类型——Chaos Mesh 故障类型更丰富（含磁盘 IO、时间、DNS、JVM 等），注入粒度细；Litmus 以「K8s 资源 + 应用」实验为主，实验模板丰富（通过 Chaos Hub 扩展）。③ 集成——Chaos Mesh 与 Prometheus、Grafana 集成好，GraphQL API 强大；Litmus 与 CI/CD 集成好（Chaos 实验作为发布门禁）、支持 GitOps、Charts 生态。④ 易用性——Chaos Mesh 有成熟的 Dashboard（可视化创建实验）；Litmus 有 Chaos Hub（共享实验）与更清晰的分层。选型：需求「丰富故障类型 + 可视化」→ Chaos Mesh；需求「实验模板 + CI/CD 门禁 + GitOps」→ Litmus。两者都是 K8s 生态的优秀开源选择，可结合环境选型。

对比核心是「故障类型丰富度（Chaos Mesh 更细）vs 实验模板与 CI 集成（Litmus 更优）」。Chaos Mesh 重注入能力与可视化，Litmus 重标准化分层与 CI/CD。选型按「注入需求 + 流程集成」。

• 混沌结果的度量维度（恢复时间、影响）
• 恢复时间（MTTR）与影响范围
• 用度量评估韧性

混沌结果的度量用于「评估系统韧性与实验价值」，核心维度是「恢复时间与影响」。① 恢复时间——实验注入故障后，系统「恢复所需时间」（MTTR/MTTR 与稳态对比）：包括「故障注入 → 达到稳态偏离 → 自愈/恢复 → 回到稳态」的时长；反映「系统自愈能力」——恢复快的系统更韧。② 影响——实验期间的影响范围与程度：受影响服务数、用户受影响程度、错误率峰值、延迟峰值、是否守住 SLO；反映「爆炸半径与稳态偏离程度」。③ 综合度量——「恢复时间 + 影响」综合评估系统韧性：能在「小影响 + 快恢复」下扛住故障的系统更韧；指标如「恢复时长、稳态偏离时长、影响服务数」。落地：测量「实验前基线 → 实验注入 → 指标偏离 → 恢复达标」的时间线，量化「恢复时间」与「影响峰值」。度量驱动改进：恢复时间长 → 优化自愈/预案；影响大 → 优化隔离/容错。混沌度量把「韧性」从「定性」变为「定量」。

混沌结果度量的核心是「恢复时间（自愈能力）+ 影响（爆炸半径与偏离程度）」。用「实验基线 → 注入 → 偏离 → 恢复」的时间线量化。度量驱动「优化自愈与隔离」，是「韧性评估」的量化依据。

• 稳态指标的设定（正确、可量化）
• 自愈的验证方法
• 稳态指标与自愈的关系

稳态指标是「验证系统自愈」的基准。设定：① 稳态指标选择——用「能反映系统健康」的指标作为稳态：可用性、错误率、延迟分位数、POD 就绪数、队列深度等；指标要「可量化、可监控、与用户体验相关」；② 基线设定——记录「正常时」的稳态指标值（或阈值范围），作为「预期基准」；③ 自愈验证——注入故障后，观察「稳态指标是否偏离 → 系统是否自动恢复 → 指标是否回到基线」：若「故障注入后指标偏离，之后系统自动恢复、指标回到基线」，说明「系统自愈成功」；若「指标持续偏离、无法恢复」，说明「系统无自愈能力（弱点）」。④ 自动判定——用「探针/监控」自动检测「指标是否回到基线」判定自愈是否成功。价值：稳态指标是「自愈的判定标尺」——通过「偏离 → 恢复 → 回基线」的时间线，量化验证「系统能否自愈、自愈多快」。落地时用「稳态探针 + 监控」自动验证自愈。

稳态指标是「自愈的判定标尺」。设定「可量化、反映健康」的指标与基线，通过「故障注入后偏离 → 自动恢复 → 回基线」的时间线验证自愈。指标正确与否决定「自愈验证的有效性」。