19.7.4 发布窗口与风险控制

发布窗口与风险控制的目标是在业务可接受时间内完成变更并将失败影响降到最低，需与业务峰谷、依赖系统与人员可用性协同。发布窗口应结合历史流量、SLA、外部依赖维护周期、合规要求确定，并对紧急发布与常规发布采用不同审批与执行路径，明确窗口开启/关闭条件与例外处理。

原理草图（发布窗口与风险控制流程）

发布窗口设定与日历示例
- 建议建立统一发布日历与冻结机制：重大活动、结算周期设置冻结；紧急修复走快速通道。
- 例：用 YAML 维护发布窗口与冻结规则，便于平台读取。

# /opt/release/calendar.yaml
timezone: "Asia/Shanghai"
regular_windows:
  - name: "工作日夜间窗口"
    cron: "0 22 * * 1-5"   # 每周一至五 22:00
    duration_minutes: 120
freeze_periods:
  - name: "双11活动冻结"
    start: "2024-11-01T00:00:00"
    end: "2024-11-12T23:59:59"
emergency_window:
  approval: "快速评审(2人)"
  max_scope: "单服务/单功能"

风险评估分级模板与示例
- 评估维度：变更范围、影响面、复杂度、依赖关系、可回滚性、监控完备度。
- 分级示例（S=严重度，P=概率）：

| 维度 | 说明 | 分值(1-5) |
|---|---|---|
| 范围 | 影响服务数 | 4 |
| 复杂度 | 需要数据迁移 | 5 |
| 依赖 | 依赖外部支付 | 4 |
| 可回滚 | 可回滚但需停机 | 3 |
| 监控 | 核心指标完备 | 2 |
总分=18 -> 高风险(需预演+回滚演练+隔离策略)

窗口内风险控制要点与操作示例
- 限制并发变更数量、隔离相互影响系统，避免跨团队多依赖耦合发布。
- 关键组件（数据库、缓存、消息）需容量评估与兼容性验证。

示例：K8s 发布前先做灰度与观测阈值设置

# 1) 创建 10% 灰度发布
kubectl -n prod rollout pause deploy/api
kubectl -n prod set image deploy/api api=registry/app:1.2.3
kubectl -n prod rollout resume deploy/api

# 2) 观察核心指标（示例：PromQL）
# QPS、错误率、P95 延迟

# 错误率
sum(rate(http_requests_total{job="api",status=~"5.."}[5m])) 
/ sum(rate(http_requests_total{job="api"}[5m]))

# P95 延迟
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{job="api"}[5m])) by (le))

发布窗口内数据库变更示例（低风险验证 + 预期效果）

# 1) 评估表大小与索引
mysql -h db01 -uroot -p -e "SELECT table_name, data_length/1024/1024 MB FROM information_schema.tables WHERE table_schema='app' ORDER BY data_length DESC LIMIT 5;"

# 2) 在线变更预演（示例：仅验证，不执行）
pt-online-schema-change --alter "ADD COLUMN note VARCHAR(64)" \
  D=app,t=orders --dry-run

# 预期效果：输出将创建影子表与触发器计划，无实际变更

发布窗口检查清单（可直接落地）

发布前确认清单：
- 依赖系统维护窗口确认完成
- 回滚方案与脚本准备完毕
- 监控看板与告警阈值开启
- 数据库/缓存兼容性验证完成

窗口内执行清单：
- 单批次变更<=2项
- 变更顺序遵循依赖拓扑
- 实时观察核心指标与业务日志

发布后验收清单：
- 关键指标恢复或优于基线
- 错误率低于阈值
- 回滚触发条件未命中

回滚触发阈值示例

# /opt/release/rollback_rules.yaml
rules:
  - name: "错误率阈值"
    metric: "http_5xx_rate"
    threshold: 0.5   # %
    duration: "5m"
  - name: "P95延迟"
    metric: "latency_p95_ms"
    threshold: 800
    duration: "3m"
action: "自动触发回滚脚本"

回滚脚本示例（可执行）

#!/bin/bash
# /opt/release/rollback.sh
set -e
echo "[INFO] rollback to previous version"
kubectl -n prod rollout undo deploy/api
kubectl -n prod rollout status deploy/api
echo "[INFO] rollback completed"

排错与应急处置
1. 指标波动但日志无异常：检查依赖服务与限流策略是否生效。
bash # 查看依赖服务状态 kubectl -n prod get pods -l app=payment
2. 发布失败卡住：确认 Rollout 进度与镜像拉取。
bash kubectl -n prod rollout status deploy/api kubectl -n prod describe pod <pod_name>
3. 数据库变更超时：检查锁等待与慢查询。
bash mysql -uroot -p -e "SHOW FULL PROCESSLIST;" mysql -uroot -p -e "SHOW ENGINE INNODB STATUS\G"

练习
1. 以“订单服务”为例，设计一周内发布窗口与冻结期，并写出 calendar.yaml。
2. 给出一个高风险变更（含数据库变更）并完成风险评估表，计算分级并制定回滚阈值。
3. 在测试环境执行一次 kubectl rollout undo，记录回滚所需时间与关键观察指标。