智能微服务治理：让 AI 参与告警聚合，而不是替人拍板

智能微服务治理：让 AI 参与告警聚合，而不是替人拍板

一、微服务告警多，不等于系统更可观测

微服务规模扩大后，告警数量很容易失控。一个数据库抖动可能引发几十个服务错误率上升，一个网关超时可能让下游服务同时报警。值班同学真正需要的不是更多告警，而是更快理解“哪些告警属于同一个事件，影响范围是什么，第一条异常在哪里”。

AI 可以参与告警聚合，但不应直接替人判断根因。模型适合做事件归并、文本摘要、变更关联和排查建议生成；最终根因仍要通过指标、日志、Trace 和变更记录验证。智能治理的目标，是减少人工在信息整理上的消耗，而不是把决策责任交给模型。

二、事件聚合：先对齐时间、拓扑和变更

flowchart TD A[指标告警] --> D[事件聚合器] B[日志异常] --> D C[Trace 慢调用] --> D E[发布变更] --> D D --> F[事件簇] F --> G[AI 摘要] G --> H[值班人员验证]

事件聚合要先做确定性处理。可以按照时间窗口、服务拓扑、traceId、错误码、调用方向和最近变更，把零散告警归并成事件簇。只有聚合后的上下文足够干净，模型生成的摘要才有价值。否则把一堆无关告警丢给模型，只会得到看似流畅但不可验证的结论。

拓扑关系尤其重要。假设订单服务调用库存服务超时，订单服务和网关都会报警，但根因可能在库存服务或数据库连接池。聚合器要识别调用链上的上游和下游关系，把“被影响服务”和“疑似源头服务”分开展示。模型可以解释关系，但不应该凭文本猜拓扑。

三、聚合上下文：输入给模型前先结构化

下面是一个简化的事件上下文对象。实际项目中可以把它序列化为 JSON，作为模型分析的输入。

public record IncidentContext( String incidentId, Instant startTime, List<String> affectedServices, List<String> suspectedSources, List<MetricPoint> abnormalMetrics, List<TraceSample> slowTraces, List<ChangeEvent> recentChanges, List<String> topErrorMessages ) {}

模型接收这类结构化上下文后，输出也要结构化。建议要求它返回“摘要、影响范围、证据列表、根因候选、下一步验证动作”。其中证据列表必须引用输入里的具体指标、日志或变更事件，不能只写泛泛判断。没有证据引用的结论，应在页面上降低置信度。

为了降低误判，可以给模型明确约束：不能声明唯一根因，只能给候选；不能建议高风险操作，如重启集群或回滚全部服务；不能使用输入中不存在的信息。约束越清楚，AI 摘要越容易被值班团队接受。

四、落地边界：从低风险告警开始试点

智能告警治理建议从低风险场景开始，例如非核心服务延迟升高、缓存命中率下降、批处理任务失败、单机实例异常。先验证事件聚合质量、摘要准确率和排查动作可执行性，再逐步扩展到核心交易链路。

评估指标不要只看“模型回答像不像专家”。更应该看平均告警归并率、首次定位时间、无效告警减少比例、AI 建议被采纳率和误导性建议比例。尤其是误导性建议，一旦过高，就要回到输入证据、Prompt 约束和事件聚合规则上重新设计。

组织流程也要配合。AI 输出可以成为值班页面的一部分，但值班记录仍应由人确认。故障复盘后，把真实根因、有效证据和无效线索回写到案例库，让下一次模型能基于已验证经验生成更好的建议。

五、总结

AI 参与微服务治理的价值在于聚合信息、整理证据和生成排查候选，而不是替人拍板。把告警、拓扑、Trace、日志和变更先结构化，再让模型总结，才能让智能治理在生产环境中真正可用。