第11章案例研究：多行业实践

航空、金融、医疗、通信

章节导读

如果混沌工程只是 Netflix 的专利，它就不会成为一门学科——充其量是一家公司的内部技巧。本章的任务是打破「混沌工程 = 互联网大厂专属」的迷思：我们将走访四家背景迥异的组织——一家传统航空公司（Alaska Airlines）、一家实时通信 SaaS（Slack）、一家数字医疗公司（Babylon Health）、一家国有铁路系统（Dutch Railways）——外加一家把混沌工程做成生意的公司（Gremlin），看看这门学科如何在监管严格、安全攸关、技术栈陈旧、文化保守的真实环境中落地生根。这些案例的价值不在于「他们做到了所以你也能」的鸡汤，而在于展示每个行业特有的约束条件如何塑造了各自不同的实践形态：航空业的安全管理体系（SMS）为混沌工程提供了现成的无指责文化框架，但也带来了适航认证的合规边界；医疗行业的数据隐私法规（HIPAA、GDPR）决定了实验不能触碰真实患者数据流；铁路系统的物理世界耦合（信号机、道岔、列车）让「爆炸半径」这个概念有了字面意义上的生命安全含义；而 Slack 这样的实时系统则展示了「消息投递」这种异步语义下稳态定义的独特挑战。

先说为什么多行业视角如此重要。本书前九章建立的方法论——稳态假设、变量选择、爆炸半径、自动化、可观测性——是普适的，但方法论的每一次实例化都依赖具体语境。当你向管理层论证混沌工程时，「Netflix 在做」对传统企业的说服力有限（「我们又不是 Netflix」是最常见的反驳）；而「同行业的 Alaska Airlines 在做，且他们的起点比我们更传统」的说服力则强得多。行业案例还揭示了一个反直觉的事实：传统企业引入混沌工程的路径往往比互联网公司更平稳，因为它们已经有几十年「安全演练」的文化积淀——航空业的飞行模拟器训练、核电行业的应急演习、铁路系统的故障演练，本质上都是混沌工程的前身，只是没有用在软件系统上。把这些组织的既有演练文化「迁移」到软件领域，比在互联网公司从零建立「主动制造故障」的文化反而更容易。

Alaska Airlines 的案例（本书第 11 章的核心素材之一，Nora Jones 曾亲自在该公司推动实践）展示了一条教科书级的传统企业路径：从一次真实事故的教训出发，先在非生产环境做手动故障演练，用演练发现说服怀疑者，再逐步把演练移向生产环境、把手动操作变成自动化工具。关键转折点是 Nora Jones 团队设计的「游戏日」形式——不是工程师关起门来杀服务器，而是把客服、运营、产品负责人都拉进演练现场，让非技术角色亲眼看到「系统故障时用户会遇到什么、我们的应对流程哪里卡壳」。这种「全职能参与」的演练设计让混沌工程从工程团队的自娱自乐变成了组织级的可靠性投资。

Slack 的案例聚焦实时通信系统的独特挑战。Slack 的稳态不是「请求-响应」模型能描述的：消息投递是异步的，一条消息延迟 30 秒到达与彻底丢失对用户的伤害完全不同；WebSocket 长连接意味着客户端状态与服务端状态的同步本身就是故障面；「已读回执」「正在输入」这些辅助功能的故障不影响核心消息流，但会显著伤害体验。Slack 的工程团队为此发展出分层的稳态定义：核心层（消息发送成功率、投递延迟 P99）、体验层（连接稳定性、状态同步及时性）、外围层（搜索、集成、通知），实验判定按层级设置不同的容忍度。他们的另一个贡献是把混沌实验与「降级模式」设计结合：Slack 预先定义了多种降级状态（如关闭已读回执以保护消息主链路），混沌实验的核心目的之一就是验证「降级开关真的有效、切换过程真的平滑」——这比单纯发现弱点更进一步，验证的是应对机制本身。

Babylon Health（数字医疗公司，提供 AI 症状检查与在线问诊）代表了安全攸关行业的谨慎落地模式。医疗系统的混沌工程有三条不可逾越的红线：患者数据不能进入实验环境（用合成数据）、任何实验不能影响正在进行的问诊会话（爆炸半径必须排除活跃诊疗流量）、涉及临床决策路径的系统变更需要合规审查（实验设计要过安全委员会）。在这些约束下，Babylon 的实践聚焦于「非临床路径」的韧性验证：预约系统、通知系统、身份认证的故障演练，以及临床系统的「基础设施层」实验（数据库副本切换、区域故障转移）——这些实验验证系统可用性而不触碰诊疗逻辑。他们的经验对金融、政务等强监管行业同样适用：找到「监管约束」与「实验价值」的交集，从交集最大的区域开始。

Dutch Railways（荷兰铁路，NS）的案例最有戏剧性：他们的调度系统故障会导致真实列车停运、站台混乱、数十万乘客滞留——这是字面意义上的物理世界后果。NS 的实践揭示了「数字-物理耦合系统」混沌工程的核心原则：实验的爆炸半径控制必须考虑物理层的不可逆性。软件系统杀错了进程可以重启，列车错过了调度窗口无法回滚。因此 NS 采用「数字孪生优先」策略：先在调度系统的仿真环境中运行大规模故障场景（信号丢失、联锁失效、通信中断），验证调度逻辑与人工接管流程；生产环境的实验仅限于已被仿真验证过的场景，且选择夜间无列车运行的维护窗口。这种「仿真先行、生产跟进」的分层策略，对所有涉及物理世界的系统（工业控制、物联网、车联网）都有直接借鉴意义。

