凌晨两点的告警：Old 区 12 分钟涨满 2 月 18 号凌晨 2 点 07 分，值班电话响了。监控看板上，我们的智能问答服务实例 qa-svc-7d9f 的老年代曲线是一条近乎垂直的直线：从 1.2 GB 到 5.8 GB 用了 12 分钟，然后 Full GC，STW 4.7 秒，接着又是一条
27 万个虚拟线程，把 4 核 8G 的容器拖死了 12 月 6 号凌晨，告警电话把我叫醒。AI 批处理服务的响应时间从正常的 300 毫秒涨到 30 秒以上，CPU 100%，但业务吞吐几乎归零。 # 监控截图里的数据 jvm_threads_live
安全部甩来 213 个漏洞，限期两周整改 11 月初，安全部门用他们的商用扫描器对我们的 14 个 Java 服务扫了一遍，发来一份 Excel：213 个"高危及以上"漏洞，要求两周内清零。 我们团队三个人，14 个服务，平均每人每周要处理 35 个漏洞。第一反应是不可能完成。但真正让我头疼的不是
周五下午 16:42，37 万行订单没了 11 月 15 号周五，下午四点四十二，我正准备收拾东西下班，监控群里炸了。 [16:42:07] 告警：order_center 慢查询数 5 分钟内 0 → 143 [16:42:31] 告警：order_center QPS 从 3800 跌到 41
毫无征兆的线程池打满 新上线的网关用 JDK 21 虚拟线程处理请求。压测到 8000 并发时，吞吐量突然从 1.2 万 req/s 跌到谷底，响应从 30ms 飙到 8 秒，CPU 却只有 40%——典型的"线程都在等，CPU 没事干"。jstack 一看，200 个平台线程（carrier）全卡
发现：21 点 47 分，Pod 开始被 OOMKilled 2021 年 12 月 28 号晚上，年终大促的预热场。21:47 分监控群开始报： [P1] promotion-service 实例不可用 事件类型：ContainerOOMKilled 命名空间：prod Pod：pro
告警：0 点 15 分，堆积 1200 万 8 月 31 号晚上大促，我们值守到凌晨。0 点 15 分，告警响了： [P1] RocketMQ consumer lag: group=order-sync-consumer, topic=ORDER_SYNC_TOPIC diff=1,20
现象：发布到 K8s 之后 Pod 一直在重启 周一上午发了个小版本，只改了几行。结果 K8s 里这个 Pod 一直 CrashLoopBackOff，被杀了五次。 $ kubectl get pod -n prod | grep order order-service-7d9f8b6c5-x2m4
晚上八点半，所有接口一起超时 4 月 15 号晚上八点二十几分，告警群开始刷屏：订单服务全部接口超时，错误率 100%。 Pod 是活的，CPU 和内存都正常，CPU 只有 31%。但所有请求都在报同一个错： 2021-04-15 20:23:41.882 ERROR [http-nio-8080-
十一月二十三号：一条 SQL 拖垮了五个服务 那天上午 10:07，监控大屏开始变红。从商品服务开始，10 分钟内波及五个服务，最后整个交易链路不可用，持续 23 分钟。这篇把整个过程复盘一遍，包括我们当时做错的判断。 时间线 时间 事件 10:07 商品服务接口 TP99 从 45ms 涨到 3.
