AIOps SOP

评估现状与识别痛点

Assess & Identify

• 基础设施评估
  • 软件、硬件、云服务、网络拓扑、现有的监控和自动化工具
• 数据源盘点
  • 识别所有潜在的可观测性数据源，例如监控日志、指标、分布式追踪、服务依赖关系图、以及ITSM工单等。
• 痛点识别
  • 通过与开发、运维和SRE团队访谈，量化当前最主要的运维痛点
  • 告警疲劳（每天收到多少“噪音”告警）？
  • 平均故障解决时间（MTTR）过长？
  • 频繁的、重复性的人工干预任务有哪些？
  • 面对新问题时，故障排查耗时多久？

对齐业务目标

AIOps不是为了技术而技术，它的最终目的是服务于业务。将技术目标与明确的业务成果挂钩是成功的关键。

• 定义业务成果
  • 明确AIOps项目希望驱动的业务指标。
  • 例如：
    • 将核心服务的停机时间减少20%。
    • 将新功能发布的失败率降低50%。
    • 提升最终用户满意度分数。
• 设定可衡量的技术目标 (SLO)
  • 将业务成果转化为技术团队可以执行的服务水平目标（SLO）
  • 例如
    • “99.95%的登录请求必须在200ms内完成”。

选择合适的工具与平台

• 平台选型
  • 数据集成能力
  • 模型透明度
  • 自动化能力
  • 安全性
• 构建数据基础
  • 规划数据架构
  • 例如
    • 实施一个集中的数据湖架构来统一数据摄入，并使用AI驱动的数据规范化技术来清洗和结构化原始遥测数据，以提高分析的准确性。

规划分阶段实施

• 阶段一：AI辅助分析与建议:
  • 目标：减少告警噪音，提供关联性洞察。
  • 行动：首先使用AIOps平台进行事件关联和异常检测，将结果作为“建议”推送给运维团队，但不自动执行任何变更。
• 阶段二：半自动化（人机协同）:
  • 目标：加速已知问题的修复。
  • 行动：对于重复出现的、解决方案明确的问题，让AIOps系统自动生成修复计划，并等待人工点击“确认”后执行。
• 阶段三：有限的完全自动化:
  • 目标：实现低风险场景的自主修复。
  • 行动：授权AIOps系统在预定义的、低风险的场景下（例如，清理磁盘、重启非核心服务的某个实例）自主执行修复，无需人工干预。
• 阶段四：迈向更广泛的自主运维:
  • 目标：处理更复杂的、甚至是未知的问题。
  • 行动：在建立了充分的信任和完善的治理机制后，逐步扩大AIOps系统的自主决策和行动范围。

培训团队与推动变革

• 技能培训: 对DevOps和SRE团队进行新工具和新流程的培训。
• 文化建设: 清晰地向团队传达AIOps带来的好处（例如，减少重复性劳动、让工程师能专注于更有创造性的工作），以获得团队的认同和支持。
• 角色演变: 引导运维工程师的角色从“手动执行者”转变为“自动化流程的监督者和优化者”。

执行与治理

• 实施治理控制: 确保始终有人类监督AI驱动的决策，特别是在初期阶段。
• 安全优先:
  • 使用零信任架构和基于角色的访问控制（RBAC）来严格限制AI智能体可以执行的变更范围。
  • 所有由AI执行的操作都必须留下不可篡改的审计日志。

监控、衡量与优化

• 监控AIOps系统本身: 像对待任何一个生产系统一样，监控AIOps平台的性能和健康状况。
• 建立反馈循环:
  • 创建一个机制，让工程师可以方便地评估AI决策的准确性和有效性（例如，对告警场景标记“误报”或“准确”）。
  • 定期（例如每两周）召开复盘会议，回顾AIOps系统的表现，并根据工程师和真实用户反馈来微调自动化策略。
• 持续优化: 将反馈数据用于模型的再训练和算法的优化，使系统随时间推移变得越来越智能。