Capital One：在强监管行业落地

一句话

你以为强监管意味着「不能做混沌工程」，其实监管要的东西——能扛住故障的证据——恰恰是混沌实验最擅长产出的。Capital One 的路线是三步：从外部团队突袭的盲测（blind resiliency testing），转向由应用团队自己写假设的混沌实验，再把实验嵌进 CI/CD 流水线，让每次发布都自动跑一遍、自动留痕。在这条路上，「先在非生产环境做」不是妥协，而是在攒取进生产的许可。

Glossary · 术语表

坐标

全书第 8 章，Part II「原则落地」的最后一篇。前面四家各自弯折了 Ch3 的五条原则：Slack 让位于人在回路、Google 放大到公司规模、微软解决排序、LinkedIn 把爆炸半径落到人。这一章是最受外部约束的那一种：原则三「在生产跑」被监管推到了最后一步。往后 Part III 转向人的因素，Ch16「持续验证」是本章「把混沌放进流水线」的终点形态。现实里它对着银行、支付、保险、医疗这类「出一次事要向外部交代」的团队。

这章要解决什么

先摆约束。银行系统的故障不只是体验问题：刷卡授权要在一两秒内给出结果，失败了就是有人在收银台前付不了钱；重大中断要向监管机构报告，每一次生产变更都要走变更管理、留审批记录。本书写作时 Capital One 正在把业务整体迁上公有云——依赖关系一下子变多、变新，团队凭经验已经说不清「哪个组件坏了会怎样」。

这时 Ch3 的原则三「在生产跑实验」会直接撞上制度：在一个每次变更都要审批的环境里，主动注入故障看上去就是故意制造事故。

不解决会怎样？两种退化。一是只做纸面演练：一年一两次灾备切换，按清单打勾，证明「我们有预案」，却证明不了「预案管用」——而系统每周都在变，上次的结论很快过期。二是没有授权就硬上：摇出一次事故，从此混沌工程在这家公司成了禁语。

所以这章的问题是：在「每一步都要能向外部交代」的约束下，怎么把混沌工程做起来、并一步步走向生产？

核心内容，讲透

一、盲测：先测的是人和流程

Capital One 的起点不是混沌工程，而是盲测：由另一个团队对某个应用注入故障，被测团队事先不知道时间和形式。它测的是三件事——告警会不会响、值班会不会接、预案（runbook）能不能用。

它有真价值：事先打招呼的演练，人人都提前坐在屏幕前，测不出真实的发现时延；盲测测得出。但它的结构性毛病也很清楚：

• 是考试，不是实验。结果以「你们没通过」的形式到达，被测团队的本能是辩解而不是暴露问题。
• 是一次性的。依赖一个中心团队手工组织，频率上不去；系统在变，结论在过期。
• 知识留不住。假设是出题方的，被测团队并没有因此更懂自己的系统。

二、转向混沌：从「被考」到「自己做实验」

转折在于谁来提出假设。混沌实验由应用团队自己写：「当缓存层不可用时，交易查询的成功率仍保持在稳态范围内，只是变慢。」然后在受控环境里验证；假设被推翻，就是一个在上线前找到的缺陷。

这一步改变了三件事：所有权回到最懂系统的人手里；实验是可复跑的，而不是一次性的突袭；每次实验天然带着「假设—注入—观测—结论」四段式记录。最后这一点，正是监管行业最需要的东西——它是结构化的证据，而不是一份事后补写的报告。

三、把实验装进 CI/CD：证据成了流水线的副产品

本章最可操作的一步：把混沌实验做成流水线里的一个阶段。新版本部署到非生产环境之后，流水线按随代码入库的混沌配置（在哪个环境、注入什么、跑多久、什么算通过）自动注入故障，检查稳态假设；成立就放行，不成立就拦下、退回开发。

它解决的是盲测的两个毛病。频率：从一年几次变成每次发布都跑——系统在变，验证跟着变。证据：流水线本来就记录每一步的执行人、时间、版本与结果，实验结果写进同一条记录，审计员要的东西就不需要另写报告。

隐含的代价也要说：门禁上的实验必须稳定、可重复。一个时好时坏的实验挂在门禁上，几周之内团队就会学会绕过它——那比没有更糟，因为记录里写着「已验证」。

