Chaos Engineering 第 17 章 · 走向信息物理系统

Chaos Engineering: System Resiliency in Practice · Ch 17 · Let's Get Cyber-Physical · 2020

这一章讲什么？

前面的章节里，「故意搞点故障」的对象是网站和手机应用：最坏情况是一小撮人刷不出视频。可今天软件也在开车、开飞机、控制工厂机械臂和医疗设备。当一次故障可能伤到人，故意制造故障这件事还能不能做、该怎么做？这一章就讲这个。

先说个怪事

造汽车、造飞机的工程师，其实比互联网公司早几十年就在「专门研究东西会怎么坏」。他们有一套老办法：开会坐下来，把每个零件挨个点名，问「它会怎么坏？坏了会怎样？有多严重？」，写成一张大表格。这一章的作者说：这套老办法和混沌工程是一对天生的搭档，只是彼此没怎么认识。

旧世界为什么难

表格靠想象。大家只能写下自己想得到的坏法。真正出事的，往往是两个零件「各自都没坏、凑在一起却出了岔子」。
软件不会「磨损」。零件用久了会老化，可以估「多久坏一次」；软件的毛病是一开始就写在里面的，没法这样估。
不能直接上路试。网站出错可以马上撤回，车在路上出错撤不回来。

核心机制直觉

把表格里的每一行，变成一次真实的小考试。表格里写「定位信号丢了，车会改用别的办法估位置」——那就真的把信号掐掉，看它是不是这样做、反应够不够快。
先在「模拟器」里试，再上「练习场」。像学开车：先在电脑上练，再在驾校的封闭场地练，最后才上马路。故障实验也一样，一级一级往真实世界靠。
小心「一看就变」。这类系统对时间特别敏感，你为了观察而加的小工具本身就会让它慢一点、行为变一点——像给病人量血压，病人一紧张血压就高了。办法是让这些观察工具从一开始就常驻在产品里，测的和用的是同一个东西。

带来了什么 / 该怎么选

老办法负责「把可能的坏法想周全」，新办法负责「证明你的应对真的管用」，结果再写回表格，表格就成了一份会随系统更新的活文档。一句诚实的代价：模拟器再逼真也不是真实世界，越往真实环境靠，试一次就越贵、越要层层把关。

一句话记住

想象出来的故障，要用实验去证实；会伤人的系统，实验先进模拟器和练习场。

想看 FMEA 怎么算风险、为什么软件故障没法估概率、实验该放在仿真 / 台架 / 场地哪一级，以及探针效应怎么对付？ → 切到精读版

一句话

你以为混沌工程是互联网公司发明的新东西，其实安全关键行业几十年前就在系统性地「想象故障」。本章主张两者互补：功能安全的 FMEA 负责在纸上把故障想周全，混沌工程负责用实验证实这些想象；而在会伤人的物理世界里，实验要先进仿真与台架，并正视「观察本身会改变系统」的探针效应。

Glossary · 术语表

信息物理系统（cyber-physical system，CPS）：软件通过传感器感知、通过执行器（电机、刹车、阀门）作用于物理世界的系统，如汽车、无人机、工业控制、医疗设备。
功能安全（functional safety）：一门工程学科，目标是系统某部分出故障时，整体仍能避免造成不可接受的人身伤害。
安全状态（safe state）：出故障后系统该退到的无害状态，如靠边停车、悬停降落、阀门关闭。
随机失效 / 系统性失效（random / systematic failure）：前者是硬件老化、偶发损坏，可估失效率；后者是设计或规格里本来就有的缺陷，在同样条件下必然重现。
故障树分析（fault tree analysis，FTA）：从一个顶层事故往下倒推，画出哪些故障组合会导致它。
硬件在环（hardware-in-the-loop，HIL）：真实控制器接在模拟出来的车辆 / 环境上测试，控制器以为自己在真车里。
实时系统（real-time system）：结果不仅要对、还要在截止时间（deadline）内给出，晚了就等于错。
爆炸半径（blast radius）：一次实验出错时最多波及的范围。

坐标

全书第 17 章，Part V「演进」，作者 Nathan Aschbacher。上接 Ch16 持续验证——那是混沌工程在 Web 世界的终点形态；这一章把它往外推到软件控制物理设备的领域，下启 Ch18 用「人与组织绩效」视角重看实验设计。

这章要解决什么

一辆现代汽车上常有上百个电子控制单元（ECU）、代码量常被引用为上亿行的量级；一架无人机的飞控每秒要做数百次姿态解算。软件正在接管原本由机械和人完成的控制，而它出错的后果单位不再是「失败请求的百分比」，而是伤亡。

这些行业早有一套成熟做法——功能安全，由 IEC 61508（通用）、ISO 26262（汽车）、DO-178C（航空软件）等标准约束，核心是设计前先做危害分析、分析做到位再动手。问题在于：

