19.7.3 变更评审与审批机制

变更评审与审批机制是发布管理中控制风险的核心环节，目标是在保证业务连续性的前提下，实现变更的可追溯、可审核与可控执行。本节给出可落地的评审对象、流程、审批机制，并配套示例、命令与排错要点。

一、变更评审原理与流程草图

二、评审对象与范围（示例）
- 生产环境发布、配置调整、数据库变更、网络与安全策略调整等高风险操作必须评审。
- 中间件变更（MySQL/Nginx/Redis/Nacos/Kafka/ZooKeeper/Keepalived/HAProxy/ProxySQL）纳入统一评审。
- 容器平台变更（Docker、Kubernetes集群升级、组件调整）需专项评审。

三、评审流程与角色（示例工单字段）
- 申请人提交变更单：目的、影响范围、实施步骤、回滚方案、验证计划、变更窗口。
- 评审委员会：业务负责人、运维负责人、安全合规人员，必要时架构/DBA参与。
- 紧急变更走快速审批，但必须补齐事后复盘与风险说明。

四、审批机制与权限控制
- 分级审批：低风险自动审批；中高风险多级审核。
- 权限与职责分离：审批与执行分离，避免同人同环节。
- 审批记录与审计日志全量留存，支持监管与合规。

五、与自动化平台的集成（Jenkins 示例）
在流水线中嵌入审批节点，审批通过才能发布：

pipeline {
  agent any
  stages {
    stage('预检查') {
      steps {
        sh 'scripts/precheck.sh'
      }
    }
    stage('审批') {
      steps {
        input message: '是否批准变更？', ok: '批准'
      }
    }
    stage('发布') {
      steps {
        sh 'scripts/deploy.sh'
      }
    }
    stage('验证') {
      steps {
        sh 'scripts/verify.sh'
      }
    }
  }
}

六、典型评审清单（示例）
- 变更目标与范围是否清晰；
- 受影响服务与依赖是否已通知；
- 备份是否完成且可用；
- 回滚演练是否验证；
- 监控与告警是否已配置；
- 变更窗口是否符合业务要求。

技术示例：变更申请、验证、回滚与审批命令#

1）变更单样例（YAML 模板）

change_id: CHG-20250108-001
title: Nginx 开启新站点域名
risk_level: medium
scope:
  - app: web-portal
  - hosts: ["10.0.1.10","10.0.1.11"]
steps:
  - "下发 /etc/nginx/conf.d/portal.conf"
  - "nginx -t 校验"
  - "systemctl reload nginx"
rollback:
  - "恢复旧配置文件备份"
  - "nginx -t && systemctl reload nginx"
verify:
  - "curl -I https://portal.example.com"
window: "2025-01-08 02:00-02:30"

2）变更前检查（示例脚本）

#!/usr/bin/env bash
set -e
echo "[预检查] 配置语法检查"
nginx -t

echo "[预检查] 端口监听"
ss -lntp | grep -E '(:80|:443)'

echo "[预检查] 备份配置"
cp /etc/nginx/conf.d/portal.conf /backup/portal.conf.$(date +%F_%H%M)

3）变更实施与验证

# 下发新配置
scp portal.conf root@10.0.1.10:/etc/nginx/conf.d/portal.conf
scp portal.conf root@10.0.1.11:/etc/nginx/conf.d/portal.conf

# 语法检查并重载
ssh root@10.0.1.10 "nginx -t && systemctl reload nginx"
ssh root@10.0.1.11 "nginx -t && systemctl reload nginx"

# 业务验证
curl -I https://portal.example.com

4）回滚示例

# 恢复配置并重载
ssh root@10.0.1.10 "cp /backup/portal.conf.2025-01-08_0200 /etc/nginx/conf.d/portal.conf && nginx -t && systemctl reload nginx"
ssh root@10.0.1.11 "cp /backup/portal.conf.2025-01-08_0200 /etc/nginx/conf.d/portal.conf && nginx -t && systemctl reload nginx"

中间件变更评审示例与命令#

MySQL：新增索引评审示例
- 风险：锁表与性能影响，需评估业务峰值。
- 变更：ALTER TABLE users ADD INDEX idx_email(email);
- 预估：使用在线 DDL 或低峰期执行。

-- 评估索引基数
SHOW INDEX FROM users;

-- 在线 DDL（MySQL 5.7+）
ALTER TABLE users ADD INDEX idx_email(email), ALGORITHM=INPLACE, LOCK=NONE;

Kafka：配置变更评审示例
- 风险：副本因子与 ISR 变化影响可用性。

# 查看主题配置
kafka-configs.sh --bootstrap-server kafka01:9092 --describe --entity-type topics --entity-name orders

# 修改配置（示例）
kafka-configs.sh --bootstrap-server kafka01:9092 --alter --entity-type topics \
  --entity-name orders --add-config min.insync.replicas=2

Kubernetes：Deployment 变更评审
- 风险：镜像升级与资源变更影响稳定性。

# 变更前检查
kubectl get deploy web -n prod
kubectl describe deploy web -n prod

# 升级镜像
kubectl set image deploy/web web=repo/web:1.2.3 -n prod

# 观察滚动更新状态
kubectl rollout status deploy/web -n prod

审批平台化示例（工单系统 API）#

# 提交变更工单
curl -X POST https://ops.example.com/api/change \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "title":"Nginx新增站点",
    "risk":"medium",
    "window":"2025-01-08 02:00-02:30",
    "steps":["下发配置","nginx -t","reload"],
    "rollback":["恢复备份","reload"],
    "verify":["curl -I https://portal.example.com"]
  }'

排错与常见问题处理#

1）审批节点卡住
- 检查审批人是否有权限或超时策略。
- Jenkins 示例排错：

# 查看流水线日志中是否等待 input
grep -n "Input requested" /var/log/jenkins/jenkins.log

2）变更后服务异常
- 先按回滚方案操作，恢复服务；
- 再进入复盘，确认配置或版本差异：

diff -u /backup/portal.conf.2025-01-08_0200 /etc/nginx/conf.d/portal.conf

3）数据库变更导致锁表
- 检查当前锁：

SHOW PROCESSLIST;
SHOW ENGINE INNODB STATUS\G

若锁表严重，终止长事务并回滚变更。

练习题（动手实践）#

设计一个“Redis 配置变更”的工单模板，包含风险评估、回滚与验证。
使用 Jenkins pipeline 增加“审批节点”和“回滚节点”，模拟一次失败回滚。
在测试环境对 Nginx 做一次变更并记录审批与审计日志（日志内容需包含变更人、时间、影响范围）。