【技术思考】AIOps 方案观察

一、 背景：

随着LLM崛起，每个行业都面临着改变。

个人感受：

在前东家的时候，管理配置混乱，部门墙严重。而且由于没有引入iac（Infrastructure as code） ，手工步骤繁琐，导致手机银行半小时内无法登陆的严重问题。
而且前东家没有配置sre团队，在从下主机背景下的 devops 工具链严重缺失，而且对于前东家这种传统行业中厂来说，人才稀缺，迭代缓慢，建设sre团队在财力和精力上来说都是不划算的。

而LLM 的出现，改变了一切。
由于copilot、cursor的出现，大家已经看到了LLM在编码领域的巨大优势，虽然我个人认为无法完全取代高级程序员（或者是架构师），但是在编码领域，中低级程序员的需求肯定是越来越少了。

如果搭配AI agent,LLM 在 ops领域也会大放异彩。

二、 AIOps 产品分析

我观察到的AIOps 项目的实现方式主要是用AI agent 对日志、监控数据进行预判、分析等。但是微软的AIOpsLab 却是从整体框架入手，做了顶层设计，我个人认为格局更高，也更好利用这个框架，改造成适应自己企业的智能运维工具。

收益：

如果使用 AIOps ,个人认为有以下几点收益

• 可以大大减轻运维成本，将优秀运维人员的知识利用 积累到文本库，利用RAG 进行判断，减轻对人力的强依赖，将优秀人才的精力放到更值得需要关注的事情上。
• 迅速：利用adaptive-RAG等技术，快速识别问题、快速分析问题、快速修复问题
• 丰俭由人：企业不需要一次性将庞大的aiops工具链统一上线，而是可以慢慢迭代，慢慢进步。可以将之前建设sre工具链的人力和财力，投入到aiops领域，借助大模型降低成本，减少前期投入。

AIOpsLab：原则性愿景

模块化设计：框架应支持应用、工作负载和代理的灵活集成。

灵活的代理接口：框架应提供多样化的接口，以满足人类、数字和AI代理的不同需求。

可扩展性：框架应在不同的空间和时间尺度上运行，以适应不同的用例和资源可用性。

可重复性：框架应提供一致的、自动化的部署，以实现可重复和标准化的评估。

操作环境的多样性：框架应能够与生产环境集成，或在沙盒中部署简化版的应用。

全面的故障支持：框架应支持跨整个堆栈的故障注入，包括硬件、网络、OS、中间件、应用和外部服务。

多样化和现实的工作负载条件：框架应允许生成反映不同领域工作负载特征的工作负载。

运维生命周期的覆盖：框架应支持故障检测、根本原因分析和缓解等不同阶段。

对应用的充分可观测性：框架应提供足够的系统和应用环境的可见性，以检测故障及其影响。

对代理操作的充分控制：框架应提供足够的接口，以便代理能够执行修改配置文件或重启VM和服务等操作。

系统架构

AIOpsLab的系统架构包括五个关键部分：
协调器（Orchestrator）：作为代理和应用服务之间的中介，提供接口供其他系统部分集成和扩展。

服务（Service）：抽象多样化的服务，以反映生产环境中的变化。

工作负载生成器（Workload Generator）：创建模拟故障和正常场景的工作负载。

故障生成器（Fault Generator）：设计用于通用应用的故障注入器，能够模拟复杂的故障场景。

可观测性（Observability）：提供跨系统各层的全面监控能力，收集包括追踪、日志和指标在内的多种遥测数据。