北京
深夜告警轰炸，DBA 被“救火”困住
去年年底的一个深夜，古茗科技集团运维负责人刘星光再次被手机震动惊醒，屏幕上跳动着上百条数据库告警短信。古茗全国上万家门店，每一杯奶茶的下单、库存调度、会员积分、联名营销，都跑在 100 多个数据库实例上，包括 RDS、Redis、MongoDB、PolarDB。门店在扩，订单在涨，联名活动频率比以往翻了一倍，尖刺流量来得快去得也快。
支撑这一切的 DBA 团队，一共就那么几个人。刘星光回忆，每天 70% 的时间耗在“接警—登跳板机—看 Process List—Kill 慢 SQL—判断是否扩容”这套流程上。一次大促处置，最快也要 10 到 20 分钟；人不在电脑前，时间更长。而这 10 分钟里，客户下单有延迟，门店出杯有卡顿。
每天都在重复的三件事
让刘星光下定决心做改变的痛点，不是一天攒出来的。MySQL 主库 CPU 飙高，几乎每次新业务上线必现；DBA 来不及看完所有慢查询就被下一波告警淹没；元数据散落各处，研发新人写 SQL 时，对历史字段的业务含义、有没有关联数据，需要来回沟通。变更审批流程也长得让人崩溃，加个索引、加个权限，走完审批可能要等上一天。DBA 成了整个研发链路的瓶颈，但他们自己也不想当这个瓶颈。
刘星光开始想：这些事情有共性、有规则、有标准答案，能不能让智能体来做？
人做判断，智能体做执行
去年下半年，古茗与阿里云瑶池数据库团队合作，引入阿里云的 AI 原生数据库服务（AIDBS），让智能体接管救火和答疑这两件最耗人的事。目标很朴素：人来做判断和决策，智能体来调度和执行。
第一步是让数据资产“活”过来。古茗之前搞过静态元数据平台，做出来就是个数据字典，半年之后基本没人用了，因为它只能展示信息，不能解决问题。这次思路变了：不让人来查它，让它主动出现在研发的工作流里。在 IDE 里写 SQL，元数据智能体自动识别涉及哪些表、字段口径是什么、有没有合适的索引；数据库变更审批时，自动算血缘、评估上下游影响面和风险等级。低风险操作，比如加索引、加配置，直接让智能体执行，DBA 不再需要逐条审批。效果立竿见影：DDL 审批时间平均下降 30%–40%。
第二步是让智能体成为一个“永不下班的值班员”。以前告警的逻辑是出事了、短信找人、人去诊断、人做决策、人执行操作。现在变了：出事了，智能体先主动诊断，人做决策，智能体执行操作。智能体自动拉慢日志、对比历史基线、定位问题 SQL，给出组合索引建议、限流方案、临时扩容三个选项，直接推送给 DBA，由人选择走哪一步。
刘星光举了一个例子：有一次大促，订单库 CPU 突然飙高。以前这种情况，从收到告警到处理完毕最快十几分钟。这次智能体几分钟就定位完了，给出建议，DBA 一键执行，整个事情不到五分钟就搞定了。刘星光说，智能体给出的建议和资深 DBA 的判断基本没有区别，有些时候甚至更客观。
给 AI 划一道不可逾越的线
让智能体真正读写数据是自然的下一步，但问题也随之浮现。早期智能体直连数据库，一个智能体套一个账号，越往后权限管控越松。最怕的几件事：智能体拼的 SQL 有没有问题？会不会越权访问？会不会删表？出了问题能不能追溯？刘星光说，智能体不记日志的时候，出了事连查都没法查。
古茗的做法是在智能体和生产数据库之间加了一层数据网关：SQL 进来先解析、改写，越权字段脱敏，危险操作拦截。身份维度从“一个大账号”变成“场景 + 会话 + 工具”的模式，所有操作按 Session 可追溯。目前在客服答疑等场景已经跑通，智能体接库的周期从平均一两天降到几个小时。
改变的不只是数据库
回头看这 90 天，技术层面的提升是一方面，但对组织的影响可能更大。研发开始信任数据库这一层了。以前研发对数据库总有距离感，怕改错、怕被骂、审批又慢；现在写 SQL 时智能体就在旁边给建议，上线后还有兜底。研发自主变更的比例从以前的很少，到现在过半以上。
专家经验开始变成组织资产。资深 DBA 处理过的 Case 以前藏在他们脑子里，人走了就带走了；现在每一次智能体的处置都回流到知识库，下次同类问题直接复用。预算决策也变得透明了。哪些库该降配、哪些该升配、哪些表半年没人查可以归档，这些过去靠拍脑袋的判断，现在有了数据支撑。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
