数据库运维规范与变更流程

摘要：绝大多数数据库事故来自「无流程的操作」。本文给出可直接落地的变更分级、审批模板、备份策略基线与应急联系人制度，用制度把风险前置。

适用环境

bash

# 规范落地前先摸清家底：有哪些实例、谁在用、备份在哪
mysql -uroot -p -e "SELECT @@hostname, @@server_id, @@version;"
# 建议维护一份实例台账（负责人、用途、RPO/RTO、备份位置）

操作步骤

1. 操作分级

级别	示例	要求
L1 常规	查询、加只读账号	执行人记录即可
L2 有风险	DDL、加索引、参数调整	双人评审 + 变更单 + 备份
L3 高危	删数据、改主键、主从切换、版本升级	负责人审批 + 演练 + 回滚方案 + 低峰窗口

2. 变更单模板（直接复制使用）

【变更单】
1. 变更对象：<实例地址/库表>
2. 变更内容：<完整 SQL 或操作命令>
3. 影响范围：<影响行数/影响接口/预计耗时>
4. 执行窗口：<2026-10-09 02:00-04:00>
5. 执行人 / 复核人：<姓名>
6. 备份方式：<备份文件位置，已验证可恢复>
7. 验证方式：<执行后跑的检查 SQL>
8. 回滚方案：<反向 SQL 或还原步骤，已演练>
9. 风险与应对：<主从延迟、锁表、磁盘等>

危险

没有「回滚方案」和「已验证的备份」的变更单一律不予批准。回滚方案写成「用备份恢复」而不指明备份文件与恢复命令，视为无效。

3. 备份策略基线

数据重要度	全量频率	增量/binlog	异地留存	恢复演练
核心	每日	binlog 实时	有，保留 30 天	每季度
重要	每日	每日	有，保留 14 天	每半年
一般/可重建	每周	无	可选	每年

4. 账号管理规范

一人一账号，禁止共享 root；管理员账号走堡垒机与审批。
业务账号最小权限，禁止 % 来源与 ALL PRIVILEGES。
人员离职/转岗当天回收账号，季度做一次账号审计。

sql

-- 季度账号审计
SELECT user, host, account_locked, password_expired FROM mysql.user;

5. 应急制度

明确值班与升级路径：值班人 → 数据库负责人 → 技术负责人，各带时限。
每个核心集群一份「一页纸应急预案」：如何切主、如何限流、如何回滚。
事故后 24 小时内出复盘，改进项有责任人与截止时间。

6. 日常禁止清单（红线）

sql

-- 禁止在生产主库直接执行以下操作（举例）
DROP TABLE / TRUNCATE TABLE;               -- 需审批 + 备份 + 双人
DELETE FROM t;                              -- 无 WHERE
UPDATE t SET col=1;                         -- 无 WHERE

bash

# 禁止：rm -rf 数据目录、直接 kill -9 mysqld、在高峰执行大 DDL

验证

[ ] 每类操作的分级与审批人已明确并公示
[ ] 变更单模板在最近一次变更中实际使用过
[ ] 核心实例的备份与演练记录可查
[ ] 应急预案文档存在且值班人员知道在哪

常见坑

WARNING

规范写得很全但没人执行，等于没有。把变更单做成流程系统的必填项，而不是靠自觉。

WARNING

例外通道（紧急变更先做后补）会被滥用；应限定触发条件并记录事后补单时限与复盘要求。

DANGER

规范里若没有「拒绝权」（任何人可以叫停不合规操作），制度在压力下会被绕过。

数据库运维规范与变更流程 ​

适用环境 ​

操作步骤 ​

验证 ​

常见坑 ​

参考资料 ​

数据库运维规范与变更流程

适用环境

操作步骤

验证

常见坑

参考资料