背景

“在数字化转型和智能化升级的⼤背景下，数据库不再只是存储⼯具，⽽是⽀撑业务创新的核⼼。”在这样一个行业大背景下，个人有幸参加了摩天轮社区和TiDB社区合作举办的社区活动（活动地址：墨天轮社区https://www.modb.pro/event/935，TiDB社区https://asktug.com/t/topic/1044437），活动中除了数据库产品介绍、⾏业案例、ACE的经验传承外，还举办了一场关于数据库智能化运维的圆桌对话。非常荣幸受邀和各位行业内的专家大佬相互交流，整个交流活动，个人获益良多。尤其是萧老师对于智能运维的鞭辟入里的见解、以及盖老师作为领域大咖的技术深度思考、行业趋势把握的准确性等，让我们收获颇丰、醍醐灌顶。

作为本次活动的亲临者，这里记录和总结下本人对这次圆桌讨论内容的理解和思考，供社区的各位专家大佬一起交流。内容可能是次要的，最大的目标，旨在抛砖引玉，引发各位对AI本身、对数据库智能化运维、对数据库从业者+AI发展的未来思考。

话题 1：AI 调优 vs DBA 调优：谁更胜一筹？ 

• 自动化调优在什么场景能超越 DBA？ 

谁更胜一筹，要分不同的场景。

AI更优秀：

1）实验室-海量参数组合场景，海量参数空间探索

数据库调优，从CPU架构、OS、数据库内核等全栈参数的组合中找出最优解，各个参数的组合由几十万、上百万个组合，对于这些海量参数组合的遍历、测试，AI的效率远高于DBA，能高效遍历人类DBA难以穷尽的组合，无疑能节省巨大的人力成本和时间成本。

2）生产-实时动态自适应调优

能跟随业务的实时负载自适应动态变化，比如突变的流量高峰，能在秒/分钟级别动态调整关键配置，如连接池大小、缓存策略，而DBA手动调整通常存在滞后性。在云原生、微服务架构下的瞬时弹性场景尤其突出。

3）生产-历史模式学习与预测性调优

AI能学习和识别历史负载中的周期性、关联性模式。在固定时间点发生的事件当中，如月初月末报表出账、结算、大促活动，在预期事件发生前提早优化配置，变被动为主动。

• AI 失败的典型案例有哪些？

DBA更胜一筹：

1）精细化调优

需要结合业务访问特点、特殊场景的配置，需要DBA介入进行精细化调优。比如MySQL5.7主从半同步性能，通过调整从库自旋锁等待时间可以提升性能，但是会加大同步延迟，导致高可用风险隐患较高。

2）错误调整索引

相同的表，两个业务访问，AI根据慢SQL优化针对业务A调整了索引，但影响了业务B的访问性能。模型未充分理解复杂业务逻辑关联或数据访问模式的相互影响。

3）训练数据偏差导致的误判

接着上一个错误调整索引的例子，这其实是因为训练数据有偏差导致的。实际操作时，训练数据主要来自开发/测试环境，未能覆盖生产环境的真实复杂性和数据分布偏差，导致模型在线上表现失真，在复杂场景下实时动态自适应调整情况下，可能给出错误的调整参数。

4）目标设定不当的故障

如果优化目标过于单一，如只盯着内存、CPU、或者网络带宽等单一指标的利用率压到最低，AI可能通过不合理的操作，破坏了业务的稳定性。

小结

AI输出必须需要DBA的监督、验证和最终决策权。对于AI参与的行为，必须建立完善的回滚机制和决策审计。

话题2：智能化运维真的能减少 50% 运维成本吗？

运维成本要看怎么定义，如果是考虑部署和使用AI自身的成本，也是比较高的，但是从业务上“因为故障处理、风险隐患而导致的损失”成本，也就是业务风险成本（如故障损失），这块是可以极大压缩的，而且甚至超过50%。

• 哪些 AI 功能（告警预测、故障诊断）最先落地？

故障处理流程：发现，分析，方案，处理，复盘

1）告警压缩、告警收敛

通过自动化的工具进行升级，结合大模型的能力，将海量、重复、低价值的初级告警，通过模式识别、拓扑分析，压缩合并成少量有明确根因指向和业务影响评估的“智能事件”，大幅减少DBA的“告警噪音疲劳”。

2）异常检测

基于历史时间序列分析或统计模型，自动发现偏离历史基线的性能指标（慢查询突增、连接数异常、存储空间消耗异常快），比基于静态阈值的告警更早、更准发现问题。

