客户说“你们敢不敢真断一下给我看“——故障演练不是搞破坏，是住进新家做消防演习

你正在项目群里跟客户聊着下个月上版本的事。

屏幕亮了一下，客户老板发来一条消息：

“容灾这块我们下周要验收。你们系统的高可用是写在PPT上的，还是真能断一台机器接着跑？我就一个要求——你们敢不敢真断一下给我看？”

群里瞬间安静了。

你盯着屏幕，手里的水杯差点没端住。

真断？

你脑子里唰唰过电影——万一断了没切回来怎么办？万一容灾切换脚本半年没跑过期了怎么办？万一炸了客户直接不信任我们了怎么办？

你回头看了一眼团队，几个小伙子面面相觑。项目经理小声说：“要不……我们回他’理论上没问题’？”

架构师清了清嗓子：“其实我们架构确实是多可用区的，主从也配了，负载均衡也做了……”

"那敢不敢真断？"客户老板又补了一句，“别光说，拉根线给我看。”

那天晚上我没睡好。不是因为写代码写到半夜，是因为躺床上翻来覆去想一件事——为什么我们所有人听到"真断一下"的第一反应，不是"好啊，断就断"，而是"万一炸了怎么办"？

我们到底在怕什么？

这一篇，我想跟你聊聊这件事。

故障演练这件事，听着像技术团队的内部功课——实际上它是你搬进新家之后要做的第一件事。不是开香槟庆祝搬家成功，是先找一下灭火器在哪、烟感器响不响、楼道的逃生通道通不通。

这不是搞破坏，是做消防演习。

往下读，我把这件最容易让人失眠的事，一层层剥给你看。

一、为什么大家一听到"演练"就腿软

我跟你说句实话。

客户提"真断一下给我看"的那个晚上，我们整组人都失眠了。

不是夸张。运维小哥半夜两点在群里发消息：“我刚把切换脚本从去年的版本库里翻出来了，我记得上次跑还是上线前，那会儿数据库IP好像都改过了……”

开发组长凌晨三点回了句：“我靠。”

第二天早会，一屋子人坐那喝黑咖啡，谁都没睡好。我问大家：“你们到底在怕什么？”

大家你看我我看你，最后说了三层怕。

第一层怕：怕担责任。

真断一下炸了，这锅谁背？是写脚本的人背，还是点"执行"按钮的人背，还是拍板说"断"的我背？万一炸到用户数据，客户索赔怎么办？奖金没了怎么办？绩效怎么办？

这层怕最真实。你在公司干久了就知道——多做多错，少做少错，不做不错。你不演练，系统就一直"理论上没问题"；你一演练，万一炸了，“理论上没问题"就变成"你看你们搞砸了”。

我打个比方让你记一辈子——你搬进新家，物业说来做一次消防演习。你第一反应是什么？

“别啊，万一演习的时候真把火点着了怎么办？万一把我家沙发烧了怎么办？万一楼道里踩踏怎么办？”

你这么想很正常。但你再想想——你因为怕演习烧沙发，就永远不演习？那真着火的时候，你连灭火器往哪喷都不知道。

第二层怕：怕回不来。

演练不是点一下"开始"就完事。你断一台机器，得能切回来；你切一个机房，得能切回去；你打一堆延迟，得能恢复正常。万一回不来——假戏真做，演练变事故，那就是大事故。

这层怕是技术团队心里最没底的——我知道我能让它坏，但我不确定我能不能让它好回来。

你记住一句话——故障演练不是纵火，而是拉警铃做消防演习。不是真要点房子，是试警铃响不响、大家会不会跑、灭火器会不会用。

就像你在家想试一下煤气报警器响不响。你敢不敢真放一点煤气？你不敢。因为你不确定放多少它才响，也不确定放了之后能不能关严，更不确定窗户开着通风要通多久才安全。

不是你不想试，是你怕试完回不来。

第三层怕：怕客户看见炸了不信任。

这层怕是商务和老板最怕的——客户本来就半信半疑，你一演练炸了，客户直接说"你们果然不行"，合同都可能黄。

