升级后的运行观察：选择能解释问题的日志、指标与追踪
版本切换结束并不是观察的终点，许多兼容问题会在特定请求、定时任务或资源累积后才显现。运行观察的目标是建立足够的证据链：发生了什么、从何时开始、影响了哪些路径、是否与版本切换有关。并非所有信号都需要采集，过多无关数据反而会掩盖异常。指标名称和采集方式依项目而异，执行时应结合当前组件说明与已有基线。
升级前先定义比较对象
选择少数真正反映服务行为的指标，例如请求成功比例、延迟分位、队列积压、任务完成时间、连接错误和资源使用。为每个指标说明它反映哪一类风险，以及旧版本的典型范围。不要把一次短时峰值立即归因于新版本；应同时检查流量、输入分布、外部依赖和部署批次是否变化。
让日志支持定位而非堆积
升级期间要确保版本信息、实例标识、请求关联标识和关键错误上下文可被检索。若新版本改变日志格式、级别或字段，应同步调整解析规则与告警条件。日志量突然增加本身也是信号，但需判断是新增调试输出、异常重试还是正常行为改变。避免在日志中记录不必要的敏感内容，重点保留排查所需的技术上下文。
使用追踪理解跨服务影响
对于多服务链路，单个服务指标可能无法解释整体延迟或失败。可通过请求关联信息观察调用顺序、重试次数和下游耗时。升级一个客户端库后，若下游请求数异常增加，追踪能帮助确认是否发生重试语义变化。采样覆盖范围应在成本与可见性之间取平衡，并明确未采样请求不能据此做绝对判断。
设置观察窗口和升级批次
将实例或流量分批切换，并在每批后保持足够观察时间。观察窗口的长短取决于业务周期、缓存预热和定时任务频率，不宜机械套用固定时长。若关键任务只在夜间运行，白天的平稳数据不能证明升级完成。记录每次批次的开始时间、版本和配置，便于将信号与变更对应。
把发现反馈到测试与计划
运行中发现的新错误模式，应转化为下一次升级的测试场景和停止条件。观察并非替代测试，而是补足测试环境难以覆盖的真实组合。持续改进后，团队会逐渐知道哪些指标最有解释力，哪些告警只会制造噪声。