最后是 Gremlin——由 Chaos Monkey 时代走来的工程师（包括 Kolton Andrus，前 Netflix 与 Amazon 可靠性工程师）创立的混沌工程 SaaS 公司。Gremlin 的意义在于它回答了「没有 Netflix 级平台工程能力的组织怎么办」：把故障注入能力（主机层、容器层、网络层、应用层）做成开箱即用的产品，把爆炸半径控制、实验审批流、结果报告做成内置机制，让一个三人 SRE 团队也能安全地运行生产实验。Gremlin 还贡献了「Reliability Score」与可靠性成熟度模型，把混沌工程的价值度量产品化。商业工具当然不是唯一选择（Chaos Mesh、LitmusChaos 等开源方案同样成熟），但 Gremlin 客户群的行业分布——银行、医疗、零售、制造、政府——本身就是「混沌工程已超越互联网行业」的最有力证据。

本章的 keyPoints 将逐一深入这五个案例的实践细节，并提炼跨行业的共性与差异：所有成功案例都遵循「稳态先行、半径渐进、文化配套」的三部曲，但每个行业的稳态定义、半径边界、文化抓手各不相同。学完本章，你应当能够回答：你的组织属于哪种类型？最接近哪个案例？该案例的哪些做法可以直接借鉴、哪些必须因行业约束而调整？

核心概念

Alaska Airlines
Slack
Babylon Health
行业差异

要点精析

Alaska Airlines 的路径证明了传统企业引入混沌工程不仅可行，而且可能比互联网公司更顺畅——前提是找对切入点。Alaska Airlines 的软件团队在 2010 年代中期面临典型传统企业困境：系统由多个收购而来的技术栈拼合（订座、值机、行李、常旅客系统各自独立），发布周期长，故障响应依赖英雄式救火，工程师对跨系统交互缺乏整体认知。Nora Jones 加入后推动的第一个动作不是部署工具，而是设计游戏日：选择一个真实的业务场景（如「值机系统在高峰时段依赖的身份验证服务变慢」），把工程师、运维、客服主管、机场运营代表召集到一起，手动注入故障，全员观察系统行为与组织响应。这个设计的精妙在于「全职能在场」：客服主管第一次亲眼看到系统故障时用户电话如何涌入，工程师第一次听到客服描述「用户被卡在值机流程时我们只能道歉」——跨职能的共情与认知对齐是任何文档无法替代的。游戏日的成功为后续实践积累了信任资本：管理层看到演练发现的是真实弱点（一次演练暴露了故障转移脚本三年未更新、早已失效），批准了更多投入。路径总结为四步：手动游戏日建立认知 → 非生产环境自动化 → 生产环境小半径实验 → 常态化验证。对传统企业的启示：不要从工具采购开始，从一场精心设计的游戏日开始——工具是演练文化的放大器，没有文化，工具只是摆设。

传统企业与互联网原生企业在混沌工程上的关键差异是「既有安全文化的可迁移性」，这是 Alaska Airlines 案例的深层启示。航空业拥有全世界最成熟的安全管理体系（SMS, Safety Management System）：无指责自愿报告制度（工程师主动上报隐患不受处罚，这是 FAA 明文保护的）、飞行模拟器训练（飞行员每半年在模拟器中演练发动机失效、液压故障等极端场景——这本质上就是针对人的混沌工程）、事故调查的瑞士奶酪模型（多因素叠加而非单点归因）。这些制度与混沌工程的原则惊人地同构：模拟器训练 = 受控环境中的故障演练，自愿报告 = 无指责文化，奶酪模型 = 复杂系统思维。成功的传统企业做的事是「桥接」：把软件混沌实验框定为既有安全文化的自然延伸（「我们已经在模拟器里演练发动机失效五十年了，现在轮到软件系统」），而不是外来文化的入侵。这个框定策略极大降低了组织阻力——怀疑者很难反对「安全演练」，即使他们本能地警惕「在生产系统上搞破坏」。反观互联网原生公司，往往需要从零建立无指责文化，反而更困难。如果你的组织来自航空、核电、化工、医疗等安全攸关行业，先盘点既有的安全管理制度，找到与混沌工程的同构点，用组织的语言而非硅谷的语言来推销它。

Slack 的案例展示了异步实时系统的稳态定义挑战：当「成功」不是简单的请求-响应时，稳态假设必须重新设计。传统 Web 服务的稳态容易定义——请求成功率、延迟分位数；但 Slack 的核心价值是「消息可靠、及时地送达所有相关方」，这涉及多个时间维度：发送方看到的「已发送」确认、服务端持久化、推送到所有在线客户端的 WebSocket 连接、离线用户的推送通知、用户上线后的历史同步。一条消息可能在发送端「成功」却在投递端延迟五分钟——请求-响应指标完全正常，用户体验已经受损。Slack 的应对是分层稳态：核心层指标（消息持久化成功率、端到端投递延迟 P99、WebSocket 连接存活率）用严格阈值；体验层指标（已读状态同步延迟、输入状态广播、表情回应投递）用宽松阈值；外围功能（搜索索引、第三方集成、文件预览）允许更长时间的降级。实验判定时按层级加权：核心层劣化 = 实验立即中止，体验层劣化 = 记录弱点，外围层劣化 = 预期内的降级行为。这个分层思想对所有异步系统（消息队列平台、协作工具、IoT 数据管道、支付清算系统）都适用：先画出你的「价值投递链」，识别链上每个环节的时效语义，再为不同环节设置不同的稳态容忍度——一刀切的稳态定义在异步系统中要么过于敏感（天天误报）要么过于迟钝（漏掉真实劣化）。

Slack 的第二个重要贡献是「验证降级机制本身」的实验哲学：混沌实验的最高形态不是发现弱点，而是验证应对措施的有效性。大多数团队的实验假设是「注入故障 X，系统应当保持稳态」——这验证的是系统的被动韧性；Slack 增加了一类实验：「注入故障 X，触发降级开关 Y，验证降级后的系统行为符合设计」。例如：消息主链路承压时关闭已读回执功能（牺牲体验层保护核心层），实验验证三件事——开关能否在压力下正常切换（降级开关本身也是软件，也会坏）、切换过程是否平滑（会不会造成连接风暴）、降级状态下核心指标是否真的改善。这类实验的价值在真实故障时刻兑现：当值班工程师需要决定是否执行降级时，「这个开关上个月刚验证过」与「这个开关理论上应该能用」是天壤之别——前者是信心，后者是赌博。2021 年 Facebook（Meta）的全球 BGP 故障中，工程师甚至无法远程登录大楼执行恢复操作，因为门禁系统依赖内部网络——「恢复机制依赖被恢复的系统」是降级设计的经典陷阱，只有通过演练才能发现。把「应急预案的验证」纳入混沌实验的常规科目，是 Slack 案例给所有组织的最实用建议：你的回滚脚本、故障转移流程、降级开关、应急通讯录，每一个都应当被定期实验验证，未经演练的预案只是愿望清单。