"还是别冒险了，"销售在电话里跟我说，“跟客户说说，我们有灾备认证、有等保三级、有架构图，就行了。真断一下万一出岔子，这单可能就黄了。”

你听，这话是不是特别熟悉？

三层怕叠在一起——怕担责任、怕回不来、怕客户看见——任何一层都足以让你打退堂鼓。三层叠在一起，难怪大家一听到"真断一下"就腿软。

但那天客户老板说了一句话，把我从"怕"里拽了出来。

他说：“你们现在不敢断，等真出事的时候就不怕了？真出事的时候是半夜三点，是大促高峰，是财务日结——那时候才是真怕。你们现在挑个周二下午、大家都在、客户也在、回滚按钮也在手边——这都不敢，等真出事你们敢接？”

我端着咖啡的手停在半空。

对啊。

真故障不会挑你方便的时间来。但演习，永远挑的是你最方便的时间。

你周二下午两点不敢断，你凭什么相信你周三凌晨三点电话被打醒的时候能断得对？

你身边全是同事、监控全开、回滚按钮就在手边的时候不敢做的事，等你一个人在家穿着睡衣、脑子还没清醒、电话那头客户在吼的时候，你就能做好？

别骗自己了。

二、剥真相：客户要的根本不是"炸系统"

我后来跟那个客户老板单独喝了一次茶。

我直说了：“X总，说实话，听到您说真断一下，我们整组人都虚。您到底想看什么？是想看我们系统炸？”

他笑了，给我倒了杯茶。

“小魏啊，你以为我想看你们出丑？我做甲方做了二十年了，我什么没见过。我要的根本不是看你们炸，我要的是三个答案。”

他掰着手指头给我数，数完我后背冒冷汗，但心里那块石头也落下来了。

第一个答案：我想知道——炸了会怎样。

不是"理论上"会怎样，是真炸了会怎样。

炸了是用户完全用不了？还是部分功能受影响？影响多少用户？多久能发现？多久能恢复？哪些数据会丢？哪些不会？

这些问题，PPT上写得再漂亮都没用。PPT上写"RTO<30分钟、RPO=0"，那是写的。真断一下，发现切换脚本半年没跑、IP地址硬编码了、切过去发现备库数据延迟了两个小时——这才是真相。

他说：“你们系统炸了我不怕，我怕的是你们自己也不知道炸了会怎样。”

我打个家里的比方——你搬进新家，你得知道：如果厨房跳闸了，是只跳厨房那一路还是全家都黑？如果停水了，是这一户停还是整栋楼停？如果煤气泄漏，报警器多久会响？响了之后该关哪个阀门？

这些不是装修公司能告诉你的，也不是物业能替你记住的，是你得自己试一次才知道的。

没试之前，你以为"跳闸了扳回来就行"。试了才知道——你家电闸箱在玄关柜子后面，堆着鞋，真黑了你摸半天都摸不到。

第二个答案：我想知道——你们团队能不能接住。

"系统炸了不可怕，"客户老板说，“可怕的是你们团队慌了。”

他跟我讲了一个故事。他上一家供应商，系统上线半年，一直没出过大问题。结果有一次数据库真挂了，团队乱成一锅粥——运维不知道该找谁，开发不知道哪个脚本能用，负责人在飞机上联系不上，两个工程师在群里互相甩锅，最后全站挂了四个小时。

"你知道最让我寒心的是什么吗？"他说，“不是挂了四个小时。是那四个小时里，没有一个人能告诉我’现在什么情况、还要多久、影响哪些用户’。”

他要的不是"不出问题"，是出了问题的时候，你们团队知道自己在干什么。

就像家里着火——你不怕小火，你怕的是火一起来，爸爸找不着灭火器、妈妈抱着孩子不知道往哪跑、老人在客厅里慌得团团转。演习一次，每个人都知道自己要做什么——爸爸关煤气、妈妈拿湿毛巾、带孩子往门口走、集合点在楼下那棵大槐树下。

演习练的不是系统，而是人。

第三个答案：你们敢在我面前演练，我才敢真信你们。

这是他最后说的，也是最扎心的一句。

