配置变更记录怎做？

本文目录导读：

1. 核心原则：记录“4W1H”
2. 方案一：最轻量级（适合个人或小团队）
3. 方案二：进阶版（适合中小团队）
4. 方案三：专业化（适合中大型团队）
5. 最佳实践流程（建议参考）
6. 总结：如何开始？

配置变更记录是运维和开发工作中非常关键的一环，主要目的是为了追踪、审计和回滚，做好配置变更记录，通常需要遵循“记录什么、用什么工具、流程怎么走”这三个步骤。

下面是一套比较完整的实践方案，从简单到专业,你可以根据团队规模选择。

核心原则：记录“4W1H”

每次变更记录都至少需要回答以下问题：

• Who：谁做的变更？
• When：何时变更？（精确到秒,包括开始和结束时间）
• What：变更了什么内容？（具体的配置项、文件、参数）
• Why：变更原因是什么？（关联需求单、故障单号或功能描述）
• How：如何变更？（操作步骤、变更前的备份、变更后的验证结果）

最轻量级（适合个人或小团队）

直接用Excel或在线表格（如飞书、腾讯文档）。

结构参考：

优点： 零成本，上手快。 缺点： 难追溯、易丢失、无法自动化、人工填写易遗漏。

进阶版（适合中小团队）

使用 Git 或 SVN 进行配置文件的版本控制。

怎么做：

1. 将所有的配置文件（Nginx、MySQL、Redis、应用配置等）统一放在一个Git仓库中。
2. 每次修改配置文件时，都遵循 git pull -> 修改文件 -> git commit -m "变更原因" -> git push 的流程。
3. 利用Git的 diff 功能，可以清晰地看到每一次修改了什么、谁修改的、为什么修改。

优点： 版本历史完整，回滚方便（git revert），可与代码管理统一。 缺点： 需要手动更新配置文件仓库，且变更记录与变更操作可能分离（如果改完忘了push）。

专业化（适合中大型团队）

这是目前行业内的最佳实践，结合了基础设施即代码和变更管理平台。

使用基础设施即代码工具

将配置视为代码，通过工具自动管理,变更记录由工具自动生成。

• Ansible / SaltStack / Puppet： 将所有服务器配置写成Playbook或State文件，存储在Git中，每次执行 ansible-playbook 都会自动生成执行日志和变更记录。
• Terraform： 管理云资源（如阿里云、腾讯云、AWS）。terraform plan 展示变更计划，terraform apply 记录谁在何时创建/修改/删除了什么资源。

使用专门的变更管理平台

结合DevOps工作流。

• GitLab / GitHub / Gitee：
  1. 开发/运维人员创建一个 合并请求。
  2. 描述变更原因，附上影响范围。
  3. 经过代码审查和审批。
  4. 通过 CI/CD流水线（如Jenkins、GitLab CI）自动下发配置变更。
  5. 合并请求的完整记录（讨论、审批、流水线日志、代码diff）就是最正式的变更记录。

使用日志和审计系统

• 堡垒机（如JumpServer、齐治）：所有运维人员必须通过堡垒机登录服务器，堡垒机会记录所有执行过的命令（who、when、what command）,这是最底层的变更审计证据。
• Prometheus + Grafana / ELK（Elasticsearch, Logstash, Kibana）：配置变更后，监控指标（如CPU、连接数、错误率）的变化本身就是变更记录的验证部分。

最佳实践流程（建议参考）

无论你选哪种工具，流程决定了记录的质量,一个标准的配置变更记录流程应该包含：

1. 发起（Create）：
   • 创建变更单（Jira、工单系统），描述清晰：“为Nginx添加www.example.com的443端口SSL证书配置”。
2. 计划（Plan）：
   • 填写变更脚本或详细操作步骤。
   • 填写回滚方案（这是核心！ 变更失败后如何恢复原状）。
   • 评估影响范围和高风险项。
3. 审批（Approval）：
   • 技术负责人审批方案的正确性。
   • 业务负责人审批变更时间点。
4. 实施（Execute）：
   • 在指定的变更窗口（如凌晨2点）操作。
   • 变更前： 备份当前配置（cp config.cnf config.cnf.bak.20240520）。
   • 变更中： 执行操作,并打开录屏或TLog。
   • 变更后： 立即进行功能验证和监控检查。
5. 记录（Record）：
   • 在工单或Git中，填写:
     • 变更前MD5值 / 变更后MD5值
     • 验证结果截图
     • 是否触发告警
     • 实际变更耗时
6. 审计（Audit）：

   定期（如每周）拉取变更记录进行复盘,寻找易错点。

如何开始？

• 如果你什么都没有： 现在就在内网共享一个Excel表格,从下一次变更开始填写。
• 如果你有代码管理： 立即把配置目录初始化为Git仓库，开始git commit。
• 如果你有自动化工具： 完善Ansible/Terraform的代码仓库，并和CI/CD集成。
• 如果你有合规要求（如金融、医疗）： 必须上堡垒机，并强制变更审批流+变更后审计。

关键在于养成习惯，配置变更记录不是写给别人看的，而是防止你自己踩坑的“救命稻草”。