LinkedIn：对真实用户负责

一句话

你以为「最小化爆炸半径」是把实验调小——少关几台机器、少放一点流量。这一章换了单位：爆炸半径的单位是人，不是机器。LinkedIn 有数亿会员，而其中一次会员体验可能正好是一场面试邀约；所以「关一台机器」的根本毛病不在风险大，而在你无权选择谁受伤。它的工程答案是把注入粒度压到一次请求：故障指令随请求沿调用链向下传播（LinkedOut），受影响集合从「谁碰巧被路由到」变成实验的显式输入；再用「先摇自己 → 内部员工 → 小队列 → 集群级」的阶梯逐级换信息，每一级都配一条跑得比伤害更快的自动中止。

Glossary · 术语表

坐标

全书第 7 章，Part II「原则落地」的第四篇，视角来自 LinkedIn。前三篇分别管「怎么演」「演多大」「先演哪个」：Ch4 Slack 给存量系统写剧本、Ch5 Google 把 DiRT 放大到公司规模、Ch6 微软解决排序；这一篇管演在谁身上，把 Ch3 第五条原则「最小化爆炸半径」从口号做成机制。往后 Ch8 Capital One 是同一问题的强监管版本，Ch16 持续验证把本章的放量与判定自动化。现实里它对着任何一个「工具已经能注入、但不敢在生产按下按钮」的团队。

这章要解决什么

把约束摆出来：本书写作时 LinkedIn 公开口径的会员数在六七亿量级，而它的特殊之处是单次体验的权重极不均匀——同一分钟里有人随手刷信息流，也有人在点「提交申请」、在和招聘方对话。前者卡一下无所谓，后者一次失败可能真改变一件事。

再看「随机关一台机器」。1000 实例的服务关 1 台 ≈ 影响 0.1% 的请求；按机器算这叫「小」，按人算还欠两个问题：这 0.1% 落在谁身上、他们当时在做什么——而杀实例这种做法根本不回答，答案由负载均衡那一刻的分配决定。

更难受的是粘性路由把数字放大的那一下：如果路由按会员哈希，「1% 的请求」其实等于「1% 会员的全部请求」。一个人连着失败一百次，和一百个人各失败一次，在可用率仪表盘上是同一个数值，在真实体验上一个可忍一个是事故。

不解决会怎样？两种退化：不敢做——工具和权限都有，但没人敢按按钮，于是混沌停在既无真实负载也无真实依赖的预发环境；或者硬做然后被叫停——摇出一次真事故，之后半年不许再提。本章的分寸恰恰是为了保住长期做实验的许可。

所以这章的问题是：怎么把「谁受影响」从一个赌注变成一个可填的参数？

核心内容，讲透

一、爆炸半径的单位是人，不是机器

本章最该带走的那次口径更换：别问「影响几台机器、几个百分点」，问影响多少人、哪些人、他们当时在做什么、持续多久、可不可逆。

后三个最常被漏。持续多久决定一个人是遇到一次重试还是五分钟白屏；可不可逆把「页面少一块」和「申请提交丢了、消息发出去一半」分成两类——后者再小的比例都不该拿来做实验。这也解释了为什么摇读路径和摇写路径在本章里不是同一档风险。

换完口径，实验设计的方向立刻变了：目标不是把规模调小，而是让「受影响集合」成为一个你能写下来的输入。杀实例做不到这件事——它的受影响集合是运行时才知道的。

二、机制：故障指令随请求向下传播

LinkedIn 的框架叫 LinkedOut，一句话概括它的位置：注入点是 Rest.li 栈里的一个请求过滤器，而「这一跳该不该注入」由随请求传下来的上下文（Invocation Context）决定。

它能注三种形态：error（抛出异常，模拟资源不可用）、delay（转发前加一段延迟）、timeout（到点抛超时）。触发方式有两类：用 LiX 把实验定向到一群会员，或者把指令放进一个 cookie 里——于是粒度可以细到「我这一次打开这个页面」。

为什么不容易：一个页面扇出几十个下游，故障要只落在「这一个会员的这一次请求打到服务 X 的那一跳」，既不漏到别的会员，也不漏到服务 X 的其他调用方——这要求框架每一跳都把上下文完整传下去。反过来就是它的隐含代价：没接这套传播机制的路径注不进去（第三方 SDK、离线任务、消息队列后面的消费者）。

换来的是爆炸半径的量级跳变：从「那台机器上所有会员在重启窗口内的所有在途请求」，降到「一个人的一次点击」。

三、放量阶梯：先摇自己，再摇一小群

一旦注入能精确到一次请求，最便宜的实验对象就是工程师自己。LinkedOut 为此配了一个浏览器扩展：工程师在自己的会话里点一下，让页面上某个下游「坏掉」，直接看页面还能不能用。爆炸半径是一个知情同意的人。