“小魏，你跟我说’我们高可用、我们多活、我们有灾备’——这些话我听过几百遍了。每个供应商都这么说。但敢在我面前、在生产环境、在工作日白天，真断一下给我看的——你们要是第一个，这合同我直接签三年。”

他说：“你敢在我眼皮子底下点火，说明你有灭火器在手、知道怎么灭、灭完能收拾干净。你连火都不敢点，跟我说你家灭火器是进口的——我凭什么信你？”

我端着茶杯半天没说话。

这三个答案叠在一起，我突然明白了一件事——

客户要的根本不是"看你们炸系统"。客户要的是信任。

信任不是你拍胸脯说"我们不会出问题"建立起来的——恰恰相反，越拍胸脯说不会出问题的人，越让人不放心。

信任是你敢当着他的面说：“来，我断给你看。断了你看着，两分钟切回来，用户都没感觉。”

这就像你请朋友来新家吃饭。你跟朋友说"我家消防做的可好了"，朋友笑笑不说话。但如果你拿起遥控器按了一下烟感测试钮，烟感器"嘀——“地响了，你拿起灭火器演示了一下怎么用，然后说"走吧，下楼看一眼逃生通道在哪”——朋友心里那块石头才真正落地。

不是"不会着火"让人放心，而是"着火了我知道怎么办"让人放心。

三、反直觉：敢演练的团队，才是真的高可用

我跟你讲个真事。

有一家公司，叫Netflix。你肯定知道，就是做流媒体那个，全球几亿人在上面看剧。

2011年，他们从自己的机房搬到了亚马逊AWS云上。搬完之后他们发现一件事——云上的机器，说挂就挂。今天这台挂了，明天那台网络断了，后天一个可用区整体出问题。传统的思路是"让机器别挂"——买更好的硬件、做更严格的运维、写更复杂的守护脚本。

Netflix那帮人想了个反直觉的招——既然机器一定会挂，那我们就让它在我们眼皮子底下挂。

他们做了个工具，叫Chaos Monkey——混沌猴子。想象一只猴子闯进你的数据中心，乱扯电缆、乱按开关、随便拔电源——这就是Chaos Monkey干的事。

但关键的细节是：这只猴子不是来搞破坏的，而是来帮你提前找问题的。

它只在工作日的白天上班时间出来捣乱。

不是半夜，不是周末，不是大促——就是工程师都在工位上、咖啡刚泡好、监控全开、回滚按钮就在手边的时候。猴子随机杀掉一台生产环境的服务器，然后工程师们看着系统会不会自动切过去、用户会不会受影响。

你猜怎么着？

刚开始的时候，猴子一出手，系统就出问题。今天杀了这台发现这台是单点、明天杀了那台发现超时设置太短、后天杀了另一台发现缓存没预热。每次出问题，工程师就修。修好之后，猴子下次再来。

一年之后——这只猴子白天怎么闹，用户看视频一点不受影响。

2012年平安夜，AWS us-east-1这个大区真出了大故障。Instagram、Pinterest一大堆网站都挂了好几个小时。Netflix呢？他们的工程师在家过圣诞，系统自动切走了流量，用户看剧一点没耽误。

Netflix的工程师后来说了一句名言，我觉得你应该记一辈子——

“Chaos Monkey doesn’t cause outages — it reveals them.”（混沌猴子不制造故障，它只是把本来就存在的故障提前暴露出来。）

猴子没来捣乱的时候，那些单点、那些过期的脚本、那些错误的超时设置——它们已经存在了。猴子不来，它们也在。只是等真出事的时候，它们就变成大事故。猴子来了，在大家都在的时候把问题暴露出来，修了，就没了。

这不是搞破坏，这是提前发现问题。

我再给你讲个国内的例子。阿里有个工具叫ChaosBlade，是CNCF的沙箱项目，阿里云、小米、工行、京东、B站、滴滴、招行、华为云这些公司都在用。PingCAP做了个Chaos Mesh，是CNCF的孵化项目，腾讯、美团、光大银行、360、小鹏也在用。腾讯和字节内部都有自己的演练平台。

这些不是什么"高科技玩具"，是大厂上线系统的标配动作。

