单接口变慢和整个服务变慢，入口完全不是一回事
15:41，值班群里丢来一句话： “/order/confirm 超时了。”
Java
Java 排障专题
这里按页继续往后翻，仍然围绕接口变慢、数据库等待、线程池、JVM 与线上问题排查这些问题。
如何建立接口慢 / 超时专题的值班检查表？
接口慢和 timeout 这类事故，难的往往不是不会查，而是现场一乱，大家又回到临时拼顺序：
慢接口排查时，日志、Trace、指标三者先看谁？
有一次慢接口排查，最先把大家带偏的不是技术问题，而是一条日志。
慢 SQL 修完了，接口还是慢，怎么做全链路复核？
很多慢接口排查，都会走到一个很让人挫败的时刻：
Spring Boot 环境不一致怎么查？从 profile、挂载文件到 JVM 参数逐项核对
“同一套代码，怎么会跑出两套结果？”
Spring Boot 服务只在高峰期漂移，该从线程池、连接池还是缓存切入？
这类问题我一般不从“线程池、连接池、缓存先看哪个”开始问，而是先盯住一台在高峰期会发飘的实例。
稳定性治理先做容量评估、慢链路梳理还是告警分层？
那次把顺序逼出来的事故，发生在一个周三晚上。
没配 startupProbe，为什么慢启动会被当成启动失败？
最像“应用自己起不来”的慢启动现场，往往长这样：