发布!乘云数字参编中国信通院《运维智能体(SRE AGENT)能力要求》正式发布

乘云数字参编运维智能体能力要求标准发布

摘要:2025年7月23日,由中国通信标准化协会主办的 “2025可信云大会” 在京举行,《运维智能体(SRE AGENT)能力要求》标准正式发布,杭州乘云数字作为运维智能体及可观测领域领导者,重点参与了本次报告的编写。

图片

2025年12月23日,由中国通信标准化协会主办、中国信通院承办的 “2025可信云大会-软件工程智能化分论坛” 在北京中关村国家自主创新示范区会议中心举行,《运维智能体(SRE AGENT)能力要求》正式发布。杭州乘云数字作为可观测性领域领导者,重点参与了本次报告的编写。该标准参与编写单位包括:中国信息通信研究院、移动云、华为云、蚂蚁、农业银行、杭州乘云数字、小米、神州灵云、农商银行、中电普华、百度、恒为科技、福建移动、宜通衡睿、银信、长三角数链。本标准文件由云计算开源产业联盟提出并归口。

图片

01 报告介绍

随着AI技术、运维自动化能力的不断发展,基于智能体的运维能力作为一种高效、自主的新型运维工具,能够实现更智能的资源调度、自动化运维和精准的故障预测,从而降低运营成本并提高系统稳定性。

本标准规范了在开展运维智能体建设或度量时,如何指导运维场景应用、协同能力构建、智能体能力建设和基智能体底座建设。

图片

本标准同时适用于服务商提供的运维智能体服务和运维智能体软件产品,即面向公共用户提供的运维智能体服务和私有环境下的软件产品或解决方案;依据交付形式的差异,本标准针对不同的使用场景其技术指标要求略有不同。

图片

该架构以场景需求为牵引,通过协同层打通系统壁垒,以智能体层的感知-决策-行动闭环为核心能力载体,最终由底座提供工程化支撑。四层能力环环相扣,既明确了技术能力边界,又强调实际落地场景的适配性,为企业构建智能运维体系提供清晰的模块化建设路径。

1. 运维场景层(顶层)

覆盖智能体服务的核心业务场景,包含:

  流程管理:自动化运维流程执行

  变更管理:系统变更的智能化控制

  故障管理:异常检测、根因定位与自愈

  风险管理:预判性监控与容错控制

  运维管理:资源调度与配置优化

定位:直接对接企业实际运维需求,定义智能体价值出口。

2. 协同能力层(承上启下)

支撑智能体在复杂环境中的协作能力:

 多智能体协同:集群任务分配与联动作业

 跨系统协同:对接CMDB、监控系统等第三方平台

 智能体安全:数据加密、权限控制与行为审计

定位:破除系统孤岛,确保人-机-系统安全交互。

3. 智能体层(核心技术层,横向三模块)

● 感知能力:

       - 运维数据(指标/日志/链路)
  - 环境数据(硬件状态/网络拓扑)
  - 交互数据(用户指令/反馈)
  (注:多源数据融合感知)

控制能力:

  - 信息理解:数据语义解析与特征提取
  - 记忆能力:知识图谱构建与经验存储
  - 计划能力:任务拆解与决策路径生成

● 行动能力:

  - 自动执行修复、扩缩容等物理操作
  - 支持工单生成、告警通知等人机协同

4. 智能体底座(基础设施)

● 模型接入:兼容AI大模型与专业算法引擎

 软件质量:高可用架构与性能保障

 自维护:智能体自监控、自升级与故障隔离

作为国内首个聚焦SRE Agent的专项能力标准,该报告具有三大核心价值:

 统一规则: 为产品开发与评估提供清晰依据,规范市场秩序。

● 赋能企业: 指导企业高效选型和建设SRE Agent能力,提升运维智能化水平。

● 引领发展: 树立行业技术标杆,加速智能运维技术成熟与应用创新。

02 篇章预览

5.3.2故障定位

