那天，我坐在挪威奥斯陆NDC大会一个黑漆漆的会议室里，听一个叫巴里·奥莱利的大佬讲课。
他一开口，说的竟然是“十万个灯泡”！每个灯泡要么亮，要么灭，还都连在一起。
听起来像在讲童话故事，对吧？但这家伙可不是在讲故事，他是在聊软件架构！
结果，他讲得我脑子都炸了！这不是又一个什么“框架”或者“套路”，而是完全颠覆了我们怎么去设计系统的思路，简直是脑洞大开！
我一直觉得，做事得先把风险想清楚。我还写过一本书，叫《忽视风险的风险》（听起来是不是很拗口？），里面讲了怎么提前把可能出问题的地方找出来，算算概率，列个计划，就像列个“防坑指南”。我一直觉得这招挺靠谱的。
但巴里这哥们儿，给我整了个新花样，叫“剩余理论”，让我发现自己之前想的还不够全面！
巴里大佬的"剩余理论（系统求生理论）"就问一个骚问题：
✅要是被陨石砸中，你的系统还能剩点啥？
而我的主打重点是：
❌要防哪些风险？
风险分析：防坑指南
风险分析就像是给你的计划做个“体检”。
你得先列个表格，把所有可能出乱子的地方写下来。比如，网站崩了、服务器炸了、客户跑光了……然后给每个问题打分：这事儿发生的可能性大不大？后果严重不严重？把这两个分数一乘，得出个“危险指数”。
如果某个问题特别容易发生，而且后果超级严重，那你得赶紧想办法，设计个“防火墙”来防着它。如果问题不太可能发生，后果也不咋地，那就先放一边。
比如，你开了家咖啡店，怕早上高峰期订单太多系统崩了，你就得提前想好：如果每秒来了1万个订单，咋办？写个应急方案放那儿，以防万一。
但问题来了：你咋知道会出啥问题？有些事儿你压根儿想不到！比如，TikTok上有人把你家咖啡店的“秘密菜单”拍了个视频，火得一塌糊涂，订单直接爆棚！或者，早上忙得要死的时候，卫生检查员突然杀到！再或者，隔壁新开的咖啡店搞半价促销，把你客户全抢走了！这些“幺蛾子”你咋防？
剩余理论：不怕乱，怕不抗揍！
巴里的“剩余理论”不走寻常路，它不问“我们得防啥风险？”，而是问：“如果系统被各种奇葩事儿冲击，它会咋样？”这俩问题听起来差不多，但差得老远了！
风险分析是防你能想到的坑，而剩余理论是让你造个系统，哪怕遇到想不到的坑，也能挺住！
巴里说，复杂的系统就像那十万个灯泡，互相连着，一个灯泡坏了，可能整串灯都得完蛋！软件系统也一样，零件之间耦合太紧，一个地方崩了，全系统就“全村一起火”。他的目标是把系统改造成“抗揍”的，能适应各种意外，还不会直接挂掉。
啥是剩余理论？
这理论听着高大上，其实就是教你怎么造一个“打不死的小强”系统。它有几个核心点：
- 压力源：就是那些可能搞乱你系统的意外。比如，服务器挂了、客户暴增、甚至……哥斯拉把你数据中心踩扁了！（哈哈，没开玩笑，连这种奇葩情况都得考虑！）
- 残留物：系统被揍了一顿后，还能活下来的部分。比如，网络崩了，但你还能手动记订单。
- 吸引者：系统在压力下会“自然滑向”的状态。比如，全系统崩溃，或者订单卡死。
- 发病率矩阵：一个表格，帮你看清楚压力源和系统零件的关系，哪儿最容易崩。
咋操作呢？简单来说：
- 脑洞大开，想一堆可能搞砸系统的奇葩事儿。
- 看看这些事儿会咋影响你的系统。
- 找出最脆弱的地方。
- 设计能抗住这些压力的方案。
- 再拿新的奇葩事儿测试，直到系统“抗揍”为止。
举个例子：咖啡店的移动App
想象你开了家咖啡店，开发了个App，顾客可以提前点咖啡、付钱，然后直接来拿，省得排队。目标是让店里不那么乱，顾客也开心。
用传统方法，你会把App分成几块：订单系统、支付系统、厨房显示订单、取货流程。然后你开始防风险：万一支付系统挂了咋办？万一网络断了咋办？
但用剩余理论，你先脑洞大开，想一堆“幺蛾子”：
- 支付平台（比如Stripe）挂了。
- 店里Wi-Fi瘫痪了。
- 咖啡师把平板摔了，屏幕碎了。
- 周一早上7:45，40个订单挤进来。
- 顾客点了咖啡却不来拿。
- 隔壁店半价促销，抢你生意。
- 卫生检查员高峰期来查卫生。
- TikTok上你家咖啡火了，订单爆棚！
然后你把这些“幺蛾子”画个表，看看会咋砸你的系统。
比如，Wi-Fi挂了，订单收不了、支付不了、厨房看不到订单、顾客收不到通知……全崩！周一高峰期也一样，系统直接“烧了”。TikTok火了更惨，服务器直接“冒烟”。
这时候你发现，问题出在系统零件太“黏”了，一个坏全坏。巴里管这叫“吸引者”，就是系统一出问题就奔着“全村着火”的状态去。
咋解决？
传统方法是加“后备胎”：多买几台服务器、加条备用网线、雇更多人。但剩余理论说，重点不是防着不坏，而是让系统坏了也能活！
比如：
- Wi-Fi挂了？ 别光想着买贵网线，搞个“网络挂了星期二”，当天进店点单打八折！系统崩了还能赚一波好感！
- 早上订单爆棚？ 别把所有系统都升级，弄个“快闪菜单”，7-9点只卖五种简单饮品，减轻系统压力，还显得你店有特色！
- 顾客点了不来拿？ 别傻傻吃亏，定个规矩：15分钟没人领的咖啡，免费送给排队的顾客，变废为宝，还赚个好名声！
改完再测，发现系统“抗揍”多了！新的事件矩阵显示，Wi-Fi挂了只影响部分功能，订单爆棚也不会全崩。你还加了点新玩意儿：
- 技术上：用俩支付平台（Stripe+Square），加个备用收据打印机，员工手机开热点当备用网络。
- 业务上：搞“网络挂了星期二”促销、快闪菜单、无人领咖啡捐赠计划，还跟隔壁书店共享Wi-Fi，弄个“常客板”手写订单当备用。
这下，系统不怕坏了，甚至坏了还能“反败为胜”！快闪菜单可能变成你店的招牌，捐赠咖啡还能拉拢顾客忠诚度。
总结：别怕乱，怕不抗揍！
剩余理论不是要取代风险分析，而是让它更牛。你还是得找风险，但别觉得自己啥都能猜到。世界太乱了，竞争对手、病毒视频、设备故障……啥都可能冒出来。与其假装能防住所有坑，不如造个能“挨揍”的系统。
巴里让我换了个角度看问题。建筑师造房子前会做压力测试，看楼会不会塌。咱们做软件也得这样，模拟各种奇葩情况，看系统能不能挺住。
我不是剩余理论的专家，巴里要是在这儿看到我这笔记，估计得笑我！想知道更多？去看他的演讲，或者读他的书《残留物：软件架构中的时间、变化和不确定性》。最重要的是，试试看！拿你的系统做个“压力测试”，你会发现不少新花样。
当你为“乱”做好准备，你就不怕它了！
banq注：注意系统涌现崩塌，本来一个个小故障单独坏了没啥，但是如果一起坏了，会涌现1+1>2现象，防止部件同时发生故障导致的级联崩溃。