上周三晚上，我进了 PostgreSQL 30 周年的一场线上直播。白鳝老师有句话让我印象很深，大意是：AI 纪元里，DBA 不该再把异常处理、数据恢复、各种专项处置这些”特殊技能”当成核心竞争力。
我在直播间连连点头。因为这事儿我最近刚撞过一次。
道理其实就两条。一是数据库基础设施本身在补全，以前靠人肉兜底的情形，现在高可用、容灾备份、自治调优、云托管直接在结构层兜住了。二是 AI 正通过 Agent 的形式，把原来”需要经验判断”的活变成”可以标准化执行”的活。两条一旦同时成立，那些引以为傲的绝活就不再稀缺。
那场两小时的面试，全在问绝活
这几年我只参加过一次技术面试，整个下午两个小时，对方问的全是这类：Oracle 数据库怎么加速大事务回滚？某个隐藏参数什么意思、什么时候用？各种刁钻的故障处理与数据恢复场景怎么破？
老实说，其中一些我能答。OCM 考过来的人，手艺活不至于完全陌生。但我给出的答案，明显不是对方想要的。
大事务回滚，我的回答是：在我管理的库里，监控告警做得相对到位，真出现了也安排在非工作时间用应急手段处置，而不是像您说的那样。隐藏参数我的态度更直接：能说上几个的含义，但隐藏参数是厂商留给自己的后门，把它当常规手段，等于把整套生产体系的稳定性押在一个没有官方承诺、没有回归校验、换个版本可能就变的行为上。这不是解决问题，是给下一次故障埋伏笔。
至于那些刁钻的异常处理和数据恢复，我的答案只有两句：完整可用的高可用架构，加上经得起校验的容灾备份。
面试官想要一个手艺精湛的救火队员，我回答的是一个尽量让火烧不起来的人。他甚至想用”手艺精湛”来压一下我的”预防”能力。结果不用多说。
事后我一直在想一件事：绝活的价值，建立在”系统必定会出事”这个前提上。而 DBA 这个职业真正的进步方向，恰恰是让这些事越来越少出现，出现了也不致命。
你花十年练成 30 秒定位、3 分钟恢复的本事，和花十年把系统建成根本不需要你 3 分钟恢复，哪个更难？哪个对业务更有意义？我的答案始终是后者。
打个不太技术的比方：一个城市一年不出大火灾，不是因为消防队手艺好，而是防火标准、喷淋系统、消防通道做到位了。消防员的能力当然重要，但你不会把”我们队扑救功夫一流”当作城市的安全卖点——那玩意儿最好一辈子用不上。
只懂数据库的 DBA，不算合格
直播里我也提了一句自己的观点，这里展开说：只懂数据库的 DBA，不是一个合格的 DBA。
数据库不出问题，那是及格线，不是功劳簿。你帮它擦干净了屁股，业务方只会觉得本来就该这样，没人会因为”今天数据库没坏”给你发锦旗。真正拉开差距的，是你能不能让你管的数据库上的业务跑得更高效。
还是打比方。写字楼物业，电梯不坏、空调不漏、供电不断，这些做到了租户觉得理所当然。但你要是能帮租户把货梯调度重做一遍，让早高峰排队从 20 分钟降到 5 分钟，那才是会被记住、会被感谢、会在续约时被想起来的价值。前者叫保证，后者叫增值。DBA 这个岗位的未来在后者。
两种视角的差别，我整理成一张表，你可以对照看：
| 维度 | 数据库视角（及格线） | 业务视角（价值线） |
|---|---|---|
| 稳定性 | 不出故障，RTO/RPO 达标 | 故障期间业务可降级、可绕过 |
| 性能 | 慢 SQL 数量、平均响应时间 | 关键链路端到端耗时、订单成功率 |
| 容量 | 空间使用率、增长趋势 | 单位业务量的资源开销、冷热分层 |
| 变更 | 变更成功率、回滚预案 | 业务需求的上线速度（T+1 还是 T+0） |
| 数据 | 备份能恢复 | 数据能被业务用起来（时效、口径、可复用） |
| 汇报 | 这个月零故障 | 结算批次从 45 分钟降到 12 分钟 |
看最后一行：零故障是说给同行听的，45 分钟降到 12 分钟是说给老板和业务方听的。两种语言，两种身价。
AI 该怎么用：三层分工
铺垫这么多，聊最实在的——AI 时代我们具体怎么用 AI 提效。从下往上，AI 能替你干的越来越少，我分成三层。
第一层，把日常重复事务交出去，现在就能干。包括日常巡检与健康检查报告；基线比对，和上周比、和上月比哪些指标漂了；统计信息、索引碎片、空间增长的例行检查；慢 SQL 的初筛与归类，哪些是新增的、哪些突然变差；变更方案、应急预案的模板产出；值班日报、周报、月度运行报告的初稿。
这里要搞清楚 AI 的价值在哪——它能把你”本来就知道该怎么做，但每次都懒得做、或者没时间完整做一遍”的事接过去，不是它比你更懂数据库。我自己的体感是：以前出一份像样的巡检报告要小半天，现在每天早上一份自动产出，里面直接标好异常项、跟上个周期的基线对比、以及疑似原因。我只看标红的那几行。省下来的时间干什么？往下看。
第二层，让 AI 做完巡检之外的简单处置，但要画界限。再往上走一层，就不只是看，而是动手：kill 掉异常会话；清理过期分区、回收碎片空间；表空间或磁盘的自动扩容；重建失效索引、重新收集统计信息；在明确的切换策略下触发一次主备切换；对某个异常账号或应用做限流。
这些事的共同特点是判断逻辑清晰、动作可逆、影响面可控，交给 AI 去做，效率提升立竿见影。但这里必须加三个前提，缺一个都别上。
可观测。Agent 干了什么、什么时候干的、依据什么指标、结果如何，必须有完整记录。否则你不是在用工具，是在裸奔。之前一次交流里有人现场演示过 Agent 的可观测性监控——一条消息背后上百次工具触发，你连它背后读了什么、动了什么都不知道。
权限最小化。AI 能动的库、能执行的运维清单、能操作的时间窗口，都要先框死。灰度与回滚。任何无人化处置，先在小范围跑通，再放开。
还有一条最关键：AI 能替你动手，但替不了你担责。
这话不是我拍脑袋说的。前阵子听杨向博聊过一个 PG 执行计划的例子——明明有索引，优化器非走全表扫。他把执行计划和 PG 源码都喂给 AI，连代价相关的入口函数都指给它了，结果 AI 从头到尾胡说八道。最后还是他自己手搓 GDB 打断点，把真实数据跑出来怼到 AI 脸上，AI 才认错。
所以第二层的正确姿势是：AI 执行，你校验。判断权和责任，还在人身上。
第三层，用你的经验推动 AI 做更深的业务调优，这才是重心。以前 DBA 做调优，三板斧：加索引、改 SQL、调参数。现在 AI 三分钟就能给你一份建议索引清单，还附带理由。如果你的核心技能还只是加索引，那这份工作真的没你什么事了。
多出来的价值在哪？一句话：AI 知道这条 SQL 慢，但它不知道这条 SQL 是干嘛的。这条 SQL 对应哪个业务流程、什么时候跑、谁触发、跑不完会怎样——这些上下文不在数据库里，也不在任何文档里，它在你的脑子里。这就是你指挥 AI 的资本。
具体怎么展开，我拆成四个路径。
从 SQL 到业务链路。AI 建议给某个报表查询加联合索引。你一看：这是月度对账作业，每月 1 号凌晨跑一次，全表扫 40 分钟。加索引？写入负担全盘上升，收益只落在一个月执行一次的场景上，典型的赔本买卖。真正合理的解法是预聚合加错峰加结果缓存，甚至干脆把它从 OLTP 库挪走。这个判断 AI 给不了，因为它根本不知道”月度对账”这件事的存在。
从单库到数据布局。访问热度、扫描量、增长曲线这些统计，AI 拉一遍很快。它能帮你找出那些大而不热的表——几 TB 的体积，90% 的行半年没人碰。但这些表怎么分层、历史数据按什么口径归档、归档后业务查询怎么兼容、要不要做冷热分离——这些决策牵扯业务规则、合规要求，以及跟业务方吵架的能力，全是人的活。
从资源到成本。”CPU 用了 60%”这种话，老板听不懂也不关心。但”每万笔订单消耗多少 CPU 小时、多少存储空间，环比降了 18%”——这是能进经营分析会的语言。让 AI 帮你把技术指标翻译成成本指标，是你跟决策层对话的门票。
从技术指标到业务指标。缓存命中率 99.2%，业务方没感觉。但”结算批次从 45 分钟降到 12 分钟，财务不用再等到半夜”——这是能被记住的价值。
三个层级的调优，理一下：
| 层次 | 典型动作 | 谁主导 | AI 可替代度 | 业务可感知度 |
|---|---|---|---|---|
| 语法层 | 加索引、改 SQL 写法、收集统计信息 | AI 为主 | 高 | 低（业务基本无感） |
| 架构层 | 分区、冷热分层、读写分离、数据布局调整 | 人主导 + AI 拆解 | 中 | 中（成本、容量可量化） |
| 业务层 | 错峰、异步化、预计算、口径管控、链路重构 | 人主导 | 低 | 高（业务直接可感知） |
看明白了吗——越往上，AI 越帮不上忙，而你的价值越大。
顺便说说”经验”这件事的新用法。以前，经验等于”遇到问题我知道怎么解”，是一个解法库。现在，经验等于”我知道该让 AI 去查什么、我判断得出它说得对不对、我知道它的建议在我们这套体系里能不能落地”。经验从解法库，变成了问题定义能力加结果校验能力。这两种用法的市场价，差得很远。
该攒的四项能力
聊到收尾，落到实操上，有四项能力值得现在就起步攒。
架构与兜底能力——让那些绝活根本没机会用上。这也是我当年面试时的答案，现在看，我仍然觉得它是对的。
业务语义翻译能力——能把业务语言翻译成数据语言，再把数据结论翻译回业务语言。这是 AI 当下最难跨过去的一条沟。
AI 调度与校验能力——会建 Agent、会管 Agent、能校验 Agent 的输出。顺带说一句，这也是我在做的那摊事，核心就一句话：让 Agent 变得可被管控——可观测、可调度、可运维。
可观测与量化能力——没有数据，你的价值就看不见；价值看不见，就等于没有价值。这条听着扎心，但很实在。
回到开头那场直播。白鳝老师说别再把特殊技能当核心竞争力，我完全认同，但想补半句：那些技能不是不重要了，而是它们应该退到兜底的位置上，而不是站在招牌的位置上。
一个 DBA 的招牌，不该是我能把坏掉的数据库修好，而应该是：我管的系统很少需要修；真需要修的时候，业务几乎无感；以及最重要的——跑在我这套数据库上的业务，比跑在别人那儿更快、更省、更稳。
AI 会替你干掉重复劳动，也会替你干掉一大块手艺活。但它替不掉的是：你脑子里那些关于业务的知识，以及你判断”AI 说的这个到底靠不靠谱”的能力。AI 把”怎么做”的成本降下来，你负责敲定”做什么”。而”做什么”的答案，从来都不在数据库里，在业务里。
老规矩，不知道写了些啥。
（注：文中提及的 PG 执行计划案例中，使用 GDB 打断点抓取优化器内部真实代价数据，属于源码级调试手段，仅在复现优化器异常行为时使用，不建议在生产库上操作。）
# 校验备份可恢复性的通用思路（示例，按实际备份工具替换）
# 1. 在隔离环境还原最近一次全量备份 + 增量备份
# 2. 对还原后的库做一致性校验
# 3. 抽样比对关键业务表的行数与校验和
判定标准很简单：还原出来的库能直接对外提供服务、抽样数据与源库一致，才算备份可用。只看到备份任务成功，不等于备份能恢复。