分析靠想象。系统越复杂、越互联，故障越来自组件之间的相互作用（本书 Ch1 的主题），清单式分析追不上。
软件不服从概率。硬件可以说「每十亿小时坏几次」，软件缺陷是系统性的，没有可信的失效率。
Web 那套搬不过来。「在生产里实验、靠小流量控爆炸半径」的前提是出错可撤回；刹车失灵撤不回来。

本章要回答的是：混沌工程能给功能安全带来什么，功能安全又会怎样约束混沌工程。

核心内容，讲透

一、功能安全：先问「会怎么坏、坏了会怎样」

功能安全的思路是自顶向下的：先识别危害（如「非预期加速」），评估严重度、暴露概率、可控性，定出安全目标和完整性等级（汽车里叫 ASIL，从 A 到 D 越来越严）；再给每个目标设计安全机制，并规定出故障时退到哪个安全状态。

关键的一刀是随机失效 vs 系统性失效。硬件元件会随机损坏，可以用失效率做冗余计算；软件不会磨损，它的缺陷在写下那一刻就存在，同样输入、同样时序下必然重现。所以标准对软件不要求算概率，而是用过程严谨度兜底：等级越高，要求的评审、测试覆盖、工具鉴定越多。这也意味着：软件出没出问题，只能靠证据而不是计算来回答——这正是实验的用武之地。

二、FMEA：在纸上演一遍故障

失效模式与影响分析（Failure Mode and Effects Analysis，FMEA）是功能安全最常用的工具之一，方向和故障树相反：自底向上。逐个组件问四件事：它可能怎么失效（失效模式）？局部会怎样？传到系统层会怎样？现有什么手段能发现或缓解？

每一行再打三个 1–10 分：严重度（S）、发生度（O）、可探测度（D，越难发现分越高），相乘得到风险优先数 RPN = S × O × D（1 到 1000）。白话：后果越重、越常发生、越难察觉的坏法，越该先治。

FMEA 逐组件逐失效模式列表、按 RPN 排序；它擅长单点故障，却天然看不到「两个都没坏、组合起来出事」的交互故障。

作者对 FMEA 的评价是双面的。它的价值：强迫团队系统性地思考失效，产出一份「我们认为系统会怎么坏、我们打算怎么应对」的清单。它的局限：

只能覆盖工程师想得到的。FMEA 的质量上限是参会者心智模型的质量。
一次只看一个故障。多故障叠加、组件间时序交互，在表格结构里没有位置。
发生度对软件是猜的。O 分本该基于失效率，软件却没有可信的失效率。
写完就归档。系统在改，表格不改，结论悄悄过期。

三、混沌工程是 FMEA 的下一步

本章的核心论点：FMEA 的每一行，本质上都是一个未经验证的假设。「GPS 丢失 → 系统切换到惯性导航并在规定时间内提示驾驶员」——这是一个可以被实验检验的稳态假设，正好是混沌工程的输入格式。

于是两者形成闭环：FMEA 给出值得测的失效模式与预期缓解；混沌实验真正注入该故障，观察缓解是否生效、多快生效、有没有出现表里没写的连锁影响；结果回写 FMEA——修正严重度和可探测度、补上新发现的失效模式。FMEA 从一次性文档变成被实验持续校准的活文档，而混沌工程也从「随机找弱点」变成有安全分析指路的定向实验。

FMEA 提供假设，实验在仿真 → 台架 → 场地的阶梯上逐级验证，结果回写 FMEA，使它成为持续更新的活文档。

这并非凭空嫁接：故障注入在安全领域本就是公认手段，ISO 26262 就把故障注入测试列为推荐的验证方法之一。区别在于用法——传统上它常被当作确认性测试（证明设计的机制能触发），混沌工程的姿态是探索性实验（去发现你没想到的行为）。

四、探针效应：观察本身会改变系统

CPS 大多是实时系统：控制回路每几毫秒必须完成一轮，时间本身就是正确性的一部分。这带来一个 Web 世界很少遇到的麻烦——探针效应（probe effect）：为了观测或注入故障而加的代码，会占用 CPU、改变调度和时序，从而改变被测系统的行为。加一行日志，竞态 bug 可能消失；去掉日志，它又回来。你实验验证的，可能已经不是你要交付的那个系统。

实时系统里，临时加的观测或注入代码会挤占时间片、改变时序；常见对策是让轻量探针常驻在交付版本里，并把它的开销计入时间预算。

应对思路的共同点是别让「测试版」和「交付版」分叉：把观测与故障注入钩子设计成产品的常驻部分、默认关闭但随产品一起交付和认证；尽量用低开销或硬件辅助的追踪；并量化探针自身开销，纳入时序分析。

关键权衡与选型

CPS 里做混沌实验，核心取舍是实验真实度 vs 伤害风险。Web 世界用「流量百分比」量爆炸半径，这里要用「最坏会伤到谁」来量。

实验放在哪一级（量级为示意）

