寓言
同一栋大楼，两种不同的应对手册
市中心一栋综合商业体，运营团队有两份应急手册。第一份手册管对外通道：如果通往地铁站的连廊发生烟雾报警，立即关闭连廊闸门，同时停止引导客流往那个方向走。闸门落下的标准很明确——连续三次烟雾传感器触发，或者一次人工确认的火警。关闸之后不再试探，直到消防检查完成才重新打开。
第二份手册管内部服务：如果供电容量突然下降了百分之四十，不是所有区域都停电。先把景观照明、广告屏和备用电梯关掉，优先保证收银系统、冷藏设备和逃生通道照明。哪些功能先放弃、哪些必须保，事先排好了优先级。
有次空调系统故障导致楼层温度飙升。运营团队同时触发了两个动作：楼层消防监控数据开始异常，但没到烟雾报警的阈值，闸门没关。与此同时，因为空调压缩机过载影响了整体供电稳定性，运营团队关掉了半数广告屏和所有景观喷泉，把负荷降了下来。两件事发生在同一天但执行的是不同手册。
事后复盘，一个新来的主管提了疑问：空调故障那次，既然已经知道温度异常，为什么不直接把相关楼层的入口闸门也关了？老主管解释：闸门关不关，看的是通道那一端的传感器，不是大楼这边的温度计。如果地铁站那头一切正常，关了闸门只会把客流挤到地面路口造成新的拥堵。熔断器保护的是「那个依赖还值不值得继续调用」，不是「我这边不舒服了就先断掉」。
另一个方向也出过误解。有次广告屏系统自己挂了，有人建议启动降级——把外围系统切了省资源。但广告屏本身就是非核心功能，它挂了不影响收银和冷链，不需要降级。降级的决策依据是核心资源的供给能力，不是随便哪个系统出问题都去关别的系统。
后来他们在墙上画了一张流程图：外部依赖出问题→熔断器判断→切断调用，防止连锁雪崩。内部资源紧张→降级策略判断→关闭非核心功能，保住核心业务的吞吐。两条线各自有触发条件和评估指标，但落在同一张事故报告表上时，必须标明触发了哪一个。
楼管长在季度培训上总结得直白：熔断器是对外关一扇门，怕的是对面的火烧过来。降级是对内减一批负载，怕的是自己的电不够用。两个动作都可以叫“保护”，但保护的是完全不同的东西。