本文目录导读：
配置变更记录是运维和开发工作中非常关键的一环，主要目的是为了追踪、审计和回滚，做好配置变更记录，通常需要遵循“记录什么、用什么工具、流程怎么走”这三个步骤。
下面是一套比较完整的实践方案，从简单到专业,你可以根据团队规模选择。
核心原则：记录“4W1H”
每次变更记录都至少需要回答以下问题：
- Who：谁做的变更？
- When：何时变更？（精确到秒,包括开始和结束时间）
- What：变更了什么内容？（具体的配置项、文件、参数）
- Why：变更原因是什么？（关联需求单、故障单号或功能描述）
- How：如何变更？（操作步骤、变更前的备份、变更后的验证结果）
最轻量级（适合个人或小团队）
直接用Excel或在线表格（如飞书、腾讯文档）。
结构参考：
| 变更时间 | 变更人 | 变更对象（服务器/IP/应用） | 变更前值/描述 | 变更后值/描述 | 变更原因（关联工单） | 变更结果（成功/失败/回滚） |
|---|---|---|---|---|---|---|
| 2024-05-20 10:00 | 张三 | Nginx生产服务器（10.0.0.1） | worker_processes 2 | worker_processes 4 | 应对流量高峰（工单#123） | 成功 |
| 2024-05-21 14:30 | 李四 | MySQL连接池配置 | max_connections=500 | max_connections=1000 | 修复频繁断连问题（BUG#456） | 成功 |
优点： 零成本，上手快。 缺点： 难追溯、易丢失、无法自动化、人工填写易遗漏。
进阶版（适合中小团队）
使用 Git 或 SVN 进行配置文件的版本控制。
怎么做：
- 将所有的配置文件（Nginx、MySQL、Redis、应用配置等）统一放在一个Git仓库中。
- 每次修改配置文件时，都遵循
git pull -> 修改文件 -> git commit -m "变更原因" -> git push的流程。 - 利用Git的
diff功能，可以清晰地看到每一次修改了什么、谁修改的、为什么修改。
优点： 版本历史完整，回滚方便（git revert），可与代码管理统一。
缺点： 需要手动更新配置文件仓库，且变更记录与变更操作可能分离（如果改完忘了push）。
专业化（适合中大型团队）
这是目前行业内的最佳实践，结合了基础设施即代码和变更管理平台。
使用基础设施即代码工具
将配置视为代码，通过工具自动管理,变更记录由工具自动生成。
- Ansible / SaltStack / Puppet： 将所有服务器配置写成Playbook或State文件，存储在Git中，每次执行
ansible-playbook都会自动生成执行日志和变更记录。 - Terraform： 管理云资源（如阿里云、腾讯云、AWS）。
terraform plan展示变更计划，terraform apply记录谁在何时创建/修改/删除了什么资源。
使用专门的变更管理平台
结合DevOps工作流。
- GitLab / GitHub / Gitee：
- 开发/运维人员创建一个 合并请求。
- 描述变更原因，附上影响范围。
- 经过代码审查和审批。
- 通过 CI/CD流水线（如Jenkins、GitLab CI）自动下发配置变更。
- 合并请求的完整记录（讨论、审批、流水线日志、代码diff）就是最正式的变更记录。
使用日志和审计系统
- 堡垒机（如JumpServer、齐治）：所有运维人员必须通过堡垒机登录服务器，堡垒机会记录所有执行过的命令（
who、when、what command）,这是最底层的变更审计证据。 - Prometheus + Grafana / ELK（Elasticsearch, Logstash, Kibana）：配置变更后，监控指标（如CPU、连接数、错误率）的变化本身就是变更记录的验证部分。
最佳实践流程（建议参考）
无论你选哪种工具，流程决定了记录的质量,一个标准的配置变更记录流程应该包含：
- 发起（Create）：
- 创建变更单（Jira、工单系统），描述清晰：“为Nginx添加www.example.com的443端口SSL证书配置”。
- 计划（Plan）：
- 填写变更脚本或详细操作步骤。
- 填写回滚方案（这是核心！ 变更失败后如何恢复原状）。
- 评估影响范围和高风险项。
- 审批（Approval）：
- 技术负责人审批方案的正确性。
- 业务负责人审批变更时间点。
- 实施（Execute）：
- 在指定的变更窗口（如凌晨2点）操作。
- 变更前： 备份当前配置（
cp config.cnf config.cnf.bak.20240520）。 - 变更中： 执行操作,并打开录屏或TLog。
- 变更后： 立即进行功能验证和监控检查。
- 记录（Record）：
- 在工单或Git中，填写:
- 变更前MD5值 / 变更后MD5值
- 验证结果截图
- 是否触发告警
- 实际变更耗时
- 在工单或Git中，填写:
- 审计（Audit）：
定期（如每周）拉取变更记录进行复盘,寻找易错点。
如何开始？
- 如果你什么都没有： 现在就在内网共享一个Excel表格,从下一次变更开始填写。
- 如果你有代码管理： 立即把配置目录初始化为Git仓库，开始
git commit。 - 如果你有自动化工具： 完善Ansible/Terraform的代码仓库，并和CI/CD集成。
- 如果你有合规要求（如金融、医疗）： 必须上堡垒机，并强制变更审批流+变更后审计。
关键在于养成习惯，配置变更记录不是写给别人看的，而是防止你自己踩坑的“救命稻草”。
