Chaos Engineering 第 15 章 · 混沌成熟度模型

Chaos Engineering: System Resiliency in Practice · Ch 15 · The Chaos Maturity Model · 2020

这一章讲什么？

你用的视频、打车、外卖软件，背后的公司很多都在「故意把系统弄坏一点」来找隐患。可是「我们公司搞得怎么样了」很难回答——有人说已经做了一年，有人说还没开始。这一章给了一张两条轴的地图，让团队能说清自己站在哪、下一步往哪走。

打个比方

想象一家健身房在评估会员。只问「你练了多久」不够，要问两件事：动作有多专业（还在原地跳，还是已经按计划练、有教练记录数据），以及坚持得有多普遍（偶尔去一次，还是全家人每周都去、不去反而要找理由）。动作再标准、一年只去一次，没用；天天去但只会乱跳，也练不出来。

旧世界为什么难

只有一个数字。「今年做了 50 次演练」听起来很多，可能全是同一个小组在测试环境里关机器。
不知道该补哪块。有的公司花大钱造了很厉害的平台，结果只有一个团队在用；有的公司人人都在做，但做的都是最浅的那种。两种都卡住了，药方却完全不同。

核心机制直觉：两条轴，各分四级

第一条轴：做得多专业。最初级是在测试环境里手动拔掉一台机器、看看电脑忙不忙；往上走，就是到真实环境里做、由系统自动开始和自动喊停、看的是「用户还能不能顺利下单」这种真正关心的结果，最后甚至能估出一次故障会损失多少钱。
第二条轴：做得多普遍。最开始是几个热心人偷偷做；接着公司正式认可、给了一点人手；再往后有专门的团队、重要的服务都定期做；最高一级是变成习惯——新员工入职就学，不参加反而要解释原因。
把自己点在地图上。两条轴一交叉就是一张格子图，你在哪一格，下一步就是把落后的那一条往前推一格。

带来了什么 / 该怎么选

它把一场「我们做得好不好」的空谈，变成一张能对着讨论的图：平台很强但没人用，就去推广；人人在做但都很浅，就去补工具和安全措施。一句诚实的局限：这张图只告诉你在哪、往哪走，不告诉你每一步要花多少钱、值不值。

一句话记住

别只问「做没做」，要问「做得多专业」和「做得多普遍」——先找到自己在格子图上的位置，再补短的那条腿。

想看两条轴每一级的具体判据、四个典型位置的药方，以及 Google、Netflix 怎么一格格走上来？ → 切到精读版

一句话

你以为成熟度是一条单向的梯子，其实是一张两维的地图：精细度（sophistication）衡量实验做得多有效、多安全，采用度（adoption）衡量实验覆盖了多少系统、多少人。本章的用处不是打分，而是定位——看清自己在哪一格，判断下一笔投入该押在哪一维。

Glossary · 术语表

混沌实验（chaos experiment）：在受控范围内向系统注入故障（宕机、延迟、断网），看系统是否仍维持正常。
稳态（steady state）：系统正常时某个可量化的指标，如每秒下单数，用来判断「有没有出事」。
业务指标 vs 系统指标：前者是用户直接感受的结果（下单成功率、播放启动数），后者是机器的状态（CPU、内存）。
对照组 / 实验组（control / experiment）：从真实流量里切出两小份，只对实验组注入故障，两组对比才能判断差异是不是故障造成的。
爆炸半径（blast radius）：一次实验最多影响多少用户或机器。
持续交付（continuous delivery，CD）：代码改动自动走完构建、测试、部署的流水线。
影子流量 / 流量回放（shadow / replay traffic）：把生产请求复制或录下来，发给非生产的环境，用真实形态的负载做测试。
Game Day（演练日）：事先约定时间、多团队一起参与的人工故障演练。
成熟度模型（maturity model）：把一种能力分成若干等级、用来评估现状和规划改进的框架。

坐标

全书第 15 章，Part IV「商业因素」的收尾。这个模型最早出自 Netflix 混沌团队 2017 年的 O'Reilly 报告《Chaos Engineering》，名字借自软件工程界的能力成熟度模型（CMM）。上接 Ch13 投资回报、Ch14 开放分享——它们回答「值不值」「怎么扩散」，本章回答「现在到哪了、下一步做什么」；下接 Ch16 持续验证，那正是精细度轴的顶端。

这章要解决什么

混沌工程推到第二、三年，管理层和工程师都会问：我们做得怎么样？常见的回答是一个计数——「今年做了 120 次实验」。这个数字掩盖了两种截然不同的处境：

