背景：团队新人又慌了
七月一次支付成功率骤降，新来的同学第一反应是「我先重启试试」。结果重启把现场冲了，后面复盘只能靠猜。这种事不是第一次，我干脆把我们的线上排查 SOP 固化成文档，要求所有人遇事先照流程走，别凭直觉乱动。
第一原则：止血优先
出问题第一时间想的不是「为什么」，是「怎么不让它继续坏」。顺序通常是：
- 隔离：摘流量、限流、熔断，把故障范围圈住。
- 降级：切到备用逻辑或默认值，保住主流程可用。
- 回滚：确认是最近发布引入的，直接回滚到上一个稳定版本。
重启是最后手段，而且要先 dump 堆和线程栈再重启，否则现场归零。那次支付故障，正确的止血是立刻对异常商户限流，而不是重启整个集群。
信息收集：先建全景再下钻
止血后开始收集证据，按可观测性三支柱拿：
- 指标：成功率、QPS、P99、错误码分布，先定位是全局还是单点。
- 链路：挑一条失败 trace，看卡在哪个服务、哪个 SQL/RPC。
- 日志：用 traceId 拉出该请求的完整日志，找异常堆栈。
千万别一上来就翻某个服务的日志大海捞针，先有指标指向再下钻，效率高十倍。
假设验证：一次只改一个变量
定位到可疑点后，用假设-验证的闭环推进：
假设：DB 连接池耗尽导致超时
验证：show processlist 看连接数 + 监控连接池活跃数
结果：活跃连接 200/200 打满 → 假设成立
对策：调大 maxPoolSize 或排查连接泄漏
关键是每次只动一个因素，否则改完不知道是哪个生效。我们吃过亏：同时调了超时和连接数，恢复后分不清根因，下次照样犯。
复盘沉淀：让事故不再白交学费
故障关闭前必须写复盘，且要落到三件事：根因（技术上的为什么）、触发条件（什么情况下会再发生）、加固动作（监控补点、代码修复、预案）。我们规定复盘要进知识库，并给同类服务加一条针对性告警，把「人肉发现」变成「系统预警」。
先到这
《线上问题排查 SOP：一套可复制的方法论》这块我前前后后踩了不止一次。今天先写这些，后面想到新的再补。