AIOps 是什么：理解告警关联及其局限

AIOps 是什么？它指将人工智能用于 IT 运维：借助分析和 AI 方法，帮助解读告警、日志和指标等运维信号。告警关联将可能相关的事件归在一起，供调查人员作为一组进行检查。关联分组是调查线索，并非已证实的根本原因。

真正需要判断的是：已提供的证据是否支持某项特定的故障假设。AI 编写的摘要可以帮助组织证据，但无法替代缺失的测量数据、证实服务依赖关系，或授权修复行动。

作者：Ai Flowi · 发布于 2026-10-10

AIOps 的含义：从信号到调查

监控收集观察数据，并评估可能触发告警的条件。关联分析检查这些观察之间的关系：相同服务、部署引用、时间关系，或已经验证的依赖。诊断探究是什么导致了观察到的行为。响应则改变运维状况。即使工具将它们呈现在同一屏幕上，它们仍是不同职责。

模型可以建议对两个服务联合调查，但该建议仍需要依赖图或其他证据来连接两者。相似的告警措辞可能源于共用消息模板，而不是同一故障。同样，接近的时间戳可能让事件值得比较，却不能说明哪个事件导致了另一个。

带注释的虚构告警数据包

以下记录是虚构的教学输入，并非生产环境遥测数据。所有时间都属于同一个虚构日期，并使用相同的 UTC 偏移量。CSV 列名严格为 timestamp；每个值都包含 UTC 偏移量，因此没有单独的时区列。提供的数据包没有经过验证的服务依赖图。其 observed_status 描述对应信号，而不是整个服务的健康状况。

小屏幕上可横向滚动告警表；键盘用户可将焦点移到表格区域，并使用方向键。

本数据包中的两份 evt_a 在所有字段上都相同。根据本练习的规则，事件 ID 相同且内容完全相同的重复记录，表示同一观察被再次投递，因此两份记录合为一个证据项，投递次数为两次。应保留两个原始行引用；减少重复展示不能抹去投递历史。

这样，提供的四行数据留下三个不同的证据项。如果又收到一条 evt_a，但其状态或时间戳不同，应将其保留为冲突，供进一步检查。本练习不会仅因 ID 相同就选定某条为准。要求模型总结故障前，必须先应用等价规则。

AIOps 中关联告警分组能支持什么？

候选分组可以包含 evt_a 和 evt_b，因为它们指向同一服务和部署引用。两者的观察不同：一个是延迟告警，一个是成功探测。应同时保留。探测可能针对不同端点或不同时刻，不能抵消延迟观察。

evt_c 的时间接近，但其部署引用未知。应将它作为单独标识的候选关联纳入，并说明缺失的依赖证据。合格的假设草稿应询问：当时 checkout 请求是否依赖 inventory；而不应断言 inventory 故障导致了 checkout 告警。

因此，调查材料包应包含证据 ID、拟议关联、反证、缺失的遥测数据和下一项验证问题。这里有用的问题包括：哪些端点受影响、调用是否跨越两个服务，以及部署是否发生在症状出现之前。虚构表格并未包含这些问题的答案。

范围明确的 AI Flowi Workflow 示例

Load CSV 参考文档介绍解析器契约，Data → DataFrame 介绍 JSON 到 Table 的边界。Table Operations 和 Structured Output 列在组件目录中。下方使用的能力状态为已有文档说明：组件目录中有文档说明；Ai Flowi 尚未对其进行生产环境测试。

示例配置，并非已记录的测试

准备已授权的虚构 CSV 导出数据，并取得 Workflow 编辑器的访问权限。模型阶段需要你自己的服务商账户和 API 密钥，服务商费用由你另行支付。本练习从已提供的记录开始，没有接入监控数据采集或修复操作。

1. 将 Load CSV.csv_string 设为完全一致的表头 event_id,service,timestamp,signal,deployment_ref,observed_status，后接上方展示的四条记录。保留每个 timestamp 值中的偏移量，并保留 evt_a 的第二次投递。
2. 将已加载的记录经由 Data → DataFrame.data_list 传入 Table Operations.df，中间连接遵循转换参考文档。配置排序前，检查列名仍为 timestamp。
3. 对于这个同日、相同偏移量的数据包，建议设置 Table Operations.operation = "Sort"、column_name = timestamp，以及 ascending = true。保留所有状态。如果日期或偏移量不同，需要先规范化再按时间比较。
4. 使用上方明确的相等规则审核重复记录分组。组件目录列有 "Drop Duplicates"，但并未说明用于比较的字段子集或记录保留策略。建议的 Sort 步骤并不实现按事件 ID 分组。
5. 在 Structured Output.input_value 中提供已审核的证据材料包，并根据结构化输出说明配置模型和拟议结果结构。在 system_prompt 中，要求每项假设列出支持它的事件 ID，保留成功探测，并指出缺失的依赖证据。

分组审核后，模型接收人工准备的故障摘要。摘要应包含数据采集窗口：数据包截止于 09:00:08，因此不能确定延迟后来是否恢复。之后出现成功请求会扩展证据窗口，但不会反过来使先前的超阈值观察失实。在测量数据覆盖所讨论的时间区间前，有关持续时长的问题应保持未解答状态。

审核边界与常见错误

检查拟议假设是否保留 evt_b、将 inventory 依赖标记为未知，并说明 evt_a 的第二次投递。凡是编造 inventory 部署、悄然删除健康探测，或没有额外证据就给出因果陈述的草稿，都应拒绝。

不要将告警数量等同于故障数量。不要将遥测缺失当作健康测量结果。调查延迟投递时，应区分观察时间和接收时间。如果各数据来源的时钟存在偏差，解读分组前可能需要校正看似成立的先后顺序。

如果已知规则已经明确下一项检查，应采用现有运维流程。本示例不适用于无人值守的运维事件结案、自动回滚，或需要尚未获得遥测数据的决策。这里没有声称任何故障检测率、诊断准确率或成功响应结果。

相关术语与后续参考

LLM 可观测性讨论模型请求的证据，而不是跨服务故障关联。人工智能中的产生式系统介绍选择行动的明确规则。智能体规划讨论调查步骤之间的依赖关系。

对于定期根据来源导出数据生成的报告，应遵循报告自动化，而不要将故障假设当作报告中的计算结果。构建器故障可参考 Workflow 故障排查。