120 次全部来自一个热心团队，在测试环境里手动关机器、看 CPU。组织层面几乎没变化。
120 次分散在 40 个服务，但每次都只敢拔一台机器，没人看业务指标，也没有自动中止，一旦出事就是真事故。

两者计数一样，问题与药方完全不同：前者缺推广，后者缺工具和护栏。没有一个共同的坐标系，规划就会变成「再多做一点」，资源也会押错方向——给已经没人用的平台继续加功能，或者让更多团队去做不安全的实验。

核心内容，讲透

一、为什么是两条轴，而不是一条梯子

经典的 CMM 是一条五级梯子。混沌成熟度模型刻意拆成两维，因为混沌工程的价值是两者的乘积：实验再精巧，只覆盖一个服务，组织韧性不变；覆盖再广，如果实验只能证明「关一台机器没事」，学到的东西也很有限。更关键的是，两条轴靠不同的投入推进：精细度主要靠工程（平台、自动化、度量），采用度主要靠组织（认可、人手、培训、默认规则）。拆开看，才知道钱该给工具组还是给推广。

两条轴各分四级，交叉成十六格。先把自己点上去，再看短板是哪一维；两个紫色角落是最常见的失衡位置（标注为本页的读法）。

二、精细度轴：实验做得多「科学」

精细度回答的是：这些实验能多可靠地发现真问题，又多安全地不制造真事故。原文按四级描述，大致沿着四个方向同时升级：在哪跑、谁来启停、看什么指标、注入什么。

精细度四级：每上一级，实验都更接近真实生产、更自动、更贴近业务结果；灰字是注入的故障类型。

在哪跑：从测试环境，到用真实形态的流量，再到生产，最后贯穿开发的每一步。离生产越近，发现的问题越真实，风险也越高——所以下一条必须同步升级。
谁来启停：从人手动操作，到自动执行但人盯着喊停，再到自动分析结果，最终连中止也自动。自动中止是把实验放进生产的安全前提。
看什么指标：从 CPU、内存这类系统指标，到汇总的业务指标，再到实验组与对照组的业务指标对比，最后能推算出一次故障对应多少收入损失。
注入什么：从关一台机器，到网络延迟，再到服务层的错误、多种故障组合，乃至流量模式变化、返回数据被篡改。

三、采用度轴：实验覆盖了多少人和系统

采用度回答的是：混沌工程在组织里有多「正当」、多普遍。四级大致如下：

暗处（in the shadows）：少数早期采纳者私下做，项目未经正式认可，覆盖的系统很少，组织几乎不知道。
投入（investment）：正式认可，有兼职人力，多个团队感兴趣，少数关键服务偶尔做实验。
采用（adoption）：有专职团队；事故处理接入实验框架，把每次事故变成一条回归实验防止复发；多数关键服务定期做，偶尔用实验验证事故响应、办 Game Day。
文化预期（cultural expectation）：所有关键服务频繁做，多数非关键服务也做；写进新员工入职培训；默认参与，退出要给理由。

最后一级的那条判据最值得记：从「选择加入」翻转成「选择退出」。只要还需要说服每个团队来参加，采用度就有天花板；一旦默认参加、不参加才需要解释，覆盖率就由规则而不是热情决定。

四、怎么用这张图：定位，然后补短

本章的用法很朴素：两条轴各打一个级别，点到格子上，然后看哪一维落后。它是诊断工具，不是排名——两个团队落在不同格子里，不代表谁更「好」，只代表下一步该做的事不同。也可以按时间重复标注，看轨迹是不是在往右上走，还是只在一维上越走越远。

关键权衡与选型

核心权衡只有一个：下一笔资源押在精细度还是采用度。两种失衡都会浪费钱，只是方式不同。

四个典型位置：症状与药方（场景为示意）

位置	典型症状	下一步	不这么做的代价
左下：暗处 × 初级	一两个人在测试环境手动关机器	先拿到正式认可，选 1–2 个关键服务做出一次有业务指标的成果	没有成果，项目随热心人离职而消失
右下：精致的孤岛	平台能自动分流、自动中止，但 200 个服务里只有个位数接入	补采用度：降低接入成本、给专职推广人力、把事故复盘接成回归实验	平台成本照付，组织韧性几乎不变
左上：人多但浅	每个团队都办 Game Day，但只敢拔一台机器，人工盯监控	补精细度：先建自动中止和业务指标，再扩大故障类型	实验越多，制造真事故的概率越高，最终被叫停
右上：两维都高	实验默认进流水线，结果可推算损失	维持：控制噪声与实验成本，按服务重要性分配实验频次	自动化本身老化，变成没人看的绿灯