Babylon Health 的案例定义了安全攸关行业的混沌工程红线体系：有些边界不是「谨慎」而是「不可逾越」，成熟的实践者知道在哪里止步。数字医疗系统的三条红线：第一，数据红线——实验环境绝不使用真实患者数据，故障注入实验在生产的非数据路径上进行，涉及数据流的验证用合成数据在隔离环境完成（HIPAA 与 GDPR 对健康数据的处理有严格规定，实验设计必须过合规审查）；第二，会话红线——正在进行的问诊会话（患者与医生的视频通话、AI 症状检查对话）被排除在一切实验的爆炸半径之外，实验流量标记只作用于新会话的调度层，活跃会话的连接与数据流完全隔离；第三，临床红线——涉及临床决策逻辑（分诊算法、用药建议、风险评估）的系统不做行为层实验，只做基础设施层实验（数据库副本切换、区域故障转移、依赖服务不可用时的排队与转人工机制）——验证的是「临床系统挂了会发生什么」而非「临床系统的输出对不对」。这三条红线的存在没有让混沌工程失去价值，反而让它更聚焦：Babylon 发现的弱点大多在「故障时的人工接管流程」——通知系统故障时医生收不到排班变更、认证服务变慢时患者被卡在候诊页无法转人工客服。对强监管行业的通用方法论：先与合规、安全团队共同划定红线（书面化、进实验平台的强制校验），再在红线内寻找价值密度最高的实验区域——「戴着镣铐跳舞」的正确姿势是先确认镣铐的边界，而不是假装它不存在。

Dutch Railways（荷兰铁路 NS）的案例揭示了数字-物理耦合系统的核心原则：爆炸半径必须考虑物理层的不可逆性，仿真先行是默认策略。NS 的列车调度系统（负责进路排列、信号控制、时刻表调整）故障的后果不是「用户看到错误页」而是「列车停在区间、站台 overcrowding、数十万乘客行程中断」——更严重的是安全风险：调度逻辑错误可能导致进路冲突。这决定了 NS 的实验策略与纯软件系统根本不同。第一层：数字孪生仿真——NS 维护调度系统的高保真仿真环境（包含线路拓扑、信号设备模型、列车动力学、乘客流量模型），大规模故障场景（联锁失效、通信中断、供电故障叠加恶劣天气）先在仿真中运行，验证调度逻辑的容错行为与调度员的人工接管流程；仿真环境的实验没有物理风险，可以激进探索。第二层：维护窗口的生产实验——已被仿真验证的场景，在夜间无列车运行的维护窗口于生产系统上重演，验证「仿真与生产的差异」（配置漂移、数据规模、真实设备响应时间）；这一层的爆炸半径是「零列车」，物理风险被时间窗口消除。第三层：运行时段的最小实验——仅限完全可逆、影响面被严格隔离的实验（如某个非关键信息服务的副本切换），且随时可中止。这个三层结构对所有 CPS（信息物理系统）适用：工业控制、智能电网、车联网、医疗设备——原则是「实验的激进程度与物理可逆性成正比」：完全可逆的数字实验可以在运行时做，不可逆的物理后果只能用仿真与维护窗口覆盖。另一个 NS 的重要经验是「人的演练与系统的演练同等重要」：调度员在仿真演练中的决策表现（多久识别异常、是否按规程接管、沟通是否清晰）与系统行为一起被记录和改进——在 CPS 中，人永远是韧性体系的最后一环。

Gremlin 代表了混沌工程的商业化与民主化路径：把 Netflix 级的能力封装成产品，让没有平台工程团队的组织也能安全实践。Gremlin 的产品设计浓缩了十年行业经验：故障库覆盖主机层（CPU/内存/磁盘/进程杀手）、网络层（延迟/丢包/DNS 黑洞）、应用层（HTTP 错误注入）、云原生层（Pod/Kubernetes 资源），每种故障都内置爆炸半径控制（按百分比、按标签、按实例数限定）；实验流程内置安全机制——前置健康检查（实验开始前验证目标系统健康）、实时中止（一键停止或指标触发自动停止）、审批流（生产实验需要指定角色批准）、完整审计日志。这些机制的价值在于「把纪律产品化」：自建混沌工具最大的风险不是工具本身，而是使用工具的人绕过纪律（不检查健康状态就注入、不设中止条件、爆炸半径随手拉满）——Gremlin 把纪律做成了默认路径，绕过它需要刻意的努力。Gremlin 的另一个贡献是 Reliability Score 与可靠性管理产品：把「你演练过哪些场景、覆盖了哪些关键服务、发现了多少弱点、修复率如何」量化为分数，让混沌工程的价值第一次可以用管理层语言汇报。客户行业分布（银行、医疗、零售、制造、电信、政府）证明了跨行业需求的存在。选择商业产品还是开源工具（Chaos Mesh、LitmusChaos、Chaos Toolkit）？判断标准与所有 build-vs-buy 决策相同：团队规模小、需要快速起步、重视审计合规 → 商业产品；有平台工程能力、需要深度定制、Kubernetes 原生技术栈 → 开源方案。许多组织的实际路径是「Gremlin 起步建立文化，规模化后迁移到自建平台」或两者并存。

