企业官网建设流程全解析

胖头鱼的技术专栏-466 别再把"救火"当本事——AI时代，DBA的核心竞争力该往哪放（20260907）

作者：胖头鱼的鱼缸（尹海文） Oracle ACE Pro: Database PostgreSQL ACE 10年+数据库行业经验 拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证 墨天轮MVP，ITPUB认证专家 圈内拥有“总监”称号，非著名社恐（社交恐怖分子） 全网同名：胖头鱼的鱼缸 ITPUB：yhw1809 除授权转载并标明出处外，均为“非法”抄袭

上周三（9月2日）晚上，我参加了 PostgreSQL 30 周年的活动的一场线上直播。

整场聊了不少东西，但让我印象最深的是白鳝老师的一段话，大意是：AI时代，DBA 不能再把那些"特殊技能"——故障处理、数据恢复、各种专项处理——当成自己的核心竞争力了。

我在直播间里连连点头。因为这事儿我最近就撞过一次，撞得还挺直接。

大家讨论的原因其实是两条：

一是数据库基础架构本身在不断完善。以前要靠人肉手艺去兜底的场景，现在高可用、容灾备份、自治调优、云上的托管能力，直接在架构层就给你兜住了。

二是AI 正通过智能体（Agent）的形式，把这些原来"需要经验判断"的活，变成"可以标准化执行"的活。

这两条一旦同时成立，那些我们当年引以为傲的"绝活"，就会和重复的日常工作一样——不是不重要，而是不再稀缺。

一、那场面试：两个小时，全在问"绝活"

我这几年只参加过一次技术面试，整个下午两个小时下来，对方问的全是这类特殊技能：

• Oracle 数据库如何加快大事务回滚？
• 某个隐藏参数是什么意思、什么时候用？
• 各种相当刁钻的故障处理与数据恢复场景怎么破？

老实说，其中一些问题我是能答的——毕竟 OCM 考过来的人，手艺活不至于完全陌生。但我给出的答案，明显不是对方想要的那种。

关于大事务回滚，我的回答是：在我管理的数据库里，因为监控告警做得比较到位，大事务基本没有机会长起来；退一万步，真出现了，那也是安排在非工作时间，通过应急手段去处理——而不是像您说的那样，去调整隐藏参数来"加速回滚"。

关于隐藏参数，我的态度更直接：能说上几个的含义，但隐藏参数是厂商留给自己的"后门"，是救急用的。把它当成常规手段，等于把一套生产系统的稳定性，押在一个没有官方承诺、没有回归验证、换个版本可能就变的行为上。这不太像解决问题，更像是给下一次故障埋伏笔。

关于那些刁钻的故障处理与数据恢复，我的答案只有两句：完整可用的高可用架构，加上经得起验证的容灾备份。

面试官想要的是一个"手艺精湛的救火队员"，我回答的是一个"尽量让火烧不起来"的人，甚至是想用"手艺精湛"来打压一下我的"预防"能力。

那场面试的结果不用多说。但事后我一直在想一个问题——

"绝活"的价值，建立在"系统一定会出事"这个前提上。而 DBA 这个职业真正的进步方向，恰恰是让这些事越来越少发生，以及发生了也不致命。

你花十年练成一身"30 秒定位、3 分钟恢复"的本事，和花十年把系统建成"根本不需要你 3 分钟恢复"，哪个更难？哪个对业务更有价值？

我的答案一直是后者。

这里插个不那么技术的比喻：一个城市一年不出大火灾，不是因为消防队手艺好，而是因为防火规范、喷淋系统、消防通道这些东西做得到位。消防员的能力当然重要，但你不会把"我们队扑救功夫一流"当作一个城市的安全卖点——那玩意儿最好一辈子用不上。

二、只懂数据库的 DBA，不是合格的 DBA

直播里我也提了一句自己的观点，这里再展开说一下：

我一直认为，只懂数据库的 DBA，不是一个合格的 DBA。

数据库不出问题，那是及格线，不是功劳簿。你帮它擦干净了屁股，业务方只会觉得"本来就该这样"——没人会因为"今天数据库没坏"给你发锦旗。

真正能拉开差距的，是你能不能让跑在数据库上的业务，跑得更高效。

再打个比方。写字楼的物业，电梯不坏、空调不漏、供电不断——这些做到了，租户觉得是应该的。但你要是能帮租户把货梯调度重做一遍，让早高峰的排队时间从 20 分钟降到 5 分钟，那才是会被记住、会被感谢、会在续约的时候被想起来的价值。

前者叫"保障"，后者叫"增值"。DBA 这个岗位的未来，在后者。

我把这两种视角的差异整理了一下，你可以对照着看：