四、设计实验时要当心的几件事

本章专门列了一组在受监管环境里设计实验的注意点，揉成四条判据：

• 观测先于注入。稳态指标都看不清，就不该开始；否则实验的结论无从判定，也无从留证。
• 事先通知所有会被惊动的人。运维中心、值班、安全团队都要知道——在银行，一次没打招呼的异常可能被当成真实事故甚至安全事件处理，惊动一整条应急链。
• 先写好中止与回滚。每个实验都要能在不发版的前提下立即停掉，回滚步骤在实验前演练过。
• 爆炸半径从小到大，绕开钱和客户数据。先摇可重试、可恢复的路径；会造成资金或客户数据错误的形态，不在早期实验的范围内。

五、工具、团队与布道：让它活过第一个季度

工具。自建还是采购，本章给的是判据而不是答案：能不能覆盖你的平台与多层故障（基础设施、网络、应用）、能不能让团队自助、有没有护栏与一键中止、能不能接入流水线、能不能产出审计可用的记录。最后一条在监管行业是硬门槛。

团队。起步时由一个中心团队搭平台、定规范、陪跑前几次实验；规模化之后，实验的所有权必须回到应用团队——中心团队做不完、也不如他们懂系统。中心团队的终态是平台与教练，不是执行者。

布道。技术决定能不能做，文化决定有没有人做：把实验找到的缺陷讲成「上线前拦下的事故」，用演练日让人亲手试，把成功案例在公司内反复分享。混沌工程在银行最大的阻力不是工具，是「故意弄坏东西」这几个字带来的本能恐惧。

关键权衡与选型

第一张表：受监管团队的几种起步方式，各测到什么、留下什么证据、付什么代价。

非生产的两级不是「不敢进生产」，而是零客户风险地攒证据——这是在监管行业里换取第五行许可的唯一货币。

第二张表：团队结构怎么选。

落到具体选择：

• 刚起步、制度还不认可：别先谈生产。挑一个依赖多、刚上云的服务，在非生产做几次假设驱动实验，把记录格式定下来——它是你之后所有对话的筹码。
• 已有几十次实验记录：把最稳定的几个实验挂上流水线门禁，从「人想起来才做」变成「每次发布都做」。
• 准备进生产：带着记录去和风控、审计谈，先选只读路径和可重试写入，配自动中止；涉及资金正确性的路径留到最后。

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

三句能直接改掉评审结论的话。一：监管不是混沌工程的反对者，而是证据的买家。二：非生产起步的价值不在安全，而在攒许可。三：把实验放进流水线，证据就不用另写。

面试被问「受监管行业怎么做混沌工程」：答「不能在生产做，所以只做灾备演练」是一个层级；答「从非生产的假设驱动实验起步，把稳定的实验挂上 CI/CD 门禁、结果自动进审计记录，再拿记录换取小爆炸半径的生产实验」是另一个层级——后者说明你知道这里的难点是许可，不是技术。

易错点与争议

• 把非生产当终点。预发环境没有真实负载、真实依赖和真实数据分布，连接池饱和、重试风暴这类故障在那里看不见。非生产是攒证据的地方，不是验证的全部。
• 为审计而混沌。当「每版本一条记录」变成考核指标，团队会挑永远通过的实验——记录很漂亮，什么也没验。判据：门禁上的实验过去一个季度有没有拦下过东西？
• 把盲测文化带进混沌。如果实验结果仍以「你们没通过」的形式到达，团队就会藏问题。实验的产出是知识，不是成绩。
• 忘了通知安全与运维中心。在金融机构，一次不打招呼的异常会触发真实的应急甚至安全响应，代价远超实验本身。
• 门禁实验不稳定。时好时坏的实验挂在门禁上，很快就会被绕过，且记录里仍写着「已验证」。
• 时代局限与后续。本章写于监管还没有专门要求「韧性测试」的年代，混沌工程要自己去说服制度。此后风向变了：英国 PRA / FCA 的运营韧性规则要求金融机构为重要业务设定「影响容忍度」并在严重但可能的情景下测试；欧盟 DORA 自 2025 年起要求金融机构建立数字运营韧性测试计划。工具上，各大云厂商也已提供托管的故障注入服务。不变的是本章那条路径：证据先行，范围后扩。

要点