面试知识库

P0 — Incident 状态机 + 分层自适应调查引擎#

总纲:docs/REDESIGN_CLOSEDLOOP_20260708.md §2 + §3 + §4(L2/L3) 优先级:P0(当前最大空白,后续 P1/P1.5/P2 全部依赖此骨架) 目标:写完本文后可以直接编码——每个模块有 DDL、Pydantic model、接口契约、与现有代码的 diff 清单。


1. Incident 状态机#

1.1 状态定义#

class IncidentStatus(StrEnum):
    # ── 新增(替换现有 open/mitigated/closed/suppressed) ──
    DETECTED     = "detected"       # L1 接入层产出,原始告警已归一化
    TRIAGING     = "triaging"       # L2 预处理中(聚合/关联/impact 评分)
    INVESTIGATING = "investigating" # L3 调查中(Tier 1→2→3 递进)
    RCA_READY    = "rca_ready"      # 调查完成,根因已定,待决策
    REMEDIATING  = "remediating"    # 处置执行中
    VERIFYING    = "verifying"      # 三级验证门禁中
    RESOLVED     = "resolved"       # 验证通过,事件关闭
    ESCALATED    = "escalated"      # 人工接管(审批拒绝/置信不足/验证失败回滚后)
python

1.2 状态迁移矩阵#

当前状态事件目标状态守卫条件
DETECTEDpreprocess_startTRIAGINGIncidentContext 开始构建
TRIAGINGpreprocess_doneINVESTIGATINGIncidentContext 产出完成
INVESTIGATINGrca_confirmedRCA_READYTier 1/2/3 任一命中且置信达标
INVESTIGATINGrca_insufficientESCALATEDTier 3 全部假设未达标
INVESTIGATINGnew_alert_mergedINVESTIGATING(自迁移)新告警并入,增量再调查
RCA_READYautonomy_autoREMEDIATING自治等级 = AUTO
RCA_READYautonomy_approvalREMEDIATING飞书审批 approved
RCA_READYautonomy_deniedESCALATED审批拒绝 or 超时降级
RCA_READYautonomy_handoffESCALATED自治等级 = MANUAL/HANDOFF
REMEDIATINGexecution_doneVERIFYING事务化执行完成(含补偿准备)
REMEDIATINGexecution_failedESCALATEDCAS 漂移检测失败 or 执行异常
VERIFYINGverify_passedRESOLVED三级门禁全部通过
VERIFYINGverify_failedESCALATED门禁失败 + 自动回滚完成
RESOLVEDnew_alert_mergedINVESTIGATING已关闭事件被新告警拉回
ESCALATEDhuman_resolvedRESOLVED人工介入后手动关闭

1.3 并发规则#

  • 同 Incident 串行:同一个 incident_id 在任意时刻只有一个活跃状态迁移(Postgres FOR UPDATE 行锁)。
  • 跨 Incident 并行:不同 Incident 的调查/处置互不阻塞,受全局执行槽限流(现有 Redis Streams + Worker 机制)。
  • 增量再调查合并语义INVESTIGATING 态收到 new_alert_merged 时,新告警附加到 IncidentContext.source_alerts,已有证据保留不清空,Tier 调查从当前 Tier 继续(不回退到 Tier 1)。
  • RESOLVED 拉回RESOLVED 态收到同 correlation_key 的新告警时,状态迁回 INVESTIGATING,但 resolved_count += 1 记录拉回次数,防止无限循环(超过 3 次拉回直接 ESCALATED)。

1.4 Postgres DDL 变更#

现有 incidentsstatus 字段值从 open/mitigated/closed/suppressed 迁移到新状态枚举。新增字段:

1.5 与现有代码的 diff 清单#

文件改动说明
app/incidents/models.py IncidentStatus 枚举从 open/mitigated/closed/suppressed 替换为 §1.1 的 8 个状态
app/incidents/models.py DiagnosisMode 枚举fast/deep 模式归零,不再需要
app/incidents/models.py DiagnosisTaskRecorddiagnosis_mode 字段,改为 investigation_tier
app/incidents/repository.py _upsert_incidentstatus 默认值从 'open' 改为 'detected'
app/incidents/repository.py _create_or_get_taskdiagnosis_mode 参数和字段
app/incidents/repository.py 状态迁移方法transition(incident_id, event) -> new_status,含行锁 + 迁移矩阵校验 + 审计日志
app/db/postgres.py DDL§1.4 的 ALTER TABLE + incident_transitions 表
app/orchestration/diagnosis_runner.py大改见 §3(核心:删 fast/deep 分流,换成 Tier 1→2→3 链路)

