变更管理全流程
一句话：50%+ 的线上故障来自变更——变更管理的核心不是”禁止变更”，而是让变更可控、可回滚、可观测。
变更管理全景
graph LR
REQ[变更申请] --> REVIEW[变更评审]
REVIEW --> APPROVE[审批通过]
APPROVE --> CANARY[灰度发布<br/>1% → 10% → 50% → 100%]
CANARY --> MONITOR[监控观察<br/>SLI/黄金信号]
MONITOR -->|正常| FULL[全量发布]
MONITOR -->|异常| ROLLBACK[自动回滚]
FULL --> DONE[变更完成]
ROLLBACK --> POST[变更复盘]
变更分类
| 类型 | 风险 | 审批要求 | 发布策略 |
|---|
| 标准变更 | 低 | 预批准模板 | 自动化 |
| 常规变更 | 中 | 评审 + SRE 确认 | 灰度发布 |
| 紧急变更 | 高 | 事后补审 | 先执行后评审 |
| 重大变更 | 高 | 架构评审 + CTO 批准 | 分阶段灰度 |
变更类型清单
代码变更:
├── 应用版本发布（ArgoCD）
├── 配置文件变更（ConfigMap/Secret）
└── 数据库 Schema 变更
基础设施变更:
├── K8s 版本升级
├── 节点扩缩容
├── 网络策略变更
└── 安全组/防火墙变更
数据变更:
├── DB Schema 变更（DDL）
├── 数据迁移
└── 索引变更
运维操作:
├── 重启服务
├── 清理缓存
└── 证书更新
变更评审 Checklist
## 变更评审 Checklist
### 变更内容
- [ ] 变更描述清晰（改什么、为什么改）
- [ ] 影响面分析（哪些服务/用户受影响）
- [ ] 回滚方案（怎么回、多快能回）
- [ ] 监控方案（怎么看变更效果）
### 安全验证
- [ ] CI 测试通过（单元测试 + 集成测试）
- [ ] 灰度环境验证
- [ ] 安全扫描通过（Trivy/SAST）
- [ ] 性能基线对比（非劣化）
### 时间窗口
- [ ] 非冻结窗口（大促/节假日期间不变更）
- [ ] 低峰期执行（22:00-06:00 或 10:00-16:00）
- [ ] 有足够观察时间（至少 30 分钟灰度观察）
### 回滚保障
- [ ] 回滚命令已准备
- [ ] 回滚预估时间 < RTO 预算
- [ ] 数据变更可逆（或有备份）
- [ ] 回滚后验证方案
灰度发布策略
渐进式交付（Progressive Delivery）
# Argo Rollouts 渐进式发布
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: api-gateway
spec:
strategy:
canary:
canaryService: api-gateway-canary
stableService: api-gateway-stable
trafficRouting:
nginx:
stableIngress: api-gateway-ingress
steps:
- setWeight: 5 # 5% 流量到新版本
- pause: { duration: 5m } # 观察 5 分钟
- setWeight: 20
- pause: { duration: 10m }
- setWeight: 50
- pause: { duration: 10m }
- analysis: # 自动分析 SLI
templates:
- templateName: success-rate
args:
- name: service-name
value: api-gateway
- setWeight: 100
自动分析（Analysis Template）
apiVersion: argoproj.io/v11alpha1
kind: AnalysisTemplate
metadata:
name: success-rate
spec:
args:
- name: service-name
metrics:
- name: success-rate
interval: 1m
# 查询 Prometheus 成功率
query: |
sum(rate(http_requests_total{
service="{{args.service-name}}",
code!~"5.."
}[2m])) /
sum(rate(http_requests_total{
service="{{args.service-name}}"
}[2m]))
# 成功率 < 99% 自动回滚
successCondition: result[0] >= 0.99
failureLimit: 3 # 连续 3 次失败触发回滚
发布策略对比
| 策略 | 流量切分 | 回滚速度 | 复杂度 | 适用 |
|---|
| Recreate | 全量替换 | 慢 | 低 | 无状态简单 |
| RollingUpdate | 逐个替换 | 中 | 低 | K8s 默认 |
| Canary | 按比例 | 快 | 中 | 通用 |
| Blue-Green | 全量切换 | 极快 | 中 | 快速回滚需求 |
| A/B Testing | 按用户 | 快 | 高 | 业务实验 |
| Shadow | 不切流量 | 无 | 高 | 安全验证 |
冻结窗口
冻结窗口（Change Freeze）触发条件:
- 大促期间（双11/618/春节）
- 重大活动前 7 天
- 错误预算消耗 > 80%
- SEV1 故障后 24h（除修复变更外）
冻结窗口规则:
- 仅允许紧急修复变更
- 紧急变更需 SRE Lead 批准
- 预定变更推迟到解冻后
- 自动化变更暂停（如定时配置更新）
变更自动化
GitOps 变更流程
开发提交 PR
→ CI 自动测试
→ Code Review
→ 合并到 main
→ ArgoCD 检测变更
→ 灰度发布
→ 自动分析
→ 全量 or 回滚
→ Slack/飞书通知结果
配置变更管理
class ConfigChangeManager:
"""配置变更管理器"""
def validate_change(self, config_diff: dict) -> dict:
"""验证配置变更安全性"""
result = {"safe": True, "warnings": []}
# 检查关键配置变更
for key, (old, new) in config_diff.items():
if key in ["max_connections", "connection_pool_size"]:
if new < old:
result["warnings"].append(
f"{key} 从 {old} 降到 {new}，可能影响容量"
)
result["safe"] = False
if key in ["replicas", "min_replicas"]:
if new < 2:
result["warnings"].append(
f"{key} = {new} < 2，不满足高可用要求"
)
result["safe"] = False
return result
def can_rollback(self, change: dict) -> bool:
"""判断变更是否可回滚"""
# 数据库 DDL 变更不可回滚
if change.get("type") == "ddl":
return False
# 其他变更都应可回滚
return True
常见问题 / 坑点
| 问题 | 原因 | 解决方案 |
|---|
| 变更不评审直接上线 | 流程缺失或绕过 | 强制 CI 门禁 + GitOps |
| 回滚太慢 | 没准备回滚命令 | 预编排回滚 Runbook + ArgoCD |
| 灰度比例跳太猛 | 1% → 100% | 渐进式 5% → 20% → 50% → 100% |
| 配置变更炸了 | 没有 dry-run | 配置变更先 dry-run + 影子环境验证 |
| DDL 变更锁表 | 大表 ALTER | pt-online-schema-change / gh-ost |
| 冻结窗口还变 | 紧急变更滥用 | 冻结期仅限修复，事后必须评审 |
关联知识
参考资源
状态