发布与运行期验证
把 smoke、canary、shadow、synthetic checks、rollback verification 和生产反馈回流放进同一个发布后质量体系里理解。
#type / synthesis
#status / growing
#tech / dev / test
[!info] related notes
- 所属 MOC: Testing MOC
- 相关概念: 软件测试过程与治理, Monorepo 测试架构, Agent 测试与评估
- 相关实践: 项目里 CI/CD 怎么做，怎么规划部署
发布与运行期验证
范围
这篇笔记讨论的是系统发布后、运行中仍然需要进行的质量验证。
为什么要把这些内容放在一起理解
很多团队默认认为“测试在发布前结束”，结果会遗漏一整类真实风险：
- 环境配置错误
- 部署链路错误
- 真实流量下的行为漂移
- 回滚脚本无效
- 监控和告警根本抓不到事故
这类问题往往不是单元测试或集成测试能提前完全覆盖的。
smoke test
smoke 的目标不是重新验证全部业务，而是确认关键功能和关键依赖至少还能活着。
它更像：
- 最小可用性检查
- 环境是否基本正确
- 发布是否明显破坏系统
canary
canary 的价值是把风险限制在小流量里，而不是一次性把新版本推给全量用户。
它适合回答：
- 新版本在真实环境下是否稳定
- 是否出现特定用户群或流量类型的问题
- 是否值得继续扩大发布范围
shadow
shadow 更适合不想直接影响用户决策、但想比较新旧行为的场景。
对 agent 和 ranking 类系统尤其有价值，因为很多变化不是 crash，而是行为偏移。
synthetic checks
synthetic monitor 的价值是持续、定时地从外部视角检查关键路径。
它和 E2E 的区别在于：
- E2E 更多用于开发和回归
- synthetic checks 更多用于运行中持续看活性和可用性
rollback verification
回滚流程如果从来没验证过，真正出事故时通常不可靠。
所以成熟团队不会只验证“能部署”，还会验证：
- 能不能回滚
- 回滚后配置是否正确
- 数据兼容性是否仍成立
- 告警是否恢复正常
生产反馈为什么是测试体系的一部分
真实事故、线上 bug、工单和用户反馈，不是测试体系的失败证明，而是测试体系最宝贵的输入源之一。
更成熟的闭环是：
incident / feedback -> defect report -> regression test / eval sample -> process improvement
也就是说，生产环境不是测试的对立面，而是测试体系的延伸。
agent 场景下要额外关注什么
对 agent 来说，发布后的验证还要额外补：
- prompt / model diff eval
- shadow traffic
- 小流量行为对比
- 非确定性案例回流
因为 agent 的很多风险不会表现成“程序挂了”，而是输出质量漂移。
最短记忆方式
发布不是测试的终点；真正闭环的测试体系，必须把运行期验证和生产反馈接回来。