层级	真实度	单次成本	能发现	代价 / 盲区
纯仿真 / 软件在环	低–中	极低，可并行跑成千上万次	逻辑与状态机缺陷、组合场景	模型与现实的差距；时序不真实
HIL 台架	中–高	中，台架数量有限	真实控制器的时序、驱动、总线问题	环境仍是模拟的；台架昂贵
封闭场地	高	高，每次要人、车、场地	传感器噪声、机械与环境交互	场景有限；仍需安全员与独立急停
受控实地 / 车队	最高	极高	真实长尾	伤害可能不可逆；只在安全状态有独立保障时考虑

三种「想故障」的方法

方法	方向	擅长	盲区
FMEA	自底向上：组件 → 影响	系统性列全单点失效、排优先级	交互故障、多故障叠加；软件发生度靠猜
FTA 故障树	自顶向下：事故 → 原因组合	分析某个严重事故的所有路径	只看预先选定的顶层事件；仍靠想象
混沌实验	经验式：注入 → 观察	验证缓解真的生效、暴露未知行为	只能测能安全复现的条件；受探针效应影响

判据：用 FMEA / FTA 决定测什么，用实验决定信不信；实验从最便宜、最安全的一级起步，只有当下一级有独立于被测系统的中止与安全状态保障时才往上走。

为什么重要 / 落到真实系统

自动驾驶、无人机、机器人、医疗器械（IEC 62304）、工业控制都在快速软件化，越来越多后端工程师会写进控制回路的代码。架构评审被问「这个降级方案你怎么知道它有效」时，本章给的回答是：FMEA 里写着有效，台架实验证明过它有效，而且结果已回写表格。

大厂实证

PX4 开源飞控：故障注入做成飞控的内置命令。其 failure 命令的说明写着「Inject failures into system.」，示例是「Test the GPS failsafe by stopping GPS」，可注入 GPS、电池、电机等组件的 off / stuck / garbage / delayed 等失效；且默认被参数 SYS_FAILURE_EN 关闭——注入能力常驻、但要显式开启。PX4 Autopilot · failure 命令源码（github.com/PX4/PX4-Autopilot）
NASA JPL 火星探路者（1997）：常驻追踪救了任务。着陆后探测器反复整机重启，团队在地面复制品上开启完整追踪，复现并定位到优先级反转；修复则借助随飞行软件保留下来的调试设施，远程改参数启用优先级继承。这是「观测与干预能力常驻于交付版本」的经典例证。文字出处：JPL 飞行软件负责人 Glenn Reeves 对该事件的公开说明，1997
反例 · Uber 自动驾驶测试车事故（2018）。美国国家运输安全委员会（NTSB）2019 年报告指出：系统在撞击前约 5.6 秒已探测到行人但反复误分类；车辆原厂的自动紧急制动在自动驾驶模式下被关闭，安全兜底依赖一名分心的安全员；报告还批评了公司安全风险评估与安全文化的不足。公共道路上的「实验」缺少独立的中止保障，正是本章警告的情形。文字出处：NTSB 事故报告 HAR-19/03，2019

易错点与争议

「混沌工程 = 在生产里随机搞破坏」。在 CPS 里恰恰相反：实验由安全分析指路，从仿真起步，逐级上行。原则（建稳态假设、最小化爆炸半径）不变，执行环境变了。
「FMEA 做完就安全了」。FMEA 是假设清单，不是证据；不经实验校准，它记录的是团队的信念。
「仿真通过 = 现实通过」。仿真与现实之间有模型差距，传感器噪声、机械磨损、环境极端值都可能缺席。
「软件可靠性能像硬件一样估概率」。软件缺陷是系统性的，硬套失效率会给出虚假的精确。
忽视探针效应。临时插桩得出的时序结论，未必适用于交付版本。
时代局限。本书出版于 2020 年；此后 ISO 21448（SOTIF，2022 正式版）专门处理「没有故障、但传感器或算法能力不足」导致的危险，这类问题故障注入覆盖不到，需要场景测试补位。

要点

① CPS 里故障的代价是人身伤害，混沌工程的执行方式必须改变，但原则不变。

② 功能安全早已系统研究失效：危害分析、安全目标、安全状态、完整性等级。

③ 硬件失效是随机的、可估概率；软件失效是系统性的，只能靠证据回答。

④ FMEA 自底向上列失效模式，RPN = S × O × D 排优先级；盲区是交互故障与多故障。

⑤ 核心论点：FMEA 每一行都是待验证的假设，混沌实验来证实，结果回写成活文档。

⑥ 实验沿仿真 → HIL → 封闭场地 → 受控实地逐级上行，每一级都要独立中止保障。

⑦ 探针效应：观测会改变实时系统的时序；让轻量探针常驻交付版本、开销计入预算。

⑧ 实证：PX4 内置故障注入；火星探路者靠常驻追踪排障；Uber 事故是缺少独立兜底的反例。