我认识一个在字节做基础设施的朋友，他跟我说他们组每周三下午是固定的"捣乱时间"——系统随机抽几台机器、注入几个故障，团队就盯着监控看，看系统能不能自己扛过去。能扛过去，皆大欢喜；扛不过去，记下来修，下周接着来。

你猜他们组的线上事故多不多？

"很少出大事故，"他说，“因为大问题都在周三下午被我们炸出来了。剩下的都是小问题，系统自己就恢复了，用户都感觉不到。”

我再给你讲个反面案例，真实的、公开报道过的。

2017年，英国航空。工程师做机房电源切换的时候，误操作把主数据中心的电源切了。切了就切了吧，他们有备用电源——理论上备用电源应该无缝接管。

结果呢？备用电源因为从来没有实际演练过切换，配置是错的，根本没启动。

7.5万旅客滞留机场，三天才恢复，直接损失8000万英镑——差不多1亿美元。

8000万英镑。

你说他们没有备用电源吗？有。他们没有灾备方案吗？有。他们PPT上没写"高可用"吗？肯定写了。

但没演练过——备用电源就是个摆设。

就像你家买了个最贵的灭火器，放玄关柜子里，塑封都没拆。真着火了你拿出来——你不会用、保险销不知道往哪拔、喷嘴对不准火源。那这个灭火器跟没有有什么区别？

两种团队放一起比，你就看懂了——

一种团队，拍着胸脯跟你说"我们不会出问题"，一次演练都不做，结果一出问题就是大事故。

一种团队，每周三下午定期拉警报、随机杀机器、故意找麻烦，结果线上出的都是小问题，用户都没感觉。

这就是反直觉的真相——越是敢说"我们来断一下"的团队，越不容易出大事故。越是不敢演练、天天拍胸脯"我们很稳"的团队，一出事就是你从新闻上看到的那种大新闻。

为什么？

因为问题不会因为你不敢面对就不存在。它只会在你最没准备的时候、在业务最高峰的时候、在你睡得最香的时候，突然跳出来给你一棒子。

而演练，是把问题从"凌晨三点的大事故"变成"周二下午的小插曲"的唯一方法。

四、做演练和不做演练，差的到底是什么

我给你看几个数字，别害怕，都是公开可查的。

Gremlin是一家做混沌工程的公司，他们2021年发布过一份行业状态报告。结论很直接——频繁做混沌实验的团队，高可用性超过99.9%的比例显著更高，故障恢复时间明显更短，生产事故的数量也更少。

"99.9%可用性"听起来像个数字——我给你翻译成人话：一年允许宕机多久？99.9%是不超过8.76小时。99.99%是不超过52分钟。99.999%——也就是五个九——一年不超过5分钟。

你可能觉得"8个小时也不多嘛"。我再给你一个数字——行业调研显示，98%的组织表示单小时停机成本超过10万美元。金融、电商、航空这些行业，一小时的损失可能是几百万甚至上千万。

英国航空那一次事故，直接损失8000万英镑，是3天的停机——平均一小时差不多100多万英镑。

8个小时就是800万美元。52分钟就是80多万美元。5分钟就是几万美元。

这是钱的差距。

但钱还不是最要命的，最要命的是人心的差距。

我给你打个比方——

你买了辆车。你买不买保险？

买保险的人不是盼着出车祸，是知道万一出了车祸，有保险兜着。没买保险的车上路，你开得提心吊胆——旁边过一辆大货车你都要躲远点，因为你知道万一蹭了，修车钱全是自己掏。

没做过故障演练的系统，就像没买保险的车。你敢开上高速吗？

不是你车技不好，不是你车不好——是你心里没底。你不知道万一爆胎了备胎能不能用，你不知道万一刹车失灵了应急手刹灵不灵，你不知道安全气囊弹不弹得出来。

做过演练的团队和没做过演练的团队，平时看着差不多——系统都在跑、用户都在用、页面都能打开。但差距在出事的时候才看出来。

我亲眼见过两种团队处理故障的样子，天差地别。

