首轮灰度直接放 30% 流量，出现异常时，回滚链路本身也慢。
三个坑看起来完全不一样，其实是同一件事：我只设计了成功路径，没设计失败路径。
3 个坑 → 3 条机制
没有容量基线；压测环境与生产差 3 个版本，结果不可信。
双写没做对账脏数据藏了 11 天
→
上线分钟级对账 + 差异告警
发生了什么
年终述职 · 复盘与成长
03
灰度一次放 30%回滚花了 40 分钟
峰值来了才扩容，临时加了 40 台，多花 11 万成本，还差点把库存服务拖挂。
述职里讲成绩的多，讲踩坑的少。但真正让人相信你能扛事的，是你知道自己会在哪儿翻。
迁移后第 11 天，业务侧反馈 3 张表有 0.4% 的数据对不上。
只校验了条数，没校验内容；没有自动对账，全靠人肉抽查。
大促前没压测靠加机器过关
T H E P A T T E R N
所以今年我改的不是「更小心」，是把「出错时会怎样」也当成设计的一部分——对账、回滚、基线，都是失败路径的产物。
今年踩过的三个坑
02
平均回滚 40 分 → 4 分
只设计了「怎么发」，没设计「怎么退」；回滚脚本半年没人跑过。
WHAT WENT WRONG
01
扩容 2 周 → 10 分钟
L E S S O N S / 2 0 2 6
灰度 1% → 5% → 20% 三档
根因
和它们各自改掉的那条机制
之后 0 起脏数据流出
容量基线月更 + 环境同版本
