AIOps 异常检测与根因分析

• 告警降噪聚合（AIOps 基础）
• 故障根因分析（RCA）
• 业务指标异常预判（预测）

AIOps 三大核心能力是「告警降噪聚合、故障根因分析、业务指标异常预判」。① 告警降噪聚合——把海量告警「降噪 + 聚合」为「少数高价值告警」：用「聚类、关联、去重、抑制」消除「告警风暴/误报」，只保留「根因相关、可行动」的告警；降低「值班噪音」，是 AIOps 的「基础与入口」。② 故障根因分析（RCA）——用「AI 分析」定位「故障根因」：结合「指标、日志、trace、拓扑、变更」，用「关联分析、因果图、图神经网络」推断「根因」；从「告警降噪的结果」出发，定位「哪个服务/变更/组件」是根因，缩短「MTTR」。③ 业务指标异常预判——用「异常检测 + 预测」预判「业务指标的异常趋势」：用「时序异常检测（STL/Prophet/机器学习）」检测「指标异常」，用「预测」预判「未来趋势（如容量不足、即将故障）」；在「业务受影响前」预警，实现「预防」。落地路径：① 先「告警降噪」——解决告警噪音；② 再「根因分析」——加快定位；③ 后「异常预判」——实现预防；这是「从被动到主动到预防」的 AIOps 演进路径。落地需「数据基础（指标/日志/trace 归一化）+ 算法（检测/聚类/图）+ 平台（告警/分析/可视化）」。价值：降噪提升效率、根因缩短 MTTR、预判实现预防——AIOps 让「运维从被动响应到主动预防」。

AIOps 三大能力是「降噪（基础）+ 根因（定位）+ 预判（预防）」，是「被动→主动→预防」的演进。落地靠「数据基础 + 算法 + 平台」，按「先降噪、再根因、后预判」顺序实施。价值是「提升效率、缩短 MTTR、预防故障」。

• 因果图（RCA 的因果推理）
• 关联规则（相关性分析）
• 图神经网络（微服务拓扑）

基于 AI 的根因分析用「因果图、关联规则、图神经网络」在微服务排障中定位根因。① 因果图——用「因果推理」定位「因果根因」而非「相关根因」：构建「指标间的因果图（如 PCM、DAG）」，分析「哪个指标的异常『导致』其他指标异常」；区分「因果」与「相关」，定位「真正的根因」；② 关联规则——用「关联分析」发现「指标/告警间的关联模式」：如「某告警与某变更/指标强相关」，用「规则」推断「根因可能是谁」；关联规则「快但弱」（相关≠因果），适合「初筛」；③ 图神经网络（GNN）——用「微服务拓扑图」建模「服务依赖」，用「图神经网络」学习「故障传播」：从「异常服务的拓扑」出发，用「传播模型」推断「根因服务」；GNN 能利用「拓扑结构」捕捉「故障传播」，适合「微服务的依赖传播」；④ 结合——① 用「拓扑/图」建模「服务依赖」；② 用「关联/因果」分析「指标关系」；③ 用「变更/日志」补充「证据」；综合「拓扑 + 因果 + 关联」定位根因。价值：微服务排障中「故障传播复杂」，AI RCA 用「图（拓扑）+ 因果（根因）+ 关联（证据）」快速定位「根因服务」，避免「人工逐服务排查」。落地用「因果图 + GNN + 关联规则」结合「指标/日志/变更」，输出「根因候选 + 证据」，由人工确认。核心是「从相关中找因果，从拓扑中找传播，定位根因」。

AI RCA 的核心是「从相关到因果 + 从拓扑到传播」。因果图定位「因果根因」、关联规则「初筛」、GNN「利用拓扑推断传播」。综合「图 + 因果 + 关联」在微服务中定位根因，缩短 MTTR。输出「根因候选 + 证据」人工确认。

• 告警压缩（去重聚合）
• 告警关联（根因分组）
• 告警预测、根因推荐、自动降噪