没做过演练的团队——告警一响，所有人弹起来。“什么情况？”“不知道啊！”“哪个服务挂了？”“不知道，先重启试试！”“重启哪个？”"先全重启一遍！“群里消息刷得飞起，老板在群里吼"多久能好”，没人回答。一屋子人满头大汗，一个小时过去了还没定位到问题。最后全站挂了四个小时，事后复盘发现其实就是一个简单的主从切换——但切换脚本没人跑过，连接池没配重连，重试风暴直接打死了数据库。

做过演练的团队——告警一响，值班的人扫了一眼监控。"哦，是那个场景，上次演练过。“手指一点，执行切换脚本，两分钟搞定。群里发了句"已切流，观察中”，其他人该写代码写代码、该喝咖啡喝咖啡。MTTR——平均恢复时间——两分钟。用户都没感觉到。

这两种团队的差距在哪？不是技术差距，是心态差距。

没做过演练的团队，遇到故障是第一次遇见——慌乱、摸索、互相甩锅、走弯路。

做过演练的团队，遇到故障是第N次遇见——熟门熟路、按预案走、该按按钮按按钮、该打电话打电话。

你在演习里把每一种死法都死过一遍了，真死的时候你就不慌了。

这话说得有点糙，但理就是这个理。

我再给你讲一个"备胎漏气"的比喻——这是我入行时一位老运维教我的，一辈子忘不了。

他说：“很多团队都有’备胎’——备用电源、备用机房、备用数据库、备用链路。但你知道最坑的是什么吗？备胎放了五年没打过气，真爆胎了才拿出来——发现备胎也是瘪的。”

备用电源没接过真实负载、备库没做过切换演练、切换脚本上次跑还是半年前IP还没改的时候——这些备胎，跟没有有什么区别？

没演练过的灾备，不是灾备，是心理安慰。

就像你家玄关柜子里放了个灭火器，放了三年，压力指针早就到红区了，保险销锈死拔不出来了——你以为你有灭火器，其实你有的是一个红色的铁罐子。

我第一次做完整演练之后，最大的感触是——演练发现的每一个问题，都是白赚的。

那次我们断了一个可用区，发现了三件事：切换脚本里一个IP硬编码了，备库的连接池配置没配重连，负载均衡的健康检查间隔设得太长导致切流慢了40秒。

三件事，任何一件放在真实故障里，都可能让恢复时间从两分钟变成两小时。

但在演练里发现了——修了。下次真出事，这三件事就不存在了。

这就是演练的价值：不是证明你的系统没问题，而是帮你把本来就存在的问题，在它们变成事故之前找出来。

高可用不是PPT写了就算，而是真断一次还能活才算。你说你多机房高可用，倒是断一个机房给客户看看啊。

五、演练不是给客户看的，是给自己安心的

回到我们那次演练。

我们磨了三天，终于跟客户约好了时间——周二下午两点，大家都在，客户也在，监控全开，回滚按钮在手边。

那天我才真正明白一件事——演练不是演给客户看的，是演给自己看的。

我给你讲讲那次演练前后我们团队的心态变化，你就懂了。

演练前一周——怕。

运维小哥在改切换脚本，改完一遍又一遍，自己在测试环境跑了七八次。开发组长在核对每一个服务的连接池配置、超时设置、重试策略。测试同学在写演练当天的检查清单——每一个功能点都要验证一遍，确保用户无感知。

大家嘴上没说，但我看得出来——每个人都紧张。就像高考前一天晚上，明明复习过了，但就是睡不着。

演练前一天——更怕了。

晚上十点钟，运维小哥在群里发了一条消息：“我把回滚流程又过了一遍，有三个地方需要手动确认，我已经标红了。万一自动回滚失败，我手动操作，预计5分钟内能完成。”

开发组长回了句：“好。明天我盯业务指标，出了问题我喊停。”

测试同学回了句：“我已经把所有要验证的功能点列成了一张表，23项，5分钟能跑完。”

没人说"我怕"，但每个人都在做最坏的打算。

那天晚上我又失眠了。不是害怕炸——是觉得，就算炸了，好像也不是什么天大的事。我们有回滚方案、有手动预案、有所有人都在盯着。炸了就炸了，5分钟内切回来就是。

