慢查询告警响了，但我不知道是哪条 SQL 有天早上 Prometheus 报了一条 mysql_slow_queries 突增，我登录数据库一查 SHOW PROCESSLIST，满屏都是 Sending data 的查询，根本分不清谁是元凶。那时候我们的慢查询治理还是"出问题了才去看日志"，属于事
一次误删 ConfigMap，让我重新想发布这件事 年初我们还是"人肉发布"：本地打镜像、kubectl set image、改几个 ConfigMap。有次同事手滑把生产环境的 ConfigMap 改错了一个 value，Pod 起来就读不到正确配置，故障持续了 12 分钟。事后复盘，我意识到问题
读源码时的一句注释，让我重新审视响应式 前阵子读 Spring Data R2DBC 的源码，看到 R2dbcEntityTemplate 里一句话："JDBC blocks the calling thread; R2DBC does not." 我当时手头正有个网关服务，Tomcat 的线程池经
消费组重平衡，队列堆积了 30 万条 我们一个交易通知服务用 RocketMQ 4.9 做消费，某天上午扩容，新增 2 个消费者实例。按理说扩容应该更快，结果监控上"消费积压"从 0 飙到 30 万条，持续了 20 多分钟才消化完。组员在群里贴了张图："加机器反而更慢了？" 根因在老架构上：Rock
压测时 CPU 打满，top 却看不出热点 上个月我们对订单导出服务做容量评估，用 JMeter 打 800 并发。奇怪的是：应用进程 CPU 占用 760%（8 核几乎跑满），但业务代码里我自认为的"重计算"那段——一个金额汇总循环——在抽样栈里占比不到 8%。同事在群里问："你那个汇总到底慢在哪
RSS 涨到 5.8 GB，但堆才用了 1.2 GB，也没 OOM 4 月底值班，监控告警：订单服务一个实例的容器内存（RSS）从 2 GB 缓慢涨到 5.8 GB，持续了四天还在涨，但没有抛 OutOfMemoryError。K8s 的内存 limit 是 6 GB，再涨就要被 OOMKilled
滚动发布时，监控里出现了 0.3% 的 5xx 毛刺 4 月一次常规滚动更新，发布过程中 Grafana 的 5xx 曲线冒出一排小毛刺，单个实例发布期间大约丢了 0.3% 的请求。量不大，但每次发布都有，说明是上下线姿势不对，不是偶发。 我们的 Java 服务跑在 K8s 上，Spring Boo
一次发布把下单接口打挂了，CI 里却全是绿的 4 月一次常规发布后，下单接口 5xx 飙到 12%。回看 CI 流水线，单元测试全绿。问题出在：单元测试只覆盖了方法内部逻辑，没人验证"接口契约"本身——前端传的字段名改了，后端字段名也跟着改，但两边没对齐，网关层反序列化直接失败。 这事之后我把接口自
升级 Redis 7.0 时，我把一段 Lua 脚本换成了 Functions 4 月 Redis 7.0 正式发布，我们把集群从 6.2 升到 7.0。升级本身平滑（RDB/AOF 兼容），但翻 release notes 时发现一个我一直想要的东西：Redis Functions。我们原本用 L
集群重启后要 40 分钟才能变绿，问题出在分片数 我们用 ES 做商品搜索和日志检索，版本从 7.15 升到 8.0（2022 年 2 月发布，正式用上）。3 月一次故障演练，重启集群后主分片恢复花了 40 分钟才变绿，期间搜索不可用。排查下来，根因是分片数设错了：一个 200 GB 的索引被切成
