19.7.7 变更记录、审计与合规

变更记录、审计与合规是发布管理的“可追溯、可验证、可复盘”基础。本节聚焦记录规范、审计流程、合规对齐与系统化落地，确保所有变更在时间、人员、内容、影响范围与审批链路上可追踪，并形成可审计的证据闭环。

变更记录标准与字段规范#

统一变更记录模板，保证跨团队一致性与可检索性，建议包含以下字段：
- 变更编号：全局唯一（如 YYYYMMDD-业务-流水）
- 变更类型：功能发布/配置变更/紧急修复/架构调整/安全更新
- 影响范围：系统、模块、环境、用户群
- 变更内容摘要：简洁说明改动点
- 变更前后对比：配置项、版本号、依赖变化
- 关联对象：需求/工单/问题单/缺陷单/监控告警
- 评审与审批链路：评审人、审批人、时间戳
- 执行人与执行时间：谁在何时执行
- 风险与回滚：风险评估、回滚方案与触发条件
- 结果与验证：发布结果、验证方法、验收人
- 证据链接：变更工单、流水线、日志、监控截图

示例：变更记录模板（Markdown 可直接落库或提交到 Git）

# 变更编号
20240520-pay-0007

# 变更类型
配置变更

# 影响范围
系统: pay-api
环境: prod
用户群: 全量

# 变更内容摘要
提升Nginx upstream超时，降低支付回调超时

# 变更前后对比
- proxy_read_timeout: 30s -> 60s

# 关联对象
工单: CHG-20240520-217
告警: ALERT-9341

# 评审与审批链路
评审人: zhangsan 2024-05-20 10:00
审批人: lisi 2024-05-20 10:15

# 执行人与执行时间
执行人: ops01 2024-05-20 10:30

# 风险与回滚
风险: 低
回滚: 恢复nginx.conf备份并reload
触发条件: 响应P99 > 2s 或 5xx>0.5%

# 结果与验证
结果: 成功
验证: curl /healthz + 监控查看 30min
验收人: lisi 2024-05-20 11:10

# 证据链接
Jenkins: http://jenkins/job/pay-api/1021
日志: http://kibana/logs/xxxx

原理草图：变更—审计—合规链路#

审计机制与职责分离#

建立“提出—评审—批准—执行—验证—归档”的审计链路，并落实职责分离：
- 变更发起人与审批人分离，避免自批
- 生产执行需经二次确认与授权
- 变更证据自动归档，减少人工遗漏
- 定期抽样审计与全量审计结合，形成巡检制度

示例：Linux 审计日志（auditd）安装与关键规则

# 安装并启动 auditd
sudo yum install -y audit
sudo systemctl enable --now auditd

# 记录对nginx配置文件的写操作
sudo auditctl -w /etc/nginx/nginx.conf -p wa -k nginx_conf_change

# 查看审计事件
sudo ausearch -k nginx_conf_change

# 生成可读报告
sudo aureport -f -i | head -n 20

审计日志示例输出（节选）：

file=/etc/nginx/nginx.conf  perm=wa  auid=1001  exe="/usr/bin/vim"

合规要求与基线对齐#

对齐行业合规与企业内部基线，形成统一的合规框架：
- 关键系统变更必须留存审批与验证证据
- 生产变更必须有审计日志与操作记录
- 紧急变更需补充后置评审与追责机制
- 变更记录保留期限统一（如 1～3 年）

示例：变更记录落库（MySQL）与查询

-- 表结构示例
CREATE TABLE change_record (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  change_id VARCHAR(64) UNIQUE,
  service VARCHAR(64),
  env VARCHAR(16),
  type VARCHAR(32),
  summary VARCHAR(255),
  approver VARCHAR(64),
  executor VARCHAR(64),
  exec_time DATETIME,
  result VARCHAR(16),
  evidence_url VARCHAR(255)
);

-- 插入记录
INSERT INTO change_record
(change_id, service, env, type, summary, approver, executor, exec_time, result, evidence_url)
VALUES
('20240520-pay-0007','pay-api','prod','config','nginx timeout 30->60',
 'lisi','ops01','2024-05-20 10:30:00','success',
 'http://jenkins/job/pay-api/1021');

-- 审计查询：最近7天生产变更
SELECT change_id, service, exec_time, result
FROM change_record
WHERE env='prod' AND exec_time > NOW() - INTERVAL 7 DAY;

变更审计与日志联动#

将变更记录与系统日志、监控告警、流水线日志进行联动：
- 通过变更编号关联流水线构建、部署日志
- 变更窗口内异常告警自动关联变更记录
- 关键配置变更自动生成差异报告并归档
- 审计系统定期输出异常变更与未审批变更列表

示例：配置变更差异与归档

# 备份与对比
sudo cp /etc/nginx/nginx.conf /var/backups/nginx.conf.$(date +%F_%H%M)
sudo vim /etc/nginx/nginx.conf

# 生成差异报告并归档
diff -u /var/backups/nginx.conf.* /etc/nginx/nginx.conf \
  | sudo tee /var/log/change-diff/nginx_conf_$(date +%F_%H%M).diff

# 记录变更编号到日志
echo "CHG=20240520-pay-0007" | sudo tee -a /var/log/change-diff/README

证据链与可追溯性建设#

可追溯性基于“人、事、物、时”四要素：
- 人：操作人、审批人、验证人明确
- 事：变更内容可回溯
- 物：代码、配置、镜像、制品可定位
- 时：时间戳精准，包含各节点执行时间

示例：Git 标签与制品记录

# 打标签并推送
git tag -a v1.4.7 -m "CHG 20240520-pay-0007"
git push origin v1.4.7

# 记录镜像信息
docker images | grep pay-api
# 输出示例：registry/pay-api:v1.4.7  sha256:xxxx

变更记录质量与常见问题#

需避免以下低质量记录问题：
- 缺少变更影响范围与验证方式
- 回滚方案不完整或不可执行
- 紧急变更未补审批或未复盘
- 记录与真实执行不一致（时间/人/内容）

排错示例：审计不到配置变更

# 1) 检查审计规则是否存在
sudo auditctl -l | grep nginx_conf_change

# 2) 确认 auditd 运行
systemctl status auditd

# 3) 规则被重置时持久化配置
echo "-w /etc/nginx/nginx.conf -p wa -k nginx_conf_change" | \
  sudo tee /etc/audit/rules.d/nginx.rules
sudo augenrules --load
sudo systemctl restart auditd

量化指标与持续改进#

通过指标提升记录与审计质量：
- 变更记录完整率
- 审批及时率与超时率
- 紧急变更占比与补审完成率
- 变更后故障率与回滚率
- 审计问题闭环率

示例：统计完整率（从 MySQL 快速抽样）

SELECT
  ROUND(SUM(CASE WHEN evidence_url IS NOT NULL AND evidence_url<>'' THEN 1 ELSE 0 END)/COUNT(*),2)
  AS evidence_complete_rate
FROM change_record
WHERE exec_time > NOW() - INTERVAL 30 DAY;

落地建议#

将变更记录纳入发布流水线自动生成与强制校验
在运维平台内置变更模板与字段必填校验
建立定期审计与复盘机制，固化为运维流程
对高风险系统实施强审计策略，确保可追溯与合规

练习#

为 /etc/ssh/sshd_config 添加审计规则，执行一次配置变更并用 ausearch 查询证据。
建一个简单 change_record 表，插入 3 条变更记录并查询最近 7 天生产变更。
对 Nginx 配置做一次变更，生成 diff 文件并与变更编号关联归档。