11 · 线上问题定位与可靠性

未来规划

让 AI 从监控异常一路查到日志、代码、需求和相关人员，快速提出解决方案，再由人决策修复。Northstar 希望借助结构化数据、LlamaIndex RAG 与知识图谱，缩短故障恢复时间，提高系统可用性和可靠性。

先把资料之间的关系连接完整

线上告警提示异常之后，团队还需要知道：哪个版本发生了变化？对应什么需求？谁负责实现？产品规则为什么这样定义？这些信息分散在不同系统时，定位问题往往需要反复寻找上下文。

计划统一对象的标识、字段与引用：需求关联实际开发者和产品负责人，代码提交关联需求，部署版本关联发布记录，运行信息关联服务和环境。保留来源、版本与参与记录，并检查缺失引用和失效关系，让 AI 沿规范化数据持续追查，减少关联断链。

从监控异常追查到相关人员

1. 01 · 发现监控与告警

   确定异常服务、环境和时间范围。

2. 02 · 观察日志与调用链

   核对错误、延迟与业务影响。

3. 03 · 定位变化发布与代码

   追查部署版本和相关提交。

4. 04 · 还原依据设计与需求

   查阅业务规则、方案与验收标准。

5. 05 · 确定参与者开发者与产品负责人

   结合问题类型组织相关人员。

6. 06 · 决策修复提出方案，由人决定

   执行修复、验证恢复、沉淀复盘。

LlamaIndex RAG 与知识图谱各做什么

计划用 LlamaIndex 构建 RAG（检索增强生成），组织产品知识、代码与故障资料的接入、索引和检索。结合语义检索与产品、服务、环境、版本、时间条件，为分析提供可引用的原始依据。

结构化关系和知识图谱连接对象，帮助继续查询依赖与影响。运行数据通过相应的监控和日志查询能力获取，再与检索出的研发材料对齐。每条关键判断保留来源，并按访问权限提供结果，方便相关人员核对。

实现问题找 Dev，产品问题找 PM

AI 提供问题判断、证据、候选方案、影响范围与验证方式。相关人员据此决定采用什么方案、是否执行及何时执行，再按职责推进处理。

以一次发布后的异常为例

假设订单接口在发布后错误率上升，目标流程会先查询异常时间段的日志与调用链，找到部署版本及相关代码提交，再追查需求、技术设计和此前的类似故障。

若证据指向实现缺陷，交由 Dev 与原开发者提出修复或回滚方案；若涉及业务规则取舍，则请 PM 与产品负责人共同确认。参与者核对候选方案及风险后决定执行，再检查关键业务、错误率、延迟和相关测试是否恢复预期。

把处理经验变成下次可用的知识

问题处理后，将故障原因、决策、执行动作、修复版本、验证结果和参与人员保存为结构化记录。后续同类问题可以复用这些依据，也能根据复盘补充测试、监控和关联关系，减少重复故障。

以定位耗时、恢复耗时、故障复发率和服务可用性评估效果，让知识积累落实到处理效率与运行质量。

当前已有的审计、执行证据与诊断基础主要服务于 Northstar 自身运行。上述公司级 RAG、知识图谱、用户产品监控接入和人员协同闭环属于后续规划，演进顺序见 总结与展望。