这个念头冒出来的时候，我自己都愣了一下。

我什么时候开始不怕了？

想了想，是因为——我们准备得足够充分了。知道可能炸在哪、知道炸了怎么办、知道多久能切回来。这份准备，不是PPT上写的，是我们一遍遍过脚本、一次次在测试环境验证过的。

演练当天——反而平静了。

下午两点整。所有人坐到位子上。客户那边也在线，视频开着。

我深吸一口气，跟运维小哥点了点头：“开始吧。”

他敲下命令。

监控屏幕上，被断掉的那个可用区的实例一个个变红——然后负载均衡自动把流量切到了另一个可用区，新的实例启动起来，业务指标稍微抖了一下——成功率从100%掉到99.7%，持续了大概30秒——然后恢复正常。

整个过程，90秒。

测试同学开始一项项验证功能。下单、支付、查询、退款——全部正常。

我看了一眼群里，没有用户报错。

客户老板在视频那头说了句：“挺好。切回来吧。”

运维小哥又敲了下命令，流量切回原来的可用区。又是90秒，一切正常。

结束。

大家坐在位子上，愣了几秒，然后开始鼓掌。

不是那种庆祝胜利的欢呼——是那种"原来真的可以"的、松了一口气的掌声。

演练后——心态完全变了。

演练之前，我们对系统的信心是"理论上应该没问题"。

演练之后，我们对系统的信心是"我亲眼见过它断了又切回来，我知道它能行"。

这两种信心的差距，是天壤之别。

演练之前，半夜告警响了，我第一反应是"完了完了，炸了炸了"，从床上弹起来开电脑。

演练之后，半夜告警响了——哦，是那个场景啊，上次演练过。拿起手机看一眼监控，如果是自动恢复了就翻个身继续睡。如果需要手动切，两分钟搞定。

故障演练的终极目标，不是证明你有多牛——是下次半夜告警响了，你翻个身继续睡，因为你知道系统自己会恢复。

这不是什么鸡汤，是真的。Netflix的工程师为什么能在平安夜AWS大面积故障的时候在家过圣诞？因为他们在工作日白天已经把这种场景演练过无数遍了。真出事的时候，系统自动处理了，根本不需要人爬起来。

我跟你说几个我们演练后团队里真实发生的变化——

运维小哥以前最怕半夜电话，现在他说：“怕什么？最坏的情况就是切流，脚本跑一遍两分钟的事。”

开发组长以前改代码总担心"这个改了会不会搞挂什么"，现在他说：“挂了就挂了，有演练在，真挂了也能切回来，不怕。”

以前新功能上线，大家紧张得像高考；现在新功能上线，该下班下班——因为就算上线出了问题，我们有兜底的底气。

这份底气，不是PPT给的，不是老板给的，是你自己亲手断过一次、亲眼看着它切回来——给你的。

我再给你说一个很玄乎但很真实的感受。

没做过演练之前，你看着你的系统，总觉得它是个黑盒子——里面跑着什么、哪里有坑、哪条路走不通，你好像知道，但你不敢确定。就像你走在一座桥上，桥看起来很结实，但你不敢跳，因为你不知道桥下面有没有裂缝。

做过演练之后，你对这座桥的每一个焊缝、每一根钢索、每一块桥板——你都亲自敲过、踩过、试过。你知道哪里结实、哪里需要加固、哪里可以放心踩。

你走在这座桥上的脚步，是踏实的。

这不是技术问题，是心理问题。但这份心理上的踏实，会反过来影响你的技术决策——你敢做更大的改动、敢发更快的版本、敢在白天做运维操作，因为你心里有底。

我后来跟那个客户老板喝茶的时候，他说：“小魏，你知道为什么我坚持要你们真断一下吗？”

我说：“您是想看看我们系统行不行。”

他摇了摇头：“不是。系统行不行你们自己最清楚。**我是想看看你们自己信不信你们的系统。**你们敢当着我的面断，说明你们自己信。你们自己信，我才敢信。你们自己都不敢断，跟我说’理论上没问题’——你让我怎么信？”

客户要的不是你告诉他不会出事，而是他亲眼看见出事了你能接住。

