M1 · 分层自适应调查引擎#

简历 Bullet Point: 告警经规则引擎预处理（去重、时间窗聚合、拓扑级联关联）收敛至根因候选集；随后按确定性三级递进——Tier 1 已知故障通过 Runbook 匹配与前置条件校验直接处置，Tier 2 相似故障通过向量检索限定 3 轮定向验证历史根因，Tier 3 未命中时进入 ReAct Agentic Loop 深度调查。各级未命中自动递进至下一级，并继承已有证据。

开场钩子#

场景#

V3 有 fast/deep 双模式，webhook 入口按 severity 预判走哪条——critical 走 deep 全链调查，其他走 fast 轻量分析。上线后发现一个典型误判：某次数据库主从切换，触发了 5 条 warning 级告警（web-api 502、Redis 连接超时、Celery 任务积压、支付回调延迟、下单成功率下跌），每条单独看都只是 warning，全部被分到 fast 模式。fast 模式是单链调查，没有能力把 5 条分散告警关联起来，各自输出了 5 份互不相关的低质量报告——没有一份定位到真正的根因”db-master 切换”。

问题根因不在 fast 模式的分析能力不足，而在于入口选择本身就是错的：Alertmanager 只有告警级别信息，不具备”该花多少算力”的判断力。severity=warning 不代表影响面小——5 条 warning 同时出现的影响面远大于 1 条 critical。这让我意识到：调查深度应该是诊断过程中逐步积累证据后才能做出的决策，不是在信息最贫乏的入口处做的预判。

V4 砍掉了 fast/deep 双模式，换成分层自适应调查引擎：告警先过纯规则预处理层做降噪和拓扑关联，然后进唯一一张 LangGraph 图，Tier 1→2→3 顺序执行、命中即止。“走多深”是图的输出结果，不是调用方的输入参数。

面试官切入#

“你提到了分层自适应——能展开讲讲这个三级递进是怎么工作的吗？“

一、模块运作流程#

1.1 一句话定位#

告警进入调查链路前，先用纯规则（零 LLM）做降噪和拓扑关联，产出结构化的 IncidentContext；然后进唯一一张诊断图，按 Tier 1→2→3 确定性三级递进，命中即止、未命中自动递进并继承已有证据。调查深度是系统的输出结果，不是调用方的输入参数。

1.2 全景流程图（文字版）#

NormalizedAlert (来自 webhook / 手动诊断 API)
    │
    ▼
┌──────────────────────────────────────────────────────────┐
│  L2 预处理层 (纯规则, 零 LLM)                             │
│                                                           │
│  ① 去重 (fingerprint+status 窗口 600s)                    │
│  ② 抖动检测 (firing↔resolved 翻转 ≥3 次/600s)            │
│  ③ 时间窗聚合 (优先用 AM groupKey, 退化为 service+桶)     │
│  ④ 抑制 (高优先级在场时压低优先级, 对标 AM inhibit_rules)  │
│  ⑤ 拓扑级联关联 (Tarjan SCC→多跳上溯→因果时序门→静默根因) │
│  ⑥ Impact 评分 (severity×告警数×拓扑扇出×抖动惩罚)        │
│  ⑦ Runbook 预匹配 (只返回 id, 真正校验在 Tier 1)          │
│                                                           │
│  产出: IncidentContext (suppressed=true 的不入队)          │
└──────────────────────────────────────────────────────────┘
    │
    ▼
┌──────────────────────────────────────────────────────────┐
│  L3 分层自适应调查图 (唯一一张 LangGraph StateGraph)       │
│                                                           │
│  Tier 1 已知故障 ─ hit ─► remediation_stage (零 LLM)      │
│    │ miss (继承: 前置条件探到的资源实况)                    │
│    ▼                                                      │
│  Tier 2 相似故障 ─ hit ─► remediation_planner → stage     │
│    │ miss (继承: 历史案例复核结论 + 负样本反馈)             │
│    ▼                                                      │
│  Tier 3 未知故障 ─ confirmed ─► remediation_planner → stage│
│    │ 置信不足 → ESCALATED (不做处置, 交人工)               │
│    ▼                                                      │
│  report                                                   │
└──────────────────────────────────────────────────────────┘

plaintext

三条不变量：

没有入口分流开关。调用方只提交告警，走多深由告警本身和 impact 门槛决定。
命中即止。省算力是命中即止的自然结果，不需要预设投入等级。
不回退。同一 Incident 内递进后不再回退上一级（防循环），已有证据向下继承。

1.3 分步详解#

Step 1: 去重 (`preprocessing/rules.py::dedup_key`)#

