引言：上百条告警短信背后的运维困境

去年年底的一个深夜,古茗科技集团运维负责人刘星光再次被手机震动惊醒——屏幕上跳动着上百条数据库告警短信。

"这不是什么意外。"刘星光告诉笔者,"古茗全国上万家门店,每一杯奶茶的下单、库存调度、会员积分、联名营销,都跑在我们100多个数据库实例上——RDS、Redis、MongoDB和云数据库PolarDB等,什么都有。门店在扩,订单在涨,联名活动的频率比以往翻了一倍,尖刺流量来得快去得也快。"

而支撑这一切的DBA团队,一共就那么几个人。

"每天70%的时间耗在'接警—登跳板机—看Process List—Kill慢SQL—判断是否扩容'这套流程上。"刘星光回忆道,"一次大促处置,最快也要10到20分钟。要是人不在电脑前,时间更长。而这10分钟里,客户下单有延迟,门店出杯有卡顿——这是我们不能接受的。"

我们的DBA很优秀,但好钢全用来救火了。

AIDBS：让AI真正"懂"数据库

在深入古茗的具体实践之前,先交代一个背景:古茗引入的是阿里云AI原生数据库服务(AIDBS)。这不是一个简单的监控工具或自动化脚本集合,而是一个将数据管理能力与AI技术深度融合的平台,核心包含三大能力模块——Meta Agent(数据资产管理)、DAS Agent(数据库自治运维)和Agent数据网关(安全访问控制)。

为什么要专门提这个?因为很多企业在探索AI+数据库时,第一反应是"我们自己开发一套"。但古茗的实践表明:专业的事情需要专业的工具。通用LLM看似什么都行,但它不懂锁机制、不懂分布式事务、不懂云数据库的底层特性。AIDBS的价值在于它已经内置了这些专业知识,企业只需根据自身业务场景做适配,大幅缩短落地周期。

接下来,我们看看古茗是如何通过这套方案实现转型的。

痛点：每天都在重复的三件事

让刘星光下定决心的痛点不是一天攒出来的,而是每天都在重复:

第一,MySQL主库CPU飙高。每次新业务上线、新活动推出,几乎必现。DBA来不及看完所有的慢查询就被下一波告警淹没。

第二,元数据散落各处。研发新人入职后在写SQL时对历史上存在的某个字段的业务含义是什么、是否有关联其他的数据需要来回沟通,回答的人疲惫,问的人也不好意思。

第三,变更审批流程长得让人崩溃。加个索引、加个权限,走完审批可能要等上一天。DBA成了整个研发链路的瓶颈——但他们自己也不想当这个瓶颈。

"我开始想：这些事情,有共性、有规则、有标准答案——能不能让Agent来做？"刘星光说。

破局：人做判断，Agent做执行

去年下半年,古茗与阿里云瑶池数据库团队合作,引入AIDBS帮他们接管救火和答疑这两件最耗人的事。目标很朴素:人来做判断和决策,Agent来调度和执行。

"在讲具体怎么做之前,先介绍下我们都用了什么。"刘星光介绍,"目前古茗采用了Meta Agent、DAS Agent和Agent数据网关等多项能力,覆盖数据资产治理、数据库自治运维和Agent安全用数三大场景。我们借助AIDBS具体抓3个方向：Meta Agent管知识,DAS Agent管健康,Agent数据网关管安全。"

他坦言,和阿里云磨合了一段时间,初期产品并没有那么顺手。"因为要根据古茗的架构、业务场景做大量适配和优化。如果当时团队对这个方向没信心,可能一两个月就停掉了。团队的信心比技术本身更重要。"

按上线顺序,最先落地的是Meta Agent。

Meta Agent：让数据资产"活"过来

"我们之前也搞过静态元数据平台,做出来就是个数据字典。半年之后基本没人用了——因为它只能展示信息,不能解决问题。"刘星光说,"这次我们换了思路：不让人来查它,让它主动出现在研发的工作流里。"

具体三个嵌入点:

第一,代码评审时。 研发在IDE里写SQL,Meta Agent自动识别涉及哪些表、字段口径是什么、有没有合适的索引、有没有同语义的现成视图。写完代码还没提交,建议就给到了。

第二,数据库变更审批时。 一个DDL进来,Meta Agent自动算血缘、评估上下游影响面和风险等级。低风险操作——比如加索引、加配置——直接让Agent执行。DBA不再需要逐条审批。

效果立竿见影：DDL审批时间平均下降30%–40%。新员工在群里提问数据相关的问题,明显少了。

给其他团队的启示：元数据平台的成败不在于功能多强大,而在于是否嵌入工作流。如果你的研发团队也经常因为"这个字段是什么意思""这张表和那张表什么关系"而反复沟通,关键不是建另一个知识库,而是让元数据主动出现在编码、审批的流程中。

DAS Agent：一个永不下班的"老师"

以前告警的逻辑是：出事了→短信找人→人去诊断→人做决策→人执行操作。

现在变了：出事了→Agent主动诊断→人做决策→Agent执行操作。

"Agent自动拉慢日志、对比历史基线、定位问题。"刘星光解释道,"它能精准识别是哪些新上线的SQL造成的负载升高,给出组合索引建议、限流方案、临时扩容三个选项——直接推送给DBA,由人选择走哪一步。"

