信息化时代，我们通过线上系统将传统线下工作重新做了一遍；互联网时代，用连接打破了交流的界限；数字化时代以数据驱动重塑商业模式。那么，在稳定性保障领域，大模型如何破局，打破那张“看起来惊艳，又使不上力”的纱，用全新方式引领我们重塑稳定性保障呢？

一、AIOps的演进

在Gartner还没有提出AIOps前，ITOM市场出现过由APM厂商推动的ITOA（IT Operations Analytics）建设理念。ITOA的建设理念的提出，旨在利用大数据技术和统计分析方法对海量的运维数据进行运营分析。ITOA鲜明的提出了运用各种运行数据解决稳定性保障与技术运营上的问题。在解决方案上，强调在生产软硬件环境中自动、高效地收集、整理、识别和存储数据，并为IT运营人员提供简易的数据消费场景。从时间线看，我们可以将ITOA作为AIOps的前身。

在国内，最早是由APM厂商推动ITOA。不过，从实践看，ITOA的理念并未得到广泛实践。这可能是因为当时行业背景与现在数字化重塑行业工作模式的情况不同，大家对基于数据驱动的技术运营理解不够深入，且概念含义不够明确。同时，在那个阶段，强调运维大数据和分析技术在处理复杂运维数据时面临着局限性和成本过高的挑战。

接着，Gartner在2016年首次提出了AIOps的概念，当时的英文全称为Algorithmic IT Operations，意指基于算法的IT运维，这个理念也替代了ITOA。同时，在AIOps被提出的同时，人工智能（AI）在整个IT行业中已经处于快速发展的阶段。Gartner也适时的在2018年将其英文全称更新为Artificial Intelligence for IT Operations，即人工智能在IT运维领域的应用。

相比ITOA，AIOps在技术方案、平台、场景都更加聚焦，又逢AI技术发展，在实时监控和分析大量的运维数据，预测和防止潜在故障等方面起到了比较好的效果。不过，框定在智能AI也带来一些问题，在落地基于单指标与多指标异常检测、日志模式识别、信息收敛、趋势预测等效果较好的应用场景后，AIOps进入了如何进一步扩大场景的困境。所以，近年来又有不少人将AIOps定义为基于数据分析或数据驱动的运维，似乎又回到了ITOA。

二、AIOps的挑战

我个人觉得AIOps的问题主要是厂商与用户对AI与Ops的期望、理解、场景建设有关，比如：

过度强调替代性：一些解决方案提供商过度宣扬AI能够完全替代运维工作，但由于企业数据和算法质量的限制，这种过高的期望往往导致失望。同时，有些人也对这种“替代”观念持排斥态度。实际上，AI应该被视为提升运维工作效率和体验的工具，就像在业务系统中使用人脸识别、指纹识别和语音识别技术一样，它们旨在增强现有工作的效能，而非完全取代人。

缺乏场景思维的平台导向：另一部分解决方案过于关注将AIOps打造为智能运维的“平台”，却忽视了从实际场景出发的重要性。这导致技术平台无法与企业的运维组织和流程有效融合，缺乏运营思维，从而面临难以落地的挑战。

用户对AI的信任危机：运维是一个对准确性要求极高的领域，而AI算法的运行数据分析和决策基于数据层面。当面对复杂问题时，如果算法的判断不准确或不如人类经验可靠，就会引发信任问题。例如，在故障排查这种争分夺秒的场景下，几次定位不准确就可能损害用户对AI工具的信心。

算法与专家经验的脱节：目前市场上鲜有能够将AIOps算法与企业一线专家知识有效结合的解决方案。运维领域的解决方案需要借鉴类似AI Agent技术，实现多个工具、算法和经验的交互与协作，以应对复杂任务。

数据变化不等于问题：主流的AIOps方案主要是分析数据层面分析变化，但也许在抛出一个异常的用户行为、潜在的性能风险、生产故障问题的数据变化时，还带来10个正常业务逻辑、市场环境变化的信息需要人工干预。如何减少数据变化的噪点与落实对数据变化感知后的应对措施，需要进行复杂的机制与平台设计。