做什么: 同一条告警在窗口内（默认 600s）重复推送时识别并标记
怎么做: 去重键 = fingerprint:status。fingerprint 由 Alertmanager 按 label set 算好，带上 status 是因为 firing→resolved 是状态变化，不能被当成重复吞掉。通过 PreprocessStore.seen_recently() 查窗口内此前出现次数，>0 即标记 is_duplicate=True
为什么这么做: Alertmanager 的 group_interval 会重复推送同一条告警。去重是最便宜的降噪（一次 Redis INCR），放在第一步做

Step 2: 抖动检测 (`preprocessing/rules.py::flapping_key`)#

做什么: 检测同一告警在短时间内反复 firing↔resolved 翻转
怎么做: 抖动键 = fingerprint（与 status 无关）。每次状态变化（上一次 status ≠ 当前 status）调 bump_flip() 累加翻转计数，窗口内（600s）累计 ≥3 次即标记 is_flapping=True
为什么这么做: 抖动告警通常是阈值边缘震荡（CPU 在 80% 上下跳），不是真事故。标记抖动后 Impact 评分会按 flapping_penalty=0.3 折减——不是丢弃告警，而是降低它的影响面权重

Step 3: 时间窗聚合 (`preprocessing/rules.py::group_key`)#

做什么: 把时间上接近的同类告警归为一组，产出 correlation_key
怎么做: 优先用 Alertmanager 原生 groupKey（它按 route.group_by 已聚过一次，不重复造）；没有时退化为 service + 时间桶，桶宽 = group_interval_sec（默认 300s）
为什么这么做: 聚合的语义对标 Alertmanager，不自创窗口逻辑。上游已经做了一次的事不要再做一次——双重聚合会导致双重延迟

Step 4: 抑制 (`preprocessing/rules.py::find_inhibitor`)#

做什么: 高优先级告警在场时，压掉同 scope 下的低优先级告警
怎么做: 维护按 service 分桶的活跃告警视图（active_alerts）。对每条新告警，遍历同 scope 活跃告警 × 抑制规则列表，判 source_match + target_match + equal 标签一致。自抑制护栏：同 fingerprint 不算抑制（否则一条 critical 会把自己压掉）
为什么这么做: 对标 Alertmanager 的 inhibit_rules。已经有 critical 级 MySQL 告警了，同一个 MySQL 的 warning 级连接池告警就不需要单独建任务调查

Step 5: 拓扑级联关联 (`preprocessing/topology.py` + `topology/correlate.py`)#

做什么: 在资源拓扑图上做群体级关联——一批同时 firing 的告警，谁是因谁是果
怎么做: 四步算法：
1. Tarjan SCC 缩点：把图中的环压成超级节点，图变 DAG。环里的服务分不出先后，报成整体反而诚实
2. 多跳反向上溯：在”只保留告警节点”的诱导子图中，入度为 0 的就是根因（没有告警的上游）。每跳置信度按 edge_decay=0.85 衰减，低于 min_path_confidence=0.3 停止传播
3. 因果时序门：上游必须不晚于下游开始告警（容忍 causality_skew_sec=60s）。否则”MySQL 在 web-api 挂了三分钟后才报警”会被反判成 MySQL 拖垮了 web-api
4. 静默根因：在残差集（上一步的独立根因）上找共同祖先。根因节点常常自己不告警（没配监控），用 explains × precision 双指标调和平均筛选
为什么这么做: 逐条告警各自判断拓扑，从根上就承载不了级联语义。群体操作才能回答”为什么这些看似独立的根因同时炸了”。级联抑制是降噪率的最大来源（一场故障 20 条告警收敛成 1 个 Incident），但它会吞告警——默认关闭 + 归因链必须全是人审过的边 + 静默根因永不触发抑制，三道锁

Step 6: Impact 评分 (`preprocessing/impact.py::score_impact`)#

做什么: 产出 0~1 的影响面评分，用于调节各 Tier 的置信门槛
怎么做: 四因子加权求和：severity(0.45) + service_criticality(0.25) + alert_count(0.20) + blast_radius(0.10)。severity 取组内最高（一组告警的影响面由最严重那条决定）；告警条数在 alert_count_saturation=10 处饱和；抖动告警按 flapping_penalty=0.3 折减（抖动通常不是真事故）
为什么这么做: Impact 不改变链路结构（Tier 1→2→3 顺序不变），只调节各级的置信门槛——effective_threshold = base + impact × weight，硬顶 0.95。影响面越大，越不敢便宜地停。极端情况（impact ≥ 0.9）强制走 Tier 3 复核

Step 7: Runbook 预匹配 (`preprocessing/engine.py::_match_runbooks`)#

