【圈层智汇】维享会会员专访：迷你玩科技有限公司技术总监刘琪

金句：

      1、以前是‘出了问题再找原因’，现在是‘更快知道可能哪里出了问题。

      2、关键不是信不信AI，而是‘能不能解释、能不能回滚、有没有控制边界’。 只要这三点不清楚，AI建议肯定不会直接用。

      3、云的价值更多是降低长期维护成本，而不是单点性能提升。

      4、AI只做建议，不做决定。……落地上分三层：AI输出、系统规则、人工确认。

      一、从传统运维到智能运维，游戏行业最大的痛点是什么？AI具体解决了哪些过去“没法办”的问题？

      游戏运维最大的痛点其实很简单：问题来得快、影响大、定位慢。

      主要有三类问题：

      • 活动一开服或者版本一上线，流量是突增的，很难提前完全压测出来

      • 系统链路长，从登录到战斗到存储，中间任何一段都可能出问题

      • 报警很多，但真正关键的往往混在噪声里

      AI实际带来的变化不复杂，本质就三点：

      • 更早发现异常趋势：不是等指标爆了，而是提前看到变化开始偏离

      • 更快缩小范围：从“可能是很多服务”缩到“某几个最可能的

      • 减少人工翻日志时间：不用工程师逐条翻日志找线索

      以前是“出了问题再找原因”，现在是“更快知道可能哪里出了问题”。

      二、很多公司都在提“AIOps”，但在游戏领域容易出现“AI建议不敢用、用了反而出事故”。您如何看待AI的可信度与可控性？

      这个问题本质不是AI能力问题，是生产系统不允许不确定性。我们内部原则很简单：AI只做建议，不做决定。

      落地上分三层：

      • AI输出：可能原因 + 风险提示 + 建议操作

      • 系统规则：判断这个操作是否允许（比如是否影响核心服）

      • 人工确认或灰度执行

      所以关键不是信不信AI，而是：

      • 能不能解释

      • 能不能回滚

      • 有没有控制边界

      只要这三点不清楚，AI建议肯定不会直接用。

      三、您们如何用AI提升运维效率，如果解决AI带来的运维不确定性，做了哪些AI运维场景？

      目前我们主要用在三个地方：

      1、告警合并

      以前是几百条告警，现在会自动合成几个“事件”。

      2、辅助定位问题

      把指标、日志、发布记录放一起，帮工程师缩小可能范围。

      3、运维助手

      工程师可以直接问：

      • 这个错误一般是什么原因？

      • 有没有类似历史事故及解决方案？

      减少翻文档和查日志的时间。当然这和我们过去3年坚持每周作故障模式库有很大关系，积累了大量的故障知识库。

      四、智能运维离不开数据，但游戏日志数据量极大。你们在数据采集、存储、计算上遇到过哪些坑？如何用AI降低存储成本？

      我们主要做了几件事：

      （1）分层存储

      • 热数据：最近和高频使用的

      • 冷数据：压缩后放对象存储

      • 旧数据：按策略自动清理

      （2）减少“无意义日志”

      日志采集端做了一个过滤，没有用的老日志，直接就过滤掉了。

      有些日志其实只是重复信息，我们会做一定的合并和压缩。

      （3）按使用情况调整保留时间

      在遵循国家法律法规的情况下，作必要的日志生命周期划分，哪些要保留半年，哪些长期保留。哪些一个月就可以删除。

      五、作为技术管理者，您观察到行业里推动智能运维落地时，团队面临的最大挑战是什么？是技能差距、组织惯性，还是业务侧的信任问题？

      实际最大的挑战不是技术，是三个问题：

      第一是信任

      运维团队不敢让系统自动做决策，这是正常的。

      第二是数据质量

      很多问题不是模型不准，而是：

      • 日志不全

      • 链路断

      • 数据标准不统一

      第三是系统太分散

      监控、日志、发布系统是分开的，AI很难一次看全。

      六、展望未来3年，您认为哪些AI技术会在游戏运维领域变得不可或缺？同时又有什么是AI永远替代不了运维人员的？

      会变得很重要的：

      • 自动帮你分析问题原因（类似运维助手升级版）

      • 更早发现系统风险

      • 更自动的扩容和调度建议

      • 把日志、指标、发布信息统一起来分析

      AI替代不了的：

      • 最终上线/回滚决策

      • 出大事故时的整体判断

      • 成本、体验、风险之间的权衡

      这些还是需要人负责。

      七、回顾您的职业生涯，有没有哪一次技术决策或团队管理经历让你印象最深？它给你带来了怎样的启示？

      有一次我们做核心数据库和高并发系统升级。

      当时有两个选择：

      • 继续自己优化原有架构

      • 迁移到云数据库能力更强的体系（比如Gauss DB）

      我们最后选择了GaussDB，并逐步迁移，而不是一次性切。后来还在GaussDB发布会上做了经验分享。

      关键经验是三点：

      • 大系统迁移不能赌一次成功，要分阶段

      • 数据库问题不是纯性能问题，是系统复杂度问题

      • 云的价值更多是降低长期维护成本，而不是单点性能提升

      八、 您对维享会有什么建议或反馈吗？

      比较简单三点：

      •  多讲“怎么做的”，少讲“做成了什么”

      •  多讲失败和踩坑，比成功案例更有价值

      •  可以增加一些跨厂商/跨架构的对比讨论