2. L2 预处理层(纯规则,不进 LLM)#

2.1 IncidentContext 完整 Pydantic model#

2.2 预处理规则配置格式#

对标 Alertmanager 语义,Python dataclass 配置,写在 app/config.pySettings 里:

2.3 拓扑关联#

当前项目状态:无 K8s API / OTel Service Graph 接入。

Day 1 策略

  • 拓扑关联标记为可选插件,默认关闭(topology_enabled: bool = False)。
  • 先实现静态拓扑配置topology_rules.yaml 手写 service_a depends_on service_b,满足 demo 需要。
  • K8s / OTel 接入列为 backlog,接口预留 TopologyProvider 抽象。

2.4 新增代码位置#

文件说明
app/preprocessing/__init__.py新建模块
app/preprocessing/rules.py去重/抑制/时间窗聚合/抖动检测
app/preprocessing/topology.py拓扑关联(Day 1 = 静态配置)
app/preprocessing/impact.pyImpact 评分
app/preprocessing/engine.py入口:接收 NormalizedAlert → 产出 IncidentContext
app/incidents/models.py加 IncidentContext / ImpactScore / AlertGroupReason 等 model

3. L3 分层自适应调查引擎(核心改动)#

3.1 Tier 1 — Runbook Schema#

与现有 app/skills/models.py 的关系

Skill (现有)Runbook (新增)关系
给 LLM Router 看的”菜单卡”Tier 1 确定性处置单元Runbook 是 Skill 的子集——只有能被结构化为确定性步骤的 Skill 才能转成 Runbook
triggers 启发式匹配match_conditions 正则+标签精确匹配Runbook 匹配更严格
playbook 是自由 Markdownaction_steps 是结构化动作序列Runbook 不含自由文本
保留(Tier 3 仍需 Router 选 Skill)新增并存,不替换

种子 Runbook 冷启动:从现有 app/skills/definitions/ 下的 9 个 Skill 中,提取可结构化的高频处置(磁盘清理、容器重启、OOM 处理),转为 Runbook 格式。预计冷启动 5-8 个种子 Runbook。

3.2 Tier 2 — 限定 3 轮定向验证#

Tier 2 复用现有 app/rag/ 混合检索(pgvector + BM25 + RRF),核心新增逻辑:

class Tier2VerificationRound(BaseModel):
    """Tier 2 单轮验证结果。"""
    round_number: int                            # 1/2/3
    retrieved_incident_id: str                   # 检索到的历史 Incident
    similarity_score: float
    applicability_verdict: str                   # applicable / not_applicable / uncertain
    reasoning: str                               # 小模型适用性复核的推理过程
    tokens_used: int = 0

class Tier2Result(BaseModel):
    """Tier 2 的完整结果。"""
    hit: bool = False
    reused_rca: dict[str, Any] | None = None     # 命中时复用的历史 RCA
    verification_rounds: list[Tier2VerificationRound] = Field(default_factory=list)
    negative_samples: list[str] = Field(default_factory=list)  # 误命中的 incident_id(反馈给 L6)
python
  • 限定 3 轮:检索 Top-3 相似历史 Incident,每条用便宜档小模型(Qwen-turbo)做适用性复核(“这条历史根因是否适用于当前告警上下文?”),判定 applicable / not_applicable / uncertain。
  • 命中判定:任一轮 applicable 且相似度 > 阈值 → Tier 2 命中。
  • 未命中:3 轮全部 not_applicableuncertain → 递进 Tier 3,误命中记入负样本。
  • 阈值配置tier2_similarity_threshold: float = 0.75tier2_max_rounds: int = 3

3.3 Tier 3 — Hypothesis 数据模型#

3.4 Tier 3 置信度判定#

  • CONFIRMED 阈值tier3_confirm_threshold: float = 0.8(配置项)
  • impact_score 调门槛effective_threshold = tier3_confirm_threshold + impact_score.score * 0.15(影响面越大越不敢便宜地停,最高 0.95)
  • 达标即终止:某假设 CONFIRMED + confidence >= effective_threshold → 立即停止,不验证剩余假设
  • 兜底:所有假设遍历完无 CONFIRMED → 取 confidence 最高的假设标记为 BEST_EFFORT,Incident 进入 ESCALATED

3.5 与现有代码的 diff 清单#

