首页 / 资讯详情
从「告警找人」到「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 的判断基本没