注意看最后一行的区别："零故障"是说给同行听的，"45 分钟降到 12 分钟"是说给老板和业务方听的。两种语言，两种身价。

三、AI 到底该怎么用：三层分工

铺垫了这么多，聊聊最实在的部分——AI 时代，我们具体该怎么用 AI 提升效率。

我把它分成三层，从下往上，AI 能替你干的越来越少，而你的价值越来越大。

第一层：把常规重复工作交出去（现在就能干）

这一层没什么好犹豫的，包括：

• 日常巡检与健康检查报告；
• 基线比对（和上周比、和上月比，哪些指标漂了）；
• 统计信息、索引碎片、空间增长的例行检查；
• 慢 SQL 的初筛与分类（哪些是新增的、哪些突然变差了）；
• 变更方案、应急预案的模板生成；
• 值班日报、周报、月度运行报告的初稿。

这里要搞清楚 AI 的价值在哪——不是它比你更懂数据库，而是它能把你"本来就知道该怎么做，但每次都懒得做、或者没时间做一遍"的事，稳定地、不打折地做一遍。

我自己的体感是：以前出一份像样的巡检报告要小半天，现在是每天早上一份自动产出，里面直接标好异常项、跟上个周期的基线对比、以及疑似原因。我只看标红的那几行。

省下来的时间干什么？往下看。

第二层：让 AI 完成巡检之外的"简单处置"（要画边界）

再往上走一层，就不只是"看"了，而是"动手"：

• kill 掉异常会话；
• 清理过期分区、回收碎片空间；
• 表空间/磁盘的自动扩容；
• 重建失效索引、重新收集统计信息；
• 在明确的切换策略下触发一次主备切换；
• 对某个异常账号或应用做限流。

这些事的特点是：判断逻辑清晰、动作可逆、影响面可控。交给 AI 去做，效率提升是立竿见影的。

但是——这里必须加三个前提，缺一个都别上：

1. 可观测。Agent 干了什么、什么时候干的、依据是什么指标、结果如何，必须有完整记录。你连它背后读了什么、动了什么都不知道，那就不是在用工具，是在裸奔（之前在一次交流里，有人现场演示过 Agent 的可观测性监控——一条消息背后上百次工具调用，看得人后脊发凉）。
2. 权限最小化。AI 能动的库、能执行的操作清单、能影响的时间窗口，都要先框死。
3. 灰度与回滚。任何自动化处置，先在小范围跑通，再放开。

还有一条最关键：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 越帮不上忙，而你的价值越大。

顺便说说"经验"这件事的新用法。

以前，经验 = “遇到问题我知道怎么解”，是一个解法库。

现在，经验 = “我知道该让 AI 去查什么、我判断得出它说得对不对、我知道它的建议在我们这套系统里能不能落地”。经验从解法库，变成了问题定义能力 + 结果校验能力。

这两种用法的市场价，差得很远。

四、那 DBA 该攒点什么

聊到最后，落到实操上，我觉得有四项能力值得现在就开始攒：

1. 架构与兜底能力——让那些"绝活"根本没机会用上。这也是我当年面试时的答案，现在看，我依然觉得它是对的。
2. 业务语义翻译能力——能把业务语言翻译成数据语言，再把数据结论翻译回业务语言。这是 AI 目前最难跨过去的一条沟。
3. AI 编排与验证能力——会建 Agent、会管 Agent、能验证 Agent 的输出。顺带说一句，这也是我在做的那摊事（老规矩，打个广告：https://db4agent.cn），核心就一句话：让 Agent 变得可被管理——可观测、可调度、可运维。
4. 可观测与量化能力——没有数据，你的价值就看不见；价值看不见，就等于没有价值。这条听着扎心，但很实在。

总结

回到开头那场直播。

白鳝老师说"别再把特殊技能当核心竞争力"，我完全认同——但我想补半句：那些技能不是不重要了，而是它们应该退到"兜底"的位置上，而不是站在"招牌"的位置上。

一个 DBA 的招牌，不该是"我能把坏掉的数据库修好"，而应该是：

• 我管的系统，很少需要修；
• 真需要修的时候，业务几乎无感；
• 以及最重要的——跑在我这套数据库上的业务，比跑在别人那儿更快、更省、更稳。

AI 会替你干掉重复劳动，也会替你干掉一大部分"手艺活"。但它替不掉的是：你脑子里那些关于业务的知识，以及你判断"AI 说的这个到底靠不靠谱"的能力。

AI 负责把"怎么做"的成本降下来，你负责决定"做什么"。而"做什么"的答案，从来都不在数据库里，在业务里。

老规矩，不知道写了些啥。