灰度发布是什么
灰度发布把一次全量变更拆成若干批次，用小范围真实流量先承担风险，确认无异常后再扩大。对补丁而言，价值在于把『能不能打』这个只能在真实环境下回答的问题前置：兼容性问题、依赖冲突、重启引发的连锁影响，都会在第一批就暴露。灰度不追求慢，而是用明确的观察指标与时间盒换取确定性；批次之间缺少观察期，则等同于一次性全量。
基本信息
| 适用对象 | 应用服务器、中间件、数据库引擎、终端系统更新 |
|---|---|
| 关键要素 | 批次划分、观察窗口、暂停条件、回滚点 |
| 观察指标 | 错误率、响应延迟、日志异常、业务指标 |
| 编排支持 | Ansible serial、CI 分批发布、配置管理工具的分组机制 |
典型使用场景
- 给数十台应用服务器打补丁时先选一台非核心实例试跑
- 数据库小版本升级前，先在只读从库上验证再动主库
- 中间件升级时按集群成员逐台滚动重启，保证服务不整体中断
- 更新涉及外部集成时，用部分节点先验证 TLS 与加密算法兼容性
- 终端系统更新先覆盖试点部门，收集反馈后再全量推送
分批示例（应用服务器）
分批示例（应用服务器）
批次1：1 台非核心实例 观察 24 小时
批次2：10% 实例 观察一个完整业务高峰时段
批次3：50% 实例 观察一个工作日
批次4：全量
# 每批检查项：错误率、P95 延迟、异常日志关键词、核心业务指标
# 每批开始前记录版本与配置快照，作为回滚点批次控制要点
| 要点 | 内容 | 判断标准 |
|---|---|---|
| 观察窗口 | 按业务周期设定，而非固定分钟数 | 至少覆盖一个业务高峰 |
| 暂停条件 | 错误率与延迟越界、业务告警触发 | 触发即停，不因进度压力放行 |
| 回滚点 | 批次开始前的版本与配置快照 | 回滚步骤需实测可用 |
| 沟通 | 批次节奏同步业务方与值班群 | 异常时能快速召集相关人 |
灰度不是拖延：明确的观察指标与时间盒能让发布节奏更快也更有底；反之，没有指标的『观察一天』通常只是一天没人发现问题。
涉及重启的补丁要评估连锁影响：多节点同时重启可能让集群失去法定票数或让主从切换异常，滚动顺序需提前设计。