做什么: 提前把告警指纹与 Runbook 注册表做匹配，返回命中的 Runbook id 列表
怎么做: 调 runbooks/matcher.py::match_runbook_ids，正则 fullmatch alertname + service + label 精确匹配 + severity 白名单。只返回 id，真正的前置条件校验在 Tier 1 里做
为什么这么做: 预匹配失败绝不阻断预处理——Runbook 注册表不可用时退化为”没有预匹配”，告警照常入队走 Tier 2/3。匹配成功则给 Tier 1 一个信号”这条告警有可能零 LLM 解决”

Step 8: Tier 1 已知故障 (`investigation/tier1.py`)#

做什么: Runbook 指纹精确匹配 + 前置条件校验 → 确定性处置，零 LLM 调用
怎么做:
1. Impact 闸：impact ≥ tier_confidence_impact_gate(0.9) 时跳过 Tier 1，强制走 Tier 3 复核
2. 指纹匹配：matcher.find_matches(alert) 按正则 fullmatch alertname + service + label + severity 白名单
3. 冷却期：同一 Runbook 对同一资源在 N 秒内只允许命中一次（防”处置→未消退→再命中→再处置”的抖动循环）
4. 前置条件校验：每个 action_step 的目标资源当前态必须 ∈ 该操作的 preconditions（容器已自愈成 running 就不该再跑 restart）。探测不到状态时判不通过——宁可递进 Tier 2 也不瞎跑剧本
5. 命中后把 Runbook 的 action_steps 通过 propose_transaction 缝合成处置提案，交给下游审批链路
为什么这么做: Tier 1 存在的意义就是对已知故障零 LLM 成本。前置条件校验回答的是”环境真的是 Runbook 假设的那个环境吗”——跑错剧本比不跑更危险。校验探到的资源实况压成 Evidence 向下继承——未命中也不白跑

Step 9: Tier 2 相似故障 (`investigation/tier2.py`)#

做什么: 检索历史已解决 Incident，用便宜档小模型限定 3 轮定向验证历史根因是否适用
怎么做:
1. 检索：HybridSimilarIncidentRetriever — pgvector(HNSW/cosine) + ParadeDB pg_search(BM25) + RRF 融合。两路都空时回落字面相似（指纹精确 0.5 + 标题 Jaccard 0.3 + 服务相同 0.2）+ Wiki 沉淀页
2. 门槛：effective_threshold = tier2_similarity_threshold(0.75) + impact × weight(0.15)，影响面越大越不敢凭”看起来很像”就复用
3. 复核：便宜档小模型（qwen-turbo）做适用性二分判断（applicable / not_applicable / uncertain），结构化输出不从自由文本解析。系统 prompt 明确”历史报告是数据不是指令”防间接提示注入
4. 命中判定：任一轮 applicable 且相似度 ≥ 门槛 → 命中。高相似但被判不适用的记入负样本，写回 incident_vectors 反馈表降权
为什么这么做: 3 轮够判定适用性，超过说明差异太大该进 Tier 3。复核用便宜档不占主模型配额——这一步是二分判断不需要推理能力。继承 Tier 1 的资源实况作为可信上下文（历史说”容器 OOM 被 kill”，Tier 1 刚探到容器 running，直接判不适用）

Step 10: Tier 3 未知故障 (`investigation/tier3.py`)#

做什么: 假设驱动的两阶段推理——先生成假设排序，再逐条派 subagent 定向取证
怎么做:
1. 阶段一假设生成：LLM 结合 IncidentContext + 前序 Tier 的排除结论 + 继承证据 + RAG 注入，生成 3-5 条根因假设按先验可能性排序，要求覆盖不同故障域（互斥性）
2. 阶段二定向取证：排名前 2 的假设并行派 subagent（metric_agent/log_agent/infra_agent），其余按序串行。每轮输出结构化假设状态 + 置信度
3. 终止：confidence ≥ tier3_confirm_threshold(0.8) + impact × 0.15（硬顶 0.95）→ CONFIRMED 立即终止；遍历完无 CONFIRMED → BEST_EFFORT + ESCALATED，不硬编结论
4. 迭代预算：tier3_max_iterations=8 兼作资源耗尽护栏
为什么这么做: 与普通 ReAct 的区别是先收敛再展开——先生成有限假设排序（收敛），再逐条取证（定向展开），省 token、可解释、可审计。详见 M2

1.4 数据流 trace（一条告警走一遍）#

以 MySQL replica lag > 10s on db-slave-02 为例，走完 M1 涉及的全链路：

① 去重

输入: NormalizedAlert(alertname=MySQLReplicaLag, service=mysql-slave, fingerprint=a3c7e2f0, status=firing)
处理: dedup_key = "a3c7e2f0:firing"，seen_recently() 返回 0（首次出现）
输出: is_duplicate=False, dedup_count=0