成本与收益的平衡难题：从平台层面来看，数据类研发工作琐碎且成效难以明确，这可能导致数据质量不足，进而影响上层场景的准确性。在近年来市场下行和厂商追求毛利的背景下，厂商在现场投入减少，同时在一些偏自研的组织对于AIOps团队效益的认内也不够高。大模型的出现，也许会让AIOps成本大大下降。

二、AIOps是一种运维工作模式

我在《运维数字化转型》一书中提出过我对AIOps的理解：AIOps不能单纯的认为一种技术手段或技术平台，而应该是数智时代人机协同的运维模式。AIOps这种人机协同的模式，是一种利用算法（含AI、规则、经验）、机器算力、海量数据、机器人相结合，赋能稳定性保障场景的工作模式。总结一下，可以归纳为“算法、数据、机器人”+“场景”四个关键词。

算法在运维决策中占据核心地位。算法应融合AI算法、专家规则与经验，才能让算法更加贴近运维实践的真实需求，还显著提升了决策的准确性。在实际应用中，当前比较有效的算法场景有:基于单指标与多指标的异常检测、日志模式识别、向量数据库的匹配。同时，通用大模型展示出来的算法能力如能融入到运维领域，也将是颠覆性的。

数据是智能运维的基石，为算法提供了必要的输入和丰富的训练样本。通过全面收集、精细整合及深入分析运维数据，可以洞察系统中的潜在问题，准确预测故障趋势，并据此优化资源配置。在这个过程中，对于琐碎、枯燥的数据治理工作也需要关注与投入，它是确保数据质量、提升数据价值的关键环节。

机器人是实现自动化运维的重要力量，承担大量重复性、繁琐的任务。我理解在机器人上不应该限制机器人载体，比如:chatOps机器人负责高效协同、自动作操作机器人负责执行，在大模型加持下的AI Agent的工具也可以作为一系列技能高超的机器人。机器人通过与算法和数据的在线协同，重点是解放人的行为。另外，站在稳定性保障过程，推动应用系统在架构韧性的自动化恢复也可归到泛化的机器人能力上，也就是只要是替代人的行为都可以，目标是人机协同。

场景是智能运维的价值创造的载体，“算法、数据、机器人”应聚焦重塑场景的细节赋能上。不可否认，新技术的引入会带来新的工作方式，但是作为稳定性保障领域，目前看最重要的工作场景还未发生太大变化，新技术更多是赋能作用。所以，突出场景驱动，重点是强调了技术对实际工作的赋能价值。所以，我们要先抓住AIOps在异常检测、日志模式识别等效果好的技术，拥抱大模型这种黑科技，站在场景角度则去思考AI赋能。场景的选择上，应以痛点驱动，先梳理现有的稳定性保障工作场景，评估哪些环节可以加入算法与机器人，帮助这些场景下的人更高效的落实保障工作。

三、围绕在“感知、决策、执行”的智能运维场景

在前面的智能运维模式中，“算法、数据、机器人”重点聚焦在细节的赋能，“场景”是关键。如何将“算法、数据、机器人”应用在运维场景上，重新设计一遍一系列稳定性保障场景，需要有一个利于理解、可实施的套路。在《全数字化赋能》一书中提出过“感知、决策、执行”的闭环解决方案，我觉得适合作为构建智能运维场景的指导方法。

感知是智能运维场景的起点，依赖于全面而精准的监控、运行感知、风险挖掘。一方面，延续现有的各类监控工具和技术，实时、全面地监控系统、应用、网络、服务器、IDC、依赖平台与上游系统等各个层面对象，及时发现潜在问题和异常。另一方面，利用成熟的AIOps算法解决一些监控在准确度、敏感度，或工作量过高方面的问题，更好的感知异常与潜在风险的挖掘。

决策环节是智能运维的大脑，应结合管理决策规则、一线专家经验以及智能化分析方法。在实施上，应该以专家规则与经验优先，比如一线运维专家分析问题的步骤、可观测涉及的排障步骤、特定场景下的故障愈策略、历史告警处理或故障处置的匹配等，先打平现有工作模式或为现有工作模式提能增效。在这些决策能力有效的同时，再引入更具期待的AI算法决策可能是一种比较可行的决策方式。