跨行业比较揭示的第一个共性：所有成功案例都遵循「稳态先行」的次序，无一例外。Alaska Airlines 的第一个游戏日之前，团队先定义了「航班值机成功率」作为核心业务指标；Slack 的分层稳态体系先于其实验平台；Babylon 的红线体系本质上是「稳态的负面定义」（什么绝对不能被破坏）；NS 的仿真环境首先复现的是「准点率与安全性」的度量。这个共性背后的逻辑在第 3 章已经阐述（没有稳态定义就无法判定实验结果），但多行业视角给它增加了新的维度：不同行业的稳态指标形态差异巨大——航空业是「航班正常执行率 + 安全事件数」，通信业是「消息投递延迟 + 连接存活率」，医疗业是「问诊会话完成率 + 临床系统可用性」，铁路是「列车准点率 + 进路排列成功率」——但抽象结构完全相同：一个直接代表核心价值交付的北极星指标，加上一组分层的质量指标，再加上不可逾越的红线约束。给你的实操建议：启动混沌工程的第一步永远是「用你的行业语言写出稳态定义文档」，并让业务方（不只是工程方）确认它——Alaska Airlines 的客服主管确认「值机成功率下降 5% 意味着每小时数百个用户电话」，这个业务翻译让工程指标获得了组织级的意义。稳态定义文档是你的混沌工程实践中最值得精雕细琢的交付物，它的质量决定了后续一切实验的判定质量。

跨行业比较的第二个共性：爆炸半径的渐进路径在所有行业都成立，但「半径的度量单位」因行业而异。互联网系统的半径单位是流量百分比与实例数（1% 请求、一个 Pod）；航空业的半径单位是业务环节与地理范围（先演练值机系统再演练订座系统，先一个机场再全网）；医疗业的半径单位是会话与数据类型（排除活跃会话、只用合成数据）；铁路的半径单位是时间窗口与物理范围（维护窗口、单条线路的仿真）。抽象出的通用原则是：找到你的行业中「损失最小的可实验单元」，从它开始，逐级放大。放大的每一级都需要新的准入条件：Alaska Airlines 从非生产到生产的跨越，前提是前三次非生产演练全部安全完成且发现了被修复的真实弱点；NS 从仿真到生产维护窗口的跨越，前提是仿真结果被调度团队评审通过。这个「逐级准入」机制是向管理层和监管方证明实践成熟度的核心证据链——每一级的安全记录是下一级的通行证。另一个跨行业观察：半径放大的速度受组织信任积累速度限制，而信任积累速度各行业差异不大（都与演练次数正相关，与行业无关）——这意味着传统企业不必自卑于「我们比互联网公司慢」，慢是所有人的常态，快的组织只是开始得更早。

跨行业比较的第三个共性，也是最难复制的：文化配套决定成败，但每个行业的文化抓手不同。互联网公司的抓手是工程文化本身（「move fast」「生产环境是最好的老师」）；航空业的抓手是既有 SMS 体系（无指责报告、模拟器训练传统）——Alaska Airlines 把软件游戏日框定为「安全演练的数字延伸」；医疗业的抓手是患者安全文化（医疗行业几十年患者安全运动积累的「系统思维」，与瑞士奶酪模型同源）——Babylon 把混沌实验框定为「患者安全的工程保障」；铁路的抓手是运营安全传统与工会参与——NS 的演练包含调度员代表的全程参与，工会对「演练不是考核员工」的书面承诺是前提。共同点是：成功的组织都找到了混沌工程与本行业既有价值观的「连接点」，用行业自己的语言讲述混沌工程的正当性。失败的引入尝试几乎都栽在同一个坑：用硅谷语言向传统行业推销（「Netflix 在生产环境杀服务器，我们也来」），触发行业本能的防御反应（航空人听到的是「无视安全规程」，医疗人听到的是「拿患者冒险」）。给你的行动建议：在引入混沌工程之前，先研究你所在行业的核心价值观与既有安全实践，找到三个连接点，用它们重构你的推广叙事——第 12 章将系统展开组织落地方法论，而「行业语言翻译」是其中最重要的软技能。

行业差异矩阵：四个维度决定你的实践形态应当如何调整。维度一，监管强度——金融（银保监会审计）、医疗（HIPAA）、航空（适航认证）的实验设计需要合规审查环节，实验记录需要满足审计要求（Gremlin 的审计日志功能在强监管行业是刚需而非可选项）；监管弱化的行业（内部工具、游戏）可以更快迭代。维度二，故障可逆性——纯数字系统（Slack）的故障秒级可逆，数字-物理系统（NS）的故障可能不可逆，这决定了「仿真先行」是可选还是必须。维度三，稳态的时间语义——同步系统（Web 服务）的稳态是瞬时的（当前成功率），异步系统（消息、清算）的稳态是有时间窗的（延迟投递最终也算成功），事件驱动系统（IoT）的稳态是统计的（长期数据完整性）；时间语义错了，实验判定就全错。维度四，组织技术成熟度——云原生 + 微服务 + 可观测性完善的组织可以直接做服务级定向实验；单体 + 自建机房的组织应从基础设施级实验（杀进程、断网络）与游戏日起步。用这四个维度给你的组织定位，然后回看本章案例：Alaska Airlines（强监管、数字为主、同步语义、传统成熟度）的路径最接近多数传统企业；Slack（弱监管、纯数字、异步语义、云原生）适合互联网同行；Babylon（极强监管、数据敏感、会话语义）适合医疗金融；NS（物理耦合、不可逆风险）适合工业与交通。没有万能模板，但有可参照的坐标系。