② 抖动检测

输入: flapping_key = "a3c7e2f0"，previous_status = ""（无前序状态）
处理: 无状态变化，跳过翻转计数
输出: is_flapping=False, flip_count=0

③ 时间窗聚合

输入: 告警自带 group_key（来自 Alertmanager route 配置）
处理: 用 AM 原生 groupKey → group_key = "am:oncall-sre:mysql-replication"
输出: group_reason=ALERTMANAGER_GROUP, group_size=1

④ 抑制

输入: scope = "mysql-slave"，查同 scope 活跃告警
处理: 同 scope 无更高优先级告警 → 不抑制；自身登记为活跃告警
输出: suppressed=False

⑤ 拓扑级联关联

输入: alert.service = "mysql-slave"，全局 firing_services 窗口视图
处理: 身份解析 → service:mysql-slave 节点。查窗口内无其他 firing 服务 → 无级联上下游。mysql-slave 入度为 0 → 它本身就是根因
输出: candidates=["mysql-slave"], cascade_of="", suppressible=False

⑥ Impact 评分

输入: severity=warning(0.5), alert_count=1, blast_radius=0.2(单实例), is_flapping=False
处理: 0.45×0.5 + 0.25×0.5 + 0.20×0.1 + 0.10×0.2 = 0.225+0.125+0.02+0.02 = 0.39
输出: ImpactScore(score=0.39, factors={severity:0.5, service_criticality:0.5, alert_count:0.1, blast_radius:0.2})

⑦ Tier 1 命中

输入: IncidentContext(impact=0.39, matched_runbooks=[mysql_replica_lag_runbook])
处理: impact 0.39 < 0.9 → 不强制 Tier 3。指纹匹配 ✓ → 冷却期外 ✓ → 前置条件校验：探测 service://mysql-slave 当前态 active, lag=12s，operation=service.restart 的 precondition 包含 active ✓ → Tier 1 命中
输出: 处置提案 {resource: "service://mysql-slave", operation: "service.restart", via: "tier1_runbook"}，Investigation(hit=True, tier=TIER1, total_iterations=0)

1.5 技术选型决策表#

组件	选了什么	备选方案	为什么选它	什么情况下换
L2 运行态存储	Redis（去重窗口/抖动计数/聚合桶/活跃告警视图）	Postgres、进程内存	多 Worker 共享窗口状态需要集中存储；Redis 的 INCR/SADD/ZSET 原语天然适配滑动窗口语义	Redis 不可用时自动退化为进程内存 `InMemoryPreprocessStore`（降噪不跨 Worker 但仍工作）
拓扑图存储	进程内存邻接表	Neo4j、JanusGraph	小企业几十到几百节点，全量装内存遍历微秒级，不需要图数据库	节点上万或需要多进程共享图时考虑 Neo4j
SCC 缩点算法	迭代版 Tarjan	递归 Tarjan、Kosaraju	递归版在深链上会爆栈，而拓扑深度由用户数据决定不可控	当前规模不会换
Tier 2 检索	pgvector + ParadeDB pg_search + RRF	Milvus、Elasticsearch、纯字面	复用已有 Postgres 连接池零额外运维；BM25 和向量在同一个 DB	数据量到十万级需要专用向量库；pg_search 分词有问题时回退 ES
Tier 2 复核模型	qwen-turbo（便宜档小模型）	主模型 DeepSeek-V4	适用性复核是二分判断不需要推理能力，便宜档不占主模型 TPM 配额	复核准确率不够时升到主模型，但要注意 TPM 预算
拓扑数据来源	compose/nginx 解析 + `ss` 连接嗅探 + 告警共现挖掘 + 手写 YAML	K8s API、Service Mesh、CMDB	不依赖 K8s，适配裸机/docker-compose 环境	接入 K8s 集群时用 API watch 替代静态发现

1.6 口述脚本#

开场（30s）: “告警进来后先过一层纯规则预处理——去重、抖动、拓扑关联、Impact 评分——一行 LLM 都不调。然后进唯一一张诊断图，三级递进：已知故障走 Runbook 零 LLM 处置，相似故障检索历史案例用便宜小模型做 3 轮适用性验证，都没命中才进假设驱动的 ReAct 深度调查。”

[留钩子]: “这个设计最关键的一点是——走多深是系统的输出，不是调用方的输入。“（引导面试官问”为什么不让调用方选模式”）

