客服机器人上线两周,P95 首字延迟 4.2 秒 9 月初,我们给内部工单系统做的智能客服上了线。第三天开始收到投诉:"问一句话要等四五秒才出字"。我拉了 Grafana 看,数据比投诉描述的还难看: gateway_request_duration_seconds{quantile="0.95",
把命运交給一家供应商太冒险 工单助手全量依赖 OpenAI,某次它区域性抖动 40 分钟,我们的自动回复全挂,运营被迫人工顶上,积压了上千条工单。AI 能力已经是生产依赖,就不能有单点。我搭了一套多模型路由加降级,核心:多供应商接入、健康检查、自动降级兜底。上线后两次抖动都平稳度过。 多供应商统一接
一次全量上线引发的事故 三个月前我们直接全量发了订单服务 v2,结果一个新分支的序列化逻辑和旧版不兼容,老客户端解不出字段,半小时 rollback 了,期间丢了几十笔订单的回调。复盘会上被喷得不轻。痛定思痛,我搭了一套灰度发布体系,核心四件事:流量染色、网关路由、数据兼容、回滚机制。这套跑顺之后,
背景:一次排查花了三个小时 六月一次线上下单失败,从接到告警到定位根因花了三个小时。不是问题复杂,是信息散——日志在 ELK、指标在 Prometheus、链路在 SkyWalking,三套系统各看各的,人肉拼不出完整画面。那周我推动了可观测性体系重构,把三大支柱真正串起来。 三大支柱:日志、指标、
给内部文档做个能问答的机器人 公司几百份技术文档散在 Wiki,搜起来费劲——关键词搜只能匹配字面,问"怎么处理订单超时"搜不到"订单 30 分钟未支付自动关单"的那段。我想用 RAG(检索增强生成)做个问答,让模型"先查资料再回答"。2023 年初这套链路在 Java 侧得自己拼,没有现成框架,正
一次没顶住的流量 去年大促,预估峰值 8000 QPS,实际来了 1.4 万,订单服务被打挂 12 分钟。复盘发现:我们的容量评估靠的是"去年×2"的拍脑袋,没有真实压测支撑,对系统的真实拐点一无所知。那天凌晨告警炸了,扩容来不及,限流没配,全靠手动重启扛,资损不小。这次我把容量评估正经做了一遍,把
我们为什么离不开 Nginx 后端是 Spring Boot 起的 8080 服务,但直接把 8080 暴露在公网既不安全也难扩展。一来没有 TLS 卸载,二来单实例挂了没容灾,三来限流得在每个应用里写。Nginx 在我们架构里身兼数职:反向代理、负载均衡、限流、长连接优化。它配一次能管一片服务,是
集群重启后要 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,再往上就开始超时。加节点成本太高,而且
一次资损:限领 1 张的券,用户领了 2 张 1 月初的一个上午,运营在群里 @ 我:一张"新客专享 50 元券",配置的是每人限领 1 张,有用户领到了 2 张,已经核销了一张。 我查了数据库: mysql> SELECT user_id, coupon_id, count(*) c FROM c