智能告警的核心能力包括「压缩、关联、预测、根因推荐、自动降噪」。① 告警压缩——把「重复/相似告警」压缩为「一条」：用「指纹、时间窗、去重」合并，减少「告警数量」，避免「风暴」；② 告警关联——把「同根因的告警」关联为「一组」：用「时间、拓扑、指标、聚类」把「相关告警」分组，识别「一个根因引发多条告警」，展示「关联告警」；③ 告警预测——用「预测」提前预警「可能发生的告警」：用「时序预测/机器学习」预测「指标趋势」，在「故障发生前」预警（如「容量预测不足」）；实现「预防」；④ 根因推荐——基于「关联 + 分析」推荐「根因」：告警到达时推荐「可能的根因（服务/变更/组件）」与「处置建议」，辅助值班「快速定位」；⑤ 自动降噪——用「算法」自动「降低噪音」：动态基线、智能过滤、误报识别，自动「抑制无效告警」，只保留「有效告警」；降噪让「告警质量」提升。整合：① 压缩「减少数量」；② 关联「识别根因」；③ 预测「提前预防」；④ 根因推荐「辅助定位」；⑤ 降噪「提升质量」；共同实现「智能告警」——「告警少而准、有根因、能预判」。价值：智能告警让「值班从被告警淹没」到「聚焦高价值告警 + 有根因推荐」，提升「响应效率」。落地用「AI 算法 + 规则引擎 + 告警平台」组合。

智能告警的核心能力是「压缩（减量）+ 关联（分组）+ 预测（预防）+ 根因推荐（定位）+ 降噪（提质）」。这些能力让告警「少而准、有根因、能预判」，是「AIOps 的告警侧」能力。落地靠「AI + 规则 + 平台」。

• 各算法的原理与适用场景
• 局限（趋势、季节、规模）
• 算法选型

AIOps 时序异常检测算法各有「适用场景与局限」。① STL 分解——把时序「分解为趋势 + 季节 + 残差」，对「残差」检测异常；适用「有周期性的时序」（如 QPS 日规律）；局限「对非平稳/突变敏感、需调参」；② Prophet——Facebook 的「可加模型」，擅长「趋势 + 季节 + 节假日」建模；适用「有季节与节假日效应的业务指标」；局限「对高频/复杂模式弱、需足够数据」；③ ARIMA——传统「统计时序模型」，适合「平稳/线性」时序；局限「对非平稳、复杂非线性弱、需人工判断平稳性」；④ LSTM——「深度学习」时序模型，能捕获「复杂非线性、长依赖」；适用「复杂模式、高维」；局限「需大量数据、训练成本高、可解释性差」；⑤ Isolation Forest——「无监督异常检测」，基于「孤立性」找异常点；适用「无标签、高维特征」的异常点检测；局限「不直接利用时序结构（需特征工程）、对时序模式不敏感」。选型：① 有「季节/趋势」→ STL/Prophet；② 简单「平稳」→ ARIMA；③ 「复杂非线性」+ 数据足 → LSTM；④ 「无标签异常点」→ Isolation Forest。局限共性：① 时序异常检测「误报/漏报」难平衡；② 需「数据质量与调参」；③ 对「突变/新规律」可能误判。落地「组合 + 人工校准」——用多算法 + 人工确认降低误报。核心是「按数据特征选算法 + 理解局限 + 调参校准」。

时序异常检测算法选型按「数据特征」：STL/Prophet 适合季节趋势、ARIMA 适合平稳、LSTM 适合复杂非线性、Isolation Forest 适合无标签异常点。局限是「误报、调参、非线性」。落地「组合 + 校准」降低误报。

• 指标数据的异常检测可用性
• trace 数据的异常检测可用性
• log 数据的异常检测可用性