展开（60s）: “V3 我们做过 fast/deep 双模式，让入口按 severity 预判。结果发现 warning 级的跨域故障——5 条 warning 同时出现——被分到 fast，单链调查无法关联多域证据。根因是在信息最贫乏的地方做了最关键的决策。V4 砍掉了这个入口开关，改成 Tier 1→2→3 自动递进命中即止。还有一个细节——每级未命中时已有的证据会向下继承。比如 Tier 1 为了校验前置条件已经对资源做了一轮只读探测，这些观测是 Tier 3 生成假设时最想要的事实，丢掉就等于让 Tier 3 再派一次 subagent 去问同一个问题。”

[留钩子]: “说到拓扑关联，有一个特别有意思的概念叫静默根因——根因节点自己不告警但它承载的一切都在烧。“（引导面试官追问拓扑算法细节）

二、踩坑实录#

坑 1：因果时序门的时钟偏移容忍量不能太大#

现象: 拓扑关联上线初期，causality_skew_sec 设了 300s（5 分钟），结果一场故障里几乎所有告警都被判成”因果成立”，根因候选退化成”最底层的那个节点”——跟没有拓扑关联时一样
根因: 运维告警的典型传播链条是秒级到分钟级（数据库挂 → 10s 内 web-api 开始报 502 → 30s 内业务指标下跌）。容忍量 300s 太宽，几乎把任意两条告警都判成因果关系——因果时序门形同虚设。而 Alertmanager 的 group_wait（默认 30s）+ 抓取周期（15s）+ 网络延迟加起来也就几十秒
修法: 收紧到 causality_skew_sec=60s。这个值覆盖了绝大部分的时钟偏移和抓取延迟，同时不会把”偶然同时出现”的无关告警误判为因果
教训: 时序类参数的默认值不能”宁宽勿窄”——太宽等于没有。要从真实告警传播链条的时间尺度倒推，而不是拍一个”肯定够”的数

坑 2：Alertmanager `group_wait` 与自建聚合窗口的双重延迟#

现象: L2 的 group_interval_sec=300s 做时间窗聚合，但发现一组本该同属的告警被拆成了两个 Incident。第一条告警 12:00:00 到，第二条 12:05:30 到（Alertmanager 的 group_wait=30s + group_interval=5m 导致的延迟推送），恰好跨了 L2 的 300s 桶边界
根因: 没理解 Alertmanager 的 group_interval 语义——它是同一 group 两次推送的最小间隔，不是告警产生间隔。一条告警可能在产生后 30s~5min 才被推送到 webhook，而 L2 的时间桶用的是 starts_at（告警产生时间），两者的时间基准不同
修法: 聚合时优先用 Alertmanager 原生 groupKey（代码里的 if alert.group_key: 分支）——上游已经聚过一次就不要再按时间桶重新聚。只有 groupKey 缺失时才退化为自建时间桶
教训: 不要在上游已经做了的语义上再做一遍自己的版本。双重聚合不但多余，还会因为时间基准不同产生边界错位

坑 3：身份解析才是拓扑关联的真正瓶颈#

现象: 拓扑图算法调通了（Tarjan + 因果时序门 + 静默根因），但实际告警灌进去后大量节点解析失败——同一个 MySQL 在不同告警里长成 service=mysql-master、instance=10.0.0.5:9104、container_name=prod-mysql-1、job=mysqld-exporter，四种写法指向同一个节点
根因: 图算法只处理”已知拓扑上的已解析节点”。解析不到的告警会退化成”自己是根因”——级联关联对它无话可说。实战里 80% 的工作量在身份解析（topology/resolver.py），不在图算法
修法: 建了 AliasIndex——每个拓扑节点可注册任意多个别名（id、name、aliases 列表），告警进来后按 _IDENTITY_LABELS（topology_node → service → container_name → instance → hostname…）优先级逐个尝试解析。冲突时先注册的赢，解析不到就返回 None——绝不猜，猜错的拓扑归因比没有拓扑归因更有害
教训: 做”数据驱动”的系统时，核心难题往往不是算法而是数据质量。在这个场景里，拓扑数据的获取和保鲜比图算法难一个量级

坑 4：Tier 2 检索的相似度量纲陷阱#

现象: pgvector + BM25 用 RRF 融合后，tier2_similarity_threshold=0.75 几乎永远命不中——RRF 出来的分数在 0.01~0.05 区间
根因: RRF（Reciprocal Rank Fusion）出来的是排名分数不是相似度。1/(k+rank) 的值域跟 cosine 相似度的 [0,1] 完全不是一个量纲。用排名分数去跟 0.75 的相似度门槛比，等于用千米跟公斤比
修法: 排序用 RRF（对量纲不敏感，融合两路），门槛用 cosine 相似度（天然 [0,1]）。BM25-only 命中（向量路没召回）时回落字面相似度，同样 [0,1] 且偏保守。两者再经 penalized_similarity 按历史误命中次数降权
教训: 融合排序和门槛判定是两个不同的问题，不能用同一个分数解决。排序只关心”谁在前面”，门槛关心”够不够像”——前者对量纲不敏感，后者必须有可解释的量纲

