数据库运维这活儿，干好了没人夸，干砸了全公司找你。我见过太多团队，备份脚本写了一大堆，真出了事才发现恢复不了；监控告警配了几十条，半夜三更被叫起来一看，全是误报。问题出在哪？不是技术不行，是压根没把运维计划当回事。所谓计划，不是贴在墙上的制度文件，而是你遇到故障时肌肉记忆般的操作流程。今天这篇东西，不跟你聊高大上的架构设计，就说说从日常维护到故障应急，一份能落地的数据库运维计划到底该怎么搭。
日常维护的核心，不是勤快，是规律。很多DBA喜欢每天手动跑一遍检查脚本，今天查磁盘，明天看慢查询，后天清日志。这种随机性的维护方式，看着忙忙碌碌，其实漏洞百出。你今天忘了查连接数，明天就可能被突增的并发打爆。我的建议是，把维护动作拆成三个时间维度：小时级、天级、周级。小时级看活跃会话数和锁等待，天级看慢查询趋势和备份完整性，周级做索引碎片整理和表空间预估。每一类动作固定时间点执行，比如每天凌晨两点跑全量备份，早上七点检查备份日志。规律一旦建立，出问题的概率会直线下降。
监控告警是运维计划里最容易走偏的部分。告警配少了，故障发现不及时；配多了，狼来了喊太多，真出事了反而没人看。我见过最离谱的案例，某公司一条慢查询告警一天能触发两千次，DBA直接把告警关了，结果某天这条SQL把库拖死，全站挂了四十分钟。正确的做法不是关告警，是给告警分级。P0级，比如主库宕机、数据目录损坏，直接电话通知；P1级，比如磁盘使用率超85%、复制延迟超30秒，发短信加企业微信；P2级，比如慢查询增多、连接数超过阈值80%，只记录到日报里。分级之后，告警量会骤降，而真正重要的消息一次都不会漏。
备份这件事，我每次都要单独拎出来说，因为翻车率实在太高。很多人觉得，我每天全量备份，够安全了吧？可你恢复过吗？备份文件在不在？能不能用？恢复需要多久？这三个问题，十个团队里有八个答不上来。真正的备份计划，必须包含定期恢复演练。我建议每季度做一次随机时间点的恢复测试，找个测试库，把最近一次备份导进去，模拟业务查询。这个过程能暴露的问题太多了：备份文件损坏、日志断档、恢复脚本权限不足。另外，备份文件一定要异地存储，别跟数据库放同一台机器——机房漏水、硬盘阵列同时故障，这种小概率事件，遇上了就是百分百。
故障应急这块，最忌讳临场发挥。很多团队没有预案，出了事全凭主DBA的个人经验，其他人只能干瞪眼。真正落地的应急计划，得把故障场景穷举出来：主库宕机、从库复制中断、磁盘写满、误删数据、连接数打爆、慢查询拖垮CPU。每一个场景，都要有明确的处理步骤和责任人。比如主库宕机，第一步不是重启，是确认从库数据延迟，然后决定是提升从库还是修复主库。这些步骤写下来，打印出来贴在工位上，比任何运维平台都管用。平时每个月做一次故障演练，随机挑一个场景，全员参与，掐表计时。演练过的团队，真出事时手都不抖。
应急响应的节奏感，决定了故障的最终影响。我观察过很多团队，出故障时第一反应是慌，第二反应是瞎试。正确的节奏应该是：前五分钟，确认故障范围和影响面，别急着动库；五到十五分钟，按预案执行第一步操作，同时通知相关业务方；十五分钟到半小时，如果预案没解决问题，立刻升级，叫上技术负责人一起判断。记住一个原则：故障处理不是秀操作，是止损。尤其生产环境，任何不确定的操作，都可能让情况恶化。如果你不确定一条SQL会不会锁表，不确定一个参数改了会不会引发连锁反应，那就别动，等更专业的人来。
复盘这件事，很多团队流于形式。出了故障，开会骂一顿，写个报告，然后该干嘛干嘛。真正的复盘，得回答三个问题：根因是什么？监控为什么没提前发现？处理过程中哪个环节最耗时？第三个问题尤其重要，因为很多故障不是解决不了，是解决得太慢。比如某公司数据库连接数被打爆，DBA花了二十分钟才定位到是某个新上线的服务没配连接池，这二十分钟就是纯浪费。复盘之后，要形成行动项，每一条都得有人认领，有截止时间。下个月再开会，先检查这些行动项完成没有，否则复盘就是走过场。
说了这么多，回到计划本身。一份能落地的数据库运维计划，不需要花里胡哨的文档，也不需要一年更新八次。它应该像飞机的检查清单，每个起飞前飞行员都会逐项核对，哪怕飞了一万次也不跳过。日常维护的规律性、监控告警的分级、备份恢复的演练、故障应急的预案，这四块拼图缺一不可。哪怕你从明天开始，只把备份恢复演练做了，只把告警分级调了，这份计划就已经开始发挥作用了。数据库这东西，平时安安静静的，但它出事的时候，从来不会提前打招呼。你准备的每一分，都会在那一刻兑现。