AIOps 异常检测在「指标、trace、log」三种数据源上的可用性差异明显。① 指标（Prometheus）——可用性最高：指标是「数值型、结构化、时序」数据，天然适合「时序异常检测算法」（STL/Prophet/机器学习）；能检测「突发、趋势、异常」；是「AIOps 异常检测」最成熟的数据源；① 优点——结构化、易计算、时序规律明显；② 局限——只能是「聚合指标」，无法看到「单请求细节」；② trace——可用性中等：trace 是「调用链数据」，异常检测可针对「span 的延迟、错误、某服务」；① 优点——能定位「哪个环节慢/错」；② 局限——数据量大、采样、结构复杂，异常检测需「聚合 trace 为指标」或「检测 trace 结构异常」，较复杂；③ log——可用性低但价值高：log 是「非结构化文本」，异常检测难（需「日志解析、语义分析」）；① 优点——包含「错误细节、根因信息」；② 局限——非结构化、噪声多、需「日志解析/NLP/LLM」处理，误报率高；近年来用「LLM 做日志语义分析与异常检测」提升可用性。落地差异：① 指标——用「时序算法」直接检测，成熟；② trace——「聚合为指标」或「检测 trace 模式」；③ log——「解析 + 语义（LLM）」检测，最复杂。价值：指标「易上手但只见聚合」，trace「定位链路」，log「挖掘细节但难」。AIOps 落地「先指标（易）、再 trace（定位）、后 log（细节）」，按「可用性」分阶段。

三种数据源可用性差异是「指标（成熟）> trace（中等）> log（难）」。指标结构化适合时序算法、trace 需聚合、log 需解析语义。落地「先指标、再 trace、后 log」，按可用性分阶段。log 价值高但技术难。

• AIOps 落地顺序（压缩→根因→预测）
• 各阶段的收益
• 收益评估

AIOps 落地应「分阶段、由易到难」，按「先告警压缩、再根因关联、后预测预防」实施。① 阶段一：告警压缩——先解决「告警噪音/风暴」：用「去重、聚类、关联」压缩告警，降低「值班噪音」；收益「快、可量化」——告警数量下降、值班响应提升；是「基础」——干净的告警是「后续根因分析的前提」。② 阶段二：根因关联——再「根因分析」：在「压缩后的告警」基础上，用「关联 + 因果 + 图」定位「根因」；收益「显著」——MTTR 下降、定位加快；需要「告警/指标/拓扑/变更」数据。③ 阶段三：预测预防——最后「预测预防」：用「时序预测/机器学习」预判「业务指标异常、容量、故障」；收益「最高但最难」——实现「预防」；需要「高质量历史数据 + 成熟模型」。收益评估：① 告警压缩——告警减少率、误报率下降、值班响应时间；② 根因关联——MTTR 降低、根因定位准确率、定位时间；③ 预测预防——异常提前发现率、预防的事故数、预警准确率。实施顺序的理由：① 先「压缩」——干净的告警是「根因分析」的基础，且收益快「建立信心」；② 再「根因」——在「压缩后」基础上做「根因」，价值高；③ 后「预测」——需求最高、最复杂，最后做。核心是「循序渐进」——先易后难、先基础后高级，每阶段「可量化收益」，避免「一刀切投入高级 AI」。落地评估「每阶段 ROI」驱动「推进」。

AIOps 落地顺序是「压缩→根因→预测」，由易到难、层层递进。压缩是基础（干净告警）、根因是价值（缩 MTTR）、预测是预防（最复杂）。每阶段收益可量化，循序渐进避免「投入过高风险」。收益评估驱动推进。

• LLM 的日志语义理解
• LLM 的因果推理（根因）
• 自愈闭环（LLM 驱动）

LLM 在日志分析与根因定位中用于「语义理解、因果推理、自愈闭环」。① 语义理解——LLM 理解「日志语义」：把「非结构化日志」解析为「语义」：① 日志摘要——把海量日志浓缩为「摘要」；② 日志分类——按「错误类型/语义」分类；③ 日志关联——识别「语义相似」的日志；LLM 用「语义」理解日志，优于「关键词/正则」。② 因果推理——LLM 做「根因推理」：结合「日志、指标、告警、变更、上下文」用「推理」推断「根因」：① 综合多源证据——把 log/指标/变更「喂给 LLM」推理；② 因果链——LLM 推断「先后因果」；③ 根因候选——输出「根因 + 证据 + 置信度」；LLM 的「推理能力」辅助「根因定位」。③ 自愈闭环——LLM 驱动「自愈」：① 定位根因后「推荐处置」；② 对「已验证/低风险」的处置「自动执行」（如自动重启、回滚、扩容）；③ 用「反馈」验证「处置是否有效」；④ 把「成功处置」沉淀为「runbook/自动化」；形成「检测 → 定位 → 处置 → 验证 → 沉淀」的「自愈闭环」。设计要点：① LLM 推理「需证据」——要求「引用证据 + 置信度」，防「幻觉」；② 高风险处置「人工确认」——LLM 建议、人工执行关键动作；③ 反馈「闭环优化」——LLM 的处置结果反馈，优化「后续推理」。价值：LLM 提升「日志理解与根因推理」效率，并驱动「自愈闭环」，缩短「MTTR」。落地用「LLM + RAG（检索历史/runbook）+ 证据 + 人工确认」。

