AI 基础
什么是AIOps？面向IT运维的人工智能
将 Unite.AI 添加到您在 Google 上的首选来源
AIOps 将机器学习和自动化应用于 IT 运维数据，使团队能够检测异常行为、减少重复警报、关联相关事件、对可能的原因进行排序，并推荐或执行响应操作。
AIOps 并不是对运维的自主替代。它是 ITOps 系统中的一层，其价值取决于遥测数据质量、服务拓扑、变更历史、人为反馈以及安全自动化边界。
关键要点
- 在应用复杂模型之前，先对事件进行标准化并添加服务上下文。
- 异常检测识别偏差，并不一定意味着故障或根本原因。
- 关联与可能原因排序应展示证据和不确定性。
- 自动化修复需要最小权限、审批、金丝雀、回滚以及结果监控。
构建运营数据层
AIOps 平台会摄取指标、日志、追踪、警报、工单、拓扑、部署和配置变更。时间戳、标识符和服务所有权必须统一，以便系统能够关联指向同一事件的信号。
缺失或不一致的上下文会导致错误关联。数据保留、访问和隐私同样重要，因为日志中可能包含凭证或个人信息。应遵循其他生产数据系统的治理要求。
检测与噪声消除
静态阈值适用于已知限制；统计和 机器学习 方法可以对季节性或多变量模式进行建模。去重将重复通知归为一组，而抑制则根据定义的规则删除不可操作的警报。
异常仅是对预期行为的偏离。计划发布、流量活动和业务周期可能看起来异常，但却是健康的。应评估精确率、召回率、检测延迟和运维人员工作负荷，而不是仅仅庆祝删除的警报数量。
关联与可能原因
事件关联在依赖图和时间窗口内链接症状。可能原因模型可以对可能解释事件的组件或近期变更进行排序。这有助于调查优先级，但并不等同于因果关系。
展示贡献证据、备选假设和置信度。可解释 AI 在运维人员需要决定是否隔离服务或回滚部署时尤为重要。
从推荐到自动化
运行手册可以收集诊断信息、重启无状态工作者或扩容容量。协助系统可以对事件进行概述并检索操作流程。代理可以规划工具调用，但生产权限应当受限，且操作需与当前状态进行验证。
从只读推荐开始。通过仿真、人工批准、金丝雀和自动回滚提升成熟操作。记录每次操作的输入、模型版本、授权和结果。
评估与运营反馈
在不将最终标签泄露到特征中的前提下回放历史事件。对新服务和变更进行测试，衡量误抑制、检测时间、缓解时间、运维人员接受度和复发率。与现有规则和简单基线进行比较。
当架构、流量或响应实践发生变化时会出现漂移。通过让运维人员纠正关联和结果来闭环，然后审查系统是否在降低重复劳动的同时未隐藏风险或导致自动化自满。
AIOps 数据与分析流水线
AIOps 对运营数据（如指标、日志、追踪、事件、拓扑、工单和变更）应用统计和机器学习方法。流水线收集并标准化信号，以服务和所有权上下文进行丰富，检测异常，关联相关事件，估计可能原因，并推荐或触发行动。质量取决于时间戳、标识符、拓扑和变更记录。模型若面对名称不一致的同一服务，无法可靠地关联警报。
异常检测通过服务、季节和运行状态学习基线；已知安全阈值的场景下静态阈值可能更合适。事件关联利用时间、拓扑、文本和历史模式将症状归为同一事件。根因排序提出假设，但可能将首次观察到的故障误认为真实原因，或遗漏拓扑中缺失的共享依赖。自然语言摘要可以帮助响应者，但必须链接到原始证据并说明不确定性。
自动化、评估与反馈
从决策支持和低风险可逆修复开始。每一次自动化操作都需要授权、前置条件、受限范围、超时、后置条件验证、回滚以及审计日志。模型不得自行获取凭证或将日志文本视为可信指令。人工响应者应接受、拒绝或纠正推荐，并通过审查将这些结果更新到规则或训练数据，而非进行不受控的自学习。
评估在不遗漏事件的前提下降低警报数量，衡量检测前置时间、关联精度、根因排序、修复成功率、恢复时间、复发率以及响应者工作负荷。使用历史回放和注入故障进行测试，但要考虑事件标签不完整的情况。按服务和事件类型进行度量；平均值可能掩盖关键系统的严重故障。与确定性规则和改进的可观测性进行比较后，再引入 AI 复杂度。
治理与失效模式
AIOps 可能放大遥测盲点、自动化错误诊断，或产生全 fleet 关联操作。应隔离环境、限制并发、在模型外维护紧急关闭开关，并演练 AIOps 平台本身的失效。保护包含机密或个人数据的日志和工单。监控模型漂移、拓扑新鲜度、错误操作和覆盖。AIOps 在让证据与受限行动更快的情况下支持可靠运营；但它并非对服务所有权、事件指挥或工程判断的自主替代。
案例演示：AIOps 在支付事件中的应用
AIOps 将 API 错误激增、数据库饱和和地区警报归为同一事件，并结合最近的部署、拓扑和所有者信息进行丰富。它将该部署排为可能的贡献者，同时展示原始遥测和备选方案。确定性策略暂停进一步发布；人工事件指挥官在确认容量和数据一致性安全后批准流量切换。
系统在历史回放和演练日中衡量分组精度、检测前置时间、排序准确性、响应者接受度、恢复情况以及错误修复。所有自动化操作都有限制、幂等性、后置检查和回滚。日志已被清理，恶意文本无法成为指令。事件结束后，确认的原因和行动结果会更新已审查的规则和评估数据。AIOps 平台帮助提供证据和协作，但永远不会取代事件指挥或外部授权。
实施证据与运营准备度
生产决策需要的不仅是成功演示。必须定义预期用户、运行环境、输入、输出、依赖、所有者以及每个关键失效的后果。建立可复现的基线和版本化的评估集后再进行调优。测试常规案例、边界条件、格式错误或缺失的输入、分布漂移、依赖中断、误用以及最可能被忽视的群体或环境。将任务质量与校准或不确定性、延迟、吞吐量、资源成本、可访问性、隐私和安全一起衡量。记录每一次转换和阈值，以便独立审查员能够复现结果并区分证据与吸引人的原型。
上线前，指定发布、例外、变更、回滚和退役的授权。使用分阶段发布，保留安全回退，并通过有意注入的故障验证监控。运营遥测应揭示输入质量、输出行为、模型或规则版本、依赖健康、人工覆盖以及确认的结果，同时避免收集不必要的敏感数据。定义警报阈值和响应负责人，然后在部署后审查真实世界的证据，而不是假设离线表现会持续。每当数据源、用户、模型、供应商、政策、硬件或目标变化时都要重新评估。维护中的系统还需要有文档化的恢复、事件学习、删除和保留流程，以及明确的停用或替代时点。
常见问题
AIOps 与可观测性是同一概念吗？
不是。可观测性提供并探索系统信号；AIOps 在这些信号之上使用分析和自动化。两者可以独立存在。
AIOps 能自动确定根本原因吗？
它可以对假设进行排序并收集证据，但因果判断需要拓扑、变更上下文和验证。许多事件存在交叉原因。
主要参考文献