多行业案例共同指向混沌工程的未来图景：从「工程团队的实验活动」演变为「组织级的可靠性管理体系」。三个趋势值得注意。趋势一，与既有管理体系融合——航空业把混沌工程纳入 SMS 框架，金融业把它纳入运营风险管理（Operational Risk Management，巴塞尔协议框架下的正式科目），医疗业把它纳入患者安全体系；混沌工程不再是独立学科，而是各行业可靠性管理体系的「实验验证组件」。趋势二，监管方的态度转变——早期监管者对「在生产系统注入故障」本能警惕，但随着案例积累，监管开始把「主动韧性验证」视为加分项：英国 FCA 对金融业的重要业务服务（Important Business Services）韧性测试要求、欧盟 DORA 法规对金融机构 ICT 风险测试的强制规定（包括威胁导向的测试），实质上是在监管层面要求「金融业的混沌工程」——合规从阻力变成了驱动力。趋势三，供应链与生态韧性——单个组织的系统越来越依赖第三方 SaaS 与云服务，2021 年后的大规模故障（AWS us-east-1、Cloudflare、Fastly、CrowdStrike）证明了「你的韧性取决于依赖链的最弱环节」；行业实践开始把混沌实验扩展到「第三方依赖故障」场景（如果 Slack 挂了我们的客服流程怎么运转？如果 AWS 区域故障我们的备份云能接管吗？），生态级韧性验证是下一个前沿。这些趋势意味着：今天学习混沌工程，你学的不仅是一门技术，而是未来十年可靠性管理的通用语言。

代码示例

/* 示例 1：Slack 式分层稳态定义——异步消息系统的三层指标体系（PromQL 表达） */
/* ===== 核心层：消息价值投递，严格阈值 ===== */
/* 消息端到端投递成功率（发送确认到客户端收到） */
sum(rate(msg_delivered_total{layer="core"}[5m]))
/ sum(rate(msg_sent_total{layer="core"}[5m])) > 0.999

/* 端到端投递延迟 P99（异步语义：从发送到所有在线客户端收到） */
histogram_quantile(0.99,
  sum(rate(msg_delivery_duration_seconds_bucket[5m])) by (le)) < 2.0

/* WebSocket 连接存活率（长连接是实时性的基础） */
sum(ws_connections_alive) / sum(ws_connections_expected) > 0.995

/* ===== 体验层：状态同步，宽松阈值 ===== */
/* 已读回执同步延迟 P95——允许降级但记录 */
histogram_quantile(0.95,
  sum(rate(read_receipt_sync_seconds_bucket[5m])) by (le)) < 10

/* ===== 外围层：辅助功能，允许长时间降级 ===== */
/* 搜索索引新鲜度——落后 15 分钟内可接受 */
time() - search_index_last_updated_timestamp < 900

/* ===== 分层判定：核心层劣化触发实验中止，体验层劣化仅记录 ===== */
groups:
  - name: slack-style-tiered-steady-state
    rules:
      - record: steady:core_held        /* 核心层信号：实验中止的依据 */
        expr: (sum(rate(msg_delivered_total[5m])) / sum(rate(msg_sent_total[5m])) > 0.999)
              and (histogram_quantile(0.99, sum(rate(msg_delivery_duration_seconds_bucket[5m])) by (le)) < 2.0)
      - record: steady:experience_held  /* 体验层信号：弱点记录的依据 */
        expr: histogram_quantile(0.95, sum(rate(read_receipt_sync_seconds_bucket[5m])) by (le)) < 10

这份配置把 Slack 的分层稳态思想翻译成可执行的指标体系，核心设计是「不同层级不同容忍度、不同后果」。先看异步语义的度量难点：msg_delivery_duration_seconds 度量的不是「服务端处理请求的耗时」而是「从发送方提交到所有在线客户端确认收到的端到端时长」——这需要在客户端埋点上报确认时间，是纯服务端监控做不到的；如果你的系统只有服务端指标，消息在推送链路上丢失或延迟你将完全看不见，这是异步系统最常见的监控盲区。再看分层判定的差异化后果：steady:core_held 为假时实验系统立即中止注入（核心层劣化 = 用户价值受损 = 不可接受），steady:experience_held 为假时只生成弱点记录（体验层劣化 = 降级可容忍但需要修复排期）——同一个实验，不同层级的指标触发不同的响应，这比「所有指标一票否决」的粗暴判定精细得多。外围层的搜索索引新鲜度用「落后时长」而非「成功率」度量，因为索引是最终一致的批处理系统，它的稳态语义天然是时间窗而非瞬时值。落地建议：为你的系统画一张「价值投递链」图（消息类系统：发送 → 持久化 → 推送 → 客户端渲染 → 确认；交易类系统：下单 → 风控 → 支付 → 清算 → 通知），链上每个环节标注时效语义（瞬时/时间窗/最终一致），再按环节的业务关键性分配到核心/体验/外围三层——这张图值得团队花一个下午共同绘制，它本身就是极有价值的架构认知对齐活动。

/* 示例 2：Babylon 式红线体系——医疗系统实验平台的强制准入校验（实验前置检查清单的可执行化） */
/* 实验平台的准入规则：任何实验提交时自动校验，违反红线的实验无法创建 */
experimentAdmissionRules:
  - name: patient-data-isolation          /* 红线 1：数据隔离 */
    rule: |
      experiment.dataAccess != "real-patient-data"
      AND experiment.environment IN ["prod-non-data-path", "staging-synthetic"]
    onViolation: reject
    message: "实验不得接触真实患者数据流；数据路径验证请使用合成数据环境"

  - name: active-session-exclusion        /* 红线 2：活跃会话排除 */
    rule: |
      experiment.blastRadius.excludes ALL traffic WHERE session.state == "active-consultation"
      AND experiment.target NOT IN clinical_session_services
    onViolation: reject
    message: "进行中的问诊会话必须完全排除在爆炸半径之外"

  - name: clinical-logic-protection       /* 红线 3：临床逻辑保护 */
    rule: |
      experiment.faultType IN ["infra-only"]   /* 仅基础设施层故障：副本切换、区域转移、依赖不可用 */
      WHEN experiment.target IN clinical_decision_services
    onViolation: require-approval
    approvers: [safety-committee, chief-medical-officer]
    message: "临床决策路径的实验需要安全委员会与首席医疗官双重批准"

  - name: compliance-audit                /* 合规审计：所有实验记录留存 7 年（医疗记录要求） */
    rule: experiment.auditLog.retention >= "7y"
    onViolation: reject

  - name: fallback-to-human               /* 强制要求：涉及患者交互的实验必须验证「转人工」路径 */
    rule: |
      experiment.steadyState.metrics INCLUDES "manual_takeover_availability"
      WHEN experiment.target IN patient_facing_services
    onViolation: reject
    message: "患者侧实验必须把「人工接管通道可用性」纳入稳态指标

