发布标记如何帮助故障定位？

简化版

发布标记把代码、配置、流量和基础设施变更以时间事件叠加到指标、日志与 Trace 上，帮助判断异常是否与变更相关。标记只能提供相关性线索，不能单凭时间重合认定根因。

详细版

每个标记记录 service、environment、region、version/digest、changeId、类型、开始结束时间、灰度范围和操作者，由流水线自动发送。仪表盘展示版本分布，Trace/日志携带版本属性，便于比较新旧实例。

告警发生时查询前后变更并计算各版本错误率；回滚也生成独立标记。时钟统一、重试幂等、失败补发，确保部署成功但标记不丢；高频配置变更按影响范围过滤，避免时间线噪声。

完整版教学

一、没有标记会怎样

P99 在 10:07 上升，排障者若不知道 10:05 切了 10% 新版本，只能遍历依赖猜测。标记把“系统何时发生了什么变化”变成可查询证据。

记忆钩子：先问最近变了什么，再用版本对比证明是不是它。

二、标记最小字段

字段	用途	示例
artifact	精确制品	image digest
scope	爆炸半径	region=A, 10%
changeId	审批与追溯	CHG-1024
actor	责任主体	pipeline/user
timestamps	关联窗口	start/end

仅写“发布了 v2”不足以区分区域、批次和配置。

三、怎样自动生成

deploy start -> marker STARTED
traffic shift -> marker 10%/50%/100%
verification -> marker SUCCEEDED|FAILED
rollback -> new marker ROLLBACK

由流水线产生比人工备注可靠；同一 changeId+stage 幂等，网络失败后可补发。

四、版本对比而非时间猜测

若新版本错误率 3%、旧版本 0.1%，且相同 region/流量条件下差异显著，变更嫌疑很高。若两版本同时恶化，应继续检查共享依赖或流量变化。

发布时间接近异常只说明相关，不能跳过对照组和 Trace 证据。

五、配置和基础设施变更

动态配置、特性开关、数据库迁移、证书和网络策略都应进入同一变更流。只标代码发布会漏掉大量真实事故来源。

对频繁开关记录 diff 摘要和影响对象，不把敏感配置值直接写入标记。

六、数据质量

统一 UTC 事件时间并记录接收时间，监控标记发送失败和流水线覆盖率。部署平台不可用时本地 Outbox 保存，恢复后补发。

标记保留期至少覆盖遥测排障窗口；Trace 中的 service.version 要与制品标记一致。

数据库迁移跨越多个发布批次时，应分别记录开始、回填水位、切换和完成，而不是压缩成一个瞬时点。

七、常见误区与追问

• 误区：异常紧跟发布就一定是发布导致。 需要版本对照和因果证据。
• 误区：只标发布完成时刻即可。 灰度各阶段和回滚同样重要。
• 误区：版本号足以追溯。 还需不可变 digest、范围和 changeId。
• 误区：配置变更不算发布。 它同样会改变运行行为。
• 追问：谁发送标记？ CI/CD 与配置平台自动发送，人工只补充说明。
• 追问：标记丢失怎么办？ 幂等 Outbox、失败告警和补发。
• 追问：如何控制噪声？ 按服务、环境、范围过滤并聚合同批变更。

八、加强记忆

发布标记按“所有变更自动记录—不可变版本与范围—时间线展示—新旧对照—回滚留痕”建设。它缩短假设生成时间，但根因仍需版本指标、Trace 和实验验证；代码、配置与基础设施都必须纳入同一变更事实流。