id: “d16d3f27-a7df-48e9-963d-ac00c74f2a68” name: “四阶段在线发布验证” description: “一个可重用的、阈值驱动的在线发布验证工作流程，覆盖回归测试、灰度发布、实时监控观察和全量发布 — 具有明确的、用户指定的通过/失败条件、数字监控阈值、固定观察窗口和角色范围的回滚权限。” version: “0.1.1” tags:

“发布流程”
“验证”
“阈值驱动”
“灰度发布”
“监控”
“回滚策略”
“SRE” triggers:
“定义发版各阶段通过条件”
“明确监控阈值”
“设置灰度终止标准”
“制定回归测试准入门槛”
“规定全量发布触发条件”
“指定谁有权执行回滚”

四阶段在线发布验证

一个可重用的、阈值驱动的在线发布验证工作流程，覆盖回归测试、灰度发布、实时监控观察和全量发布 — 具有明确的、用户指定的通过/失败条件、数字监控阈值、固定观察窗口和角色范围的回滚权限。

提示

目标

执行一个四阶段在线发布验证过程：(1) 回归测试，(2) 灰度发布，(3) 实时监控观察，(4) 全量发布 — 每个阶段必须在严格的、可量化的通过标准下才能进行。输出每个阶段的明确通过/不通过决策，引用观察到的指标与定义的阈值。

约束与风格

所有通过条件必须是具体的、数字的、用户指定的 — 不使用模糊术语如“稳定”、“可接受”或“看起来良好”。
监控阈值必须以绝对值或百分比偏差范围表达（例如，“P95 延迟 ≤ 800ms”、“错误率 < 0.1%”、“性能偏差 ≤ ±15%”、“基线 × 1.15”）。
如果任何所需阈值被违反，则拒绝该阶段 — 不允许部分通过、主观覆盖或手动绕过。
违反时必须回滚：在定义的地方自动触发；否则，仅由授权角色（SRE 和技术负责人）通过预验证的脚本执行（例如，./rollback.sh <prev_version>），需要双人确认（操作员 + 验证者）和多因素认证。
所有时间限制条件使用严格的、不间断的滚动窗口（例如，“≥20 连续分钟”） — 中断会重置计时器。
不要发明阈值、策略、工具或角色；仅使用用户在本线程中明确确认的内容。
以普通语言输出决策，包括指标名称、观察值（如果提供）和阈值比较 — 不使用 Markdown 表格或装饰性格式。
不要假设环境、技术栈或工具 — 保持逻辑与技术栈无关，除非用户指定集成（例如，K8s、Nacos）。

工作流程

灰度发布阶段：
- 监控至少持续时间（≥30 分钟；对于重大更改 ≥2 小时）。
- 如果发生以下任何情况，立即终止：(a) 错误率 > 0.5%；(b) 核心接口 P95 延迟增加 > 50%；© 关键资源异常（例如，数据库连接池耗尽、OOM、线程死锁）。
- → 仅当没有终止条件触发时才进入观察阶段。
监控观察阶段：
- 使用以下确切阈值验证四个维度： • 可用性：HTTP 5xx 错误率 < 0.1% AND 服务健康探测成功率 ≥ 99.9%； • 性能：核心接口 P95 延迟偏差 ≤ ±15% AND 数据库查询平均时间偏差 ≤ ±15%； • 业务：关键转换/成功率与前一小时基线相比未出现退化； • 资源：CPU/内存使用率和 JVM GC 频率未出现持续峰值或悬崖。
- → 仅当所有四个维度在 ≥20 连续分钟内都满足阈值时才进入全量发布。
全量发布阶段：
- 仅在以下条件下触发：(a) 成功的观察窗口；(b) 核心流程的手动验证签名；© 零未解决的 P0/P1 问题。
- 通过渐进式流量切换执行（例如，5% → 20% → 50% → 100%），每步之间至少间隔 5 分钟并在每步验证指标。
- 如果在发布期间监控观察阶段的任何阈值被违反，则在 5 分钟内强制执行硬回滚。

触发器

定义发版各阶段通过条件
明确监控阈值
设置灰度终止标准
制定回归测试准入门槛
规定全量发布触发条件
指定谁有权执行回滚