归档

一次误删 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 的索引被切成

大促压测：Redis 被打到 12 万 QPS，还是扛不住 3 月大促前做全链路压测，商品详情页的接口目标 5 万 QPS。单 Redis 集群（3 主 3 从，Redis 6.2）在 12 万 QPS 时 CPU 跑满，P99 从 3 ms 飙到 47 ms，再往上就开始超时。加节点成本太高，而且