LLM 在日志/根因中的用法是「语义理解（摘要分类）+ 因果推理（综合证据）+ 自愈闭环（检测-定位-处置-验证）」。关键要「证据 + 置信度 + 人工确认」防幻觉，高风险处置人工确认。LLM 提升效率、驱动自愈。

• 告警聚合的维度（主机/服务/时间窗）
• 智能降噪（动态基线）
• 工程实现

告警聚合与智能降噪的工程实现用于「减少告警噪音」。① 告警聚合——按「维度」把相关告警「合并」：① 按主机——同一主机/节点的告警聚合：一个主机故障引发「CPU/内存/磁盘」多条告警，聚合为「一条主机告警」；② 按服务——同一服务的告警聚合：一个服务故障引发「延迟/错误/可用性」多条告警，聚合为「一条服务告警」；③ 按时间窗——同一时间窗的告警聚合：突发故障在短时间内引发多条告警，按「时间窗」聚合为「一条」；实现——用「分组键（group_by：主机/服务）+ 时间窗（group_wait/interval）」合并，Alertmanager 等支持。② 智能降噪（动态基线）——用「动态基线」代替「固定阈值」：① 动态基线——根据「历史/趋势」自适应计算「正常基线」（如按「日/周」周期动态调整），超过「动态基线」才告警；② 相比「固定阈值」——动态基线「适应业务波动」（如高峰/低谷），减少「误报」（固定阈值在波动时误报）与「漏报」（固定阈值在低峰漏报）；③ 实现——用「时序算法（STL/Prophet/机器学习）」计算「动态基线 + 置信区间」，异常检测「超出置信区间」告警。工程实现：① 告警聚合——「分组 + 时间窗」合并，减少数量；② 动态基线——「算法计算基线 + 异常检测」，减少误报漏报。价值：聚合「减少重复告警」、动态基线「减少误报漏报」，两者共同「智能降噪」——「告警少而准」。落地用「告警引擎（分组聚合）+ 算法（动态基线）」组合。

告警聚合的工程实现是「按主机/服务/时间窗分组合并」，智能降噪用「动态基线（算法算基线 + 异常检测）」。聚合减少重复、动态基线减少误报漏报。两者是「告警降噪」的工程实现，让告警「少而准」。

• Precision/Recall/F1（检测准确率）
• MTTD（平均检测时间）
• False Positive Rate（误报率）

异常检测的评估指标用于「衡量检测效果」。① Precision（精确率）——检测出的异常中「真正异常」的比例（TP/(TP+FP)）；高 Precision 说明「误报少」；② Recall（召回率）——真正的异常中「被检测出的比例」（TP/(TP+FN)）；高 Recall 说明「漏报少」；③ F1——Precision 与 Recall 的「调和平均」，综合「检测质量」；F1 越高越好。④ MTTD（Mean Time To Detect，平均检测时间）——从「异常发生」到「被检测到」的时间；MTTD 越短说明「越早发现」；反映「检测的及时性」。⑤ False Positive Rate（误报率）——「正常被误判为异常」的比例（FP/(FP+TN)）；误报率低说明「噪音少」；与「报警疲劳」相关。评估权衡：① Precision vs Recall——提高 Precision（少误报）可能降低 Recall（漏报），需「平衡」；② MTTD vs 误报——越早检测（MTTD 短）可能误报多，需「平衡」；③ 实际中「业务优先」——对「关键故障」重 Recall（不漏报）、对「噪音敏感」重 Precision（少误报）。落地：① 用「标注数据」计算 Precision/Recall/F1；② 用「时间戳」计算 MTTD；③ 用「正常样本」计算误报率；综合「Precision/Recall/F1 + MTTD + 误报率」评估「异常检测模型」。核心是「用多指标评估，理解权衡，按业务选择」。

