为什么想上 Mesh 团队有 30+ 微服务，TLS、重试、熔断这些逻辑散落在每个 Dubbo/Spring Cloud 应用里，升级一次 SDK 全员陪跑。一次熔断规则改版，光是让各服务升级 SDK 就花了两周，还有三个老服务因为没人维护迟迟不动。我们想试试把这部分下沉到基础设施，于是拉了一套 I
周五下午的告警 2022-03-31 Spring4Shell（CVE-2022-22965）被公开，我们安全群里炸了。我负责的两个服务跑在 Spring Boot 2.3 上，得立刻确认是否在影响范围内。应急响应的第一步不是升级，而是确认影响面——盲目全量升级可能引入别的问题，先搞清楚"我中没中"
背景 上周联调一个订单状态机，本地用 Redis 做幂等缓存。单元测试里我习惯用 Mockito 把 RedisTemplate 整个 mock 掉，结果上线后在缓存过期那块直接炸了。mock 根本没覆盖 TTL 和原子自增的真实语义，自测全绿却带着隐患上了线。 复盘那次事故，根因是我们对"缓存是否
一次误删 ConfigMap，让我重新想发布这件事 年初我们还是"人肉发布"：本地打镜像、kubectl set image、改几个 ConfigMap。有次同事手滑把生产环境的 ConfigMap 改错了一个 value，Pod 起来就读不到正确配置，故障持续了 12 分钟。事后复盘，我意识到问题
滚动发布时，监控里出现了 0.3% 的 5xx 毛刺 4 月一次常规滚动更新，发布过程中 Grafana 的 5xx 曲线冒出一排小毛刺，单个实例发布期间大约丢了 0.3% 的请求。量不大，但每次发布都有，说明是上下线姿势不对，不是偶发。 我们的 Java 服务跑在 K8s 上，Spring Boo
一次发布把下单接口打挂了，CI 里却全是绿的 4 月一次常规发布后，下单接口 5xx 飙到 12%。回看 CI 流水线，单元测试全绿。问题出在：单元测试只覆盖了方法内部逻辑，没人验证"接口契约"本身——前端传的字段名改了，后端字段名也跟着改，但两边没对齐，网关层反序列化直接失败。 这事之后我把接口自
周五晚上十点，安全组在群里丢了三个 CVE 编号 2021 年 12 月 10 号晚上 22:17，公司安全组群里一条消息，只有三行： CVE-2021-44228 Log4j2 RCE，影响版本 2.0-beta9 至 2.14.1，请各业务线今晚完成自查并反馈。 那时候这个漏洞还没被媒体炒起来，
为什么又搞了一套 Prometheus 我们本来有 SkyWalking 8.6，链路追踪和拓扑都挺好用。但它有两个地方不满足需求：一是数据默认只存 7 天（ES 成本摆在那），二是加自定义业务指标比较麻烦，我更习惯"自己埋点 + 自己配告警"这套。 于是给核心的几个服务加了 Prometheus
上了 K8s 之后，Pod 每天重启三四次 6 月初把订单服务迁到公司新搭的 K8s 集群（1.19）。上线第一天就发现问题：Pod 频繁重启。 $ kubectl get pod -l app=order-service -n trade NAME
编译一次 8 分钟，改一行代码等半天 5 月中旬，我们的主工程已经长成一个 47 个 package、21 万行的单体。mvn clean install 的时间： $ time mvn clean install -DskipTests [INFO] BUILD SUCCESS [INFO] To