这份准入规则展示了强监管行业混沌工程平台与互联网版本的核心差异：纪律不是约定而是强制。三个设计原则值得所有行业借鉴（不只是医疗）。第一，红线代码化：Babylon 式的红线如果只写在文档里，总会在「这次情况特殊」的压力下被绕过；把红线做成实验平台的准入校验（违反即 reject，无法创建实验），纪律就变成了物理约束——这与 Conformity Monkey 的思想同源：用自动化机制而非人的自觉来保证合规。第二，分级响应而非一刀切：注意临床逻辑保护规则用的是 require-approval 而非 reject——涉及临床路径的基础设施实验不是被禁止，而是需要安全委员会与首席医疗官的双重批准；这保留了实验价值（验证「临床系统挂了会怎样」至关重要）同时把决策权交给最理解风险的人。一刀切的禁止会催生地下实验（团队绕过平台手动操作），分级审批把高风险实验纳入正式治理。第三，行业特有的稳态扩展：fallback-to-human 规则强制要求患者侧实验把「转人工通道可用性」纳入稳态指标——这是医疗行业的领域知识代码化：数字系统故障时，患者必须能到达人类医护，这条路径的可用性比任何技术指标都重要。每个行业都有自己的「fallback-to-human」等价物：金融业的「电话银行通道」、铁路的「人工调度接管」、航空的「人工值机柜台」——识别你行业的最终兜底路径，把它变成实验的强制稳态指标，这是行业案例给平台设计者最有价值的模板。

/* 示例 3：NS 式三层实验策略——数字孪生仿真 + 维护窗口 + 运行时段最小实验的编排定义 */
/* 第一层：数字孪生仿真（无物理风险，激进探索） */
simulationExperiment:
  name: interlocking-failure-scenario-042
  environment: digital-twin-full           /* 完整线路拓扑 + 信号模型 + 列车动力学 + 客流模型 */
  scenario: |
    阿姆斯特丹中央站联锁系统通信中断 15 分钟，
    叠加早高峰客流（仿真客流模型加载 08:00-09:00 分布），
    验证：调度逻辑降级行为、进路安全侧默认（所有信号转红灯）、
    调度员人工接管流程、旅客信息系统自动播报
  aggressiveness: high                     /* 仿真中允许探索复合极端场景 */
  outputs: [dispatch-logic-trace, operator-decision-timeline, passenger-impact-estimate]
  gateToNextLayer: |
    仿真结果经调度团队评审通过，且发现的弱点已修复或确认可接受，
    方可申请第二层生产维护窗口实验

/* 第二层：生产维护窗口（零列车时段，验证仿真-生产一致性） */
maintenanceWindowExperiment:
  name: interlocking-comm-loss-prod-rehearsal
  window: "01:00-04:00"                    /* 夜间维护窗口，无列车运行 */
  precondition: simulation-gate-passed     /* 强制依赖第一层通过 */
  scenario: 在生产调度系统上重演仿真场景（物理信号设备处于维护模式）
  focus: 配置漂移检测、真实设备响应时间、生产数据规模下的行为差异
  abortCriteria: 任何影响凌晨首班车准备的操作立即中止

/* 第三层：运行时段最小实验（完全可逆 + 严格隔离） */
liveMinimalExperiment:
  name: passenger-info-service-replica-failover
  target: station-information-display-api  /* 非安全关键：站台信息屏的后端 API */
  fault: kill-one-replica
  reversibility: instant                   /* 副本秒级重建，完全可逆 */
  exclusion: 不触碰进路排列、信号控制、列车防护等安全关键系统（永久排除清单）
  window: "10:00-14:00"                    /* 平峰时段 */

这份三层编排是数字-物理耦合系统（CPS）混沌工程的完整模板，核心思想是「实验激进程度与物理可逆性成正比」。第一层的价值不只是「安全地做实验」，更是「安全地做极端实验」：早高峰 + 联锁失效 + 通信中断的复合场景在生产中永远不该尝试，但在数字孪生中可以反复运行——仿真层承担了探索未知故障组合的任务，这是纯软件组织没有的奢侈品，也是 CPS 组织必须投资的基建（如果你的行业涉及物理世界而没有仿真环境，建设它的优先级高于任何混沌工具）。gateToNextLayer 的强制门禁体现了「逐级准入」原则：生产窗口实验的准入条件是仿真评审通过 + 弱点已处置，这个证据链让监管方与工会都能看到「每个生产实验都经过了无风险的预验证」。第二层的 focus 值得注意——它验证的不是调度逻辑（仿真已验证）而是「仿真与生产的一致性」：配置漂移（生产环境某台服务器的参数与孪生模型不同）、真实设备响应时间（物理继电器的动作延迟与模型假设的偏差）、数据规模效应（生产的历史数据量对查询性能的影响）；仿真-生产差异本身是重要的发现类别，数字孪生的可信度靠这一层持续校准。第三层的 exclusion 永久排除清单是 CPS 的红线代码化：进路排列、信号控制、列车防护系统在任何情况下都不接受运行时实验——安全关键系统的验证完全由第一、二层覆盖。这个「永久排除 + 分层覆盖」的组合，就是「不可逆风险零容忍」与「韧性验证全覆盖」两个目标的兼容解。