异常检测评估指标是「Precision/Recall/F1（质量）+ MTTD（及时性）+ 误报率（噪音）」。需理解「Precision vs Recall」「MTTD vs 误报」的权衡，按业务侧重选择。综合多指标评估模型效果。

• 各检测方法的特点（3-sigma/EWMA/Prophet/深度学习）
• 选型依据
• 误报治理

时序异常检测在监控中的选型需「按数据与需求」，并治理误报。① 3-sigma——基于「均值 ± 3σ」，检测「偏离均值 3 个标准差」的点；简单、易理解；局限「假设正态分布、对趋势/季节不敏感、易误报」；适合「相对平稳、无强趋势」的指标。② EWMA（指数加权移动平均）——对「近期」加权，「平滑 + 检测」；对「局部突变」敏感；局限「对长期趋势/季节弱」；适合「平滑波动、检测突变」。③ Prophet——「趋势 + 季节 + 节假日」建模；适合「有季节/趋势」的业务指标；局限「需数据、对高频弱」；④ 深度学习（LSTM/自编码器）——捕获「复杂非线性模式」；适合「复杂、高维」；局限「需数据、训练成本、可解释性差」。选型：① 平稳 → 3-sigma/EWMA；② 季节趋势 → Prophet；③ 复杂 → 深度学习。误报治理：① 动态基线——用「动态基线 + 置信区间」代替「固定阈值」，适应波动，减少误报；② 多窗口判断——异常需「持续多窗口」才告警，避免「瞬时抖动」误报；③ 组合确认——「多算法/多指标」交叉确认，减少误报；④ 人工反馈——误报「标注反馈」，校准模型；⑤ 阈值调优——按「误报率」调阈值；⑥ 分级——「疑似」（低优）与「确认」（高优）分级，疑似不打扰。核心：按「数据特征」选算法 + 用「动态基线/多窗口/反馈」治理误报。落地「先简单（3-sigma/EWMA）后复杂（Prophet/深度学习）」，逐步「降误报」。

时序异常检测选型按「数据特征」：平稳用 3-sigma/EWMA、季节用 Prophet、复杂用深度学习。误报治理靠「动态基线、多窗口、组合确认、人工反馈、阈值调优」。落地「先简单后复杂」，逐步降误报。

• 机器建议（AI 输出建议）
• 人工确认（把关）
• 自动化执行（权限分级）

AIOps 与人工的协作边界需「权限划分」，避免「机器全自动」或「机器只建议」。设计：① 机器建议——AI 输出「建议」：告警、根因、处置建议；机器「只建议不执行」（默认）；② 人工确认——关键/高风险「人工确认」：机器建议「需人工确认」才执行；「人工把关」高风险动作（回滚、重启、扩容）；③ 自动化执行——按「风险分级」授权自动化：① 低风险/可逆——「自动执行」（如自动重启高可用实例、自动清除缓存）；② 中风险——「自动 + 人工可视」（自动执行但人工可干预）；③ 高风险——「人工确认才执行」（如回滚、删数据）；权限划分：① 按「动作风险」分级——低风险自动、高风险人工；② 机器「建议」+「人工确认」+「自动化执行」的「权限阶梯」；③ 有「人工紧急停止」——自动化失控可人工接管；④ 审计——自动执行留痕。价值：① 不「全自动」——避免机器误判造成事故；② 不「全人工」——利用机器效率；③ 「权限分级」——低风险自动化、高风险人工，平衡「效率与安全」。设计原则：① 机器「建议」，人工「把关」；② 自动化「从低风险到高风险」渐进；③ 高风险「人工确认」+「可停止」；④ 「审计留痕」。核心是「机器建议 + 人工确认 + 风险分级自动化」的协作边界，平衡「效率与安全」。

