19.4.7 自动化变更与审批联动

自动化变更与审批联动的核心目标是将变更申请、风险评估、审批流转与执行编排打通，形成可控、可追溯、可回滚的闭环。平台需定义统一的变更模型（变更类型、影响范围、风险等级、窗口期、回滚方案、验收标准），并与任务编排引擎绑定，实现“审批通过即触发、审批驳回即终止”。

原理草图（审批、执行、审计联动）：

变更模型与审批联动示例（YAML 模型 + 审批回调触发）：

# /opt/change/change-20240501.yaml
id: CHG-20240501-001
type: standard         # standard/emergency/routine
service: api-gateway
env: prod
risk: medium
window: "2024-05-01 02:00-03:00"
owner: ops_a
plan:
  exec_job: rundeck/job/rolling-restart
  parameters:
    batch: 20%
    delay: 60
rollback:
  exec_job: rundeck/job/rollback-restart
acceptance:
  - check: "http 200率 > 99.5%"
  - check: "P95 < 200ms"

# 1) 生成变更单并提交审批（示例：调用内部审批API）
curl -X POST http://approve.local/api/v1/change \
  -H 'Content-Type: application/yaml' \
  --data-binary @/opt/change/change-20240501.yaml

# 2) 审批通过后回调执行引擎（示例：Rundeck Webhook）
curl -X POST http://rundeck.local/api/40/job/trigger \
  -H 'Content-Type: application/json' \
  -d '{"jobId":"rolling-restart","argString":"-batch 20% -delay 60"}'

# 3) 验收证据采集（示例：Prometheus指标快照）
curl -G http://prom.local/api/v1/query \
  --data-urlencode 'query=rate(http_requests_total{code="200"}[5m])'

安装示例（轻量审批联动服务 + Webhook 接收器）：

# 安装Python运行环境与依赖
yum -y install python3
pip3 install flask gunicorn pyyaml requests

# /opt/approve/app.py（审批回调服务）
cat >/opt/approve/app.py <<'PY'
from flask import Flask, request, jsonify
import yaml, requests

app = Flask(__name__)

@app.route('/api/v1/change', methods=['POST'])
def create_change():
    data = yaml.safe_load(request.data)
    # 简化：直接记录并模拟审批通过
    # 实际应写入DB并走审批流
    cb = {"jobId": data["plan"]["exec_job"].split("/")[-1],
          "argString": f'-batch {data["plan"]["parameters"]["batch"]} -delay {data["plan"]["parameters"]["delay"]}'}
    requests.post("http://rundeck.local/api/40/job/trigger", json=cb, timeout=5)
    return jsonify({"status":"approved","id":data["id"]})

if __name__ == '__main__':
    app.run(host="0.0.0.0", port=8081)
PY

# 启动服务
gunicorn -b 0.0.0.0:8081 /opt/approve/app:app

自动化执行与回滚示例（Ansible 编排 + 验收）：

# /opt/ansible/rolling-restart.yml
- hosts: api_gateway
  serial: 20%
  tasks:
    - name: 重启服务
      systemd:
        name: api-gateway
        state: restarted
    - name: 健康检查
      uri:
        url: "http://{{ inventory_hostname }}:8080/health"
        status_code: 200
      register: hc
      retries: 5
      delay: 3
      until: hc.status == 200

# /opt/ansible/rollback-restart.yml
- hosts: api_gateway
  tasks:
    - name: 回滚到上一版本
      shell: /opt/bin/rollback.sh

# 执行编排
ansible-playbook -i /opt/ansible/hosts /opt/ansible/rolling-restart.yml

# 回滚执行
ansible-playbook -i /opt/ansible/hosts /opt/ansible/rollback-restart.yml

关键命令解释与执行闭环要点：
- curl -X POST http://approve...：提交变更单到审批服务并触发审批流。
- curl -X POST http://rundeck...：审批通过后的执行触发，参数与变更单一致。
- ansible-playbook ... rolling-restart.yml：分批重启并做健康检查，失败触发补偿。
- ansible-playbook ... rollback-restart.yml：回滚到上一稳定版本。
- Prometheus query：采集验收指标，形成变更证据。

排错与常见问题（含命令）：
1) 审批通过未触发执行

# 查看审批服务日志
journalctl -u gunicorn -n 100
# 验证回调接口是否可达
curl -I http://rundeck.local/api/40/job/trigger

2) 执行失败未回滚

# 检查Ansible失败原因
ansible-playbook -i /opt/ansible/hosts /opt/ansible/rolling-restart.yml -vv
# 验证回滚脚本是否存在且可执行
ls -l /opt/bin/rollback.sh

3) 变更窗口被阻止（冻结）

# 检查监控告警是否触发冻结规则
curl -G http://prom.local/api/v1/query --data-urlencode 'query=ALERTS{alertstate="firing"}'

练习与实操建议：
1) 设计一份标准变更与紧急变更的 YAML 模型，分别配置不同审批链与回滚策略。
2) 将 rolling-restart.yml 改造成灰度发布（10%/30%/60% 三阶段），并在失败时自动执行回滚。
3) 在审批服务中增加“审批超时自动拒绝”逻辑，并验证任务不会被触发。
4) 使用 Prometheus 指标作为验收条件，形成“验收未通过自动回滚”的闭环。