背景
在科技的发展以及现有大环境降本增效的趋势下，企业对IT运维的要求也越来越高。然而，许多企业仍然依赖传统的运维方式，这种模式在面对复杂的IT环境时暴露出诸多问题。
首先，运维效率低下成为一大痛点。传统运维方式主要依靠人工监控和规则设定，无法快速响应突发事件，常常导致问题发现滞后，影响业务连续性。
其次，随着企业IT系统的规模和复杂性不断增加，运维数据呈现爆炸式增长，海量的日志、告警信息难以被及时分析和处理，导致问题定位缓慢甚至误判。
此外，传统运维难以满足企业对故障预测和主动防御的需求，往往只能在问题发生后进行被动修复，增加了运维成本和业务风险。
最后，运维团队还面临着知识管理的难题，运维过程中的经验难以系统化和共享，导致团队依赖于少数专家，抗风险能力不足。
这些问题都会成为阻碍企业发展、降低企业竞争力的重要因素。而大模型赋能的智能化运维为企业提供了一种全新解决运维难题的路径。
它能够通过类似人一样强大的文字阅读和数据处理能力，从海量运维数据中快速提取有用信息，实现问题的精准定位和快速解决。
此外，大模型可以依托RAG和内置的运维通识能力从而提供预测分析技术，帮助企业提前识别潜在的故障风险，实现从被动响应到主动预防的转变。
对于企业沉淀的诸多运维解决方案资料库，大模型通过自然语言处理技术，将运维文档、案例库和实时数据整合为RAG智能知识系统，降低了对人工经验的依赖，提升了团队协作效率。
同时，大模型还可以自动化处理重复性任务，如告警分类、日志分析和运行状态监控，并辅以Agent，可以让大模型实现智能化的自动排障，从而让运维团队能够专注于更具战略意义的工作。
通过这些能力，大模型智能运维可以显著提高企业IT系统的稳定性、降低运维成本，并为企业在数字化竞争中提供了更强的韧性和灵活性。
本文来自社区深度探讨，聚焦大模型智能化运维落地面临的难点、IT运维团队需要具备的能力、构建智能运维大模型时运维工具的整合等具体问题，并对解决方案进行探讨和总结。
1、企业落地大模型智能化运维的难点有哪些？
● 仙守 苏宁易购 算法工程师：
大模型已经算是一种新的革命，各行各业都可以将其引入进行尝试，以期是否能带来新的希望。但是在智能化运维上，应用大模型的成功案例还是不够多，这主要是因为：
1.运维团队多是Linux高手，而对人工智能的知识储备不足，算法的概念，以及算法能做什么，怎么做，算法边界又是怎样的等知识储备不足。
2.智能化运维中的故障修复等统计归纳工作不足，大量的运维都是命令式、脚本式运维，或者大规模工具的可视化运维，代码式运维的占比不够多。
3.运维面临的环境复杂多变，诸多问题是需要按图索骥一点点进行溯源，甚至需要跨机器，或者更深层次定位才能解决，而系统版本变化，应用软件版本变化，都导致故障修复的解决方案有所不同。
4.运维团队的日志数据，解决方案数据等储备不足，而这也是大模型做训练时缺少的样本。
5.企业领导在财务计算上会发现一个人的成本可能远低于大模型私有化训练且需要显卡等高额的成本，除非某个云厂商直接提供一个完全成熟的大模型服务直接调用，且价格低廉。
在打动领导者实时智能化运维上永远是3点：
1.安全，使用智能化运维能够减少敏感数据的泄露。
2.成本，总体计算下来和多招人相比智能化运维能够省钱。
3.收益，使用智能化运维能够更快速更高效地解决运维问题。
●huyue SGM数据分析师：
有如下难点：
1.数据安全：企业数据的安全问题，一般企业数据是不能将数据流出到外面，因此不可用外部的大模型服务。
2.模型的选型及部署：根据不同的业务场景选择经过验证且合适的私有化大模型，并进行工程化部署。比如：一个简单的意图识别任务，用一个14b大小的模型即可，不需要直接用72b的模型，以避免成本的增加及性能的下降等。
3.价值收益：如何衡量业务场景的运维收益和大模型的成本高低。
4.任务拆解：运维场景的具体任务拆解成大模型的任务，这需要有对业务场景和大模型功能都非常熟悉理解的专业技术人员。
● Luga Lee 系统架构师：
这是大多数中小企业面临的共性问题，我们可以从数据、经济成本以及核心技术力等3个核心维度解析，具体可参考：
1.数据质量与规模问题：企业计划落地大模型，首先要有明确的目标，到底是基于大模型做什么，拿什么做，一定要想清楚。通常情况下，大模型训练和推理依赖于海量高质量的数据。而我们的运维数据通常分散在各种监控系统、日志文件、告警信息中，存在数据孤岛、格式不统一、噪声多等问题。如何有效地采集、清洗、整合这些数据，并构建高质量的训练数据集，是首要面对的一个不可避免的难题之一。
2.核心技术力层面：现有团队中有没有合适的人去负责推动、去主导大模型落地？知识储备是否能够支撑大模型的应用及开发？针对目前的业务系统架构，如何将这些领域知识有效地融入进大模型中，使其能够理解运维人员的意图，使得模型能够正确理解所投喂的食材，产生预期的效果，也是面临的问题。
3.资源投入及成效回报：这里面涉及基础平台建设以及所投入的计算及存储资源。如果一个公司没有完善或健全的可观测性体系框架或堆栈，对于数据的维护及管理是非常头疼的问题。毕竟，全面的监控指标和详细的日志记录以及丰富的事件数据，是构建高质量训练数据的基础。没有这些数据，大模型的落地显然没有更多的实际意义。再者，模型选择与训练是需要成本的，无论是底层基础设施还是人力成本，都是需要考虑的问题。
● 顾黄亮 某金融企业技术总监：
准确地说，智能运维的推进在企业中有很多的门槛，重点是人才培养和人员的理念。
第一是人才方面，运维人员首先需要具备一定的研发能力，尤其在机器学习和算法方面，需要有介入的能力，而且这部分人群转型也非常困难，让一个熟悉服务器硬件维修的运维人员去理解和应用机器学习算法进行故障预测是有很大难度的。还有招聘方面，如果具备这种素质的人员，也不会选择运维领域。
第二是数据，智能运维的根基是数据，要实现全面的智能化运维，需要收集包括硬件、软件、网络等多个维度的数据，数据收集后，还要进一步进行加工和处理，最后整合阶段也是一个非常大的挑战，因为这种大量的异构不同源的数据，其数据格式和存储方式都不一样。
第三是系统的异构性，目前很多企业的IT系统，有自研的，有购买的，而且IaaS环境的标准也不统一，所以造成数据处理环节，甚至语料准备阶段就开始形成推进的阻力。
关于工具，其实并没有难点。
2、IT运维团队需要具备哪些能力，才能更好地使用大模型赋能自动化运维？
● Luga Lee 系统架构师：
若面向运维团队的话，运维领域知识与大模型结合的能力可能是最需要考虑的首要要素。运维团队需要构建自身的领域知识体系为大模型作平台支撑，通过建立运维框架为大模型进行数据输入，比如，日志、指标以及相关事件信息等。同时，基于不同的运维场景转化为模型可以理解的任务以验证模型输出的准确性及合理性。当然，编程能力以及大模型知识也是需要掌握。
因此，在实际的工作中，若想更好的使用大模型赋能运维，我们可以通过系统培训、实践项目、技术交流、优质学习资源以及外部合作的有机结合，可以为团队成员构建一个全面的学习与成长环境，不仅有助于提升个体技能，还能增强团队的整体竞争力。
● 仙守 苏宁易购 算法工程师：
在IT运维团队的能力构建方面需要基于以下几个点展开：
1.大模型相关能力
（1）需要了解市面上有哪些成熟的大模型，每个大模型开源，商用的规则，每个大模型能否支持微调，以及他们是基于哪种领域数据训练出来的。
（2）调用大模型的能力。通过调用市面上不同云厂商提供的大模型达到快速验证的目的，和自己通过vllm进行大模型本地化部署。
（3）大模型Agent的理解以及使用能力。
（4）自动化运维故障修复，或者任务执行的抽象能力。抽象好才能以大模型Agent的函数调用方式去执行。
（5）大模型prompt的编写以及调试能力，每个大模型都有各自的切合点，不同的prompt影响很大。
（6）运维日志采集，清洗，转换，标注
2.工具使用能力
（1）运维常见工具的使用能力
（2）自动化运维工具的使用能力
（3）常见大模型的微调涉及到的工具和库，如openai，deepspeed
（4）docker使用能力、cuda安装及问题排错能力等等。
● 匿名同行：
1.私有化运维场景的业务能力，清晰明确的知晓运维的场景、目的、相应的策略、系统化拆解的能力。
2.大模型的能力挖掘和使用，需要知道大模型的能力范围、使用方式、调优方式，以便更好的运用大模型。
3.大模型的私有化部署和选型能力。
4.智动化运维业务场景的拆解和大模型能力结合的能力
● 顾黄亮 某金融企业技术总监：
我个人觉得，运维团队需要1-2名工具研发工程师，模型本质也是个工具，拿来即用，语料输入进去后，根据输出结果进行调优，一直到你觉得合适就行。总之要不停地尝试。
大模型智能化运维这几个问题如何解决：1.如何对设备系统的数据收集、清洗和转换？2.如何自动化执行运维任务，故障修复，提高运维效率？3.大模型被认为一个黑盒，如何对问题处理决策进行解释？
● 仙守 苏宁易购 算法工程师：
针对题目中的三个问题：
1.如何对设备系统的数据收集、清洗和转换？
（1）数据收集：利用传统监控工具，日志获取，埋点增加监控指标等方式进行数据收集和完善。
（2）数据清洗：可以利用传统nlp等方法进行清洗，比如控制字符过滤，大量安全日志采样降低比重等清洗方式。
（3）数据转换：传统nlp需要进行分词，词性标注等等，而到了大模型时代，不需要太多的数据转换，只需要大模型的词表统计即可，方便后续token化。
2.如何自动化执行运维任务，故障修复，提高运维效率？
大模型本质上是个生成模型，也就是通过上一个token计算下一个token的概率，其类似一个大脑，是无法完成执行等具体行为的，必须通过Agent，也就是函数调用等方式，而这需要提前编写。通过构建对应的Agent，当日志中发现一些之前设定好的场景或者意图即可触发对应的修复Agent函数调用完成任务。
3.大模型被认为一个黑盒，如何对问题处理决策进行解释？
大模型一定程度上无法完全解释，但是如果对性能无实时要求，可以让大模型将每一步的思考过程输出出来，比如“请将你的思考过程一步一步的输出”来让大模型给出具体的思考过程。但是仍需注意大模型的确存在幻觉问题，即这也可能引发未知的运维事故。
****●匿名同行：
大模型智能化运维面临的内容和问题主要包括以下几个方面：
1.数据收集、清洗和转换：
智能化运维的效果高度依赖于数据的质量和完整性。如何确保数据的高质量和完整性是一个重大挑战。企业可以采用数据清洗和预处理技术，去除错误和不一致的数据，建立完善的数据治理机制，确保数据的完整性和一致性。
2.自动化执行运维任务，故障修复，提高运维效率：
智能化运维可以利用机器学习算法对历史数据进行分析，提前预测潜在的系统故障，从而采取预防措施，减少停机时间。自动化工具能够根据预设的规则和知识库，自动执行一系列排查步骤，缩短故障恢复时间。
基于智能分析的结果，可以自动执行一系列运维任务，如资源分配、故障修复、系统优化等。同时，通过持续监控执行效果，不断调整和优化运维策略，形成一个闭环的运维体系。
3.大模型的“黑盒”问题和决策解释性：
大模型被认为一个黑盒，如何对问题处理决策进行解释是一个挑战。需要对模型输出的归因结果进行解释和评估，判断其合理性和准确性，结合领域知识和人工经验，对归因结果进行验证和修正。通过大模型做到智能运维，需要对云事件进行自动根本原因分析，这包括数据采集与整合、模型选择与训练、归因推理、结果解释与验证以及持续优化。
4.技术整合与兼容性：
现代IT系统通常包含多种技术和平台，如何将这些系统的数据和技术整合到一个统一的智能化运维平台上，是另一个重要挑战。不同系统之间的兼容性问题可能导致数据无法有效共享，影响智能化运维的整体效果。
5.安全性与隐私：
智能化运维涉及大量的数据收集和处理，这对数据的安全性和隐私保护提出了更高的要求。如何确保数据在传输和存储过程中不被泄露或篡改，是一个亟待解决的问题。此外，智能化运维还需要遵守相关的法律法规，以确保数据处理的合法性。
6.技术复杂性：
为了克服技术复杂性的难题，企业需要培养一支具备跨学科知识的技术团队，并积极引入外部专家进行指导。
7.成本问题：
智能化运维的成本较高，对于中小企业来说可能是一个负担。因此，建议企业根据自身实际情况选择合适的智能化运维方案，并逐步推进实施。
这些内容和问题指出了大模型智能化运维在实际应用中需要关注和解决的关键点，以确保智能化运维的有效性和安全性。
●叶创 某城商行 应用运维：
1.对设备系统的数据收集、清洗和转换还是从专业监控工具走，大模型的运维智能体主要还是做数据消费，而且是对已经由专业监控工具处理过的数据做消费，结合工单数据、自动化作业执行数据和CMDB数据。智能运维由要做运维数据治理的说法，但是目前不成熟，大都就是做了个数据湖把所有数据存在一起方便查询消费，投入产出比低 ，其实不如直接从各类工具走API读取。
2.用了大模型仍然和以前AIOps一样，除了已经完全确定的自愈方案之外，大模型只做故障修复方案推荐，决策在人。大模型相当于一个具备大量知识且学习能力很强的运维新手，技术强但是实战经验差，主要做辅助。
3.运维层面的问题决策大多数到不了黑盒的程度，不管是公域知识还是私域知识都可以让它把对应的参考链接列举出来，也可以在提示词里让它把整个决策推理过程进行说明，更进一步地还可以让它出多个方案进行对比。对应的运维红线和决策升级机制都可以写到智能体的提示词里，规避大模型的“幻觉”导致的运维事故。
4、企业构建智能运维大模型时，当下的运维工具是否需要重新整合？
● 顾黄亮 某金融企业技术总监：
需要看情况，运维工具的建设大概有几个方面，第一个是工作流的集成，第二个是工具功能的使用，第三个是数据层面。
如果不考虑成本，在构建运维大模型的时候，会对工作流和工具功能重叠情况进行整合，这是模型自身的工作，和工具层没关系，所有工作流程和工具功能不需要变动，无论工具原本是原子化还是工具集群，都不重要。
唯一要整合的是数据，数据分两块，一块是数据格式，还有个是数据兼容性问题，数据问题牵扯到模型的训练，比如说大模型在输入统一格式的数据时，训练和推理能力会大大增强，所以在数据收集这个层面，需要对所有工具的数据进行约束。数据兼容性其实就是存储方式，和数据收集中间层一样，存储层也需要重新规划。
● 仙守 苏宁易购 算法工程师：
智能运维的核心是大模型实时读取各种监控系统的日志，进行特定场景和问题的分析，并给出解决方案，然后通过Agent的函数调用进行执行来自动化修复。基于上述的定义，那么基于问题的涉及的范围就缩小到了数据收集、执行工具的调用这2大方面。
1.数据收集和格式化
企业的历史原因，一定是多种监控系统，多种监控指标并行的，而如果将不同格式的数据都给大模型，那大模型就要面对不同的数据格式，这本身就是一种挑战。所以如果输入给大模型的数据是统一格式，那么在大模型解释以及执行上，效果会有很大的提升。
2.执行工具的调用
执行工具包含了比如flink数据清洗、sql进行性能监控、修复脚本执行等，要完成实际意义上的智能化运维，那么需要最后的执行，而如果大模型直接接入每个系统，那难度将会成倍增加。所以可以通过Agent的函数抽象，将每个执行工具进行函数调用的统一化，然后选定一个大家都同意的执行方式，比如shell，比如python，比如java等等最终去实际执行具体的动作。
● Luga Lee 系统架构师：
智能运维大模型的建设对企业现有运维工具提出了更高要求，但是否需要重新整合，取决于工具链的适配性、改造成本以及对业务目标的支撑能力。
从本质来讲，针对大部分公司而言，智能运维大模型的 “ 核心 ” 便是 “ 数据 ” ，针对各种各样的数据进行抽取、训练，以实现异常检测、根因分析、故障预测等高级功能。而现实情况下下，很多企业所规划的运维工具往往是 “ 断层式 ” 的，各自负责不同的监控、告警、日志分析等任务，数据分散且格式不统一。
我们拿全链路可观测性体系来说，通常使用 Prometheus 采集指标数据、 Jaeger 或 Zipkin 负责分布式追踪以及 Elasticsearch 或 Splunk 负责聚合和存储日志。这些工具生成的数据格式、存储方式和访问接口各异，难以直接被智能运维大模型利用。因此，若要充分发挥大模型的优势，需要整合这些工具，使其数据能够被统一采集、转换和存储。比如，我们可以基于标准化的协议（如 OpenTelemetry ），将多种工具的功能整合为统一的运维架构，减少系统割裂的问题，通过统一的数据收集和导出机制，将 Prometheus 、 Jaeger 以及其他等工具的数据接入大模型，以方便数据训练。
议题共识综述
本次活动聚焦于企业在大模型的趋势下如何进行智能运维的问题，通过广泛的讨论和业内诸多专家的经验分享，总结了落地大模型智能化运维的难点、IT运维团队需要具备哪些能力、大模型智能化运维面临内容和问题、构建智能运维大模型时运维工具是否需要重新整合等4个核心议题，从判断引入大模型后会面临的问题，以及该具备哪些能力到具体工具整合上，最终形成一整套完整的解决方案：
1、落地大模型智能化运维的难点
在企业落地大模型智能化运维过程中，主要面临以下难点：数据安全性问题使得企业无法使用外部模型服务；模型的选型与部署需要按照特定业务场景展开；价值收益的衡量也相对复杂，需清晰理解运维收益与模型成本之间的关系；任务拆解要求专业技术人员具备全面的业务理解与模型运用能力。所以，企业首先需明确目标，解决数据孤岛及格式不统一的问题；其次，团队需具备推动大模型落地的知识储备；最后，全面的监控体系和足够的资源投入是确保成功应用的基础。
2、IT运维团队需要具备哪些能力
在IT运维团队使用大模型赋能自动化运维的过程中，关键能力主要体现在以下几个方面：首先，团队需具备扎实的运维领域知识和大模型的结合能力，要建立有效的数据采集框架和体系，包括日志和指标。其次，团队成员应掌握大模型的相关知识，如了解市面上成熟模型的特性、调用能力、微调方法及Agent使用。此外，工具使用能力同样重要，包括自动化运维工具和大模型相关库的应用。团队在构建大模型智能运维时，需明确运维场景与目标，将一个大的难题进行子问题拆解，最终落实到大模型以及Agent上，要确保团队在实际应用中不断尝试与优化，逐步迭代完成整体的智能运维的目的。
3、大模型智能化运维面临内容和问题
在大模型智能化运维中，面临的主要问题包括数据收集清洗转换的质量保障，自动化执行运维任务的有效性，以及大模型的劣势规避。首先，数据的高质量和完整性至关重要，企业需借助专业监控工具进行数据治理，确保准确性。其次，虽然大模型可以辅助故障修复和任务执行，但决策仍需人工介入，模型更多地作为知识丰富的助手。最后，针对大模型的决策透明性，需结合领域知识，要求模型输出推理过程并提供多个解决方案进行对比，以减少“幻觉”风险。通过系统化的策略和合理的资源配置，企业能更好地实现智能化运维的目标。
4、运维工具是否需要重新整合
在构建智能运维大模型时，是否需要重新整合现有运维工具取决于工具的适配性和改造成本。智能运维的核心在于高质量的数据，企业通常面临多种监控工具和数据格式不统一的问题，这可能影响大模型的训练和推理能力。因此，整合数据成为首要任务。有效的解决方案包括标准化数据格式和协议（如OpenTelemetry），以便将不同工具的数据统一采集和存储。此外，通过Agent函数调用的方式，将执行工具进行统一化处理，有助于简化执行流程并提高效率。
**综上所述，**在大模型的发展趋势下，企业不能盲目的直接将大模型引入运维体系中，需要先判断企业自身环境是否可以引入，并分析引入后面临的问题以及落地将可能遇到的难点、自身团队需要什么样的能力、当前的工具是否需要为了大模型而适配等问题，只有将这些问题想清楚了，环境准备充足以及对应技能的人员配备都到位了，才可以实时大模型的智能化运维，当然也不能以一步到位的策略开展大模型的智能运维，当前大模型仍有一些难解决的问题，所以需要企业步步为营，稳扎稳打的方式来不断地迭代自身的运维体系，最终达到满意的效果。
如何学习大模型 AI ？
由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。
但是具体到个人，只能说是：
“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。
这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。
我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
第一阶段（10天）：初阶应用
该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。
- 大模型 AI 能干什么？
- 大模型是怎样获得「智能」的？
- 用好 AI 的核心心法
- 大模型应用业务架构
- 大模型应用技术架构
- 代码示例：向 GPT-3.5 灌入新知识
- 提示工程的意义和核心思想
- Prompt 典型构成
- 指令调优方法论
- 思维链和思维树
- Prompt 攻击和防范
- …
第二阶段（30天）：高阶应用
该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。
- 为什么要做 RAG
- 搭建一个简单的 ChatPDF
- 检索的基础概念
- 什么是向量表示（Embeddings）
- 向量数据库与向量检索
- 基于向量检索的 RAG
- 搭建 RAG 系统的扩展知识
- 混合检索与 RAG-Fusion 简介
- 向量模型本地部署
- …
第三阶段（30天）：模型训练
恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。
到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？
- 为什么要做 RAG
- 什么是模型
- 什么是模型训练
- 求解器 & 损失函数简介
- 小实验2：手写一个简单的神经网络并训练它
- 什么是训练/预训练/微调/轻量化微调
- Transformer结构简介
- 轻量化微调
- 实验数据集的构建
- …
第四阶段（20天）：商业闭环
对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。
- 硬件选型
- 带你了解全球大模型
- 使用国产大模型服务
- 搭建 OpenAI 代理
- 热身：基于阿里云 PAI 部署 Stable Diffusion
- 在本地计算机运行大模型
- 大模型的私有化部署
- 基于 vLLM 部署大模型
- 案例：如何优雅地在阿里云私有部署开源大模型
- 部署一套开源 LLM 项目
- 内容安全
- 互联网信息服务算法备案
- …
学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。
如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。
