从「告警找人」到「Agent 先接手」，「古茗」如何用 AI Agent 重构万店运维？

AI to B，要真的能「救火」。

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

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

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

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

好钢全用来救火了。

01

每天都在重复的三件事

让刘星光下定决心做改变的痛点，不是一天攒出来的，而是每天都在重复。

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

元数据散落各处。研发新人入职后写 SQL，对历史字段的业务含义是什么、有没有关联数据，需要来回沟通。回答的人疲惫，问的人也不好意思。

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

「这些事情，有共性、有规则、有标准答案——能不能让 Agent 来做？」刘星光开始想这个问题。

02

人做判断，Agent 做执行

去年下半年，古茗与阿里云瑶池数据库团队合作，引入了阿里云的 AI 原生数据库服务（AIDBS），让 Agent 接管救火和答疑这两件最耗人的事。目标很朴素：人来做判断和决策，Agent 来调度和执行。

具体落了三个方向。

第一步是让数据资产「活」过来。古茗之前也搞过静态元数据平台，做出来就是个数据字典，半年之后基本没人用了——因为它只能展示信息，不能解决问题。这次思路变了：不让人来查它，让它主动出现在研发的工作流里。

在 IDE 里写 SQL，Meta Agent 自动识别涉及哪些表、字段口径是什么、有没有合适的索引；数据库变更审批时，自动算血缘、评估上下游影响面和风险等级。低风险操作——比如加索引、加配置——直接让 Agent 执行，DBA 不再需要逐条审批。效果立竿见影：DDL 审批时间平均下降 30%–40%。

第二步是让 Agent 成为一个「永不下班的值班员」。以前告警的逻辑是出事了、短信找人、人去诊断、人做决策、人执行操作。现在变了：出事了，Agent 先主动诊断，人做决策，Agent 执行操作。

Agent 自动拉慢日志、对比历史基线、定位问题 SQL，给出组合索引建议、限流方案、临时扩容三个选项——直接推送给 DBA，由人选择走哪一步。

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

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

第三步是给 AI 划一道不可逾越的线。让 Agent 真正读写数据是自然的下一步，但问题也随之浮现。早期 Agent 直连数据库，一个 Agent 套一个账号，越往后权限管控越松。最怕的几件事：Agent 拼的 SQL 有没有问题？会不会越权访问？会不会删表？出了问题能不能追溯？

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

古茗的做法是在 Agent 和生产数据库之间加了一层数据网关：SQL 进来先解析、改写，越权字段脱敏，危险操作拦截。身份维度从「一个大账号」变成「场景 + 会话 + 工具」的模式，所有操作按 Session 可追溯。目前在客服答疑等场景已经跑通，Agent 接库的周期从平均一两天降到几个小时。

03

改变的不只是数据库

回头看这 90 天，技术层面的提升是一方面，但对组织的影响可能更大。

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

专家经验开始变成组织资产。「资深 DBA 处理过的 Case 以前藏在他们脑子里，人走了就带走了。现在每一次 Agent 的处置都回流到知识库，下次同类问题直接复用。」

预算决策变得透明了。哪些库该降配、哪些该升配、哪些表半年没人查可以归档——Agent 都会主动评估。数据库单位成本是下降的，但容量和性能反而更好了。

更深层的变化在于 DBA 的角色本身。过去 70% 的时间在救火，现在这部分被 Agent 接走了。他们终于有精力去做架构优化、容量规划、引擎升级这些「本来应该做但一直没空做」的事情。

04

先标准化，再放权

采访最后，刘星光说了一句挺实在的话：「很多公司是『我不知道 AI 能干什么，但我一定要做』，这个出发点不太对。AI 不是万能药。别一上来就让它解决你最痛的场景，先从可控的、有共性的事情开始，给团队和产品一个磨合期。」

他也提到一个关键原则：人和 Agent 的边界要提前定好。哪些事情让 Agent 自治，哪些必须 DBA 二次确认——「过分相信 AI 也会出问题。等磨合几年之后，可以逐步放权到 80%–90%，但现在还不是时候。」

从被上百条告警短信困住的深夜，到 DBA 团队终于能腾出手做架构优化，古茗这个案例其实说明了一件事：AI Agent 在企业里真正能跑起来的前提，不是技术多先进，而是你得先想清楚哪些事该交给机器、哪些事必须留给人。先标准化，再自动化；先划好边界，再放开权限。这个顺序反了，再好的工具也白搭。

*头图来源：阿里巴巴

极客一问

当 AI 能自动诊断数据库故障并给出处置建议，DBA 这个岗位的价值会被重新定义吗？