第4章 前置条件清单：系统、监控、回滚与基线
灰度发布与 A/B 测试并非凭空启动，每一次上线前都需要对四个前置条件进行逐项确认。条件不满足时强行发布，轻则干扰线上用户指标，重则引发大面积故障。本章以“前置条件清单”为主线，梳理适用场景、操作步骤、各角色责任边界以及异常处理方案，确保团队在进入流量切换环节前具备完整的安全底盘。
4.1 适用场景
本条件清单适用于所有准备进入灰度发布或 A/B 测试阶段的微服务、Web 应用、移动端功能模块。无论是由 SRE 主导的基础设施灰度，还是由产品经理发起的 A/B 实验，启动前均须执行此清单。
4.2 前置条件
四项前置条件作为本章核心内容，每个条件均需满足以下细则：
| 条件编号 | 条件名称 | 关键确认项 | 验收方式 |
|---|---|---|---|
| PC-01 | 依赖系统就绪 | 下游 DB、缓存、消息队列、外部 API 均处于正常状态，版本无冲突 | 自动化健康检查脚本返回 all green |
| PC-02 | 监控告警就位 | 自定义指标落入监控系统，告警规则已配置且阈值验证通过 | 模拟异常触发告警通知到值班群 |
| PC-03 | 回滚预案通过评审 | 回滚步骤文档化，负责人确认，至少一次桌面推演或 dry-run | 评审会议纪要签字确认 |
| PC-04 | 指标基线已采集 | 灰度前至少一周的 p99 延迟、错误率、QPS、成功率等基线数据保存 | 基线报告在 dashboard 中可查 |
4.3 操作步骤
- 执行依赖系统预案检查：运行统一健康检查脚本，输出所有核心依赖状态；若发现异常，进入第 4.6 节异常处理。
- 验证监控与告警：使用测试工具（如 locust、wrk）对目标服务施加小流量，确认监控面板刷新正常，并触发一条测试告警。
- 组织回滚预案评审：召集开发、测试、运维三方，对照预案逐条确认；在预发环境执行一次回滚演练并截图留档。
- 导出并存储指标基线：从 Prometheus / Datadog 导出最近 7 天小时级粒度数据，生成基线 PDF 或共享看板。
- 填写前置条件确认表：将以上结果汇总至统一检查清单，由技术负责人签字确认。
4.4 输入输出物
- 输入：版本发布计划、依赖关系拓扑图、监控配置模板、回滚预案文档、历史指标快照。
- 输出：前置条件检查表（含签字）、基线报告 PDF、告警触发截图、回滚演练日志。
4.5 责任边界
- SRE / 运维：负责执行健康检查、监控告警验证、回滚 dry-run；输出确认结果。
- 开发团队：提供依赖节点清单、回滚脚本、指标定义；参与评审。
- QA：验证基线数据完整性，确认测试环境与生产环境依赖一致。
- 技术负责人（TL / 架构师）：最终审批前置条件检查表，决策是否进入灰度。
4.6 记录材料
以下材料须归档到发布管理系统的“灰度发布”页面，至少保留 6 个月：
| 记录项 | 格式 | 存储位置 |
|---|---|---|
| 前置条件检查表 | Excel 或 Wiki 页面 | 项目发布文档库 |
| 基线报告 | PDF / PNG | 共享 Dashboard 快照 |
| 回滚演练截图 | PNG | 工单附件 |
| 监控告警验证截图 | PNG | 运维日报链接 |
4.7 异常处理
异常一：依赖系统不可用 —— 立即暂停灰度准备，通知依赖方修复；待恢复后重新执行健康检查。
异常二：监控告警未触发 —— 检查告警规则语法、namespace、签名；使用 curl / POSTman 手动推送测试 metric 验证。
异常三：回滚预案评审未通过 —— 记录评审提出的风险点，修订预案后再次评审；不允许未通过即启动。
异常四：基线数据缺失（如新服务不足7天） —— 获取同类服务或压测数据作为参考基线，并在发布计划中备注“非严格基线”。
4.8 验收标准
灰度前置条件检查的最终验收标准为 “四项全绿”，即：
- 依赖系统健康状态均为 ✅；
- 监控告警触发日志存在于近 5 分钟记录中；
- 回滚预案评审邮件确认，且 dry-run 无阻塞；
- 基线数据覆盖最近 7 天所有核心指标。
只有四人（SRE、开发、QA、技术负责人）在检查表上签字确认，才允许进入下一章“灰度流量切换”。