3）故障前-精准的告警预测

精准、全面的告警监控，提前预警潜在的故障问题，提前防范，变被动为主动。结合异常检测、日志分析模式识别、容量预测模型，在硬件故障、资源耗尽（存储、CPU、内存、连接数）等问题发生前，发出预警并触发自动化预案。可以最大提升业务体验、提升客户满意度的地方。

4）故障中-快速的故障诊断

根据训练模型、运行信息，以及AI强大的推理能力，可以快速诊断故障根因，并实时给出优化决策，极大缩短了故障时长，降低了业务的影响。

• 呈现怎样的价值产出，甲方企业才愿意买单？

 甲方永远最关注的是业务的稳定性，服务的高可用性。在此基础上，对于“收入增长、成本降低、风险规避”是比较关注的价值点。

1）提升服务稳定性、可用性

● 智能诊断，可以将定位时间从小时级降至分钟级，缩短排障时长。减少业务中断时长/损失： 通过预测性维护和快速定位，避免或缩短业务中断带来的直接经济损失和声誉损失。

● 提升SLA履约率： 确保关键业务系统的响应时间和可用性达标。

2）风险规避

● 故障预测，变被动为主动，提前消除隐患点，降低故障导致损失这类业务风险成本。

3）减低人力成本

● 人力投入减少/重分配： 将开发、DBA从重复性低价值工作中解放出来（如基础监控、巡检、运维工单处理），转向高价值的架构优化、创新工作。可节省大量的人力成本，或将人力投入到高产的内容点上。

话题 3：AI应用边界与⻛险：智能是否可能“失控”？ 

正如新能源汽车的智能驾驶系统存在风险，目前各家都改为“智能驾驶辅助系统”了。对于数据库场景，AI“失控”风险的确会存在，尤其是在涉及数据变更、配置更改等高风险操作时。所以，设定清晰、可控、透明的边界，是AI智能运维在关键领域落地的必要条件。

• 数据隐私、模型偏差问题如何控制？ 

1）数据隐私

● 风险： 智能运维平台需采集大量监控数据（指标、日志、SQL语句等），这些数据可能包含敏感企业业务信息、用户信息等商业数据，处理不当会导致泄露。

● 控制

○ 最小化采集： 仅采集必要数据，进行敏感字段脱敏。

○ 数据本地化/加密传输存储： 严格遵守合规要求，确保数据在传输和存储中安全。

○ 严格访问控制与审计： 控制谁可以访问哪些数据，并且有详细的可追溯的审计日志。

2）模型偏差

● 风险： 训练数据不全面、不均衡或有缺陷，导致模型对特定场景判断错误，产生如在资源调度异常等不可控后果。

● 控制：

○ 使用更全面、均衡的数据集合训练： 确保数据集代表性强、覆盖广泛场景，最好从生产环境获取。

○ 持续监控与建立正向反馈训练机制： 在生产环境中持续监控模型预测结果与现实的偏差，建立反馈闭环和定期再训练机制，不断纠错，完善AI自身的能力和准确性。

• 对核⼼金融系统，AI 介入的安全底线是什么？

我认为，这个底线是不因为AI的介入而变成一个负向的因素，为此，我们要求AI不做或少做变更类执行，最多只有“读”的权限。

1）限制介入场景，与核心事务路径隔离

交易处理核心引擎（如账务更新、清算核心）应禁止AI直接介入调优或操作。AI主要应用于外围监控、诊断、容量管理和非关键路径优化。

2）对于核心系统，当前阶段遵循“只读不写”的原则

对于分析诊断，可以对AI的权限放开，但任何涉及数据变更、参数变更、资源配给变更的操作，必须强制通过DBA审查确认，或限定在预先审批的、有完备回滚预案的情况下自动执行。

3）严格的变更审核与审计追溯

所有由AI触发的或建议的配置变更、执行的操作，必须有完整、不可篡改的日志记录，包括操作内容、上下文、建议来源的模型或规则、责任人审批记录等。

同时必须对AI的变更操作，都支持快速回滚。

总结

未来成功的数据库运维团队，我认为将是精通数据库内核原理、深谙业务需求、能使用AI的复合型人才组成的精英部队。

智能运维的过程，一定是人与机器智能协同进化的旅程。

AI不会取代DBA，但会用AI的DBA一定会取代不用AI的。