AIOps 与人工协作边界是「机器建议 + 人工确认 + 按风险分级自动化」。低风险自动、高风险人工确认、可紧急停止。平衡「效率与安全」，避免「全自动的失控」与「全人工的低效」。审计留痕保障。

• 各场景的 ROI（告警压缩、日志摘要、根因推荐）
• 场景优先级
• 落地选择

AIOps 场景选择按「ROI（投入产出比）」优先落地「高价值、低难度」场景。① 告警压缩——ROI 高：解决「告警噪音/风暴」痛点明显，技术成熟（去重/聚类），投入相对低、见效快；「高 ROI、低难度」→ 优先落地；② 日志摘要——ROI 中高：解决「日志海量难读」痛点，用 LLM 摘要提升「排障效率」；技术（LLM）较新、有一定成本，但价值高；「中高 ROI、中难度」→ 次优先；③ 根因推荐——ROI 高但难：解决「定位根因慢」痛点（缩短 MTTR，价值高），但技术复杂（需数据/模型/拓扑）、落地难；「高 ROI、高难度」→ 有条件时落地。优先级：① 先「告警压缩」——最快见效、建立信心；② 再「日志摘要」——提升排障效率；③ 后「根因推荐」——价值最高但难，逐步投入。ROI 考量：① 价值——痛点强度、对 MTTR/效率的影响；② 难度——数据、技术、人力成本；③ 见效——实施周期、见效速度；选「高价值 / 低难度 / 快见效」的场景优先。落地选择：先做「告警压缩」（ROI 最清晰），再「日志摘要」（LLM 提升效率），最后「根因推荐」（有条件）。核心是「按 ROI 排序，先易后难、先高价值」，避免「投入高难度高级场景却回报慢」。告警压缩是「AIOps 落地的最佳起点」。

AIOps 场景按 ROI 排序：告警压缩（高 ROI 低难度）优先、日志摘要（中高 ROI 中难度）次之、根因推荐（高 ROI 高难度）最后。选「高价值/低难度/快见效」优先，告警压缩是「最佳起点」。按 ROI 决策避免「投入回报慢」。

• 数据的归一化存储
• 统一查询
• 数据工程架构

AIOps 的数据工程核心是「指标、日志、追踪的归一化存储 + 统一查询」，为「AI 分析」提供「统一数据」。① 归一化存储——把三类数据「统一格式、统一存储」：① 统一采集——用「OTel/Collector」统一采集三类数据；② 统一格式——用「统一语义（Resource/Attribute/时间戳）」归一化；③ 统一存储——用「统一存储引擎（如对象存储 + 查询引擎）」或「分而治之（指标用时序库、日志用检索、trace 用 trace 库）但统一接入」；④ 关联标识——统一「trace_id/时间戳」，支撑跨数据「关联」；归一化让「三类数据可统一处理」。② 统一查询——提供「统一查询层」：① 统一查询接口——用「一个查询语言/API」查三类数据（如 PromQL + LogQL 或统一查询引擎）；② 统一数据模型——查询「统一数据模型」而非「各自格式」；③ 跨数据关联查询——「一条查询」关联「指标 + 日志 + trace」；统一查询让「AIOps 分析」方便「取数」。③ 数据工程架构——① 采集层：OTel/Agent 统一采集；② 归一化层：统一格式、关联标识；③ 存储层：统一存储（时序 + 日志 + trace）；④ 查询层：统一查询接口；⑤ 分析层：AIOps 算法消费统一数据。价值：① 统一——三类数据「统一格式、统一查询」，支撑「AI 分析」；② 关联——统一标识支撑「跨数据关联」（指标↔日志↔trace）；③ 高效——AIOps 分析「取数统一」，加速「模型落地」。核心是「归一化 + 统一查询」是「AIOps 的数据基础」——没有统一数据，AI 分析「取数难、关联难」。

