Red Hat AI

Why ITOps needs a governed automation foundation for AI

8.5内容质量

TL;DR · AI 摘要

IT运维引入AI需要治理的自动化基础,否则可能导致执行混乱和风险。Red Hat指出当前AI与自动化层存在三大混淆误区。

核心要点

  • AI生成的洞察不等于可执行的自动化流程,需独立治理执行层
  • 自动化剧本需经过审核测试才能成为可信的生产流程
  • 赋予代理生产权限可能引入不可控的非重复性变更

结构提纲

按章节快速跳转。

  1. 当前客户在AI落地时普遍遭遇预期效果未达的困境。

  2. AI增加系统压力但不构建自动化基础设施,导致风险累积。

  3. 洞察与执行、编写与运行时、代理即自动化三类错误认知普遍存在。

  4. 需建立分层治理架构,确保AI输出与自动化执行的独立性和可控性。

思维导图

用一张图看清主题之间的关系。

查看大纲文本(无障碍 / 无 JS 友好)
  • AI与自动化治理
    • 核心问题
      • 压力与基础设施失衡
    • 三大误区
      • 洞察≠执行
      • 编写≠运行时
      • 代理≠自动化
    • 解决方案
      • 分层治理架构

金句 / Highlights

值得收藏与分享的关键句。

#AI#IT运维#自动化#Red Hat
打开原文

为什么IT运维需要AI的治理自动化基础

Component | Article_teaser

2026年10月29日

5分钟阅读

人工智能

Chad Zammar

Ansible自动化架构师

Subpattern | social_share_set

Component | social_share

分享

Subpattern | subscribe

Component | social_icon

订阅RSS

Component | Icon

© Red Hat, Inc. CC-BY-4.0授权

Subpattern | results_nav

组布局

Component | Nav_links

  • 返回所有文章

Component | Generic

最近我经常听到许多客户用不同的表述说出相同的话——他们在环境中添加了AI层,期望一切都会变好,但至今尚未发现明显变化。

在实践中,我首先看到的新增功能通常位于上游,无论是协作者(copilot)、AIOps关联层,还是能够跨工具推理的代理(agent)。这部分帮助人们更快地起草、分类和推荐。但将这些工作投入生产仍然需要不同的层级,且通常与添加AI之前的流程保持一致,包括相同的交接、队列和审批流程。Red Hat的概述《AI与自动化:有何不同?》也指出了这种分裂。一侧负责解释和推荐,另一侧则以一致性和控制性执行预定义任务。我在现场观察到的关键问题是:团队是否以与上游AI工作相同的目标来设计生产路径,还是继续沿用现有流程?

我常常用管道类比来解释这个问题。如果在没有足够管道、阀门和排水系统的情况下向建筑中注入更多水,不会改善水流,反而会导致洪水。AI增加了堆栈顶部的压力,但它不会构建安全管理这种增加流量所需的管道、阀门和排水系统。

当团队将这些层级视为相同能力时,客户工作中就会出现同样的困惑。

客户合作中常见的三种混淆

AI辅助与真正自动化的界限很快就会变得模糊。当协作者生成剧本(playbooks)、AIOps诊断事件、工具被标记为“智能体(agentic)”时,团队会误以为生产系统正在自主运行,因为手动输入量减少了。从自动化架构师的视角来看,这种感觉通常源于三个混淆:

  • 洞察与执行:很容易将上游输出误认为是完成的工作,但生产仍需要可追溯的受控执行。将两者混淆是主要问题。可观测性与AIOps案例是常见例子。从可观测性到AIOps自动化的旅程展示了分析和分类如何连接到自动化平台上的受控执行,而不会停留在洞察本身。
  • 编写与运行时:生成的剧本和角色仍需审查、测试和推广,才能成为受信任的自动化。撰写内容与在策略下运行内容并非一回事。
  • 将智能体视为自动化:赋予智能体广泛的生产访问权限以解决问题看似是进展,但通常会用未经审核、不可重复的变更取代人工交接,模型成为集成层,每次运行都可能不同。

当这些混淆被归结为一个名为“AI”的单一概念时,团队就会跳过关键问题:谁可以采取行动?在哪些系统上?需要什么批准?如果出错,有哪些证据?

这种混淆带来的代价

当AI被误认为是自动化时,程序会以可预测的方式失败。

  • 无闭环的洞察:建议通过聊天、电子邮件或工单评论传达,同时AIOps或可观测性技术可同步提升问题分类效率。提示信息数量和仪表板置信度上升,但工作流程仍通过相同的人工交接关闭,事件通常不会更快解决,且仍需相同的人工操作。
  • 无治理的加速:团队为代理授予凭证以弥补差距。代理"修复"事件的速度加快,直到某处出现故障且无人能重建范围、身份或历史记录。回滚操作仍无明确定义。
  • 错误的自动化:团队将当前的临时解决方案编码到操作手册或生成内容中,然后要求AI进行优化。处理量上升,但底层流程并未改善。

在最近的一次合作中,我看到了该模式的压缩版。可观测性堆栈和AIOps层确实发挥了作用:重复警报减少、分组效果更好、基础设施故障的严重程度更清晰。管理层能看到"AI帮助运维",但相同类型的故障事件仍需同样时间解决,仍需要相同数量的人工变更生产环境。分析师仍需创建工单、粘贴建议的修复方案,并等待人工批准执行修复。

转折点并非升级AI堆栈,而是将可信信号接入基于事件驱动的Ansible规则书。这些规则书触发经过审核的工作模板和流程,用于收集事实、丰富工单、应用已知修复方案或升级处理。这正是操作员手动执行的相同已批准自动化,明确划分了AI停止的位置和治理执行接管的界限。

