深色模式
变更管理流程
摘要：绝大多数线上事故源自变更。本文把变更拆成申请、评审、灰度、回滚四段，给出每段的必填项与可执行的流水线卡点，让"可回滚"成为硬约束而非口号。
适用环境
bash
# 变更必须走版本控制，禁止手工改线上
git rev-parse --short HEAD
kubectl -n prod get deploy -o custom-columns='NAME:.metadata.name,IMAGE:.spec.template.spec.containers[0].image' | head1
2
3
2
3
操作步骤
第 1 步：变更单必填五项
bash
cat > change-request.md <<'EOF'
# 变更单 CR-<编号>
1. 变更内容：<改了什么、影响哪个服务>
2. 风险与影响面：<最坏情况>
3. 回滚方案：<具体命令/操作，不是"回滚版本">
4. 验证方式：<如何确认成功>
5. 灰度计划：<批次与观察时长>
EOF1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
回滚方案写不出具体步骤的变更，一律不予批准。
第 2 步：评审关注三点
bash
cat > review-checklist.md <<'EOF'
- [ ] 是否可回滚（版本/配置/数据三类中哪类）
- [ ] 是否有灰度与观察窗口
- [ ] 是否避开大促、发布冻结期与其他团队变更
EOF1
2
3
4
5
2
3
4
5
第 3 步：灰度分批次推进
bash
# 例：先 1 个副本灰度，观察 10 分钟
kubectl -n prod scale deploy/demo-canary --replicas=1
sleep 600
curl -sS --data-urlencode 'query=sum(rate(http_requests_total{job="demo-canary",code=~"5.."}[5m]))' \
http://127.0.0.1:9090/api/v1/query | jq -r '.data.result[].value[1]'1
2
3
4
5
2
3
4
5
第 4 步：流水线卡点
yaml
# CI 中强制校验：变更单号存在、回滚命令可执行
steps:
- name: check-change-id
run: |
grep -qE '^CR-[0-9]+' change-request.md || { echo "缺少变更单"; exit 1; }
- name: check-rollback
run: |
grep -q 'kubectl.*rollout undo' change-request.md || { echo "缺少回滚方案"; exit 1; }1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
第 5 步：回滚并验证
bash
# 应用类回滚
kubectl -n prod rollout undo deploy/demo
kubectl -n prod rollout status deploy/demo --timeout=180s
# 配置类回滚（以 GitOps 为例）：恢复提交
git revert --no-edit <commit> && git push1
2
3
4
5
6
2
3
4
5
6
验证
bash
# 1. 变更单填写完整
for s in '变更内容' '风险' '回滚方案' '验证方式' '灰度计划'; do
grep -q "$s" change-request.md && echo "$s OK" || echo "$s 缺失"
done
# 2. 回滚确实生效（镜像版本回到上一版）
kubectl -n prod rollout history deploy/demo | tail -3
# 3. 变更后服务健康
kubectl -n prod get deploy demo -o jsonpath='{.status.readyReplicas}/{.spec.replicas}{"\n"}'1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
常见坑
回滚方案只写"回滚版本"
数据变更（改表结构、刷数据）无法靠回滚版本解决。数据类变更必须有前向兼容与补偿脚本。
一次变更包含多个改动
混杂变更后无法定位是哪一处引发问题。一个变更单只做一件事。
跳过灰度直接全量
全量发布把风险一次性放大。任何生产变更都要有至少一档灰度与观察窗口。