同事的问题：我加了 @Cacheable，为什么没生效 上周三下午，组里的小杨问我："我在方法上加了 @Cacheable，压了 100 次，数据库慢查询日志里还是 100 条，Redis 里也看不到 key，是不是缓存没配好？" 我过去看了一眼他的代码： @Service public class
现象：一个接口慢，但监控上看不出慢在哪 客服反馈"订单详情页打开要转好几秒"，我们查 Grafana，GET /order/{id}/detail 的 P99 从平时的 120 ms 涨到了 900 ms 左右，P50 没变。也就是说不是全量慢，是部分订单慢。 SkyWalking 8.6 上只能看
现象：发布到 K8s 之后 Pod 一直在重启 周一上午发了个小版本，只改了几行。结果 K8s 里这个 Pod 一直 CrashLoopBackOff，被杀了五次。 $ kubectl get pod -n prod | grep order order-service-7d9f8b6c5-x2m4
背景：一封邮件引发的升级 五月底基础架构组发了封邮件，说 Oracle JDK 8 从 8u211 起商业使用要收费，公司统一切 OpenJDK 11（下一个 LTS），老服务年底前迁完。我们组四个服务，清一色 Spring Boot 2.3.12 + JDK 8u282。我手上这个订单服务先动，Q
上了 K8s 之后，Pod 每天重启三四次 6 月初把订单服务迁到公司新搭的 K8s 集群（1.19）。上线第一天就发现问题：Pod 频繁重启。 $ kubectl get pod -l app=order-service -n trade NAME
升级到 2.4，服务起不来了 6 月初，把一个服务从 Spring Boot 2.3.7 升到 2.4.6。改完 pom 里的版本号，启动，直接炸： *************************** APPLICATION FAILED TO START *******************
编译一次 8 分钟，改一行代码等半天 5 月中旬，我们的主工程已经长成一个 47 个 package、21 万行的单体。mvn clean install 的时间： $ time mvn clean install -DskipTests [INFO] BUILD SUCCESS [INFO] To
半年内第四次，又是新 SQL 没索引 2021 年 5 月 10 号，一个上线不到两小时的功能把数据库打挂了。原因是一段新写的查询没走索引，全表扫 4000 万行。 难受的是，这不是第一次。我翻了下过去半年的故障记录： 日期 原因 影响时长 2020-12-08 新接口 SQL 未加索引 47 分钟
实习生问我：这堆 GC 日志到底看什么 4 月底，团队来了个实习生。有次他看到我电脑上的 gc.log，问了一句："这一行行的数字，你是怎么看出问题的？" 2021-04-28T09:14:22.118+0800: 341882.221: [GC (Allocation Failure) [PSY
8200 万行数据，怎么搬到 32 个分片里去 接上一篇。分片规则定好了、ShardingSphere 配好了，接下来的问题是：老库里那 8200 万行数据怎么搬过去，而且不能停服。 这篇文章写的是迁移本身，跟分片设计是两件事，但难度可能更大。 先算停机方案要多久 最省事的做法是挂维护页，导出导入。