三、量化评估#

3.1 评估数据集构建#

数据来源: 手工构造模拟告警（覆盖去重/抖动/抑制/级联/各 Tier 命中场景）+ data/runbooks/*.yaml 种子 Runbook 覆盖的高频场景回放
规模与分布: 预处理层单测覆盖 test_preprocessing_rules.py；拓扑关联覆盖 test_topology_correlation.py（含环路/多跳/静默根因/因果时序门）；三级递进覆盖 test_investigation_ladder.py（Tier 1/2/3 各条路径 + 证据继承 + escalation）
标注方式: 每条测试用例的预期结果人工标注（哪些该去重、哪些该级联、Tier 几命中）

3.2 评估方法#

怎么跑: pytest tests/test_preprocessing_rules.py tests/test_topology_correlation.py tests/test_investigation_ladder.py
对照组: 预处理层关闭 (preprocessing.enabled=False) 后全量透传 vs 开启后的压缩比；Tier 2 混合检索 vs 纯字面检索的召回对比（test_tier2_hybrid_retrieval.py）
可复现性: 全部单测用 InMemoryPreprocessStore（不依赖 Redis）和 mock LLM，一键可跑

3.3 结果与解读#

指标	数值	来源	说明
降噪率（burst 场景）	97% (75→2)	`scripts/loadtest.py` 300QPS 压测	去重+聚合的直接结果
Tier 1 命中耗时	<5s	端到端计时	零 LLM 调用，纯内存匹配+资源探测
Tier 2 命中耗时	~15s	端到端计时	1-3 次 qwen-turbo 调用
Tier 3 耗时	30s-3min	端到端计时	取决于假设数量和取证轮次
单次诊断成本	Tier 1: ¥0, Tier 2: ~¥0.01, Tier 3: ~¥0.20	token 台账	DeepSeek-V4 经百炼
拓扑关联测试覆盖	环路/多跳/静默根因/因果时序门/空图	`test_topology_correlation.py`	全部通过

局限性: 降噪率数据来自模拟压测（同一条告警重复灌），不等于生产环境的真实降噪率（生产环境的告警多样性更高，去重命中率会低于模拟场景）。Tier 命中分布（多少走 Tier 1 / 2 / 3）依赖种子 Runbook 覆盖率和历史 Incident 积累量，冷启动期绝大部分走 Tier 3。

四、面试问答#

基础题（必问级）#

Q1: 三级递进的”命中即止”具体是怎么实现的？#

答：唯一一张 LangGraph StateGraph，用条件边实现递进路由。每个 Tier 节点执行完后检查 state["tier_completed"] 是否有值——有值说明命中，路由到 remediation_stage（Tier 1）或 remediation_planner（Tier 2/3）；没值说明未命中，路由到下一个 Tier 节点。

核心代码就是三个路由函数：route_after_tier1 看 tier_completed 有没有值走 remediation_stage 还是 tier2；route_after_tier2 同理走 remediation_planner 还是 tier3；route_after_tier3 看 escalate 标志走 remediation_planner 还是 report。

追问 1： 证据继承怎么做的？答： InvestigationState 里 evidences 字段用 Annotated[List, operator.add] 声明为累加器——每个 Tier 节点往里追加自己产出的 Evidence，LangGraph 的 reducer 自动合并，下一个 Tier 从 state["evidences"] 读到前序所有 Tier 的证据。比如 Tier 1 为了校验前置条件探到了资源实况”容器当前态 running”，这条 Evidence 追加进去后 Tier 2 的适用性复核和 Tier 3 的假设生成都能看到它。

追问 2： 为什么不用一个简单的 for 循环代替 LangGraph？答：纯调查阶梯确实可以用 for 循环——engine.py::run_ladder 就是这么做的，供不需要审批/事务的场景和单测使用。但生产路径需要审批挂起：Tier 1 命中后处置可能需要人工审批，LangGraph 的 interrupt() 能在审批节点挂起图等待响应，恢复后接着跑。自己实现这套 checkpoint + resume 成本太高。两条路径的 Tier 顺序、命中即止、证据继承必须保持一致——改一处就得改另一处。

Q2: L2 预处理层为什么不用 LLM？#

答：三个原因。第一，调用量：告警风暴下一分钟可能涌入上百条告警，每条都调 LLM 会直接撞百炼 TPM 限流。L2 的职责是降低下游负载，它自己不能成为负载源。第二，确定性：去重、聚合、抑制需要的是精确匹配和窗口计数，LLM 做这些反而不如规则可靠——fingerprint 相同就是重复，不需要”理解”。第三，延迟：L2 在 webhook 处理的同步路径上，必须毫秒级完成，LLM 调用的秒级延迟不可接受。

追问： 那 L2 能做语义级降噪吗？比如两条不同 alertname 但描述同一个故障？答： L2 本身不做语义降噪——它只用指纹和标签做精确匹配。但拓扑级联关联在某种程度上弥补了这个缺口：如果两条不同 alertname 的告警在拓扑图上有因果关系（一个 depends_on 另一个），级联分析会把它们归到同一个根因下。真正的语义去重需要 embedding 相似度计算，这是 Tier 2 的事——到了 Tier 2 告警量已经被 L2 压缩过了，调 LLM 的成本可控。

进阶题（区分度）#

Q3: 拓扑关联里的”静默根因”是怎么找到的？#

答：先做直接根因分析——Tarjan 缩点后，在告警节点的诱导子图里入度为 0 的就是根因。但真实故障里根因节点常常自己不告警——磁盘写满了但没配磁盘监控，只有 MySQL 和 web-api 在报警。

静默根因在残差集上找共同祖先。残差集 = 上一步得出的那些互相独立的直接根因（已被某个根因解释的受害者不算）。用两个指标筛选候选：explains = 它能解释多少个独立根因 / 独立根因总数；precision = 它辖区里有多少在告警 / 辖区总大小。两者取调和平均。

只看 explains，最顶层节点（整个机房）永远满分，毫无信息量；只看 precision，任何叶子的父节点都是 1.0。两者同时高才有意义。还有个安全约束：静默根因永不触发级联抑制——没人会去调查一个没有告警的节点，把它的受害者全吞了等于让整场故障静默。

追问： 静默根因的误报率怎么样？答：有两道门槛控制：silent_min_residual=2（至少解释 2 个独立根因才配当静默根因）和 silent_min_explains=0.5 / silent_min_precision=0.4。加上 silent_discount=0.9 对分数打折——静默根因是推断不是观测，天然比直接根因低一档。实测中静默根因出现的频率不高（需要多个独立根因同时出现），但一旦出现往往定位精准——因为它回答的问题本身就很具体：“为什么这些看似独立的根因同时炸了？“

Q4: Impact 评分”只调门槛不改结构”具体怎么理解？#

答： Tier 1→2→3 的执行顺序和路由逻辑跟 Impact 完全无关——不管 Impact 是 0.1 还是 0.9，图都是先试 Tier 1 再试 Tier 2 再 Tier 3。Impact 影响的是每级的置信度门槛：effective_threshold = base + impact × weight，硬顶 0.95。

举例：Impact=0.3（单条 warning），Tier 2 检索到相似案例 cosine=0.78 > 门槛 0.75+0.3×0.15=0.795？不够，继续。如果是 Impact=0.1，门槛 0.75+0.1×0.15=0.765，0.78 > 0.765，Tier 2 命中。

有一个例外：must_escalate_to_tier3——当 Impact ≥ 0.9（tier_confidence_impact_gate）时，即使 Tier 1 匹配到 Runbook，也强制跳过进 Tier 3 复核。这是”影响面极高时不敢便宜地停”的极端保护。但注意它仍然不改变”Tier 1 先执行”的顺序——Tier 1 节点照常跑，只是在 impact 闸处提前返回 miss。

追问： 为什么不让 Impact 直接决定跳过 Tier 1/2？答：因为 Tier 1 是零成本的——Runbook 指纹匹配是微秒级纯内存操作。即使是灾难性故障，如果恰好有精确匹配的 Runbook，Tier 1 处置的确定性和速度远优于 Tier 3 的 LLM 推理。跳过 Tier 1 是在”确定有确定性答案”时强行走不确定性路径。

压力题（面试官挑战设计决策）#

Q5: 你的拓扑数据来自 compose/nginx/ss 嗅探，这在真实微服务环境下能用吗？#

答：坦白说，当前的拓扑发现方案是为小企业裸机/docker-compose 环境设计的，不适合大规模微服务。但架构上做了解耦——拓扑数据来源是可插拔的 TopologyProvider（topology/providers/ 目录下有 compose.py、nginx.py、static_yaml.py），图算法（SCC、因果时序门、静默根因）完全不关心数据从哪来。

接入 K8s 环境时需要新增一个 K8sProvider（watch Deployment/Service/Ingress 资源变化），拓扑图会从几十节点扩展到几百甚至上千节点。当前的进程内存邻接表在千级节点仍然可行（Tarjan 线性复杂度），万级需要考虑增量更新而不是全量重建。

真正难的不是图算法也不是接入方式，是拓扑数据的保鲜——服务依赖关系会随着部署变更而变化，ss 嗅探看到的是”此刻谁连着谁”，不一定反映正常态的依赖关系。告警共现挖掘（topology/discovery/mining.py）是用历史数据推断依赖，准确率有限。

追问： 既然拓扑数据不可靠，拓扑关联的价值在哪？答：价值在于当拓扑数据正确时，它能在零 LLM 成本下把 20 条告警收敛成 1 个 Incident——这是 L2 降噪率最大的来源。而数据不正确时的保护机制已经就位：解析不到节点就退化为”自己是根因”；自动发现的边（status=pending_review）只参与打分不参与抑制；级联抑制默认关闭。最坏情况下拓扑关联跟没做一样，不会比没做更差。

Q6: L2 预处理的 Redis 依赖是单点，挂了怎么办？#

答： Fail-open。PreprocessStore 的 Redis 实现 RedisPreprocessStore 每个方法都包了 try-except——seen_recently 失败返回 0（不重复），active_alerts 失败返回空列表（无抑制），firing_services 失败返回空字典（无级联）。Redis 挂了等于所有降噪规则失效，全部告警放行。

为什么 fail-open 安全？因为降噪是增益不是正确性前提——宁可多跑一次诊断，不可因缓存不可用把真告警吞掉。而且有进程级兜底：get_preprocess_store() 在 Redis 连不上时会退化为 InMemoryPreprocessStore（降噪不跨 Worker 但进程内仍工作）。

更深一层：L2 和队列入队用的是同一个 Redis。Redis 挂了 → 降噪 fail-open 放行 → 但 XADD 入队也失败 → 告警到不了 Worker。放行的请求只多做一次 Postgres 落库（告警不丢），LLM 不会被打爆。

五、前沿概念与延伸#

5.1 Alert Correlation（告警关联：基于图 vs 基于 ML）#

是什么: 把大量原始告警聚合、关联、归因到少量根因事件的技术。业界有两条主线：基于拓扑图的因果推理（Graph-based）和基于机器学习的统计关联（ML-based）。

为什么要这么做: 一场故障可能触发几十条告警（数据库挂 → web-api 502 → 支付失败 → 下单成功率下跌），OnCall 工程师不可能逐条排查。告警关联的核心价值是降噪——把”症状列表”收敛成”根因候选”。

这么做的理由: 本项目选了基于图的方案，因为三个优势：（1）可解释——每条归因都有拓扑边和因果时序作为证据；（2）冷启动友好——不需要历史数据训练，有拓扑图就能跑；（3）确定性——同一组告警 + 同一张图 = 同一个结论。ML-based 方案（如 GNN 做告警聚类）在大规模场景下可能更准，但需要大量标注数据且结果难以解释。

举例说明: 本项目用 Tarjan SCC 缩点 + 因果时序门 + 静默根因。Microsoft 的 NetSage/CloudRanger 用类似因果图方法；PagerDuty 的 Event Intelligence 用 ML-based 聚类（基于告警文本和时序相关性）。

延伸问答:

面试官：“基于图和基于 ML 的告警关联，什么情况下用哪个？” 答：看两个条件。有没有拓扑数据——有清晰的服务依赖图用图方法更直接；没有拓扑但有大量历史告警数据用 ML 做统计关联。需不需要解释——运维场景高度需要解释，图方法天然可解释；不需要解释的场景 ML 更灵活。最理想是混合：图方法做确定性关联，ML 做图覆盖不到的”软关联”。

5.2 Tiered Escalation Pattern（分层升级模式）#

是什么: 将问题处理按复杂度/成本/风险分为多个层级，低层级先尝试，解决不了才升级到高层级。每层有独立的终止条件，升级时携带已有上下文。

为什么要这么做: 运维场景的核心矛盾是”80% 的告警是已知故障重复出现，但 20% 的未知故障需要深度调查”。全走深度调查成本不可接受；只做规则匹配则未知故障没人管。分层升级让系统按需投入算力。

这么做的理由: 相比固定模式选择（V3 的 fast/deep），分层升级的关键优势：（1）决策点后移——不在信息贫乏的入口做选择，而是在每层积累足够信息后再决定是否升级；（2）证据继承——低层级的探测结果不浪费，高层级拿来当起始上下文。

举例说明: 本系统 Tier 1→2→3。业界类似模式：Kubernetes Liveness → Readiness → Startup Probe（三级健康检查逐步加严）；PagerDuty Escalation Policy（oncall → 二线 → 管理层）；StackStorm Sensor → Rule → Action → Workflow。