排查与解决要分离：先用"几板斧"恢复服务，再从容排查根因

问题排查这件事本身是复杂、不可控的——正如前述”原因、路径、现象不是一一对应”所揭示的，排查往往需要反复试探、可能耗时很长，如果把”排查清楚根因”当成”恢复服务”的前提条件，等于让本该尽快恢复的业务，去等待一个耗时不可控的过程。因此系统设计和应急响应上一条重要建议是：不要把排查和解决混在一起，应当尽量先解决、再排查——先用相对固定、见效快的几种手段把服务恢复到可用状态：重启、回滚、扩容、降级、迁移，这几板斧不追求理解问题的根本原因，只追求最快速度止损；等服务恢复、业务影响止住之后，再从容地去做真正的根因排查，这时排查工作不再背负着”业务还在持续受损”这个巨大压力，可以更冷静、更系统地进行。这个原则和后续几条建议是一体的：系统要尽可能对外暴露内部状态和干预手段（少打一句关键日志、没把某个变量输出出来，都可能导致排查时不得不绕一个大圈去用复杂工具查询），以便”解决”和”排查”这两个阶段都能高效执行；系统本身是不稳定的，所以高可用架构设计必须考虑隔离，为”实在不行了”这种最坏情况留出退路（这样才能在触发”先解决”这几板斧时真正有路可退）。这个案例给出的核心启示是：应急响应和事后复盘是两件性质完全不同、不应该被绑在一起处理的工作——应急响应追求的是速度和确定性（用几种见效快的固定手段止损），事后复盘追求的是准确性和完整性（找到真正的根本原因，避免问题再次发生），把两者混在一起处理，往往会让应急响应被拖慢（因为想着”要不要再查查根因”而犹豫），也会让排查工作被业务压力干扰而变得仓促和不彻底。