一次配置发布把 sync-worker 这一档的数据库连接池上限
从 64 降到了 8，在下午常规负载下连接被打满。同步 API 在 47 分钟内
约有 21% 的请求返回 502。我们通过回滚配置并轮替 worker 集群完成缓解；
没有数据丢失。
cfg-9a12 通过标准发布流水线
推到生产环境。
sync_5xx_rate > 2% 持续 60 秒。
On-call (Devon) 确认接手。
cfg-9a12
已回滚；worker 集群已轮替。三分钟内 5xx 率降到 0.2% 以下。
PR #4888 让连接池上限可以按 worker 等级
独立配置。新增的 sync-worker 键本应继承
全局值（64），但在一次本地调试时被硬编码成 8 并提交了。配置 linter
只校验类型不校验数值范围，所以这次变更顺利过了 CI。
由于配置发布和代码发布走的是两条不同的流水线，on-call 第一反应 — 回滚最近两次应用发布 — 没起作用，白白消耗了大约 13 分钟诊断时间。
| 失败请求数 (502) | 约 41,200 |
|---|---|
| 峰值错误率 | 21.4% |
| 受影响用户 | 约 2,300 个工作区 |
| 数据丢失 | 无 — 客户端已重试 |
| SLA 违约 | 否（仍在月度预算内） |
max_connections 的取值范围检查（小于 32 时告警）
4 月 18 日