摘要
日均数千起宕机、百万条告警，碎片化地散落在数百万台异构服务器之中——这是当前规模化集群平台面临的普遍挑战，每一次的故障定位和根因溯源都如同大海捞针。庞大基数下，传统的“人肉排障”模式已触及极限。据OpenCloudOS团队内部统计，异常分析工单的耗时高达普通工单的6倍。大模型带来了破局希望，但在“辅助排障”与“接管排障”之间，仍然隔着巨大鸿沟。直接接入运维系统，常遭遇执行黑盒、上下文污染等致命问题，以及幻觉与确定性的缺失，非但无法减负，反而可能制造更大混乱。把Agent接进宕机现场，不只是提建议，而是让AI跑完整条排障链路，这在生产环境能否行得通？OpenCloudOS团队花了三年时间，在数百万台服务器的真实故障中寻找答案。今天，他们把这套三年摸索出来的系统层AI 诊断方案 OCManager，连同背后经受住实战考验的积累，正式开源。一、 运维的困局与AI的边界过去十年，Prometheus、ELK、Ansible 等运维领域的工具极大提升了单点效率，却始终“各管一段”：监控归监控，日志归日志，配置管理归配置管理。当一台服务器出现问题，工程师需要在这些工具之间来回切换，把分散的信息拼凑成一张完整的故障图。这个"拼凑"的过程，才是真正耗时的地方。而运维团队更深层的挑战还在于经验的不可传递性。专家看到 CPU 抖动，能直觉关联到内存和 IO 队列，形成多维关联判断。但这个判断过程往往是隐性的，无法被系统化、无法被检索、无法被复用。人员流动，经验就随之流失。这也是为什么，即便市面上的运维管理工具已经足够丰富，宕机排障依然消耗了运维工程师的大量精力与时间的症结——因为工具可以被传递和复制，但人的经验却不能。所以，大模型能解决这个问题吗？直觉上，大模型天然适合做“串联”链路的判断，它有语义理解能力，能处理多维信息。但 TencentOS 团队在工程实践中发现，直接把大模型接进生产环境，会带来三个硬伤：一是黑盒问题，Agent 执行路径不可预测，同样问题可能走向截然不同的分析；二是上下文污染，规划与反思逻辑混杂在长 Prompt 中，模型极易迷失目标；三是深度绑定，现有框架难贴合业务定制，“改到最后不如重写”。归根结底，运维排障缺的不是更强的模型，而是一套工程化约束机制，一套能让大模型在正确的时间、正确的地点，思考正确问题的工作流程。