首页

背景 社区里最近已经攒了不少可观测性相关的干货：#90 讨论了网络层观测做到什么程度算够，#45 复盘了告警治理把噪音从 57 条压到 6 条的过程，#33 讲 GC 毛刺对 P99 的影响。这些文章共同指向一个问题——观测能力是稳定性体系

背景 我做了 10 年技术产品，近两年主要在做带 LLM 的功能（一个是智能客服改写，一个是代码评审意见生成）。团队 6 人（2 后端 + 1 算法 + 2 前端 + 1 测试）。我们卡在一个很具体的工程问题上：LLM 功能到底怎么定「验收

背景 我负责一个 Go 1.22 写的订单网关，部署在 K8s 1.28（containerd 1.7，节点 16C64G）。QPS 峰值 ~3k，单副本。最近一个月被 OOMKilled 3 次，每次都在流量高峰 1~2 小时内，重启后又

«结论先行：索引没变、SQL 没变、buffer pool 命中率也没掉，但 P99 还是从 15ms 飙到了 3.4s——根因是 InnoDB 的统计信息（cardinality）在数据批量写入后严重失真，优化器据此选错了索引/访问路径。

背景 在数据工程和后端高并发领域，"缓存和数据库不一致"几乎是每个团队都撞过的墙。但每次聊起来，发现大家的做法差异非常大，而且往往跟业务场景、团队规模、运维能力强相关——没有银弹，只有取舍。我做了 10 年数据工程，见过从"纯 TTL 兜底

一、现象：一条「图片预览」接口，把内网扫了个遍 去年给一家做 SaaS 的客户做渗透评估，目标是一套 Go（Gin 1.9）+ 云上的「文档图片代理预览」接口 "GET /api/img/preview?url=..."——前端把外链图片地

【背景】 我做了 10 年算法，近两年主要精力在指标体系与数据监控。负责一条 B 端 SaaS 的核心大盘，日均核心指标约 20 个（DAU、任务成功率、API P99 延迟、付费转化率等），需要 7×24 自动告警，值班同学只看告警群、不

«结论先行："kubectl edit configmap" 之后 Pod 里读到的还是旧值，这不是 bug，而是 K8s 的设计——配置「更新」和「Pod 感知到更新」之间隔着两层机制，且它们的生效条件完全不同。这篇文章把 ConfigM

背景 做了 10 年测试开发，我始终觉得有一类 bug 特别「冤」：功能逻辑本身没错，代码评审也过了，单测全绿，但上线后因为环境和数据形态的差异翻车。我盘点过自己经手的 5 次发布事故，至少 3 次的根因都能归到这一类： - 生产数据里存在

背景 我 10 年里换过 4 个团队，每个团队对"本地开发怎么跑起来"这件事的答案都不一样。有的是"本地起全套 docker-compose，连真库、连真 Kafka、连真 Redis"；有的是"下游全部 mock，只测自己这一层"；还有的

背景 10 年 SRE，最近接手一个 K8s 1.28（containerd 1.7，节点 16C64G）上的 Go 1.21 网关服务，4 副本、单副本峰值 QPS 约 2k，主要工作是转发 + 一些带 30~60s 长连接的任务。 现象

MySQL 连接池打满不是 max_connections 的锅：一次 P99 从 80ms 飙到 12s 的复盘 一、现象与背景 2024 年 3 月，某中型电商订单服务在内部压测中出现了严重的性能退化： - 数据库：MySQL 8.0.

«结论先行：滚动发布期间那波「每次都来、但每次又只持续几十秒」的 5xx，根因几乎都是优雅下线的时序没配对，而不是代码 bug。这篇文章给一份我能直接抄的 preStop + terminationGracePeriodSeconds 配置

【背景】 React 18 + Vite 5 的 B 端中台，主线程之外拆了 3 个 Worker：一个跑 Markdown 解析（约 200k 行代码）、一个跑图表渲染（OffscreenCanvas）、一个跑本地搜索索引。今年把 Sen

人均 GMV 凭空多出 2.5 倍：一对多 JOIN 放大（fan-out）让 SUM/COUNT 静默虚增的根因与三层解法 «结论先行：大多数「指标对不上」不是数据错了，而是聚合粒度错了。当你把「一」侧的指标（如订单金额）和「多」侧的行（

背景 做了 10 年 DBA，被业务方问得最多的一个问题就是："我们的表要爆了，下一步该怎么办？" 每次问这话的时候，团队里通常已经开始在四条路线之间摇摆： 1. 垂直扩容：升配，更大规格的实例（vCPU / 内存 / SSD 升级一档），

【背景】 K8s 1.29 + Kafka 3.5（3 broker，ISR=3），消费组 12 实例（K8s Deployment，maxSurge=1 / maxUnavailable=0），topic "order-pay" 32 分

【背景】 B 端订单服务，JDK17 + Spring Boot 3 + Netty 4.1，单机 8C16G，K8s cpu limit=4 / mem limit=8G。下游：Redis 7（3 主 3 从）+ MySQL 8.0.32

背景 上周在排查一次 P99 毛刺时，顺带翻了下我们网关侧的几段老代码，发现一个挺有意思的分歧：同一个团队里，三个不同服务的"安全门"（鉴权、风控、限流、白名单校验）在下游依赖抖动时，处理方式完全不一样——有的直接 403 拒掉，有的直接放

背景： 我做了 8 年技术产品经理，带过 3 个 0→1 的项目。每次排期会上，"先上 MVP 快速验证" 和 "干脆一次做扎实别返工" 这两派都会吵起来。有意思的是，同一个团队、同一个功能，最后选哪边，往往不取决于功能本身，而取决于当下面