课程简介
让学员深入理解运维自动化演进路径。熟悉云原生背景下的运维变革以及SRE 运维模式。掌握 AI 自动化运维在大数据基础、机器学习算法与运维场景适配等方面的知识与技能。能够将所学应用于实际工作，提升运维效率与质量。
目标收益
培训对象
课程大纲
| 一、自动化运维、DevOps和SRE |
1.自动化运维基础 -运维的发展过程：手动运维、脚本化阶段、工具化阶段、平台化阶段。 -自动化运维的优势：批量快速执行、可重复/标准化、提高运维人员技能水平。 -自动化运维主要工具：Ansible适用于小型场景、SaltStack -声明式API运维：IaC将基础设施的配置、部署流程以代码形式描述和管理 -自动化运维中的gitops：利用声明式配置来管理IT资源、并使用git仓库管理运维脚本和资源配置脚本。 【案例实战分析】：利用Terraform和Ansible实现资源的配置 2.DevOps思想 -DevOps 的产生的背景：敏捷开发普及后对 “快速交付” 的更高需求。传统模式开发与运维割裂导致 “开发快、交付慢” -DevOps 的定义：DevOps 是开发（Development）和运维（Operations）的融合，旨在打破研发全生命周期中的部门壁垒，实现软件快速、可靠交付。 -DevOps 的四要素（CAMS 模型）：文化（Culture）、自动化（Automation）、测量（Measurement）、共享（Sharing） -DevOps 的文化和组织：协作文化、责任共担、持续学习、容忍失败。 “职能型团队”到特性团队（Feature Team） -DevOps 与敏捷开发的关系：目标一致：均以 “快速交付价值” 为核心，相辅相成： -敏捷强调 “开发过程的灵活性”，DevOps 强调 “交付全流程的高效性”。 范围不同：敏捷聚焦 “开发阶段”，DevOps 覆盖 “全生命周期” -DevOps 研发流程与工具链：（Plan → Code → Build → Test → Deploy → Operate → Monitor → Plan）。项目管理、代码管理、代码质量、自动化测试、CI/CD 工具、IaC 工具、监控工具。 -DevOps 核心实践：持续集成（CI）、持续交付（CD）、基础设施即代码（IaC）、持续测试（CT）、监控与可观测性 【案例实战分析】：利用GitLab和JIRA实现DevOps平台 3.SRE 运维模式 -SRE 的起源与发展：起源：2003 年由 Google 提出，最初为解决搜索引擎、Gmail 等服务的 “大规模运维困境” -SRE 的定义：SRE（Site Reliability Engineering，站点可靠性工程）核心是 “用代码替代人工操作”，以保障大规模、高复杂度系统的可靠性。 -SRE 的核心目标：保障服务可靠性、推动系统可扩展性、实现运维自动化。 -SRE 的角色与职责：定义 SLI/SLO/SLA，可靠性保障、管理错误预算、主导故障复盘、开发自动化工具、实现代码化管理（XaC）、向管理层提供可靠性数据报告。 -SRE关键指标：服务级别指标（SLI）、量化衡量服务性能和可靠性。可用性（Availability），延迟（Latency），错误率（Error Rate），吞吐量（Throughput） -SRE关键指标：服务级别目标（SLO）、对 SLI 设定的目标值，是SRE 团队的核心工作基准。 -SRE关键指标：服务级别协议（SLA）、用户（或内部团队）签订的具有约束力的协议 -SRE关键指标：错误预算、系统允许出现的故障或性能不达标时间的总量 -SRE主要工作：自动化运维、监控与可观测性、容量规划与性能优化、灾备与容错设计、故障管理与复盘 【案例实战分析】：SRE常见开源工具讲解 |
| 二、云原生背景运维 |
1.云原生定义与容器 -云原生的定义和由来：指利用云计算基础设施和平台特性构建和运行应用的方法。 -云原生核心技术：如容器技术（Docker）、容器编排引擎（Kubernetes）、服务网格（Istio）、微服务框架（Spring Cloud 等）、持续集成 / 持续部署（CI/CD）工具（Jenkins、GitLab CI 等）。 -容器的发展历史：cgroups 和 namespace的出现预示着容器的出现，LXC整合到linux内核进一步普及容器，Docker 的出现为容器提供了产品标准。 -容器的基本概念：通过镜像、容器、仓库等。实现了应用的标准化发布 -容器的技术内幕：cgroups实现资源限制、Namespace实现资源隔离、Mount Namespace 隔离文件系统挂载点、Overlay Network虚拟网络栈、UnionFS联合文件系统实现镜像的高效存储。 -其他容器产品简介：containerd和OCI容器标准、无守护进程的podman、强隔离性的安全容器产品 【案例实战分析】：利用Docker搭建应用发布平台 2.Kubernetes 核心概念 -容器编排的定义和主要功能： -Kubernetes 的基本概念：如 Pod（容器组）、Service（服务发现与负载均衡）、Deployment（应用部署与管理）、Namespace（资源隔离）等。 -Kubernetes 的网络和存储：常见的CNI协议如Flannel、Calico -Kubernetes 的存储配置：PersistentVolume（PV）与 PersistentVolumeClaim（PVC）的绑定，StorageClass 动态供给存储 -Kubernetes 的核心组件：集群的统一入口API Server、分布式键值存储etcd、 Pod 的调度Scheduler、多种控制器进程Controller Manager、Pod 生命周期管理Kubelet、网络代理Kube-proxy、容器运行时containerd、CRI-O。 【案例实战分析】：Kubernetes 的部署和日常运维 3.微服务和服务网格 -微服务的核心概念与特点：独立运行的小型服务，去中心化治理、轻量级通信协议 -微服务的设计原则：单一职责原则、边界上下文原则、API优先设计、容错与弹性设计。 -微服务和容器的结合：容器为微服务提供标准化部署单元，实现快速启停、资源隔离、环境一致性、弹性伸缩等微服务管理难题。 -微服务注册中心：负责服务自动注册与状态监控如Eureka、Nacos； -微服务网关：负责请求路由、负载均衡、认证授权如Kong、APISIX -微服务的通讯协议：HTTP/REST：基于标准HTTP协议、gRPC：高性能、基于Protobuf的RPC框架、消息队列：异步通信模式，如RocketMQ、RabbitMQ -服务网格的定义：为微服务提供标准服务管理和的网络通信基础设施 -服务网格的组成：数据平面的Sidecar代理、控制平面的策略管理、配置分发、证书管理 -服务网格关键能力：流量管理、可观测性、安全 -服务网格的常见模式：Sidecar 模式、proxyless模式、Ambient 模式 【案例实战分析】：istio和Higress的部署 |
| 三、大数据和统一运维平台 |
1.大数据技术简介 -大数据的技术简介：3篇论文、5V特性、 -Hadoop技术栈：分布式文件系统HDFS、分布式列存储数据库HBase、离线处理MapReduce、 -数据计算框架：快速批处理Spark、实时流处理框架Flink、 -数据仓库技术：HIVE，Trino数据查询引擎、ClickHouse列式存储 -数据湖技术：Parquet ORC数据存储、Delta Lake、Iceberg数据湖 -日志处理的常见框架ELK：Elasticsearch日志存储与检索引擎、Logstash日志处理管道、Kibana日志可视化平台、Beats轻量级数据采集器。 【案例实战分析】：利用ELK框架处理日志 2.大数据分析平台的建设 -传统大数据的数据割裂：数据不一致、开发维护成本高、资源利用率低等 -大数据的架构进化：Lambda架构与Kappa架构。 -流批一体的概念与理念：一套班子、一套系统、一个逻辑的含义：统一开发人员角色，使用同一套数据处理技术框架，保持离线和实时计算逻辑一致。 -技术架构分层：数据采集层、消息队列层、存储层、计算层、元数据管理层、调度与协调层。 -数据采集层：流批一体系统的 “数据源头”，需同时支持实时增量数据（如数据库变更、日志流）和离线批量数据 -消息队列层：实时数据流的 “暂存与转发中心”，解决数据生产与消费的速度不匹配问题，同时支持流处理（实时消费）和批处理（历史数据回溯）的协同。 -存储层：流批一体系统的 “数据底座”，通过数据湖表格式实现 “一份数据、两种访问模式 -计算层：流批一体系统的 “大脑”，通过统一的计算引擎执行数据处理逻辑（如清洗、聚合、分析），核心目标是 “一套代码、两种执行模式”（流模式 / 批模式），避免重复开发。 -元数据管理层：负责管理系统中所有数据的描述信息（如 Schema、分区、血缘），核心目标是 “让流批数据可发现、可追溯、可信任”。 -调度与协调层：负责管理流批任务的资源分配、依赖关系和生命周期，核心目标是 “高效、稳定、可扩展” 地执行任务，避免资源浪费和任务冲突。 【案例实战分析】：流批一体的大数据处理平台 3.应用和平台的可观测 -可观测性的定义：通过系统输出的外部数据（日志、指标、链路），全面理解系统内部运行状态的能力。 -与监控系统的区别：“主动发现未知问题” 而非仅 “监控已知指标” -可观测性的核心价值：缩短故障排查时间、提升系统可靠性、支撑业务决策 -可观测性的三大支柱：日志（Logs）、指标（Metrics）、链路追踪（Traces） -日志的存储和分级：结构化日志、非结构化日志、二进制日志。根据日志级别分级存储与处理 -指标和报警体系：指标只可以分为系统层、应用层、业务层。指标属于结构化时间序列数据，相比日志更轻量化，支持聚合性计算。 -链路追踪的作用：识别服务依赖瓶颈、优化调用路径、排查偶发故障。链路追踪的核心指标包括：链路长度、单 Span 耗时、错误传播率 -链路追踪的实现：分布式追踪模型通过Trace ID（全局唯一标识一个请求）和Span ID（标识请求中的一个服务调用环节）关联整个链路。 -多维报警体系设计：日志报警、指标报警、链路报警。注意报警降噪，报警关联、报警升级。 -分析与展示层：多维度关联分析、统一仪表盘设计、智能分析能力 【案例实战分析】：一体化运维管理平台功能设计 |
| 四、机器学习、大模型和AIOPS |
1.机器学习算法和运维 -机器学习基础概念：监督 / 无监督 / 强化学习的核心区别、 -模型训练全流程：数据采集→特征工程→模型迭代→部署监控 -常见机器学习算法：逻辑回归、随机森林、XGBoost/LightGBM、K-means、DBSCAN、PCA -逻辑回归：二分类场景。通过历史故障数据训练，输出故障概率 -随机森林：多特征融合。融合服务器、网络、应用三层指标，识别复杂关联故障 -XGBoost/LightGBM：时序预测。基于历史性能指标，预测资源瓶颈，支撑容量规划 -K-means：指标聚类的。对同批次服务器的性能指标聚类，识别 “性能偏移” 的异常节点 -DBSCAN：密度异常检测。基于源 IP、端口、流量大小等特征，识别 DDoS 攻击等突发异常 -PCA：高维指标降维的。将服务器的 CPU、内存、磁盘、网络等 20 + 指标降维，可视化展示系统状态 【案例实战分析】：服务器故障预测模型构建 2.大模型技术原理与应用 -大模型定义：大模型是具有大规模参数（通常数十亿至万亿级）和复杂计算结构的机器学习模型，通过海量数据训练学习复杂模式和特征。 -大模型的优势：通用性与泛化能力，可处理多模态任务（通用文本、图像、语音），无需为单一任务单独训练。 -大模型的Transformer 架构：通过自注意力机制，突破远距离文本依赖学习限制，通过计算输入序列中每个元素与其他元素的关联程度，有效捕捉全局依赖关系。 -生成式模型工作流程：文本经分词、向量化后进入 Transformer 架构的编码器提取特征，解码器依据编码器输出和已生成的前文逐步生成后续文本，直至生成完整文本。 -开源的大模型的关键参数：参数量与硬件需求、上下文窗口长度、推理速度、显存占用计算 -大模型常见应用：模型微调（Fine - tuning）、RAG 系统维护、Agent 服务运维 -大模型蒸馏：将复杂大模型（教师模型）的知识迁移到简单小模型（学生模型）的技术。 -MOE（混合专家模型）：由多个专家子网络和一个路由机制组成，根据输入特征将不同输入分配给不同的专家子网络处理，最后综合专家的输出得到结果 【案例实战分析】：大模型在运维场景的应用 3.大数据、机器学习及 AIOPS -AIOPS 定义与目标：以数据驱动为核心，通过大数据，机器学习、大模型等技术实现运维全流程自动化的体系。 -AIOPS 的目标：自动化闭环：从 “异常检测→根因定位→故障修复” 全流程无需人工干预、预测性维护：提前识别潜在风险、资源动态优化：基于业务负载实时调整资源分配 -AIOPS 核心框架：数据层、算法层、应用层、 -数据层：构建 “全域数据湖”，整合监控指标、链路追踪、工单等异构数据。通过数据标准化实现跨源关联。 -算法层：搭建 “混合算法库”，包含传统机器学习模型（负责指标预测、规则生成）、大模型（负责文本解析、方案生成） -应用层：预测性维护、自动化根因分析、自动化故障自愈、动态阈值与告警优化、智能容量规划 -机器学习、大模型与大数据的协同：大数据技术解决了数据的规模和处理效率问题，机器学习擅长从结构化数据中挖掘数据规律和构建预测模型，大模型则能够处理和理解复杂的非结构化数据，三者协同形成 “数据处理 - 规律挖掘 - 语义理解” 的完整能力链条，提升运维智能化水平。 【案例实战分析】：AIOPS 平台落地 |
|
一、自动化运维、DevOps和SRE 1.自动化运维基础 -运维的发展过程：手动运维、脚本化阶段、工具化阶段、平台化阶段。 -自动化运维的优势：批量快速执行、可重复/标准化、提高运维人员技能水平。 -自动化运维主要工具：Ansible适用于小型场景、SaltStack -声明式API运维：IaC将基础设施的配置、部署流程以代码形式描述和管理 -自动化运维中的gitops：利用声明式配置来管理IT资源、并使用git仓库管理运维脚本和资源配置脚本。 【案例实战分析】：利用Terraform和Ansible实现资源的配置 2.DevOps思想 -DevOps 的产生的背景：敏捷开发普及后对 “快速交付” 的更高需求。传统模式开发与运维割裂导致 “开发快、交付慢” -DevOps 的定义：DevOps 是开发（Development）和运维（Operations）的融合，旨在打破研发全生命周期中的部门壁垒，实现软件快速、可靠交付。 -DevOps 的四要素（CAMS 模型）：文化（Culture）、自动化（Automation）、测量（Measurement）、共享（Sharing） -DevOps 的文化和组织：协作文化、责任共担、持续学习、容忍失败。 “职能型团队”到特性团队（Feature Team） -DevOps 与敏捷开发的关系：目标一致：均以 “快速交付价值” 为核心，相辅相成： -敏捷强调 “开发过程的灵活性”，DevOps 强调 “交付全流程的高效性”。 范围不同：敏捷聚焦 “开发阶段”，DevOps 覆盖 “全生命周期” -DevOps 研发流程与工具链：（Plan → Code → Build → Test → Deploy → Operate → Monitor → Plan）。项目管理、代码管理、代码质量、自动化测试、CI/CD 工具、IaC 工具、监控工具。 -DevOps 核心实践：持续集成（CI）、持续交付（CD）、基础设施即代码（IaC）、持续测试（CT）、监控与可观测性 【案例实战分析】：利用GitLab和JIRA实现DevOps平台 3.SRE 运维模式 -SRE 的起源与发展：起源：2003 年由 Google 提出，最初为解决搜索引擎、Gmail 等服务的 “大规模运维困境” -SRE 的定义：SRE（Site Reliability Engineering，站点可靠性工程）核心是 “用代码替代人工操作”，以保障大规模、高复杂度系统的可靠性。 -SRE 的核心目标：保障服务可靠性、推动系统可扩展性、实现运维自动化。 -SRE 的角色与职责：定义 SLI/SLO/SLA，可靠性保障、管理错误预算、主导故障复盘、开发自动化工具、实现代码化管理（XaC）、向管理层提供可靠性数据报告。 -SRE关键指标：服务级别指标（SLI）、量化衡量服务性能和可靠性。可用性（Availability），延迟（Latency），错误率（Error Rate），吞吐量（Throughput） -SRE关键指标：服务级别目标（SLO）、对 SLI 设定的目标值，是SRE 团队的核心工作基准。 -SRE关键指标：服务级别协议（SLA）、用户（或内部团队）签订的具有约束力的协议 -SRE关键指标：错误预算、系统允许出现的故障或性能不达标时间的总量 -SRE主要工作：自动化运维、监控与可观测性、容量规划与性能优化、灾备与容错设计、故障管理与复盘 【案例实战分析】：SRE常见开源工具讲解 |
|
二、云原生背景运维 1.云原生定义与容器 -云原生的定义和由来：指利用云计算基础设施和平台特性构建和运行应用的方法。 -云原生核心技术：如容器技术（Docker）、容器编排引擎（Kubernetes）、服务网格（Istio）、微服务框架（Spring Cloud 等）、持续集成 / 持续部署（CI/CD）工具（Jenkins、GitLab CI 等）。 -容器的发展历史：cgroups 和 namespace的出现预示着容器的出现，LXC整合到linux内核进一步普及容器，Docker 的出现为容器提供了产品标准。 -容器的基本概念：通过镜像、容器、仓库等。实现了应用的标准化发布 -容器的技术内幕：cgroups实现资源限制、Namespace实现资源隔离、Mount Namespace 隔离文件系统挂载点、Overlay Network虚拟网络栈、UnionFS联合文件系统实现镜像的高效存储。 -其他容器产品简介：containerd和OCI容器标准、无守护进程的podman、强隔离性的安全容器产品 【案例实战分析】：利用Docker搭建应用发布平台 2.Kubernetes 核心概念 -容器编排的定义和主要功能： -Kubernetes 的基本概念：如 Pod（容器组）、Service（服务发现与负载均衡）、Deployment（应用部署与管理）、Namespace（资源隔离）等。 -Kubernetes 的网络和存储：常见的CNI协议如Flannel、Calico -Kubernetes 的存储配置：PersistentVolume（PV）与 PersistentVolumeClaim（PVC）的绑定，StorageClass 动态供给存储 -Kubernetes 的核心组件：集群的统一入口API Server、分布式键值存储etcd、 Pod 的调度Scheduler、多种控制器进程Controller Manager、Pod 生命周期管理Kubelet、网络代理Kube-proxy、容器运行时containerd、CRI-O。 【案例实战分析】：Kubernetes 的部署和日常运维 3.微服务和服务网格 -微服务的核心概念与特点：独立运行的小型服务，去中心化治理、轻量级通信协议 -微服务的设计原则：单一职责原则、边界上下文原则、API优先设计、容错与弹性设计。 -微服务和容器的结合：容器为微服务提供标准化部署单元，实现快速启停、资源隔离、环境一致性、弹性伸缩等微服务管理难题。 -微服务注册中心：负责服务自动注册与状态监控如Eureka、Nacos； -微服务网关：负责请求路由、负载均衡、认证授权如Kong、APISIX -微服务的通讯协议：HTTP/REST：基于标准HTTP协议、gRPC：高性能、基于Protobuf的RPC框架、消息队列：异步通信模式，如RocketMQ、RabbitMQ -服务网格的定义：为微服务提供标准服务管理和的网络通信基础设施 -服务网格的组成：数据平面的Sidecar代理、控制平面的策略管理、配置分发、证书管理 -服务网格关键能力：流量管理、可观测性、安全 -服务网格的常见模式：Sidecar 模式、proxyless模式、Ambient 模式 【案例实战分析】：istio和Higress的部署 |
|
三、大数据和统一运维平台 1.大数据技术简介 -大数据的技术简介：3篇论文、5V特性、 -Hadoop技术栈：分布式文件系统HDFS、分布式列存储数据库HBase、离线处理MapReduce、 -数据计算框架：快速批处理Spark、实时流处理框架Flink、 -数据仓库技术：HIVE，Trino数据查询引擎、ClickHouse列式存储 -数据湖技术：Parquet ORC数据存储、Delta Lake、Iceberg数据湖 -日志处理的常见框架ELK：Elasticsearch日志存储与检索引擎、Logstash日志处理管道、Kibana日志可视化平台、Beats轻量级数据采集器。 【案例实战分析】：利用ELK框架处理日志 2.大数据分析平台的建设 -传统大数据的数据割裂：数据不一致、开发维护成本高、资源利用率低等 -大数据的架构进化：Lambda架构与Kappa架构。 -流批一体的概念与理念：一套班子、一套系统、一个逻辑的含义：统一开发人员角色，使用同一套数据处理技术框架，保持离线和实时计算逻辑一致。 -技术架构分层：数据采集层、消息队列层、存储层、计算层、元数据管理层、调度与协调层。 -数据采集层：流批一体系统的 “数据源头”，需同时支持实时增量数据（如数据库变更、日志流）和离线批量数据 -消息队列层：实时数据流的 “暂存与转发中心”，解决数据生产与消费的速度不匹配问题，同时支持流处理（实时消费）和批处理（历史数据回溯）的协同。 -存储层：流批一体系统的 “数据底座”，通过数据湖表格式实现 “一份数据、两种访问模式 -计算层：流批一体系统的 “大脑”，通过统一的计算引擎执行数据处理逻辑（如清洗、聚合、分析），核心目标是 “一套代码、两种执行模式”（流模式 / 批模式），避免重复开发。 -元数据管理层：负责管理系统中所有数据的描述信息（如 Schema、分区、血缘），核心目标是 “让流批数据可发现、可追溯、可信任”。 -调度与协调层：负责管理流批任务的资源分配、依赖关系和生命周期，核心目标是 “高效、稳定、可扩展” 地执行任务，避免资源浪费和任务冲突。 【案例实战分析】：流批一体的大数据处理平台 3.应用和平台的可观测 -可观测性的定义：通过系统输出的外部数据（日志、指标、链路），全面理解系统内部运行状态的能力。 -与监控系统的区别：“主动发现未知问题” 而非仅 “监控已知指标” -可观测性的核心价值：缩短故障排查时间、提升系统可靠性、支撑业务决策 -可观测性的三大支柱：日志（Logs）、指标（Metrics）、链路追踪（Traces） -日志的存储和分级：结构化日志、非结构化日志、二进制日志。根据日志级别分级存储与处理 -指标和报警体系：指标只可以分为系统层、应用层、业务层。指标属于结构化时间序列数据，相比日志更轻量化，支持聚合性计算。 -链路追踪的作用：识别服务依赖瓶颈、优化调用路径、排查偶发故障。链路追踪的核心指标包括：链路长度、单 Span 耗时、错误传播率 -链路追踪的实现：分布式追踪模型通过Trace ID（全局唯一标识一个请求）和Span ID（标识请求中的一个服务调用环节）关联整个链路。 -多维报警体系设计：日志报警、指标报警、链路报警。注意报警降噪，报警关联、报警升级。 -分析与展示层：多维度关联分析、统一仪表盘设计、智能分析能力 【案例实战分析】：一体化运维管理平台功能设计 |
|
四、机器学习、大模型和AIOPS 1.机器学习算法和运维 -机器学习基础概念：监督 / 无监督 / 强化学习的核心区别、 -模型训练全流程：数据采集→特征工程→模型迭代→部署监控 -常见机器学习算法：逻辑回归、随机森林、XGBoost/LightGBM、K-means、DBSCAN、PCA -逻辑回归：二分类场景。通过历史故障数据训练，输出故障概率 -随机森林：多特征融合。融合服务器、网络、应用三层指标，识别复杂关联故障 -XGBoost/LightGBM：时序预测。基于历史性能指标，预测资源瓶颈，支撑容量规划 -K-means：指标聚类的。对同批次服务器的性能指标聚类，识别 “性能偏移” 的异常节点 -DBSCAN：密度异常检测。基于源 IP、端口、流量大小等特征，识别 DDoS 攻击等突发异常 -PCA：高维指标降维的。将服务器的 CPU、内存、磁盘、网络等 20 + 指标降维，可视化展示系统状态 【案例实战分析】：服务器故障预测模型构建 2.大模型技术原理与应用 -大模型定义：大模型是具有大规模参数（通常数十亿至万亿级）和复杂计算结构的机器学习模型，通过海量数据训练学习复杂模式和特征。 -大模型的优势：通用性与泛化能力，可处理多模态任务（通用文本、图像、语音），无需为单一任务单独训练。 -大模型的Transformer 架构：通过自注意力机制，突破远距离文本依赖学习限制，通过计算输入序列中每个元素与其他元素的关联程度，有效捕捉全局依赖关系。 -生成式模型工作流程：文本经分词、向量化后进入 Transformer 架构的编码器提取特征，解码器依据编码器输出和已生成的前文逐步生成后续文本，直至生成完整文本。 -开源的大模型的关键参数：参数量与硬件需求、上下文窗口长度、推理速度、显存占用计算 -大模型常见应用：模型微调（Fine - tuning）、RAG 系统维护、Agent 服务运维 -大模型蒸馏：将复杂大模型（教师模型）的知识迁移到简单小模型（学生模型）的技术。 -MOE（混合专家模型）：由多个专家子网络和一个路由机制组成，根据输入特征将不同输入分配给不同的专家子网络处理，最后综合专家的输出得到结果 【案例实战分析】：大模型在运维场景的应用 3.大数据、机器学习及 AIOPS -AIOPS 定义与目标：以数据驱动为核心，通过大数据，机器学习、大模型等技术实现运维全流程自动化的体系。 -AIOPS 的目标：自动化闭环：从 “异常检测→根因定位→故障修复” 全流程无需人工干预、预测性维护：提前识别潜在风险、资源动态优化：基于业务负载实时调整资源分配 -AIOPS 核心框架：数据层、算法层、应用层、 -数据层：构建 “全域数据湖”，整合监控指标、链路追踪、工单等异构数据。通过数据标准化实现跨源关联。 -算法层：搭建 “混合算法库”，包含传统机器学习模型（负责指标预测、规则生成）、大模型（负责文本解析、方案生成） -应用层：预测性维护、自动化根因分析、自动化故障自愈、动态阈值与告警优化、智能容量规划 -机器学习、大模型与大数据的协同：大数据技术解决了数据的规模和处理效率问题，机器学习擅长从结构化数据中挖掘数据规律和构建预测模型，大模型则能够处理和理解复杂的非结构化数据，三者协同形成 “数据处理 - 规律挖掘 - 语义理解” 的完整能力链条，提升运维智能化水平。 【案例实战分析】：AIOPS 平台落地 |
近期公开课推荐