安全部甩来 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
搜索改版做了三个月，用户还在搜不到东西 公司的技术文档站搜索，原来是纯 Elasticsearch BM25。今年 8 月我接手改版，第一版直接换成了向量检索，想着"语义搜索肯定更强"。上线一个月，搜索结果的点击率从 68% 掉到 51%，用户投诉反而变多了。 我把 200 条低点击率的 query
数据量涨到 2300 万，向量检索 P99 从 60ms 崩到 1.8 秒 我们的商品语义搜索，7 月份上线时是 420 万条向量，P99 稳定在 60 毫秒。到 10 月底商品库扩到 2300 万条，接口 P99 涨到 1820 毫秒，同时 Milvus 集群的内存水位长期在 91%，隔三差五触发
10 月账单 11.7 万，调用量才涨了 40% 11 月 1 号早上收到云厂商账单：10 月大模型调用费用 11.73 万元。9 月是 4.31 万，涨了 172%。但同期我们的业务量只涨了 40%，这中间肯定有浪费。 我花了两天做了一次完整的用量审计，最后把 11 月的账单压到了 5.1 万。过
没人动过代码，准确率从 87% 掉到 71% 10 月中旬的一个周二，运营反馈客服机器人的回答质量明显变差。我看了一圈发布记录，前后三天没有任何代码上线。但监控上的数字是实打实的： chat_answer_quality_score{date="2024-10-14"} 0.871 chat_an
三个人都点了 Approve，上线还是出了事故 9 月底的一次线上故障，起因是个不到 200 行的 PR：修改优惠券核销逻辑。三个人 review 过，两个 LGTM 加一个 Approved，上线两小时后，监控发现优惠券超发了 1.7 万张。 复盘时我把三个人的评论翻出来看，发现一个规律： 评审人
HPA 扩容跟不上流量，问题出在启动要 8 秒 10 月初做了一轮容量压测，暴露了个之前没重视的问题。我们的 AI 网关在 K8s 上配了 HPA，CPU 超过 60% 就扩容。压测时流量从 500 QPS 拉到 3000 QPS，HPA 在 15 秒内触发扩容，但新 Pod 从调度到 Ready
网关从 3.2 升到 3.3，我把虚拟线程打开了 国庆前最后一周，我把内部 API 网关从 Spring Boot 3.2.5 升到了 3.3.4。这次升级的动机不是安全补丁，而是 3.3 里那几个终于能用的东西：虚拟线程的正式支持、CDS 启动优化，还有服务连接抽象。 网关是个典型的 IO 密集型
文档下线三天了，客服机器人还在引用它 9 月中旬出了个不大不小的故障。运营下架了一份过期的《海外退换货政策 V1》，三天后还有用户在客服机器人里问到"海外订单 30 天可退"，而新政策是 15 天。用户截图投诉到了客服主管那里。 我查了一圈，问题出在存储架构上。我们当时的 RAG 是这样的： MyS
