火线上的操作顺序
英文版：English
症状
一个租户的查询量冲到基线之上很远。serving 延迟上升，依赖链错误率攀升，异步重算开始和消息队列、数据库争夺同一份余量。
顺序，以及为什么不能重排
-
**先止血。**把流量 50/50 切到第二个集群。秒级可逆，为下游所有环节买到余量，不改变任何行为。
-
**再卸载非关键负载。**动态降级非关键的异步重算：运行时配置把它限流到零，不用重启。系统继续履行主契约，后台工作让路。
-
**最后带上限扩容。**serving 与异步池在显式上限下扩容；消息队列分区翻倍；数据库垂直扩 2 倍。
先扩容是直觉动作，也是错误动作：在失控的流入下增加消费者，等于把激增直接喂给最慢的有状态组件。数据库会被本该拯救它的容量推下悬崖，而压力之下追加的容量对秒级问题来说总是晚几分钟。先卸载，扩容才安全。
验证纪律
每一步都要自证之后才有下一步：错误率、P95/P99、消费积压斜率反转（积压必须在下降，持平不算恢复）、数据库余量，每项至少 10–15 分钟稳定窗口。回滚判据提前分级，降级操作是一张清单，不是凌晨两点的临场判断。
过载之下，操作顺序就是决策本身。清单上每一项都是对的；顺序错了，同一张清单会把系统放倒。