告警根因分析

告警风暴的本质是依赖传导：数据库慢了，上面十几个服务全报超时，再往上的网关也报。值班工程师面对几十条告警，要做的第一件事是找出哪一条是首发。

同时还得去翻当天有没有发版、有没有配置变更、有没有人在改数据。这些信息在三个不同的系统里。等把上下文拼齐，故障已经持续了二十分钟。

工作流用 HTTP 请求节点从监控系统拉取时间窗内的告警，先经代码执行节点按服务维度和时间邻近度归并同源告警。

顺序很重要。不做归并直接把几十条塞给模型，Token 烧掉不说，结论也是散的——模型会认真地逐条分析每一个次生告警。

用数据库节点（只支持 SELECT，只读连接）查同期发布记录、配置变更与工单。

绝大多数线上故障与变更相关。把变更时间线和告警时间线对齐之后，根因范围通常能立刻收敛到很小。这一步技术含量不高，但在紧急状态下最容易被跳过——人在压力下倾向于直接扑向最显眼的那条告警。

让流程固定做这件事，是自动化在这个场景里最实在的价值。

服务依赖拓扑整理成结构化知识库。代码执行节点按拓扑做因果排除：下游服务的超时告警，若时间上晚于上游故障且存在依赖关系，标记为次生，不进入根因候选。

这是确定性推理，有明确规则可循，不该交给模型判断。模型在这里的角色是最后一步——拿收敛后的首发故障点和关联上下文，输出根因判断、影响面、分步处置建议，并说明判断依据。

配定时任务按周汇总高频故障、平均恢复时长、变更相关性与趋势。

同一个坑反复踩，通常不是因为没人发现，是因为没人把散落在二十次值班记录里的模式聚起来看。这份周报的价值在这里。