AIOps 数据工程核心是「归一化存储（统一采集/格式/关联标识）+ 统一查询（统一接口/跨数据关联）」。归一化让三类数据统一处理、统一标识支撑关联、统一查询方便取数。这是「AIOps 分析的数据基础」。

• AIOps 评估指标（根因准确率、MTTR、误报率）
• 度量方法
• 用指标驱动迭代

AIOps 的评估用「根因定位准确率、MTTR 下降、误报率」等指标，并驱动迭代。① 根因定位准确率——AI 推荐的根因「正确的比例」：① 用「标注/反馈」计算「根因推荐准确率」（AI 推荐的根因是否真是根因）；② 按「Top-1/Top-K」评估（Top-1 准确率、Top-K 覆盖）；③ 反映「AI 根因分析能力」；② MTTR 下降——使用 AIOps 后「MTTR 是否下降」：① 对比「使用前后」的 MTTR；② 分「定位时间」与「恢复时间」；③ 反映「AI 对排障效率的贡献」；③ 误报率——AI 告警/建议的「误报比例」：① 误报率（正常被误判）；② 反映「AI 告警质量」；误报率高导致「报警疲劳」。度量方法：① 用「历史数据 + 标注」评估准确率；② 用「时间戳」统计 MTTR；③ 用「反馈/标注」统计误报率；驱动迭代：① 根因准确率低 → 优化「模型/数据/特征」；② MTTR 未下降 → 分析「AI 落地环节」是否有效；③ 误报率高 → 调阈值/校准模型/加反馈；④ 用「反馈闭环」——AI 结果「人工反馈」标注，持续优化模型；用「评估指标」驱动「AIOps 迭代」。核心是「用指标评估 + 反馈驱动迭代」——AIOps 是「持续优化」的，指标（准确率/MTTR/误报率）驱动「模型与落地」改进。价值：AIOps 不能「上线即完」，需「评估 + 迭代」持续提升。

AIOps 评估指标是「根因准确率（能力）+ MTTR（价值）+ 误报率（质量）」。度量靠「标注 + 时间戳 + 反馈」，驱动迭代靠「反馈闭环 + 指标优化」。AIOps 是「持续优化」——用指标驱动「模型与落地」改进。

• 模型阈值校准（降低误报）
• 反馈标注（人工反馈）
• 误报归因与闭环

AIOps 误报治理需「闭环」，包括「阈值校准、反馈标注、误报归因」。① 模型阈值校准——用「校准」降低误报：① 调整「检测阈值」——按误报率「调高/调低阈值」；② 用「动态基线 + 置信区间」——适应波动，减少误报；③ 「校准」——让「模型置信度」与「实际准确率」一致，避免「高置信度却误报」；阈值校准是「降低误报」的直接手段。② 反馈标注——「人工反馈」驱动优化：① 值班/分析师对「告警/建议」标注「是否误报」；② 用「标注数据」反馈模型；③ 「反馈标注」持续积累「错例」用于「再训练/调优」；反馈是「误报治理」的数据来源。③ 误报归因——分析「误报的原因」：① 归因——误报是「阈值不当」「数据漂移」「模式变化」「模型局限」；② 按「归因」针对性治理——阈值错则调阈值、漂移则回放数据、模型弱则换模型；③ 归因让「误报治理」有针对性。闭环设计：① 告警触发 → ② 人工确认（标注是否误报）→ ③ 误报归因（分析原因）→ ④ 校准/优化（调阈值/再训练）→ ⑤ 验证（误报率下降）；形成「检测-反馈-归因-优化」的「误报治理闭环」。价值：① 降误报——阈值校准 + 反馈优化；② 可持续——归因 + 闭环持续治理；③ 降噪音——误报率下降，减少报警疲劳。核心是「误报治理是闭环」——「反馈标注提供数据、归因定位原因、校准优化模型」，持续降低误报率。落地用「反馈机制 + 归因分析 + 模型调优」。

AIOps 误报治理闭环是「阈值校准（降误报）+ 反馈标注（数据）+ 误报归因（针对性）」。反馈标注提供数据、归因定位原因、校准优化模型，形成「检测-反馈-归因-优化」闭环。持续降低误报率、减少报警疲劳。