什么时候先推哪一维

处境	先推	理由 / 代价
还没在生产做过	精细度（自动中止、对照组）	没有护栏就扩大采用，等于扩大事故面；代价是推广要等工具到位
工具已能安全跑生产	采用度	边际收益在覆盖面；代价是需要组织资源，工具组自己推不动
采用已高、结果没人看	精细度（业务指标、自动分析）	大量浅实验的结论无法行动；代价是度量体系要和业务团队对齐
要向管理层要预算	精细度顶端（损失推算）	能把实验换算成钱，才接得上 Ch13 的投资回报论证

判据：先让实验安全，再让实验普遍，再让实验自动。护栏是扩大采用的门票，采用度是平台投入的回报来源。

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

面试或架构评审被问「你们混沌工程做到什么程度了」，最好的回答不是次数，而是两个坐标：「精细度在『精细』——生产跑、对照组比业务指标、但中止还靠人；采用度在『采用』——有专职团队、关键服务定期做，非关键服务还没覆盖。所以下一步是自动中止和入职培训。」这一句话同时说清了现状、短板和计划。

真实组织的轨迹也基本是两维交替推进：先有人在边缘做、再被正式认可、再有平台、最后进流水线成为默认。

大厂实证

Google 的 DiRT：从几个窄问题长成全公司协同演练。Google Cloud 博客回顾：DiRT 起初是「a small set of theoretical tests ... isolated and very narrow in scope」，如今是「a coordinated set of events organized across the company」，规模扩到断开整座数据中心。两条轴都在往前走。Google Cloud 博客 · Jesus Climent · 2019（Shrinking the time to mitigate production incidents）
Netflix 把注入接进持续交付。Chaos Monkey 仓库写明：「This version of Chaos Monkey is fully integrated with Spinnaker, the continuous delivery platform that we use at Netflix.」——对应精细度轴「接入持续交付」那一级。Netflix · Chaos Monkey README（github.com/Netflix/chaosmonkey）
开源工具把「进流水线」与「稳态校验」做成功能。LitmusChaos 的用途之一是「run chaos as a pipeline stage」，并用 probes 声明稳态校验条件；Chaos Mesh 用 Schedule / Workflow / StatusCheck 支持「recurring experiments」。精细度轴的中上段，如今可以直接买到或装到。LitmusChaos README（github.com/litmuschaos/litmus）· Chaos Mesh README（github.com/chaos-mesh/chaos-mesh）

最后一条也是反面提醒：工具能把精细度一夜拉高，采用度却买不来——这正是「精致的孤岛」最常见的成因。

易错点与争议

「级别越高越好，要尽快爬到右上角」。模型是地图不是考试。对一个 10 人公司，「推算收入损失」「接 A/B 平台降噪」可能根本不划算。
「采用度 = 实验次数」。采用度看的是覆盖、正当性和默认规则，不是计数；一个团队做 100 次仍在「暗处」。
「只推一维就行」。只推精细度得到孤岛，只推采用度得到更多事故风险——两条腿要交替迈。
级别判定是主观的。原文给的是描述性特征而非可量化的门槛，不同人对同一团队可能打出不同级别。用它来对话很好，用来做绩效考核就危险。
成熟度模型的通病。CMM 一类模型常被批评为鼓励「为了升级而升级」、把清单当目标。混沌成熟度模型同样可能被做成表格游戏，背离「找到并修掉弱点」的本意。
写作时代的局限。模型出自 2017 年的 Netflix 语境，默认有大规模微服务和自研平台；今天托管故障注入服务和开源平台普及，精细度中段的门槛已大幅降低，难点更多转到了采用度。

要点

① 混沌工程的成熟度不是一条梯子，而是精细度 × 采用度两维地图。

② 价值是两维的乘积：精巧却没人用，或普及却很浅，组织韧性都涨不上去。

③ 精细度沿四个方向升级：在哪跑、谁来启停、看什么指标、注入什么。

④ 自动中止是把实验放进生产的安全前提；业务指标 + 对照组是结论可信的前提。

⑤ 采用度四级：暗处 → 投入 → 采用 → 文化预期。

⑥ 最高级的标志是从「选择加入」翻转为「选择退出」，并写进入职培训。

⑦ 两种典型失衡：精致的孤岛（补推广），人多但浅（补护栏和工具）。

⑧ 顺序判据：先安全，再普遍，再自动；工具买得到，采用度买不到。

⑨ 汇报现状时给两个坐标，而不是一个实验次数。