他举了一个例子：有一次大促,订单库CPU突然飙高。以前这种情况,从收到告警到处理完毕最快十几分钟。这次DAS Agent几分钟就定位完了,给出建议,DBA一键执行——整个事情不到五分钟就搞定了。

"而且它给出的建议,和资深DBA的判断基本没有区别。有些时候,甚至更客观。"

更深层的变化是：DBA的工作内容在重塑。过去70%的时间在救火,现在这部分被Agent接走了。他们终于有精力去做架构优化、容量规划、引擎升级这些"本来应该做但一直没空做"的事情。

数据库并没有因为释放人力而出问题——反而更稳定了。

给其他团队的启示：DAS Agent的核心价值不是替代DBA,而是把DBA从重复性诊断工作中解放出来。但前提是你们的告警处置已经有标准化SOP。如果告警还在靠个人经验临时判断,AI也无从下手。建议先梳理Top 10高频告警的标准处置流程,再让Agent学习执行。

Agent数据网关：给AI划一道"不可逾越的线"

用了Meta Agent之后,下一步很自然——让Agent真正读写数据。

但我们很快发现问题：早期Agent直连数据库,一个Agent套一个账号。越往后权限管控越松,心里越不踏实。最怕的几件事：Agent拼的SQL有没有问题？会不会越权访问？会不会删表？出了问题能不能追溯到是哪一次对话造成的？

"Agent不记日志的时候,出了事你连查都没法查。"刘星光说。

所以古茗用AIDBS在Agent和生产数据库之间加了一层Agent数据网关：SQL进来先解析、改写,越权字段脱敏,危险操作拦截。身份维度从"一个大账号"变成"场景+会话+工具"的模式。所有操作有留痕,按Session可追溯。

"目前我们在客服答疑等场景跑通了。Agent接库的周期从平均一两天降到几个小时。红蓝攻击、SQL注入、删表操作——在网关层就全部拦下来了,没有对线上数据库造成任何危害。"

给其他团队的启示：很多企业不敢让AI直接访问生产数据,核心顾虑就是安全。Agent数据网关的价值在于：它不是简单地限制权限,而是在保证安全的前提下,让AI能够真正发挥作用。建议在试点前就明确：哪些操作可以自动执行(如加索引)、哪些需要人工审批(如删表)、哪些完全禁止(Agent直接写生产库)。这个规矩越早定,后续磨合成本越低。

90天后，改变的不只是数据库

回头看这90天,技术层面的提升是一方面,但对组织的影响更大。刘星光总结了三点变化:

第一,研发开始信任数据库这一层了。"以前研发对数据库总有距离感——怕改错、怕被骂、审批又慢。现在写SQL时Meta Agent就在旁边给建议,上线后DAS Agent兜底。研发自主变更的比例从以前的很少,到现在过半以上。"

第二,将专家经验变成组织资产。"资深DBA处理过的Case以前藏在他们脑子里,人走了就带走了。现在每一次DAS Agent的处置都回流到知识库,下次同类问题直接复用。那个'永远不下班的老师'不只是帮你做事——它还在帮你攒经验。"

第三,预算决策透明了。 "Meta Agent看见所有报表使用情况,DAS Agent看见所有实例负载分布。哪些库该降配、哪些该升配、哪些表半年没人查可以归档——它都会主动评估。年初到现在,数据库单位成本是下降的——但容量和性能反而更好了。"

三个实在的建议

采访最后,刘星光给正在考虑数据平台与AI结合的企业提了3个建议:

第一,一步到位不现实。"很多公司是'我不知道AI能干什么,但我一定要做',这个出发点不太对,AI不是万能药。别一上来就让它解决你最痛的场景,先从可控的、有共性的事情开始,给团队和产品一个磨合期。"

第二,尽早划清人和Agent的边界。"哪些事情让Agent自治,哪些必须DBA二次确认——这个规矩要提前定好。过分相信AI也会出问题。等磨合几年之后,可以逐步放权到80%–90%,但现在还不是时候。"

第三,选一个真正懂数据库的Agent。"那些通用LLM看似什么都行,但它不懂你的锁机制、不懂分布式事务、不懂云数据库的底层特性。专业的事情,还是要找专业的工具来做。"

结语：从告警短信到架构优化

从被上百条告警短信困住的深夜,到DBA团队终于可以腾出手做架构优化的今天,古茗的数据库运维转型之路印证了一个道理：AI不是要取代人,而是要把人从重复性劳动中解放出来,去做更有价值的事。

对于上万家门店的古茗而言,这不仅是技术的升级,更是组织能力的重塑。而对于更多正在经历类似困境的企业来说,这条路提供了一条可复制的思考框架：先标准化,再自动化;先划定安全边界,再放开权限;先让AI接管重复性工作,再让人专注于高价值任务。

如果你的DBA团队也被告警短信淹没,如果你的研发因为数据库门槛而步履维艰,或许现在是时候重新思考：数据库运维的未来,不应该是一场永无止境的救火行动,而应该是一次从被动到主动、从执行到决策的能力跃迁。