• LLM 事件摘要与 Runbook 生成的能力
• 在 On-Call 工作流中的工程边界
• 局限与人工

incident.io/Rootly 用 LLM 做「事件摘要与 Runbook 生成」，在 On-Call 工作流中有「能力与边界」。① 能力——① 事件摘要：LLM 把「事件信息（告警、日志、时间线、上下文）」自动生成「摘要」，供值班快速了解；② Runbook 生成：LLM 基于「历史事件/知识库」生成「处置建议/runbook」，辅助值班处置；③ 时间线自动整理：LLM 整理事件时间线，减少记录负担。② 工程边界——① 建议性：LLM 生成的是「建议/摘要」，非「最终事实」——关键决策需「人工确认」；② 准确性和幻觉：LLM 摘要可能「遗漏/误解」，runbook 可能「幻觉/过时」，需「人工核对」；③ 上下文依赖：LLM 质量依赖「提供的数据/知识库」，上下文不全则「质量下降」；④ 安全：事件信息可能含「敏感数据」，LLM 处理需「隐私考虑」；⑤ 集成边界：LLM 与「值班系统/PagerDuty/K8s」集成，能力受「集成深度」限制；⑥ 高风险动作：LLM 的 runbook 建议「高风险动作」需「人工确认执行」，不自动执行。工程边界设计：① LLM 做「摘要/建议」——辅助值班，不替代决策；② 关键动作「人工确认」；③ 用「知识库/RAG」增强 LLM「准确性」；④ 控制「敏感数据处理」；⑤ 与「值班工作流」集成（告警→摘要→建议→处置）。价值：LLM 提升「值班效率」（摘要 + 建议 + 时间线），但「边界」是「建议性、需人工确认、防幻觉」——LLM 是「辅助」而非「替代」值班。核心是「LLM 辅助值班，但人工把关关键决策」。

LLM 事件摘要/Runbook 生成在 On-Call 的边界是「建议性 + 需人工确认 + 防幻觉」。LLM 提升摘要/建议效率，但关键决策人工把关、重要数据加密、高低风险动作不自动执行。LLM 是「辅助」而非「替代」值班。

• 数据融合（调用链、服务拓扑、日志）
• 同一时间窗的关联
• 关联定位根因

根因分析的数据融合，把「调用链、服务拓扑、日志」在「同一时间窗」关联，定位根因。① 数据源——① 调用链（trace）：单请求的跨服务链路，定位「哪个服务/环节慢/错」；② 服务拓扑：服务间依赖关系，定位「故障传播路径」；③ 日志：具体错误细节，定位「根因细节」。② 同一时间窗关联——用「统一时间基准」对齐三类数据：① 聚焦「故障时间窗」——所有数据在「同一时间窗」内分析；② 用「时间戳对齐」——把「trace 的 span 时间、拓扑的变化、日志的时间」对齐到同一时间窗；③ 用「关联标识」——trace_id/服务名/实例关联；在同一时间窗内「关联」，避免「时间错位」误判。③ 关联定位——综合三源定位：① 调用链——找到「异常 span/服务」；② 服务拓扑——看「该服务在依赖图中的位置、故障是否传播」；③ 日志——看「该服务的具体错误」；④ 综合——「trace 定位异常服务 + 拓扑看传播 + 日志看根因」，在「同一时间窗」内「交叉验证」定位根因。价值：① 完整——单数据源「盲人摸象」，三源融合「完整视图」；② 精准——同一时间窗 + 交叉验证，定位「更准」；③ 高效——减少「逐数据源排查」。落地：① 统一时间窗/对齐时间戳；② 关联标识（trace_id/service）；③ 融合分析（trace 定位 + 拓扑看传播 + 日志看细节）；④ 可视化（同一时间窗展示三源）。核心是「在统一时间窗内，用调用链定位、拓扑看传播、日志看细节，交叉验证定位根因」。

根因数据融合的核心是「同一时间窗 + 三源分工」。调用链定位异常服务、拓扑看传播、日志看根因细节，在统一时间窗内交叉验证。避免「时间错位」与「单源盲区」，精准高效定位根因。