再往上一级是自动化套件：把一个页面的每个下游依次坏一遍，逐个检查是否优雅降级。这类实验之所以敢全自动、高频跑，正因为受影响的只有发起它的那个账号——它的边际伤害是零，于是可以当测试用。

阶梯的全部意义是用最便宜的一级榨出最多的问题：缺超时、缺降级、下游一挂就整页白屏，这些在第一级就暴露了。真正值得放量的，只是「必须有真实流量才看得见」的那一类。

也要诚实说上限：有些故障天生只在规模下出现——连接池饱和、重试风暴、缓存集体失效、下游被所有调用方同时打爆。单请求注入里看不见它们，必须放量或改用集群级实验。这就是阶梯的信息天花板。

四、自动中止：护栏必须比伤害跑得快

放量到真实会员之后，「有没有伤到人」这个判断不能挂在人盯屏幕上。三条要点：

• 指标要选会员感受得到的业务量：消息发送成功率、页面渲染成功率、申请提交成功率——不是 CPU 和内存。CPU 正常而用户正在失败，是本章最怕的那种盲区。
• 判定必须在本级的时间尺度内可见。若伤害要 10 分钟才在指标上看出来，这一级就得跑满 10 分钟才敢判，而这 10 分钟伤害一直在累积。结论不是「忍 10 分钟」，而是换更快的指标，或把这一级的人群再缩小。
• 中止要自动触发、秒级生效。注入开关必须能在不发布、不重启的前提下关掉；人工审批流不算中止手段。

一条可以直接拿去用的判据：没有自动中止条件的实验，不该在真人身上跑。这不是道德姿态，是成本算术——「人工发现 + 人工处置」的时延乘以放量人群，就是你为这次实验预付的伤害。

关键权衡与选型

第一张表是阶梯的落地：每一级换到什么信息、付什么代价。

第 ① 级的性价比来自它的边际伤害为零：可以当测试一样高频跑。

第二张表是同一件事的另一刀：限制伤害的几种手段，在保真度上各付什么代价。

落到具体选择：

• 刚起步、不敢按按钮：别从关机器起步。先把注入做到请求级，再给工程师一个「摇我自己」的入口——这一步伤害为零，却能把大半缺超时、缺降级问题捞出来。
• 已有请求级能力、准备放量：先补自动中止，再放量，顺序不能反。比例的选择标准不是「看起来小」，而是「伤害在指标上多久可见」。
• 粘性路由的系统：按会员定向而非按请求随机命中，并限制同一会员被命中的时长——否则「1% 请求」会变成「1% 的人全崩」。
• 涉钱、涉不可逆写入：先只摇读路径与可重试的写入；不可逆写入走 Ch8 Capital One 那条路——非生产跑熟、留下证据再谈生产。

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

三句能直接改掉评审结论的话。一：爆炸半径的单位是人，不是机器。二：「只影响 1% 流量」在粘性路由下等于「1% 的人全程受影响」。三：没有自动中止条件的实验，不该在真人身上跑。

面试被问「你们怎么在生产做混沌工程」：答「半夜随机关机器」是一个层级；答「注入做到请求级、默认先在发起人自己的会话上跑，放量走定向队列并绑定会员可感指标的自动中止」是另一个层级——后者显示你知道难点在谁受影响，不在能不能注入。

易错点与争议

• 按机器或流量百分比算爆炸半径。同样的 0.1%，落在刷信息流的人身上和落在正在提交申请的人身上，是两件不同的事。
• 以为「随机」等于「公平」。随机注入叠加粘性路由，等于让少数人承担全部伤害。
• 先放量、后补护栏。自动中止不是优化项，是放量的前置条件。
• 把「摇自己」当成全部。它便宜且高产，但天生看不见池饱和与重试风暴——那些只在规模下出现。
• 把伦理当公关问题。本章把它当设计约束，判据很具体：受影响集合可枚举、伤害可逆、每次实验都能向非工程师解释清楚。
• 争议：请求级注入的保真度不够。它注的是「这一次调用失败」，不是「服务真的挂了」；真故障会同时打在所有调用方身上、触发重试风暴与池饱和。所以它是日常高频的那一档，不能替代集群级实验——两者是分工，不是取代。
• 时代局限与后续。LinkedOut 建立在自家 Rest.li + LiX + IC 之上，自建门槛很高；今天同样的机制基本可以装——服务网格（如 Istio）原生支持 HTTP 层的 abort / delay 注入，OpenTelemetry 的 baggage 提供跨服务上下文传播，功能开关平台提供定向放量。不变的不是工具，是那句口径：先问会影响谁。

要点