AIOps 根因置信度：模型说像，不代表就是它
一、根因分析不能只看相似度
AIOps 系统常会根据历史事故、指标异常和日志模式给出根因建议。模型可能说“这次很像数据库连接池耗尽”，但像不等于就是。生产排障里，错误根因比没有根因更危险，因为它会把值班人员带向错误动作。
根因建议必须带置信度、证据和反证条件。
二、先定义证据类型
flowchart TD A[故障事件] --> B[指标异常] A --> C[日志错误] A --> D[变更记录] A --> E[拓扑影响] A --> F[历史相似]不同证据权重不同。历史相似只能提示方向，实时指标和拓扑传播更接近当前事实。变更记录要看时间窗口，不能把所有近期发布都当嫌疑。
root_cause_evidence: metric_anomaly: high topology_propagation: high log_pattern: medium history_similarity: low recent_change: medium证据权重透明，值班人员才知道系统为什么这样判断。
三、置信度要可解释
置信度不是一个孤立分数。它应该说明哪些证据支持结论，哪些证据缺失，哪些反证会推翻结论。
candidate_root_cause: cause: redis_latency_spike confidence: 0.72 supporting: - p99_latency_rise - downstream_timeout missing: - redis_slowlog_sample如果关键证据缺失，系统应该建议下一步采集，而不是直接下最终结论。
四、排障动作要分级
高置信根因可以推荐明确动作，低置信根因只应该推荐只读检查。比如查看慢日志、查看连接数、查看最近发布，比自动重启服务安全得多。
action_policy: confidence_high: allow_safe_mitigation confidence_medium: suggest_readonly_check confidence_low: collect_more_evidence还要记录人工反馈。值班人员确认或否定根因后，系统要回收这次反馈，用于后续模型和规则优化。
最后，AIOps 根因分析要接受“不确定”。不确定时说明还缺什么，比自信地给错答案更专业。
根因候选还要排序展示。一个事故可能同时出现缓存延迟、接口超时和错误率上升，系统应该说明第一候选、第二候选和它们之间的因果关系。比如缓存延迟是上游，接口超时是下游症状，就不能把两者当并列根因。
root_cause_candidates: - cause: cache_latency_spike rank: 1 role: upstream - cause: api_timeout rank: 2 role: symptom还要给出验证命令或查询入口。值班人员看到候选根因后，能一键跳到对应仪表盘、日志查询或变更记录，而不是重新拼查询语句。
最后，根因置信度要随时间更新。事故刚开始证据不足，置信度可能只有 0.4；随着更多指标和日志进入，判断应该动态变化。静态结论很容易过期。
五、总结
AIOps 根因置信度要基于实时指标、日志、拓扑、变更和历史相似共同计算，并解释证据和反证。
模型说像，不代表就是它。生产排障需要的是可验证结论，不是猜测包装。