贯穿始终的关键并非AI本身,而是AI辅助决策与生产系统变更之间缺失的"管道"。

可行的模式

可行的模式包含两个有目的连接的层级。上游AI负责感知和决策,进行分类、关联和推荐。下游自动化在运维人员已信任的控制下执行。一个信号或建议输入,经过治理的变更输出,作业历史和审批记录显示生产环境已关闭。这就是我在评审中衡量的操作闭环。

对于IT运维,当客户需要明确该模式时,我会推荐Red Hat Ansible Automation Platform。在设计评审中,我会补充团队在优先考虑上游堆栈时经常忽视的三个约束条件:

  • 一个已批准的操作词汇表:无论由人员、基于事件驱动的Ansible还是代理触发,相同的作业模板和工作流都会运行。触发方式变化,但受控内容和审计跟踪保持不变。
  • 编写不等于运行时:生成式助手可协助起草操作手册和建议,但实际在生产环境中运行的是经过审核的自动化内容,如同其他变更一样经过正式流程推广,而非直接从提示中生成的初稿。
  • 代理通过平台而非绕过平台到达生产环境:Ansible Automation Platform上的模型上下文协议(MCP)服务器暴露了与真实用户令牌和基于角色的访问控制(RBAC)绑定的检查和启动工具。代理不直接持有管理基础设施的凭证,而是调用其他人同样使用的受控接口。我们在《从可观测性到AIOps自动化的旅程》中讨论了这一执行端模式,以及可观测性和AIOps的相关内容。

基于事件驱动的 Ansible 通常是将可观测性或 AIOps 融入该闭环的桥梁:信号匹配规则手册,规则手册启动已批准的任务,并且当信号不足以单独采取行动时,会有限制并行运行和审批关卡。向外扩展时,当剧本需要判断时,工作流仍可调用上游 AI。在双向流程中,只有经过批准的自动化内容或操作员才能闭合该循环。

AI 帮助您扩展现有的执行层,但这些约束条件正是您强化该层级的方式,而不是绕过它。

总结思考

在评估时,我不会首先强调 AI 模型选择。我会要求提供通过 AI 流程完成的生产工作,并附有可审计的证据。当这条路径不够清晰时,通常造成模糊的原因是流程本身,而非他们使用的是哪种 AI。

您需要 AI 和自动化,但它们适用于不同的任务。选择一条必须在政策下完成并被视为“生产就绪”的路径:成功任务、更新的工单和审计记录。在需要帮助的地方将智能向上游集成,在下游通过已批准的自动化执行流程,然后通过衡量结果是否改善来验证效果。

如果您的组织仍在映射非正式流程并收紧 AI 治理,可以并行推进这些工作。它不会取代执行层,但能让该循环更安全地扩展。

当您准备将该循环锚定在平台上时,Ansible 自动化平台是工作模板、工作流、审批和作业历史协同工作的场所。如果您希望整合自主 AI,可以从 Ansible 自动化平台上的 MCP 服务器开始,确保“检查-启动”流程与其他所有内容一样处于基于 RBAC 的同一表面上。

Block | Dynamic pattern deluxe promo

Component | Band_header

Red Hat 虚拟活动 | 开源安全的未来方向

开源安全是我们“未来方向”虚拟活动的第一个主题,向您展示如何将修复措施从人工速度提升到机器速度。

Component | spacer

Component | Cta_multi_basic

Subpattern | simple_cta

Component | CTA

继续阅读

Deluxe mbox

Component | Card_header

关于作者

Subpattern | speaker

Card layout

Component | Image_embed

Component | Person

Chad Zammar

Subpattern | social_links

Chad Zammar 是 Red Hat Ansible 自动化架构师,专精于使用 Ansible 和 OpenShift 进行 IT 和基础设施自动化。

他于 2005 年获得计算机科学博士学位,此后在软件工程和解决方案架构领域一直非常活跃。通过与多个行业公司的合作,他掌握了分布式系统、云架构和技术、数据工程、运筹学、AI、Web 技术、电信、虚拟现实和嵌入式系统等广泛的技术技能。

Chad 住在蒙特利尔,闲暇时间喜欢徒步旅行、公路旅行、阅读纸质书籍或使用 Ansible 进行自动化。

阅读该作者的更多文章

类似文章推荐

Dynamic pattern

博客文章

Atos 如何使用 Red Hat AI 构建更小、更专业的主权 AI 模型

基于策略的访问控制实现 AI 代理安全

原始播客

自主 AI 能够修补互联网吗?

Red Hat 如何为可扩展 AI 清理 IT 债务

Subpattern | card_flex

Subpattern | text_basic

继续探索

  • 《自动化企业》电子书
  • 通过自定进度的动手实践实验室体验 Red Hat Ansible Automation Platform互动实验室
  • 《Red Hat Ansible Automation Platform 入门指南》电子书

继续探索 mbox

子模式 | 简单文本

按频道浏览

浏览所有频道

模式 | 原始HTML

自动化

关于IT自动化在技术、团队和环境方面的最新动态

人工智能

关于使客户能够随时随地运行AI工作负载的平台的最新动态

开放混合云

探索我们如何通过混合云构建更灵活的未来

安全

关于我们在不同环境和技术中降低风险的最新动态

边缘计算

关于简化边缘运算平台操作的最新动态

基础设施

关于全球领先的企业的最新动态Linux平台

应用程序

深入了解我们解决最复杂应用程序挑战的方案

虚拟化

关于企业虚拟化的未来,无论是在本地还是跨云环境中的工作负载