/* 示例 4：Alaska Airlines 式游戏日设计模板——全职能参与的手动演练剧本（值机系统场景） */
游戏日剧本：身份验证服务劣化下的值机流程
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
参与角色（缺一不可）：
  - 工程团队 2-3 人（注入操作、系统观察）
  - 运维/SRE 1-2 人（监控大盘、执行预案）
  - 客服主管 1 人（记录「用户视角」影响、演练客服话术）
  - 机场运营代表 1 人（评估柜台人工值机的接管能力）
  - 记录员 1 人（专职时间线记录，不参与操作）
  - 管理层观察员 1 人（只看不说——为后续资源申请积累认知）

时间线（总计 3 小时）：
  T-30m  全员集合，宣布规则：无指责、所有发现都是收获、任何人可叫停
  T-15m  前置检查：稳态大盘正常、回滚手段就绪、今日无真实故障进行中
  T+0    注入开始：对身份验证服务注入 3 秒延迟（非生产环境，模拟高峰依赖劣化）
  T+5m   观察点 1：值机成功率变化？监控告警是否触发？多久触发？
  T+15m  观察点 2：客服模拟——扮演乘客打电话进来，客服能否诊断并给出方案？
  T+30m  决策点：运维是否执行预案（切换到备用验证通道）？预案文档找得到吗？步骤还有效吗？
  T+45m  升级注入：延迟升至 10 秒 + 20% 错误，观察系统是否出现级联（线程池耗尽？）
  T+75m  中止注入，系统恢复，确认稳态回归
  T+90m  热复盘（当场，趁记忆新鲜）：每个角色说三个发现——系统行为、组织响应、个人认知
  T+24h  冷复盘：整理时间线，弱点转工单，流程问题转改进项，向管理层提交一页纸报告

评分卡（演练质量的度量，不是考核个人）：
  □ 告警在 5 分钟内触发且指向正确方向
  □ 预案文档在 3 分钟内被找到且步骤有效
  □ 客服能向「乘客」解释发生了什么并给出替代方案
  □ 记录员时间线完整（每分钟有记录）
  □ 热复盘每人发言（沉默的演练是失败的演练）

这份剧本的每个设计细节都来自 Alaska Airlines 式游戏日的实践经验，展开解释关键选择。角色构成的「缺一不可」是刻意的：客服主管的在场让演练第一次有了「用户视角」的实时翻译（「值机成功率降 10% 意味着每小时 400 个乘客卡在柜台」），机场运营代表评估的是数字系统之外的物理兜底能力（柜台人工值机能接管多少流量），管理层观察员的「只看不说」规则保护了演练的心理安全（领导在场且发言，工程师会倾向于表演而非探索），而管理层亲眼所见为后续资源申请提供了无法被汇报文档替代的认知基础。T+15m 的客服模拟环节是传统企业游戏日的独特价值点：互联网公司习惯只验证系统行为，但传统企业的故障影响大量落在人工渠道（电话、柜台），「系统故障时人工渠道能否接管、客服有没有话术和权限」是同样关键的韧性维度——Alaska Airlines 的多次演练发现，最深的弱点往往不在代码而在流程（客服系统看不到工程侧的故障状态，乘客描述症状客服无法关联到已知问题）。决策点的「预案文档找得到吗」是真实演练的经典发现来源：预案存在但没人知道在哪、步骤引用了已下线的系统、联系人电话已变更——这些只有演练能暴露。评分卡度量的是「组织响应能力」而非「系统能力」，且明确标注不考核个人：告警 5 分钟、预案 3 分钟这些标准针对的是工具与流程的设计，未达标的整改对象是监控配置与文档管理，绝不是值班的人。热复盘的「每人发言」规则同样重要——沉默意味着心理安全不足或参与感缺失，这样的演练做十次也不会长出文化。

/* 示例 5：Gremlin 式实验安全封装——把纪律产品化的实验模板（Gremlin API 风格 + 内置护栏） */
{
  "command": {
    "type": "network",
    "action": "delay",
    "targets": {
      "containers": {
        "labels": {"app": "checkout-service", "env": "production"},
        "percent": 10,                    /* 爆炸半径：仅 10% 的容器实例 */
        "limit": 2                        /* 硬上限：最多 2 个实例，即使 10% 算出来更多 */
      }
    },
    "args": {
      "length": 3000,                     /* 延迟 3 秒 */
      "ipAddresses": ["inventory-api.internal"],  /* 精确到依赖：只延迟对 inventory-api 的调用 */
      "duration": 300                     /* 最长 5 分钟，到期自动恢复——不依赖人工停止 */
    }
  },
  "safety": {
    "preExperimentHealthCheck": {         /* 前置健康检查：目标不健康则拒绝开始 */
      "endpoint": "https://status.internal/checkout-service",
      "expect": "healthy",
      "failAction": "abort-experiment"
    },
    "haltConditions": [                   /* 自动中止条件：绑定业务指标 */
      {"metric": "checkout_success_rate", "threshold": "drop > 2%", "window": "2m"},
      {"metric": "checkout_latency_p99", "threshold": "> 10s", "window": "1m"}
    ],
    "approval": {                         /* 审批流：生产实验需要指定角色批准 */
      "required": true,
      "approvers": ["sre-oncall-lead"],
      "expiresIn": "24h"
    },
    "auditLog": {"retention": "3y", "include": ["who", "when", "what", "halt-reason"]}
  }
}

这份 Gremlin 风格的实验定义展示了「把纪律产品化」的完整形态——对照第 2、5 章的原则，看每个原则如何变成 JSON 里的强制字段。爆炸半径的三重限制：percent: 10（比例限制）、limit: 2（绝对数硬上限，防止「10% 在千实例集群里是 100 个」的规模失控）、ipAddresses 精确到单一依赖（故障面限制：只影响 checkout 对 inventory-api 的调用，checkout 的其他依赖调用完全正常）——三重限制叠加后，最坏情况的影响被压缩到「2 个实例上、对单一依赖的、最长 5 分钟的延迟」。duration: 300 的自动恢复是容易被低估的安全设计：实验有内置的「死亡开关」，即使操作者失联、忘记停止、甚至整个实验平台崩溃，故障注入也会在 5 分钟后自行解除——「不依赖人工干预的自动恢复」应当是所有生产实验的默认属性。preExperimentHealthCheck 体现了「不在病人虚弱时做手术」原则：目标系统已经处于亚健康状态（正在处理真实故障、指标已经异常）时注入实验故障，你无法区分实验影响与既有问题，且可能把小故障推成大故障——健康检查不通过则实验拒绝启动。haltConditions 绑定业务指标（checkout_success_rate 而非 CPU），与 ChAP 的判定哲学一致。approval 的 24 小时过期防止「一次批准永久有效」的权限漂移。auditLog 的三年留存在强监管行业是合规刚需。自建实验平台时，这份 JSON 就是你的需求清单：每一个 safety 字段都对应一次真实事故教训的制度化。