描述:故障定位是指故障发生以后能够采取多种手段找到问题原因。一般故障定位能力分为现象定位、对象定位、原因定位三种。智能体应该与企业当前故障定位能力结合,在故障处理过程中通过大模型能力快速判断、整合,从而提升故障定位效率。

1级:

应具备故障现象定位能力,通过现象关联分析,实现故障初步定位及影响范围识别。

2级:

a) 智能体应具备故障对象定位能力。以及部分故障原因定位能力。

b) 智能体应具备结合多源数据进行多维度根因分析的能力。

3级:

智能体应具备精准分析故障原因与趋势,输出处置预测报告的能力

03 乘云数字运维智能体介绍

乘云数字,作为数字化可观测性领域的领军企业,持续专注于可观测性、现代AIOps、数字化经营等先进产品与技术的研究与应用,深入自主研发,聚焦解决国内企业全面上云带来的数字化运维、数字化经营的全新挑战。

凭借在领域的技术创新与行业领跑实力,乘云数字被评选为 “国家高新技术企业”、“浙江省专精特新企业”、“浙江省科技型企业”,并连续获得多轮融资。

乘云数字运维智能体引擎,结合预测性、因果关系和生成式 AI,能够实现分钟级的根因定位,利用大模型生成精准的处建建议,并可在问题对客户造成影响之前进行预测。

图片

预测AI :融合机器学习与多模态数据分析,实时处理指标、日志、追踪等运维数据,构建动态基线,提前预警潜在故障(如资源瓶颈、性能衰退),并定位根因、提供修复建议。通过仿真推演与智能决策,优化资源规划与发布策略,降低故障率,推动运维从“被动响应”迈向“主动预防”的价值驱动模式。

因果AI :分析指标、日志、追踪等数据间的因果关系,精准定位故障根因(如配置错误、依赖故障),区分直接与间接诱因,减少误报。通过回溯故障传播路径、量化影响并推荐修复方案,助力运维从“经验猜测”转向“因果可解释”的精准决策,提升故障处理效率与系统稳定性。

生成式AI :结合大语言模型(LLM)与知识图谱,实现基于自然语言的查询分析、报告生成、数据可视化等能力。通过沉淀历史经验和专家知识,推动运维自动化与知识高效复用,提升故障处理与系统优化效率。

具体实现效果可参考阅读以下内容:

https://databuff.com/resourceDetail/blog101

