配置基线为什么要版本化
把关键配置（sshd、nginx、防火墙规则、中间件配置）纳入版本化管理，定期将存档与现网做差异比对：既能在有人改了配置却没说时立刻发现，也能在故障后快速回滚到已知可用状态。适用 Linux 服务器与网络设备，轻量做法是定期复制加 diff，成熟做法是把配置目录纳入版本控制。
基本信息
| 覆盖范围 | 登录配置、Web 服务器、调度、防火墙、中间件 |
|---|---|
| 常见工具 | etckeeper、git、配置管理系统 |
| 执行频率 | 每周存档，变更后即时复查 |
| 权限要求 | 基线仓库需限制访问，内容含拓扑与策略信息 |
| 输出要求 | diff 结果附到变更记录，可追溯 |
典型使用场景
- 异常变更发现：登录方式被改动、防火墙策略被放宽时第一时间得知
- 故障回滚：配置改坏后按存档快速恢复，缩短故障时长
- 变更留痕：每次变更附 diff 记录，审计时能说明改了什么
- 多机一致性：对比同角色机器的配置，找出漂移节点
- 交接与迁移：新环境搭建时以基线为准，减少遗漏
轻量做法示例
轻量做法示例
mkdir -p /srv/baseline/2026-10-12 # 按日期存档
cp -a /etc/ssh/sshd_config /etc/nginx/nginx.conf /srv/baseline/2026-10-12/
diff -u /srv/baseline/2026-10-05/sshd_config /etc/ssh/sshd_config
git -C /srv/baseline diff --stat # 或用版本控制管理
# 更彻底的做法：etckeeper 把 /etc 整体纳入 git，每次变更自动提交常见变更与风险信号
| 变更位置 | 风险信号 | 处置 |
|---|---|---|
| sshd_config | 认证方式被放宽、端口被改 | 立即核对变更单，无单回滚 |
| nginx 配置 | 新增 location 暴露内部路径 | 确认业务需求与访问控制 |
| 防火墙规则 | 新增全通策略 | 按最小开放原则收紧 |
| 定时任务 | 出现未知脚本任务 | 确认来源，可疑则隔离排查 |
| 中间件配置 | 监听地址从内网变为全网 | 立即恢复并核查原因 |
差异比对真正的价值在『有人改了但没说』的场景：把发现后的处置流程提前约定好（谁核实、多久回复、如何回滚），否则发现了也没人处理。
基线仓库本身是敏感资产：里面包含拓扑、策略与地址规划，权限设置应与生产配置同等级别，不要顺手放进公开的代码仓库。