运维篇 · 01 · 发布 SOP
本章目标
让每次发布变成标准动作——不依赖"某个人记得怎么做"。
一、发布前置条件（Checklist）
1.1 测试交付物
- 准出报告已签字（测试报告模板）
- 无 P0/P1 遗留 Bug
- 核心用例 100% 通过
- 性能测试达标
- 安全扫描无高危
1.2 开发交付物
- 版本号已打 Tag
- Release Note 已发布
- 部署文档已更新
- 数据库变更脚本已提供
- 回滚脚本已提供
- 配置变更清单已提供
1.3 运维准备
- 发布窗口已预约（非业务高峰）
- 相关方已通知（开发/测试/产品/客服）
- 监控看板已准备
- 应急联系人已到岗
- 回滚方案已演练
1.4 业务准备
- 变更通知已发（客户/内部）
- 客服已培训新功能
- 运营物料已准备
不满足任一项 = 发布取消/延迟。
二、发布类型与节奏
2.1 三种发布类型
| 类型 | 频率 | 流程 | 示例 |
|---|---|---|---|
| Major Release | 季度 | 完整流程 + 培训 + 公告 | v2.0.0 |
| Minor Release | 月度 | 完整流程 | v1.3.0 |
| Patch / Hotfix | 按需 | 简化流程，快速发布 | v1.2.4 |
2.2 发布窗口
推荐：
- 周二至周四，避开周一（积累问题多）和周五（周末难处理）
- 北京时间凌晨 2:00-5:00（低峰期）
- 避开节假日、大促、月结
禁止：
- 周五 18:00 后
- 节假日前一天
- 大促期间
- 数据报表生成时段
三、灰度发布（Canary Release）
3.1 为什么要灰度
- 降低风险（出问题只影响小部分用户）
- 真实流量验证
- 便于对比（灰度组 vs 全量组）
3.2 灰度策略
| 策略 | 说明 | 适合 |
|---|---|---|
| 按百分比 | 随机抽 1% → 10% → 50% → 100% | 无状态服务 |
| 按用户分组 | 内测用户 → Beta 用户 → 全量 | 有用户分层的产品 |
| 按地域 | 小城市 → 大城市 → 全国 | 本地化强的业务 |
| 按时间 | 每小时增加 10% | 流量变化大 |
| 按设备 | 某机型 → 全机型 | 客户端应用 |
3.3 灰度节奏模板
T+0:00 发布版本，启用灰度 1%
T+0:15 观察 15 分钟，验证关键指标
T+0:30 增加到 5%
T+1:00 增加到 20%
T+2:00 增加到 50%
T+4:00 增加到 100%
任何一个节点出问题 → 立即停止 → 评估 → 决策回滚或继续
3.4 灰度期监控的关键指标
| 类别 | 指标 | 报警阈值 |
|---|---|---|
| 功能 | 错误率 | > 0.5% |
| 性能 | P99 响应时间 | 上升 > 20% |
| 资源 | CPU | > 80% |
| 资源 | 内存 | > 80% |
| 业务 | 核心转化率 | 下降 > 5% |
| 日志 | Error 日志量 | 上升 > 50% |
四、标准发布流程（SOP）
T-60min ┌─ 发布前检查（checklist）
├─ 通知相关方（开始发布）
├─ 开启监控放大镜
└─ 备份当前版本
T-0 ┌─ 执行发布脚本
├─ 先部署 1 个实例
├─ 健康检查通过
└─ 开始灰度
T+15min ┌─ 灰度 5%
└─ 监控指标观察
T+60min ┌─ 灰度 20%
└─ 业务指标观察
T+2h ┌─ 灰度 50%
└─ 全面监控
T+4h ┌─ 灰度 100%
└─ 持续观察
T+24h ┌─ 稳定观察
├─ 通知发布完成
└─ 归档发布报告
T+1week ┌─ 发布复盘
└─ 改进项跟踪
4.1 各角色职责
| 角色 | 发布前 | 发布中 | 发布后 |
|---|---|---|---|
| 运维 | 检查清单 + 准备 | 执行部署 + 监控 | 归档 + 复盘 |
| 开发 | 提供部署脚本 | 待命 + 支持 | 协助问题排查 |
| 测试 | 签署准出 | 关注告警 | 线上验证 |
| 产品 | 通知客户 | 观察业务指标 | 收集反馈 |
| 值班 | 预先调配 | 全员 on-call | 继续值守 |
五、回滚决策
5.1 立即回滚的条件
以下任一必须立即回滚：
- 核心业务功能不可用
- 错误率飙升超过 2%
- 数据错误/丢失
- 安全漏洞暴露
- 严重性能劣化（P99 上升 50%+）
5.2 观察后决策的情况
- 非核心功能异常
- 错误率小幅上升（< 2%）
- 性能轻微下降
决策流程：
发现问题 → 15 分钟内评估严重度 →
├── 立即回滚（上述红线）
├── 临时降级（关闭问题功能）
└── 继续观察（有缓解措施）
5.3 回滚后必做
- 确认线上业务恢复
- 发告警降级通知
- 保留故障现场（日志/监控/截图）
- 24 小时内产出故障报告
- 召开复盘会议
六、数据库发布策略
6.1 核心原则：代码与数据分两步
推荐顺序：
Step 1: 发布代码（兼容新旧两种数据结构）
Step 2: 确认代码稳定后，执行数据库 migration
Step 3: 发布新版本（只用新数据结构）
Step 4: 旧字段废弃（下个版本删除）
禁止：代码和 migration 一起发布（出问题无法回滚）。
6.2 migration 编写规范
- 必须可重入（跑两次结果一致）
- 必须可回滚（有对应 down 脚本）
- 大表变更要分批（避免锁表）
- 不要在 migration 里做业务逻辑
6.3 示例：新增字段
-- v1: 加字段（默认值，保持兼容）
ALTER TABLE orders ADD COLUMN discount_type VARCHAR(20) DEFAULT 'none';
-- v2: 回填数据（分批）
UPDATE orders SET discount_type = 'vip' WHERE user_level = 2 LIMIT 10000;
-- v3: 加 NOT NULL 约束（数据回填完成后）
ALTER TABLE orders MODIFY COLUMN discount_type VARCHAR(20) NOT NULL;
七、配置变更策略
7.1 配置与代码分离
- 代码：业务逻辑，不易变
- 配置：可能需要调整的参数
7.2 配置中心的优势
- 运行时可调（不需要重启）
- 统一管理（一个仓库管所有配置）
- 灰度能力（不同环境不同值）
- 审计能力（谁改了什么）
推荐工具：Nacos / Apollo / Consul / etcd。
7.3 配置变更流程
提交变更 ──► 评审 ──► 灰度（单实例）──► 小范围 ──► 全量 ──► 观察
八、特殊场景
8.1 紧急 Hotfix 流程
发现线上问题
↓ (5 分钟)
评估严重度
↓ (15 分钟)
开发定位 + 修复
↓ (代码评审 + 测试)
紧急发布
↓
灰度 10% → 100%（加速但不跳过）
↓
事后补流程（MR、文档、复盘）
原则：流程可以简化，但不能跳过。事后补齐文档。
8.2 无停机升级
- 数据库：读写分离、主从切换
- 服务：滚动发布、蓝绿发布
- 网关：平滑重启（graceful shutdown）
8.3 跨平台发布（App / Desktop）
- iOS：审核周期 1-3 天，灰度通过 TestFlight
- Android：分阶段发布（Play Store 支持灰度百分比）
- macOS (本项目 app/)：可通过 auto-update 库灰度
- Windows：可通过下载更新包灰度
九、发布自动化
9.1 CI/CD 流水线示例
Push 到 release/* → CI 构建 → 单测 → 集成测试 →
→ 构建镜像 → 推送仓库 → 部署预发布 →
→ 人工确认 → 部署生产（灰度）→ 健康检查 →
→ 扩大灰度比例 → 全量 → 发布报告
9.2 人工确认节点（Gate）
以下步骤必须人工确认：
- 部署到生产（第一次推送）
- 灰度比例从 20% 升到 50%
- 灰度升到 100%
9.3 自动化 vs 人工平衡
| 全自动 | 人工确认 |
|---|---|
| 构建、测试 | 生产首次部署 |
| 部署测试/预发布 | 关键灰度节点 |
| 监控告警 | 回滚决策 |
十、发布复盘
发布后 24 小时内产出简短报告：
# v1.2.0 发布报告
**发布时间**: 2026-04-20 02:00 - 06:00
**执行人**: @ops-alice
## 概览
- 总耗时: 4 小时
- 灰度节奏: 1% → 5% → 20% → 50% → 100%
- 遇到问题: 0
## 关键指标
| 指标 | 发布前 | 发布后 | 变化 |
|------|-------|-------|------|
| P99 延迟 | 180ms | 175ms | -3% |
| 错误率 | 0.1% | 0.12% | +0.02% |
| CPU | 45% | 48% | +3% |
## 问题与处置
无
## 改进项
- 灰度过程手动切换频繁，下次考虑自动化脚本