这句话我记到现在。

六、写在最后

讲了这么多，我想把这件事收一收。

你搬进新家的第一件事是什么？

是开香槟庆祝？是点外卖大吃一顿？还是把家具摆好、照片挂墙上？

都不是。

你搬进新家的第一件事，应该是——找到灭火器在哪、试一下烟感器响不响、看一眼逃生通道通不通、记住总电闸和煤气总阀在哪。

不是盼着着火。是万一着火了，你不慌。

故障演练也一样。

你做故障演练，不是盼着系统出问题，不是故意搞破坏，不是为了在客户面前表演"你看我们多专业"。

你做故障演练，是为了三件事——

第一，知道炸了会怎样。不猜、不赌、不靠理论，亲眼看见断一台机器、断一个机房、断一条链路，系统到底会怎么反应。心里有数，遇事不慌。

第二，练团队不练系统。系统坏了可以修，团队慌了才是真灾难。每个人都知道自己要做什么、按钮在哪、谁负责喊停——这比任何冗余架构都重要。

第三，给自己安心。没断过的系统，你永远心里没底。断过一次、亲手切回来一次——你睡觉都踏实。

我把这一篇的核心凝练成几句话，你记一辈子——

没演习过的消防通道都是装饰品。

故障演练不是纵火，是拉警铃做消防演习。不是真要点房子，是试警铃响不响、大家会不会跑、灭火器会不会用。

真故障不会挑你方便的时间来，但演习永远挑你最方便的时间。

客户要的不是你告诉他不会出事，是他亲眼看见出事了你能接住。

混沌猴子不制造故障，它只是提前暴露本来就存在的问题。

没恢复过的备份等于没有备份，没演练过的灾备等于没有灾备。

备胎放五年没打过气，真爆胎了才发现备胎也是瘪的。

演练发现问题不是失败，是最大的成功。问题在演练里炸，总比在业务高峰炸好一万倍。

故障演练的终极目标，是下次半夜告警响了，你翻个身继续睡——因为你知道系统自己会恢复。

搬进新家，先做消防演习。不是开香槟的时候做，是搬进来第一天就做。

因为你和你的家人，要在这个家里住很久。火不会因为你搬了新家就不来——但你可以在它来之前，就做好准备。

系统上线也一样。上线不是终点，是你和你的客户要在这个系统上"过日子"的起点。别等真着火了才找灭火器。

这一篇讲的是"为什么要做故障演练"——是心智，是认知，是那个让你从"不敢断"到"敢断"的心理转折。

但光敢断还不够。你不能上来就在客厅放一把火——那不是演习，那是纵火。

怎么在自己家点火不烧房子？怎么控制火的大小？怎么保证灭得回来？怎么让每次演练都安全、有效、不出真事故？

这是有章法的。不是勇气的问题，是纪律的问题。

下篇卷袖子干活——怎么在自己家点火不烧房子。我给你讲五道闸，一道一道落下来，把火控制在盆里、控制在厨房里、控制在你能灭的范围里。最小半径、可观测、可回滚、有预案、分批次——五道闸焊死，你就敢在自己家点火了。

我们下篇见。

关于 ArchAIHarness

这篇文章是「看懂 AI 与智能体」专栏的一部分，由ArchAIHarness持续输出。

ArchAIHarness 是一套面向 AI 时代软件工程的人机协同架构哲学与公开工程资产，主张：

架构师定义秩序，AI 在秩序中生长。人立法，AI 执行，体系审计。

如果你也希望 AI 在明确的架构边界内协作，而不是在混沌中碰运气，欢迎到 GitHub 上看看我们在做什么：

• 组织主页：github.com/ArchAIHarness — 了解完整理念与资产全景
• 本专栏：zhuanlan-ai-and-agents— 所有文章的源码与发布记录
• 实践指南：docs— 架构哲学、工程方法和落地指南
• 开源工具：agent-workflows— 可复用的 AI 协作 Agents、Skills 与 Tools
• 工程样例：framework— DDD + AI 协作的工程底座，展示如何在开发中融合 AI

Engineered by Architects · Empowered by AI · Audited by Discipline