说明

大模型、AI时代，【先上车】再说，AI辅助写代码能够极大提升效率。

对于技术系统运维，笔者个人的理解是，需要在【不确定性】和【确定性】之间权衡，明确哪些风险是可以面对或者规避的，哪些是不能出问题的，要【消灭】的风险。

AIOps的定义

AIOps 全称 Artificial Intelligence for IT Operations（或 Algorithmic IT Operations），由 Gartner 于 2016 年提出。它是指利用大数据、机器学习（ML）和自动化决策，来完成传统上需要人工干预的 IT 运维任务。

强需求

目前的强需求【1】：

• 用户期望极高：40% 的消费者会放弃加载超过 3 秒的网站；

• 环境极度复杂：超 90% 企业已上云，半数以上使用至少 6 种可观测工具；

• 数据爆炸：日志、指标、链路、事件等日增 TB 级，人工根本无法消化。

笔者理解：

• 云上云下环境多了、复杂了；
• 运维基础数据的采集，通过多种形式，是否便于交互和处理；
• 问题的识别和处置。

AIOps的演进

自 2016 年问世以来，AIOps 已从“锦上添花”或尖端工具演变为任何可观测性策略的必备组件。

截至 2020 年 11 月，Dimensional Research 调查的组织中有 25% 已经在使用 AIOps，另有 59% 有计划实施 AIOps。

AIOps核心组件

可观测性

从应用、基础设施、网络、用户体验等全栈采集数据。使工程师能够理解各组件与端到端系统健康状况之间的关系。

数据采集的全面性，比如：从监控上来看，行情数据慢了。可能涉及专线、主机、应用系统等多个层面，分层数据的全面性就很关键了。

聚合、关联和分析

通过将来自多个来源的可观测性数据相互关联并全面分析，AIOps 工具才能识别数据中的有意义趋势。

需要【联动】，比如：行情数据接入慢了，从专线状态、应用处理以及设备状态信息，是否可以产生关联。

自动化

AIOps 工具自动确定软件环境中问题的根本原因，然后规划并执行补救措施。自动识别复杂问题的源头并修复，而无需等待人工工程师，这是 AIOps 的杀手级功能。

自动化不仅更快的解决了，还提高了一致性和可预测性。

但是笔者的个人观点：执行自动化是需要的，但是方向盘需要在运维人员的手中。

AIOps使用场景

AIOps 可应用于现代 IT 团队面临的几乎任何工作流或挑战。

最常见的 AIOps 使用场景包括通过自动管理告警和响应服务质量问题来改进应用服务水平和性能。这类使用场景在涉及高度复杂软件环境的情况下尤为重要，因为在这些环境中，人工工程师将难以知道哪些告警需要优先处理，以及如何在分布式、多层环境中追踪根因。

环境复杂了，人跟不上了。

数据采集与可观测性：从混沌到信息

关键挑战不在于找到数据，而在于以一种可操作且优化的方式掌控数据，从而推动 AIOps 工作流。

异构完整性（Disparate Completeness）

可观测性的数据来源形式多样。有些可能是写入持久存储的传统应用日志，易于采集和分析。有些数据可能本地存储的时间不长，如果不实时采集并汇总到持久存储位置，事件或指标也可能消失。

另外，数据类型差异很大。不同的日志使用不同格式。一些事件和指标数据以标准化方式结构化，而其他则随意生成。

数据真实性（Data Veracity）

并非所有数据都一定准确或可操作。未实时采集的数据可能在分析时已不再相关。为了驱动可观测性和 AIOps，数据必须尽可能准确和标准化。

数据上下文（Data Context）

单个数据源本身价值有限。知道 Kubernetes Pod 重启了，或软件定义存储系统不可用了，如果这些事件无法与物理服务器、虚拟机、操作系统、CI/CD 流水线及软件栈每一层发生的事情关联起来，则意义不大。

上下文的建立，可能是“人”要重点关注的。

数据开放性（Data Openness）

在为 AIOps 准备数据采集和标准化解决方案时，最后一个关键因素是数据无关性，即 AIOps 工具能够处理任何类型的数据，并将其应用于解决任何领域问题的能力。

应用分析：从信息到洞察

AIOps 的重点似乎是检测数据集中可能指示问题的异常。但实际上，问题检测只是等式的一部分。真正让 AIOps 强大的，是其呈现可操作洞察的能力，这些洞察能帮助团队修复问题——或者，在某些情况下，允许 AIOps 工具自动执行修复。

感知是基础，“可操作性”能力才是关键。

因此，要完全兑现其承诺，AIOps 必须以既能检测问题又能解决问题的方式应用数据分析，需要有如下的依赖：

拓扑（Topology）

考虑到 AIOps 工作流中涉及的不同数据源，需要将数据映射到其所代表的系统，这一过程称为拓扑，对于有效分析至关重要。