执行环节是智能运维的落脚点。在执行环节中，各类分析、执行的工具或接口可被作为执行手段，由根据决策需求调用执行。执行工具可能包括自动化脚本、配置管理工具、持续部署、消息推送、机器人协作等。在调用执行上，中短期内可以考虑基于外部事件触发的事件驱动模式，中长期的可以探索下依赖于数据驱动的推理决策模式。

四、大模型和AI Agent给场景带来的新思路

在近期行业分享的大模型运维案例中，能看到大模型在问题咨询、脚本编写、文档编写、知识库管理等工作上有确定性效果，可以马上让SRE拥抱通用大模型产品，尝试大模型给日常工作带来的改变。同时，一些融入运维平台层面的解决方案，比如以AI AGENT与现有平台能力的对接，可以看到大模型与AI Agent对于场景细节能力的提升有很大的想像空间。

1. 大模型在决策层面的思路

在上面“感知、决策、执行”层面中，主要的挑战是“决策”。在目前成熟的方案中，单指标和多指标异常检测等依赖于精确的时序数据（日志模式识别也是将日志非结构化数据转成了以模式为维度的时序数据），需要投入较大来提供准确、连续的数据，以保证有效的异常检测。大模型在处理数据时更为灵活，能够从大规模、多样化的数据集中学习，可以降低准入、试验的门槛，成本降低。从行业案例中，大模型在决策层面已经展示出让人意想不到的效果，假以时日，大模型也许能对决策产生突破性的作用。

我尝试在文心一言中模拟验证“决策”能力，可以看到根据Prompt的提示，大模型根据告警概要与涉及的工具能力，能够推理出建议执行的动作。从这个例子看，借助更加合理的Prompt设计，适当的模型微调，以及上下文内存记忆或持久化的数据库记忆，能够得到更符合预期的输出，应该有机会打败50%的新员工的排障能力。进一步的，如果能够结合大模型的function call，将函数的元信息（如函数名称、函数描述、函数参数等）提供给大模型，根据大模型推理判断输出输入的数据来选择需要调用的函数，由函数调用Agent的执行，技术实现上已经打通。下一步要看大模型是否可以给出稳定有效的推理能力，以及企业内如何降低SRE构建一系列Agent的门槛。

2.AI Agent在执行层面的思路

（1）关于AI AGENT

在2023年年中的一场开发者活动上，OpenAI的联合创始人Andrew Karpathy发表了重要言论。他提到，当有新的研究论文提出不同的训练方法时，OpenAI内部并不会给予过多关注，因为这些方法往往是他们已经尝试过的。然而，当一篇关于AI Agent的新论文出现时，他们会非常认真且充满兴趣地进行讨论。OpenAI的应用研发主管在一篇博文中详细阐述了基于大型语言模型构建AI Agents的框架。他认为，一个完整的AI Agent应该包括大模型、记忆能力、规划技能以及工具使用能力。其中，大模型作为智能体的大脑，起着核心作用，而记忆、规划和工具使用能力则是其关键组件。

综合当前主流的思路，我们可以将AI Agent定义为一种具备自主感知、决策和执行能力的智能体。它主要包括感知、决策、执行、学习、记忆（包括短期和长期记忆）以及通讯等模块。基中，感知是Agent是在数据信息中得到的信息进行处理，发现“事件”；决策是针对发现的“事件”，制定解决问题的规划思路（大模型擅长在这个节点）；再由Agent调用工具执行，以及从工具执行过程中获得反馈，形成闭环。大模型的出现为决策和规划提供了更为坚实的基础，使得AI Agent的实现成为可能。

（2）AI Agent与现有解决方案的区别

在技术实现上，AI Agent与现在主流工具接口调用看似一样，其主要区别在于智能化和自主性。传统的工具接口调用通常是基于预设的规则和参数来执行任务，缺乏自主决策和学习的能力。这些工具接口调用通常是静态的，无法根据环境的变化或任务的复杂性进行自我调整和优化。相比之下，AI Agent则具有智能化和自主性，它需要具备能够感知和理解环境，还能根据任务目标进行思考和决策。传统的工具往往只能关注某一方面的数据，如性能指标或日志文件，而故障往往是由多个因素共同作用引起的，因此需要综合考虑各种数据源。AI Agent能够将来自不同源的数据进行关联分析，从而更全面地了解系统的状态。

