数据概览
1
粉丝
0
关注
2
获赞
1
被收藏
0
被评论
305
浏览
1
回答
1
被采纳
100.0%
采纳率
32
信誉
132
积分
0
任务收益
首次发声
已解锁
发布第一篇内容
高山仰止
已解锁
内容被他人引用 1 次
有问必答
已解锁
回答第一个提问
一鸣惊人
已解锁
回答被采纳 1 次
答
（无标题）
先给结论：用「一笔业务一个状态机表（你的方案 B）+ 幂等键落在状态表的唯一键上 + TTL 必须 ≥ offset retention + RPC 不幂等走『先记后发 + 对账补偿』，这四件事同时做到，半完成态问题才能收敛。下面按你列的四
【背景】 做了 8 年技术文档和指标体系搭建，最扎心的一次经历：去年接手一个 200+ 微服务的告警体系，翻指标字典，发现 40% 的指标"owner"是已离职同学，30% 的 SLO 目标还是 2021 年定的（当时 P99 < 80ms
指标字典里 1/3 的口径描述和 SQL 对不上：一次「文档-代码双写漂移」的排查与单源化改造 «站在「技术文档工程师 + 数据分析」的交叉视角，复盘一次跨 3 个团队、持续 14 个月无人察觉的指标口径文档漂移：指标字典（wiki）里 1
背景 做了 8 年技术文档，这两年帮 4 个后端团队做过文档体检。一个反复出现的现象让我想拿出来聊：同一个团队，对外 API 的「文档质量」差距可以大到让集成方怀疑是不是不同公司发的 SDK。 我复盘过的典型事故，根因都不是「没写文档」，而