让每次发布都可见
所有地方使用同一个版本字符串：镜像标签、
service.version、发布上报和用户体验版本。
发布前了解基线
灰度开始前，先记下服务当前的表现：主要端点的错误率和 P95、SLO 的燃烧率，以及未解决的用户体验 issue。对关键路径的拨测执行一次 立即运行，以免把发布前就存在的失败误认为是发布引起的。 把回滚条件写下来，例如：版本在错误率上被判为 变差、某个关键拨测连续失败两次，或快速燃烧率告警触发。灰度期间对比
- 两个版本同时运行时，部署页面的金丝雀卡片会把它们并排对比：各自承接的请求比例、错误和延迟，以及新版本的对比结论。
- 每个版本都会得到与前一个版本对比的结论：变差、变好、无明显变化 或 请求不足。对比需要足够的请求，默认 1,000 个；金丝雀要保持足够长的时间才能达到。
- 点击结论打开 对比两个版本，查看变慢的端点和增多的错误。
- 在用户体验中按新版本筛选探索页和错误 issue，并留意被标为 回归 的 issue：之前已解决、又在更新版本中出现的问题。
让自动化盯住发布
由 CI 任务启动的 Mole Agent 自动化可以先看一遍：发布步骤调用它的触发接口并附上变更说明，Mole Agent 按自动化的说明执行，例如对比新旧版本，然后在对话中汇报。是否回滚仍由人来决定。做出决定并记录
满足回滚条件时就回滚，不必等到完全确定。从 CI 上报回滚，把status 设为 rolled_back，这样时间线会显示它，之后的对比也会使用正确的基线。
保留下来的发布，要在接下来的一天里查看 SLO：内存泄漏、队列逐渐堆积这类缓慢的退化，往往几个小时后才会显现。
验收标准
- 每个服务都发送
service.version，每次生产发布都带着提交出现在发布时间线中。 - 前端发布上传了与所上报版本一致的 Source Map 或 Symbols。
- 灰度开始前已写下回滚条件。
- 每次发布都得到了对比结论，或金丝雀运行得足够长、达到了所需的请求数。