文件改动说明
app/orchestration/diagnosis_runner.py大改get_diagnosis_graph()/get_deep_diagnosis_graph() 两个图缓存 + resolve_effective_mode() + fast-first 升级逻辑;换成 get_adaptive_investigation_graph() 单一入口
app/orchestration/diagnosis_runner.py normalize_diagnosis_mode() / resolve_effective_mode()fast/deep 模式概念不再存在
app/orchestration/diagnosis_runner.py run_diagnosis_graph()diagnosis_mode 参数,签名改为只接收 IncidentContext(而非 raw query),调查深度由系统决定
app/agents/graph.py现有 fast 图(Router→Planner→Executor→Replanner→Report)改造为 Tier 调度图:Tier1Node→Tier2Node→Tier3Node,各节点内部保留原逻辑的精华
app/diagnosis_graphs/deep_diagnosis_graph.py合并进主图deep 图的多 subagent 取证保留为 Tier 3 内部的 orchestrator-workers,不再是独立图
app/runtime/escalation.py should_escalate_to_deep() / FastRunSignalsfast→deep 升级概念不再存在,Tier 递进是链路内部自动行为
app/incidents/models.py Hypothesis / Investigation / RootCause / Runbook 等 model§3.1-3.3 的所有新模型
新增 app/investigation/__init__.py新建调查引擎模块
新增 app/investigation/tier1.py新建Runbook 匹配 + 前置条件校验 + 执行
新增 app/investigation/tier2.py新建历史 RCA 检索 + 限定 3 轮验证
新增 app/investigation/tier3.py新建假设生成 + 定向取证 ReAct Loop
新增 app/investigation/engine.py新建Tier 调度入口:T1→T2→T3 递进 + 证据继承
新增 app/runbooks/__init__.py新建Runbook 管理模块
新增 app/runbooks/models.py新建Runbook / RunbookStep / RunbookMatchCondition
新增 app/runbooks/registry.py新建Runbook 注册表(YAML 加载 + DB 查询)
新增 app/runbooks/matcher.py新建告警指纹 → Runbook 匹配逻辑
app/config.pyPreprocessingConfig + Tier 相关阈值配置

4. 消解三级 vs 五级门禁矛盾#

总纲 §11.1 提到 itops-agent-platform 的 5 级门禁,当前实现为三级。

裁决

  • 核心三级(Day 1):命令成功 → 服务健康 → 指标恢复
  • 扩展两级(P2 backlog):baseline_comparison(与历史基线对比)+ impact_assessment(确认修复没让别处恶化)

代码映射

门禁级别现有代码改动
1. 命令成功无(事务引擎隐含检查返回码)新建 显式 gate:command_success_gate,检查执行返回码 + 状态变更确认
2. 服务健康remediation_gate_service_health_enabled + 相关配置保留,重命名为 gate_service_health
3. 指标恢复remediation_gate_metric_recovery_enabled + 相关配置保留,重命名为 gate_metric_recovery

5. Runbook 自增长流水线(L6 联动,§3.6 落地)#

5.1 生成触发条件#

  • Tier 3 调查完成 + root_cause.confidence >= 0.8
  • 人工确认 RCA 采纳(human_feedback.rca_accepted = true
  • 三级验证门禁全部通过(RESOLVED 状态)
  • 三个条件同时满足才触发

5.2 生成流水线#

5.3 新增代码位置#

文件说明
app/runbooks/generator.pyLLM Runbook 生成器(Investigation → Runbook 草稿)
app/runbooks/prompts.py提炼 prompt 模板
app/runbooks/reviewer.py审核队列(人工 + 自动回归)

6. 实施顺序(P0 内部分步)#

步骤做什么产出预估
P0.1Incident 状态迁移 + DDL + transition() 方法状态机可运行,现有链路不断1 天
P0.2L2 预处理模块 + IncidentContext 模型告警风暴可测降噪率1 天
P0.3Runbook schema + 种子 Runbook 导入 + Tier 1 匹配Tier 1 可运行1 天
P0.4Tier 2 检索 + 3 轮验证Tier 2 可运行0.5 天
P0.5Tier 3 假设驱动两阶段(合并现有 deep 图)Tier 3 可运行1.5 天
P0.6三级 Tier 调度串联 + 删 fast/deep 入口全链路 E2E0.5 天
P0.7三级验证门禁统一接口门禁可运行0.5 天

总计 ~6 天。P0 完成后即可跑 E2E 测试 + 测降噪率/Tier 命中分布指标。