以运维故障分析场景为例，AI Agent与传统的工具接口调用相比，其优势并不仅仅局限于使用大型语言模型（大模型），每一个AI Agent的智能化和自动化能力才是其真正的核心优势。大模型可以为AI Agent提供自然语言处理、文本生成、通用知识的能力，AI Agent则是让SRE构建一系列能够通过学习和理解系统的行为模式来智能地判断和响应故障的工具，比如基于基准或模式匹配的异常检测工具，负责自动化的重启服务、回滚配置或调整系统参数等工具。AI Agent对有动手能力的SRE工程师十分友好，将能更好的激发创造力。

（3）工程实现上的思考

如何由单Agent向复杂多Agent提升是工程实现的难点。单Agent与多Agent之间存在的主要区别体现在它们的交互性和任务复杂性上。单Agent主要关注单一Agent在特定场景中的交互，侧重于处理Agent与场景之间的关系。此时，Agent的行为主要受到场景反馈的影响，并通过学习来优化其决策策略。相比之下，多Agent系统则是由一组既独立又协同工作的Agent所构成。在多Agent系统中，每个Agent都通过自身的行为对场景的执行结果产生影响，同时Agent之间也存在着复杂的依赖与交互关系。

还是以故障排查为例，假设我们有一个由多个服务器、服务和应用程序组成的系统。当系统出现故障时，单Agent系统可能只涉及一个监控Agent，它负责收集和分析系统的性能指标、日志数据等信息展示。相比之下，多Agent系统能够更好地应对这种复杂的故障排查场景。当监控Agent检测到某个服务器出现故障时，它可以触发异常检测Agent来进一步诊断问题。异常检测Agent可以检查资源、应用、业务情况，并尝试定位故障原因。同时，上游依赖检测Agent可以分析故障对象所依赖的其他服务或组件是否正常运行，以确定问题是否由上游故障引起。此外，日志分析Agent可以收集和分析系统的日志文件，提取有用的信息来帮助定位问题。链路分析Agent负责分析系统中各个组件之间的调用链路，以确定故障传播的路径和影响范围。变更服务Agent则根据异常对象所涉及的对象，负责分析是否有变更行为引发。自动化操作Agent可以根据预设的规则或策略采取相应的措施进行修复。

3.技术实现

OpenAI的Andrew Karpathy指出，与OpenAI这样的大型公司相比，普通人、创业者和极客在构建AI Agents方面可能更具优势。在落地实现方面，也许可以将AI Agent作为短期的突破口，比如：将传统监控与AIOps的异常检测、故障预测等能力应用在感知环节；由知识库、大模型、规则引擎应用于决策环节；各类分析、执行的工具或接口则作为执行环节，由AI AGENT根据决策需求动态调用执行。若此方法在实践中表现出色，我在这里预判一种SRE新的工作内容——由LLM支持决策规划，SRE自主构建一系列具备“感知、决策、执行”能力的Agent工具，并将它们注册在智能运维平台上，以供各种运维场景灵活组装和应用。

五、未来展望

AIOps是数智时代人机协同的运维模式，聚焦AI技术在稳定性保障场景上赋能，将算法（含大模型）、数据、机器人(含机器人、Agent)与SRE专家的经验融合，打造人机协同的模式。一方面，现有监控与AIOps技术继续发挥在“感知”层面确切性的效果。同时，我们需要将AI技术与人类的经验智慧紧密结合起来发挥“决策”能力，共同发挥作用，具备强大推理和决策能力的大模型有可能成为推动这一融合进程的重要力量。下一步，我们可以大胆的期待大模型在识别、推理的准确性上将很快提升到稳定性保障可用的程度，成为一个辅助决策的大脑，并融入到现有的运维平台中。另外，我们还需要在SRE组织内部积极推动拥抱AIOps的文化氛围，为SRE提供低门槛融入AIOps场景，比如让SRE更好的将经验落地在Agent工具的“执行”上，激发SRE积极参与智能运维的动力。

当然，本篇不少内容还仅仅是一些思考，还需要后续实践来探索是否正确。