数据库运维工程师安全操作规程

数据库运维工程师安全操作规程一、总则与适用范围（一）目的为规范数据库运维操作行为，防范操作风险，杜绝因人为失误导致的数据丢失、泄露、篡改及服务中断等安全事故，保障数据库系统稳定、安全、高效运行，特制定本操作规程。（二）适用范围本规程适用于公司内部所有生产环境、预发布环境及重要测试环境中的关系型数据库（如MySQL、PostgreSQL、Oracle、SQLServer）、非关系型数据库（如Redis、MongoDB、Elasticsearch）及相关中间件（如消息队列）的日常运维管理、变更操作、故障处理及应急响应工作。所有涉及数据库操作的人员（含DBA、研发人员、运维人员及第三方技术支持）均须严格遵守本规程。（三）引用标准与原则1.最小权限原则：任何账号仅授予完成本职工作所必需的最小权限，严禁越权访问。2.变更可追溯原则：所有数据库结构变更、配置修改、数据订正操作必须通过工单系统审批，留存完整操作记录与审计日志。3.不落地原则：生产环境敏感数据（姓名、手机号、身份证号、金融账号等）严禁未经脱敏处理导出至本地或非安全区域。4.“四不两直”原则（操作层面）：不经审批不操作、不备份不操作、不在业务高峰期进行风险操作、不擅自使用超级用户；直接操作前必查会话、直接操作后必验数据。二、通用安全操作规范（一）账号与认证管理1.账号唯一性：数据库账号实行“一人一账号”，禁止共享账号。应用账号必须与应用系统一一对应，并在元数据管理平台登记。2.双因子认证：对于生产环境数据库的高权限账号（DBA、SYSDBA、root），必须开启双因子认证或通过跳板机（堡垒机）进行二次授权。3.口令策略：密码长度不得少于12位，须包含大小写字母、数字及特殊字符。每90天强制更换一次。严禁将密码明文保存在代码仓库、配置文件中（应使用密钥管理服务KMS或密码保险箱）。4.权限回收：员工离职或调岗时，IT运维部门须在2小时内完成其所有数据库账号的权限回收或禁用。（二）连接与操作行为规范1.跳板机接入：所有生产数据库操作必须通过堡垒机（JumpServer）登录，严禁直连数据库实例。操作过程全程录屏审计。2.命令规范：高危命令禁用：严禁在生产环境执行无WHERE条件或WHERE条件不完整的UPDATE、DELETE操作；严禁执行DROP、TRUNCATE、SHUTDOWN等不可逆命令（除非经特定审批流程）。影响行数预检：执行UPDATE/DELETE前，必须先用相同条件执行SELECTCOUNT(*)或LIMIT1查询，确认影响范围。事务控制：执行批量修改（超过1000行）必须显式开启事务（BEGIN），分批提交（每500-1000行提交一次），严禁一条语句完成超大数据量变更。SQL模式限制：生产环境禁止使用SELECT*，禁止无索引字段的模糊查询（前导通配符%），防止全表扫描拖垮数据库。3.会话管理：操作完成后必须及时断开连接。闲置超过10分钟的交互式会话将被系统自动终止。（三）数据安全与隐私保护1.脱敏要求：任何查询、导出行为涉及敏感字段（如密码、身份证、手机号、银行卡号等），必须通过数据脱敏平台申请，返回结果需动态脱敏或静态脱敏。2.数据导出管控：禁止通过数据库客户端将生产数据导出为Excel、CSV等明文格式。如因审计、风控等特殊需求导出，须经部门负责人及信息安全负责人双审批，导出文件必须加密压缩，并通过安全通道传递，使用完毕后按保密规定销毁。3.测试数据同步：生产数据同步至测试环境，必须先经过脱敏处理，严禁生产真实数据直接落地测试库。三、数据库变更操作管理（DDL/DML）（一）变更分级与审批变更级别定义与示例审批流程执行窗口L1-低风险不影响表结构及数据逻辑的变更。如：新增普通索引（非在线DDL）、修改表注释、新增非关键监控指标。DBA主管审批即可。工作时间（避开业务高峰）L2-中风险涉及表结构修改（在线DDL）、新增字段（含默认值）、新增普通索引（大表在线创建）、数据订正（DML，影响行数<10万）。变更申请人→研发负责人→DBA主管审批。维护窗口（如周三凌晨00:00-04:00）L3-高风险涉及大表（>1000万行）DDL、删除字段、修改字段类型、DROP/TRUNCATE表、批量数据订正（>10万行）、索引重建、数据库参数调整。变更申请人→研发负责人→DBA主管→CTO/技术VP审批。变更窗口（需提前48小时报备，仅限业务低峰期）L4-紧急变更因故障处理、安全漏洞修复必须立即执行的变更。可由DBA值班负责人先行执行，但需在操作后15分钟内电话报备主管，并在24小时内补全工单审批。随时，但需遵循“先恢复，后优化”原则（二）DDL变更执行规范（以MySQL为例）1.预审检查：变更执行前需检查磁盘剩余空间（至少为表体积的1.5倍）、主从延迟状态（Seconds_Behind_Master为0或极小）。2.工具选择：针对MySQL5.7及以上版本，大表DDL必须使用`gh-ost`或`pt-osc`在线变更工具，严禁直接执行原生ALTERTABLE（避免锁表阻塞业务）。3.执行与回滚：变更脚本必须包含`IFNOTEXISTS`或`IFEXISTS`判断语句，确保可重复执行。每次变更前需拍摄当前表结构快照，并备份该表近7日数据（用于快速回滚）。变更完成后，立即执行`SHOWCREATETABLE`校验结构，并检查慢查询日志确认无性能衰减。（三）DML数据订正规范1.备份要求：涉及UPDATE/DELETE的数据订正，必须先进行数据备份，备份形式为`CREATETABLE表名_bak_YYYYMMDDASSELECT*FROM原表WHERE<影响条件>;`。2.执行要求：采用“先查后改、先小后大、逐步推进”策略。先更新少量数据（如100条），观察15分钟无异常后，再扩大范围。3.复核要求：变更完成后，需编写数据校验SQL（如对比SUM、COUNT值），确保数据逻辑正确。四、数据库备份与恢复操作规范（一）备份策略数据库类型备份方式备份周期保留策略校验方式MySQL物理备份（XtraBackup）+Binlog增量全备：每日0点；增备：每30分钟Binlog全备保留30天，Binlog保留15天每日自动校验备份集可用性，每周三模拟恢复抽检RedisRDB快照+AOF日志RDB：每日；AOF：每1秒RDB保留7天，AOF保留3天定期执行`DEBUGRELOAD`验证MongoDBmongodump+Oplog全备：每日；增量：每小时全备保留14天每月执行一次恢复演练（二）备份操作细则1.备份执行：备份脚本统一由备份平台调度，禁止人工在业务库执行`mysqldump`全量导出（避免锁表）。执行前必须检查磁盘空间（备份文件存放目录使用率<80%）。2.异地存储：备份文件必须实时同步至异地灾备存储（跨机房/跨地域），并确保备份文件加密存储（AES-256）。3.备份监控：备份任务执行失败，监控平台须在5分钟内发出告警，DBA须在30分钟内处理并重新触发备份。（三）恢复操作流程（应急场景）1.恢复决策：当发生数据误删、逻辑错误时，需由DBA主管、研发负责人、业务方共同评估恢复策略（基于时间点恢复PITR或全量+增量恢复）。2.恢复步骤（以MySQL为例）：步骤一：紧急冻结所有写操作（将应用账号改为只读或断网），防止新数据覆盖。步骤二：从备份平台下载最近的全量备份集，并解压校验MD5值。步骤三：在隔离实例上执行全量恢复（`--apply-log`完成前滚回滚）。步骤四：应用Binlog增量日志至误操作前一刻的位点（`mysqlbinlog--stop-datetime`）。步骤五：数据校验（表行数、关键业务指标SUM值对比）。步骤六：重新接入业务流量，观察15-30分钟确认系统稳定。3.恢复时效（RTO/RPO）：核心业务数据库RTO≤2小时，RPO≤10分钟；非核心业务RTO≤8小时，RPO≤30分钟。五、监控、巡检与告警处置（一）监控指标体系监控维度核心指标告警阈值处理时限性能类CPU使用率、内存使用率、磁盘IOPS、磁盘延迟CPU>80%持续15分钟；IO延迟>50ms30分钟连接类活跃会话数、连接数使用率、等待事件连接数>上限80%；活跃会话>10015分钟主从状态主从延迟（Seconds_Behind_Master）、Slave_IO_Running、Slave_SQL_Running延迟>30秒；线程状态为No立即空间类表空间使用率、binlog日志空间、临时表空间使用率>85%60分钟安全类慢查询数量变化、失败连接次数、权限变更审计慢查询突增100%；失败连接>10次/分钟30分钟（二）日常巡检（每日）1.巡检时间：每日上午9:30前完成核心业务数据库巡检。2.巡检内容：实例状态：检查数据库进程存活、监听端口状态。日志检查：检查`error.log`、`slow.log`中是否有新增异常（如`InnoDB:Assertionfailure`、`Toomanyconnections`）。复制状态：确认所有从库与主库同步无延迟、无报错。备份校验：确认昨日备份任务成功执行，且备份文件大小合理（无0字节文件）。元数据核对：检查表碎片率（>30%需整理）、自增ID使用率（>70%需预警）。（三）告警分级响应告警级别定义响应要求P0-严重数据库不可用、数据丢失风险、主从全断立即响应，5分钟内介入，通知主管及研发负责人，启动应急预案。P1-高性能严重劣化（CPU满载）、连接数耗尽、单节点故障10分钟内响应，DBA主导处理，30分钟内给出修复方案。P2-中磁盘空间紧张（>80%）、慢查询增多、主从延迟超过阈值30分钟内响应，分析原因并提交优化报告。P3-低非核心指标抖动、备份任务延迟当日处理完毕，记录至运维日志。六、应急响应与故障处理流程（一）应急组织架构1.指挥者：运维负责人（负责资源协调与对外通报）。2.执行者：DBA值班工程师（负责故障诊断与具体操作）。3.支持者：研发负责人、应用运维工程师（负责业务侧验证与配合）。（二）典型故障应急处置1.场景一：数据库实例宕机（进程不存在）止损：立即拉起进程。若无法拉起，优先尝试重启（注意检查`error.log`）。切换：若一主多从架构，立即提升数据最新的从库为主库（`SHOWSLAVESTATUS`检查`Exec_Master_Log_Pos`）。恢复：原主库恢复后，作为新主库的从库重新搭建，追平数据。严禁：严禁在未确认数据一致性的情况下强制覆盖主库数据文件。2.场景二：误删除数据（DROPTABLE/误UPDATE）紧急处置：立即锁定相关应用账号（`REVOKE`或`ALTERUSER...ACCOUNTLOCK`），防止二次写入。数据找回：利用备份集+Binlog进行时间点恢复（PITR），按第四节恢复流程操作。原因复盘：检查操作记录，追溯是审批缺失还是SQL编写错误，发布整改报告。3.场景三：CPU飙升导致业务卡顿快速定位：执行`SHOWPROCESSLIST`，找到`State`为`Sendingdata`或`Copyingtotmptable`的会话，记录其`ID`和执行的SQL。应急止血：使用`KILL`命令终止异常会话（需确认非核心业务会话）。优化SQL：联合研发人员对SQL进行执行计划分析（`EXPLAIN`），强制使用正确索引或改写SQL。4.场景四：磁盘空间满导致只读立即清理：优先清理`binlog`（但需确保已备份至远程存储）、慢查询日志、临时文件。扩容：若清理无效，立即联系云厂商或基础设施团队进行磁盘扩容。严禁：严禁直接`rm-rf`数据库数据文件目录。（三）故障复盘要求1.每次P0/P1级别故障，须在恢复后72小时内提交《故障复盘报告》。2.报告内容须包含：故障现象、时间线、根因分析（5WHY分析法）、处理过程、改进措施（技术+管理）、责任认定。3.所有复盘报告归档至知识库，定期组织学习，防止同类故障二次发生。七、附则与考核（一）安全操作红线（零容忍）1.未经审批擅自在生产库执行DROP/TRUNCATE/无WHERE条件UPDATE/DELETE。2.泄露生产环境数据库账号密码或敏感数据。3.私自关闭或绕过审计系统、堡垒机、监控告警系统。4.未进行备份验证导致数据恢复失败。（二）违规处理1.违反红线规定者，视情节严重程度给予通报批评、绩效降级、辞退处理，涉及违法的依法追究法律责任。2.违反一般操作规范（如未走工单、未开事务），给予警告并扣减相应绩效分。（三）培训与考核1.所有数据库运维人员须每半年参加一次安全操作规程培训及闭卷考试，考试合格（90分以上）方可继续上岗。2.本规程由运维部负责制定、解释和修订，自发布之日起执行。附：典型高危操作场景速查表操作场景是否允许前置条件关键动作严禁事项删除表数据有条件允许工单审批（L3级）`SELECTCOUNT(*)`预检；开启事务；分批`DELETE`（LIMIT1000）无事务执行；一次性DELETE全表清空表（TR