<think>嗯,用户想了解传统运维工程师如何转型为SRE工程师,以及需要哪些技能能力转变。这个问题很专业啊,看来用户可能是运维领域的从业者,正在考虑职业转型。 从用户的问题来看,ta已经对SRE有一定认知,但需要具体的转型路径指导。用户可能面临技能焦虑,想知道传统运维技能SRE要求的差距在哪里。需要给ta清晰的技能树可操作的提升建议。 让我梳理下SRE的核心能力要求。参考谷歌SRE模型,核心转变是从被动运维到主动工程化。传统运维侧重“保持系统运行”,而SRE要求“通过工程手段保证可靠性”。这个思维转变是关键。 具体能力差距主要在五个维度: 编程能力是最大门槛。传统运维可能用Shell写脚本,但SRE需要Python/Go开发自动化工具。引用[2]提到研发工程师的Linux知识,其实运维转型也需要补这些。 可靠性工程方面,传统运维熟悉监控告警,但SRE要设计SLI/SLO,实践错误预算等体系化方法。 基础设施即代码(IaC)是必备技能,传统手工运维必须转向Terraform等工具。 协作模式上,引用[1]提到的SRE COE角色很有意思,转型者既要懂开发思维,又要保持运维视角。 最后是文化转变,从“救火英雄”变成“故障预防者”。 用户可能最关心学习路径。建议分三阶段: 先补编程基础,Python+数据结构; 再攻原生技术栈,K8s+监控体系; 最后深入SRE专项,如混沌工程。 引用[3]的计算机基础也很重要,底层原理能帮助理解分布式系统问题。 对了,用户没问但可能想知道转型时间。根据经验,全职学习需6-12个月,边工作边转型要1-2年。可以推荐些资源,比如谷歌SRE手册、Kubernetes实战课程。 最后要提醒文化适应问题。很多转型失败是因为团队仍用运维KPI考核SRE,这需要组织协同改变。不过用户没问组织层面,暂时不提也罢。</think>以下是从传统运维工程师转型为SRE工程师所需的核心能力提升思维转变,结合行业实践的系统性总结: --- ### **一、核心能力提升路径** #### 1. **编程与自动化能力(关键突破点)** - **必备技能**: - 掌握至少一门脚本语言(Python/Go)实现自动化(如日志分析、配置批量更新) $$ \text{自动化覆盖率} = \frac{\text{已自动化操作数}}{\text{总操作数}} \times 100\% \quad (\text{目标} > 90\%) $$ - 熟练使用IaC工具(Terraform/Ansible)管理基础设施 - 开发运维工具链(如自动扩缩容系统、故障自愈脚本) - **学习建议**: 从编写巡检自动化脚本开始,逐步实现部署流水线(参考引用[2]的Linux进阶知识) #### 2. **可靠性工程体系** - **核心实践**: - 定义并监控SLI/SLO(如API成功率$ \geq 99.95\% $) - 实施错误预算机制: $$ \text{错误预算} = (1 - \text{SLO}) \times \text{时间窗口} $$ - 构建可观测性体系(Metrics/Logs/Traces联动) - **转型重点**: 从"故障响应"转向"预防性设计"(如容量规划、混沌工程) #### 3. **原生技术栈** | **传统技能** | **SRE进阶要求** | |--------------|------------------------| | 物理服务器维护 | Kubernetes编排与故障排查 | | 基础监控配置 | Prometheus+Alertmanager精准告警 | | 手动部署 | GitOps持续交付(ArgoCD/Flux) | #### 4. **系统工程思维** - 理解分布式系统CAP理论 - 分析故障链式反应(如雪崩效应$ \frac{d\text{故障节点}}{dt} \propto \text{负载压力} $) - 设计容错架构(断路器、重试策略) --- ### **二、工作模式转变** #### 1. **协作方式进化** ```mermaid graph LR A[传统运维] --> |被动响应工单| B(开发团队) C[SRE] --> |协同设计| D[架构评审] C --> |共享责任| E[故障复盘] C --> |交付SLO报告| F[产品决策] ``` #### 2. **核心文化转变** - **运维目标**: $ \text{传统:系统可用时间} \rightarrow \text{SRE:用户可感知可靠性} $ - **故障处理**: 从"责任追究"到"Blameless文化"(参考引用[1]的SRE方法论) - **资源投入**: 将$ > 50\% $时间用于自动化建设而非手动操作 --- ### **三、分阶段转型建议** 1. **初始阶段(3-6个月)** - 开发自动化运维工具链(如日志分析平台) - 参与On-Call轮值并推动告警优化 - 学习Kubernetes核心概念(Pod/Service/Ingress) 2. **进阶阶段(6-12个月)** - 主导1个SLO定义项目(如API延迟$ P99 < 200ms $) - 实施基础设施代码化(Terraform管理资源) - 建设监控黄金指标(RED:请求率/错误率/持续时间) 3. **成熟阶段(1年以上)** - 设计容灾演练方案(如AZ级故障模拟) - 开发自治系统(基于ML的异常检测) - 推动开发团队采用可靠性模式(重试/降级) > **关键资源**: > - 谷歌《SRE工作手册》第四、九章(错误预算实践) > - 引用[2]的Linux进阶知识(系统调优、网络诊断) > - CNCF原生学习路径(https://training.linuxfoundation.org/) > - 引用[3]的计算机体系结构基础(理解硬件瓶颈对软件的影响) --- ### 相关问题 1. SRE工程师如何合理设置错误预算的消耗阈值? 2. 在混合环境中实施SRE会遇到哪些独特挑战? 3. 如何向管理层证明SRE转型的投资回报率(ROI)? 4. 中小团队在没有专职SRE时如何逐步引入可靠性工程实践?
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值