实验笔记

【演练目标】完成一次「行业适配」的完整练习：为你的组织（或一个选定的虚拟组织）设计并执行一场 Alaska Airlines 式全职能游戏日，同时产出该组织的红线清单与分层稳态定义。这个演练把本章四个案例的核心方法（全职能游戏日、红线体系、分层稳态、三层实验策略）整合为一次可执行的实践，总时长约 5 小时（游戏日 3 小时 + 设计工作 2 小时），建议 2-6 人参与，单人也可完成设计部分并用模拟角色执行。

【环境准备】（1）选定演练对象：你真实所在组织的某个业务系统，或前几章 labNotes 的演示系统（多服务电商应用）；（2）为演示系统补充「行业语境」：假设它是一个航空值机系统（或你选择的行业），把 orders 服务重命名理解为「值机会话服务」、inventory 理解为「座位库存服务」、gateway 理解为「乘客自助终端接入层」——行业语境不是文字游戏，它决定了你的稳态定义与红线设计；（3）准备示例 1 的分层稳态 PromQL（按你的行业语境改写指标名）并部署；（4）按示例 4 的角色清单准备「角色卡」：即使只有 2-3 人，也要为每个角色写一张卡（职责、观察重点、复盘时的发言角度），演练中轮换扮演——客服主管角色卡上写着「你的任务是每 10 分钟报告一次：如果这是真的，现在有多少乘客被影响？他们会打几个电话？你能给他们什么解释？」；（5）打印或投屏示例 4 的时间线与评分卡。

【演练步骤】第一阶段（60 分钟），设计工作 A——红线清单：参照示例 2 的结构，为你的行业语境写出红线清单（至少 4 条），每条红线包含：规则描述、违反后果（reject 还是 require-approval）、行业依据（哪条法规/安全传统/业务约束支撑它）。航空语境的参考：活跃航班值机会话排除、适航相关系统仅基础设施层实验、工会代表知情、演练不得影响真实航班运行日。写完后做一次「红队评审」：让搭档（或换一个视角的自己）尝试设计一个「技术上合理但应当被红线拦截」的实验，验证你的红线清单能否拦住它——拦不住就补规则。第二阶段（40 分钟），设计工作 B——分层稳态：按示例 1 的三层结构（核心/体验/外围）为你的系统分配指标，每个指标写出：PromQL、阈值、阈值依据（为什么是 2% 而不是 5%？引用业务翻译——「值机成功率降 2% 在早高峰意味着每小时 X 名乘客受阻」）、劣化后果（中止实验/记录弱点/预期降级）。第三阶段（3 小时），执行游戏日：严格按示例 4 的时间线运行——T-30m 角色卡分发与规则宣布（无指责声明必须大声读出来，形式感是文化的一部分）；注入用 Chaos Mesh NetworkChaos 或 toxiproxy 执行（延迟 3 秒 → 观察 → 升级至 10 秒 + 20% 错误）；每个观察点由对应角色发言（客服角色报告「乘客影响翻译」，运营角色报告「人工接管评估」）；T+30m 决策点真实演练「找预案文档」——提前把一份故意过时的预案文档（引用不存在的 dashboard、错误的联系人）放在团队 wiki 的某个位置，看多久被找到、步骤失效在第几步；热复盘严格执行「每人三个发现」，记录员朗读完整时间线。第四阶段（20 分钟），评分与产出：对照评分卡逐项打分（未达标项写明整改对象是工具/流程/文档，绝不写人名）；把演练发现整理为三类清单——系统弱点（转工单）、流程弱点（转改进项）、认知更新（写入团队知识库）。

【预期结果】（1）一份行业化的红线清单（经红队评审）；（2）一份三层稳态定义文档（含业务翻译与阈值依据）；（3）完整的游戏日档案：时间线、角色发言记录、评分卡、三类发现清单；（4）最重要的隐性产出——参与者对「全职能演练」价值的直接体感：如果你是团队推动者，这份体感记忆与档案就是你向管理层申请常态化演练的第一手证据（示例 4 中管理层观察员的设计，在真实组织中务必落实为「邀请一位决策者全程旁观」）。

【进阶挑战】（1）三层策略映射：参照示例 3，为你的组织设计「仿真/预发 → 维护窗口 → 运行时段」的三层实验策略，明确每层的准入门禁与永久排除清单——即使你的行业没有物理风险，「预发激进探索、生产保守验证」的分层依然成立；（2）行业对标报告：从本章四个案例中选一个与你组织最接近的，写 500 字对比分析——他们的哪些做法你可以直接复制？哪些因约束不同必须改造？改造方案是什么？（3）合规叙事练习：为你的游戏日写一份「给合规/安全部门的说明」（300 字），用你行业的语言（而非硅谷语言）论证演练的正当性与安全性——请一位不熟悉混沌工程的同事阅读，记录他的疑虑并逐条回应，这份问答就是你未来真实推广时的 FAQ；（4）降级开关验证：参照 Slack 的实践，为系统添加一个降级开关（如「关闭推荐模块保护主链路」），设计并执行一次「验证开关本身」的实验——开关在压力下能否切换？切换是否平滑？降级后核心指标是否真的改善？

第11章 案例研究：多行业实践