仅仅知道事件发生在系统的某个地方是不够的。必须了解事件发生的位置，系统中其他部分发生了哪些相应事件，以及这些事件如何影响系统的整体性能和业务整体。

需要梳理上下游关联

可操作的分析（Actionable Analytics）

AIOps 核心的分析必须产生可操作、切实的成果。

告警管理

AIOps 工具可以分析告警数据集中的复杂模式，并将告警数据与环境收集的其他数据关联，以对告警进行分级并识别误报，从而减少告警噪音。

根因分析

通过关联多个来源的数据，AIOps 可以准确判断复杂的根因问题。

预测与优化

AIOps 不仅仅是解决现有问题。它还通过基于对流量模式随时间变化方式的洞察来预测工作负载未来资源分配需求，帮助团队预防未来问题并持续优化性能。

度量

AIOps 驱动的分析还可以在整个软件交付生命周期中提供持续反馈循环，帮助组织评估其 IT 计划的成效。

动态基线（Dynamic Baselining）

异常检测特别具有挑战性的是，在许多情况下，没有一致的方法来定义“正常”运行状态。需要足够智能的 AIOps 工具来设置动态基线。

什么是正常的？

下钻分析（Drilling Down）

AIOps 中分析的价值不仅限于了解系统整体状态。同样重要的是能够深入问题进行深度调查。

例如，如果 Web 应用发生故障，您确定原因是网络带宽限制，您可能希望下钻并确定某类网络流量（如来自特定区域的流量）是否与导致应用问题的瓶颈有关。

实施智能自动化：从洞察到行动

在许多情况下，IT 运维团队采用了基于自定义脚本或连接到领域特定工具的 API 的有限自动化。这些方法造成了自动化孤岛，给处理跨平台和跨技术工作流带来了挑战。

有效使用 AIOps 需要智能自动化。

自动化告警管理

实现这一目标的一种方法是确保告警管理尽可能自动化和动态。手动告警不仅需要大量配置时间，而且可能导致误报，因为在某一时刻构成可接受风险、网络或其他资源消耗的情况，可能在下一刻随着环境变化而改变。AIOps 工具可以自动设置告警阈值，而不是配置手动告警阈值。它们还可以利用动态基线（如上所述）来配置告警何时触发。

告警管理是动态的。比如：某个非实时类系统，可能某个状态定时检查有异常，发出告警，可以不用持续告警。

告警上下文

告警不仅应指示发生了问题，还应附带帮助 ITOps 团队响应问题的信息。这意味着提供上下文信息，帮助工程师更全面地理解问题。AIOps 工具提供建议，同时让工程师最终决定如何解决复杂问题。

这正是 AIOps 实现真正“智能”的方式：它用 AI 驱动的洞察赋能人类，使他们能够比使用传统修复实践更快、更果断地采取行动。

修复

AIOps 工具甚至可以在识别问题后自动采取行动来解决某些问题。例如，它们可以响应安全威胁自动封锁主机或关闭端口，或者如果确定现有实例不足以满足需求，则自动启动额外的应用实例。

但是自动修复并不在所有情况下都适用；有时，事件的最终修复仍需手动执行，即使 AIOps 可以提供有助于达成修复的洞察。然而，随着机器学习算法日益复杂，AIOps 工具可以自动解决的问题数量将增加，从而实现更快、更无缝的事件解决。

自动化工单管理

AIOps 工具可以自动对工单进行优先级排序，以便 IT 团队知道应关注哪些工单。它们还可以帮助工程师找到报告问题的根本原因，从而更快解决。在某些情况下，AIOps 解决方案可以应用自动修复自行关闭工单。

采用 AIOps 解决方案的要点

定义目标

采用 AIOps 的第一步是明确通过实施 AIOps 实现什么成果：从基于手动工作流的 IT 运营模式转变为一个尽可能接近“无人值守”的模式。

不要为了改变而改变。

AIOps 是一场旅程

对于大多数团队来说，AIOps 实施始于演进现有监控实践，以使组织更接近实现 AIOps 的全部效果。 大多数团队从小处着手，先部署 AIOps 来处理选定的一些使用场景或某些数据源。

小结

笔者个人的看法：

• AIOps 并不是“无人”的，核心基础工作离不开大量的人力；
• 需要明确目标；
• 能够提供分析，加快处置，必要时可以人为介入；

以最简单的服务器重启为例，操作指令简单得不能再简单了，但是什么时候可以重启、重启之后要检查哪些项、启动哪些应用。大家可以想想重启主机时，可能会在群里面喊一下？没有【基础数据信息】的支撑，智能不起来。

• 应充分评估风险，至少明确风险点；
• 方向盘要在人的手里。

参考文献

【1】The Definitive Guide to AIOps

【2】https://docs.broadcom.com/doc/ca-aiops-solutions

【3】deepseek