# Investibook 价值评估与覆盖率设计 **Date:** 2026-05-09 **Status:** Design draft **Scope:** Investibook 故障诊断使用量、覆盖率、质量与 ROI 评估体系 --- ## 1. Summary Investibook 要证明自己的价值，第一步不是直接讨论“诊断得好不好”，而是先回答更基础的问题： > 上周一共有多少故障、Alert、ST/TCOC 工单，其中有多少被 Investibook 触达、建档、诊断和复盘？ 如果连总量、入口、使用场景、关联问题类型都没有统一口径，后续的成功率、节省工时、成本分摊和 ROI 都会变成不可复核的主观叙事。 本设计的核心目标是建立一套分阶段的价值评估体系： 1. **覆盖率优先**：先量化 Investibook 覆盖了多少真实生产问题。 2. **质量第二步**：在覆盖样本明确之后，再评估诊断质量、反馈和解决效果。 3. **复盘可追溯**：同一集群、同一时间段、同一组问题要能归并成一次可复盘的诊断事件。 4. **ROI 最后闭环**：在覆盖率和质量都有事实基础后，再计算节省时间、减少人工排障成本和业务价值。 --- ## 2. 问题定义 当前 Investibook 已经记录了 workspace、消息、飞书反馈和自动诊断状态，但这些数据还没有被组织成“价值评估”口径。 主要缺口： 1. **外部总量未知** - 上周一共有多少 TCOC Incident？ - 上周一共有多少 Alert？ - 上周一共有多少 ST / Support 工单需要诊断？ - 其中哪些本来就属于 Investibook 应覆盖范围，哪些不属于？ 2. **Investibook 内部使用量没有业务归因** - 有多少交互是普通聊天？ - 有多少交互是在诊断真实故障？ - 有多少交互关联了 Jira / TCOC / Alert / cluster？ - 有多少交互虽然在查 TCOC 故障，但没有通过标准入口创建 workspace，也没有结构化关联 issue？ 3. **覆盖率缺少分母和去重** - 一个 Alert、一个 TCOC 工单、一个 ST 工单可能描述的是同一次故障。 - 同一个集群同一时间段可能有多个入口、多个 workspace、多个飞书线程。 - 如果不先聚合成 canonical incident，就无法计算真实覆盖率。 4. **质量评估样本边界不清** - 不能把所有聊天都纳入诊断质量评估。 - 也不能只看用户点击“正确/不正确”，因为未反馈样本不等于成功。 - 质量评估必须建立在“这是一次被 Investibook 覆盖的诊断事件”之上。 --- ## 3. 总体框架 这套价值评估体系只需要抓住五个核心对象，避免一开始陷入字段和报表细节。 ### 3.1 External Signal：外部问题信号 外部信号是所有覆盖率分母的来源，可能来自： - Jira 中的 TCOC issue - Jira 中的 O11Y issue - Jira 中的 ST / Support issue - Jira 中的 TCID issue - 其他后续接入到 Jira 或可映射到 Jira 的故障入口 外部信号进入系统后，先判断它是否应该进入“故障诊断覆盖率”的分母。 ### 3.2 Incident Dossier：故障档案 故障档案表示“同一个真实问题”。这是本设计的核心聚合对象。 一个故障档案可以关联多个外部信号，也可以关联多个 Investibook workspace、Lark 线程、AutoChat 任务和人工分析过程。覆盖率按故障档案计算，而不是按 ticket、alert 或 workspace 计算。 这能解决几个常见冲突： - 同一个故障可能先有 O11Y Alert，后来有 TCOC，再后来有 ST。 - 同一个 TCOC 可能被多次导入，或被多人创建多个 workspace。 - 有些分析没有标准入口，但实际上是在查同一个问题。 - 有些 TCOC 不是故障，不能进入故障覆盖率分母。 ### 3.3 Analysis Attempt：一次分析 一次分析表示 Investibook 对某个问题做过一次具体诊断。 同一个故障档案可以有多次分析：TCOC 入口一次、O11Y 入口一次、Lark 里一次、Web 手工 workspace 一次。覆盖率只算这个故障是否被覆盖，质量评估则既可以看每次分析，也可以看这个故障最终是否被有效推进。 ### 3.4 Ground Truth：RCA / 复盘结论 诊断质量的主要参照物不是用户点击“正确/不正确”，而是最终 RCA 或人工复盘结论。 对 TCOC 来说，如果需要 RCA，Jira issue 会关联 RCA 文档链接。但 RCA 可能不是一开始就存在，通常会在故障处理后补充。因此质量评估要支持 RCA 延迟出现和重新计算。 RCA 自身也要有状态：没有 RCA、RCA 信息不足、RCA 仍是草稿，都不能强行用来判断 Investibook 对错。 ### 3.5 Periodic Review：日报 / 周报 / 月报 价值评估不是只产出一份周报，而是形成周期报告体系： - **日报**：关注昨天新增问题、未覆盖问题、待人工确认的故障档案候选、未归因分析和明显失败的诊断。 - **周报**：关注一周覆盖率、故障档案归并质量、RCA 对比质量样本和改进行动项。 - **月报**：关注趋势、ROI、重点案例、长期未解决的 instrumentation 缺口和 Investibook 能力演进。 周期报告允许后续回填。例如 RCA 下周才出来，或者人工合并/拆分了故障档案，都可以重算历史统计，但要保留版本和变更原因。 日报、周报、月报都面向 Investibook 团队内部运营和改进。周报、月报可以从内部报告中提炼关键数据用于向上汇报，但不需要从一开始设计成对外报告。 报告不作为不可变归档。它们应根据用户选择的时间范围实时计算或重新计算，所以当故障档案合并/拆分、RCA 链接补充、eligibility 修正后，历史时间范围的报告结果也会同步变化。 ### 3.6 Regression Case：回归案例 有 RCA 结论或明确解决结果的故障档案，应该沉淀为 Investibook 的回归案例。 回归案例用于持续改进 Investibook： - 检查未来版本是否还能找到相同根因。 - 检查是否还能收集关键证据。 - 检查建议动作是否仍然正确。 - 对比不同模型、prompt、skill 和工具编排的诊断质量。 不是所有故障档案都适合生成回归案例。优先选择 RCA 明确、证据链完整、业务影响较大、或 Investibook 曾经失败/部分成功的案例。 --- ## 4. 核心流程 ### 4.1 导入外部信号 按固定节奏从 Jira 导入 TCOC、O11Y、ST、TCID 等 issue。日报可以使用增量导入，周报和月报可以使用回填后的稳定口径。 导入后先做两件事： 1. **Eligibility 判断**：这个信号是否代表真实故障或强诊断场景。 2. **故障档案匹配**：这个信号是新问题，还是已有故障档案的一部分。 ### 4.2 排除非故障 TCOC 里会有大量非故障事项，例如咨询、资源申请、权限问题、账单、UI 反馈、误报、重复通知、无诊断价值的自动恢复。 这些可以统计，但不能进入故障覆盖率分母。否则会把 Investibook 的覆盖率和价值评估拉偏。 建议把外部信号分成四类： - `eligible`：真实故障或应诊断问题，进入覆盖率分母。 - `not_eligible`：明确不是故障，不进入分母。 - `duplicate`：重复信号，不单独进入分母，关联到已有故障档案。 - `unknown`：信息不足，进入人工确认队列。 ### 4.3 建立和维护故障档案 新信号导入时，系统生成候选故障档案列表，而不是直接给出不可解释的最终判断。 匹配依据按强弱分层： 1. 相同 issue、alert、TCID 或明确互相引用。 2. 相同 cluster / tenant，加上重叠时间窗口。 3. 相同症状、错误码、组件、实例、SQL、changefeed 或日志特征。 4. 文本语义相似。 5. 人工确认。 匹配结果分三类： - 高置信度：自动关联到已有故障档案。 - 明确无匹配：新建故障档案。 - 不确定或多候选：进入人工 review。 ### 4.4 人工合并与拆分 智能匹配一定会出错，所以故障档案必须支持人工维护： - 合并两个故障档案。 - 拆分误合并的故障档案。 - 把外部信号从一个档案移动到另一个档案。 - 确认某个信号是新问题。 - 标记某个 TCOC / ST 不是故障。 这些操作会影响覆盖率分母、重复事件计数和质量评估结果，因此必须有审计记录，并能触发日报 / 周报 / 月报的历史统计重算。 ### 4.5 关联 Investibook 分析 Investibook 的 workspace、session、Lark 线程、AutoChat 任务都应该归为某个 `analysis_attempt`，再关联到故障档案。 如果某次分析无法明确归因，只能放入“未归因诊断使用”池，不能直接计入 TCOC / Alert / ST 覆盖率。 ### 4.6 对比 RCA 评估质量 当故障档案有 RCA 或人工复盘结论后，再评估 Investibook 的诊断质量。 质量评估看三件事： - 是否命中 RCA 的核心根因。 - 证据链是否支持结论，是否遗漏关键证据。 - 建议动作是否与实际止血或修复动作一致。 如果没有 RCA，或者 RCA 信息不足，只能标记为 unknown / insufficient，不要强行判断成功或失败。 ### 4.7 生成回归案例 当故障档案满足以下条件之一时，可以进入回归案例候选池： - 有 final RCA 或人工确认的明确根因。 - 有明确解决动作和验证结果。 - Investibook 曾经给出错误结论、遗漏关键证据或需要人工补充。 - 属于高价值、高频或高风险问题类型。 回归案例应保留最小必要材料：问题背景、关键输入、期望诊断路径、RCA 根因、关键证据、期望结论和验收标准。它不应该只是原始聊天记录归档，而应该是可重复运行、可评分、可比较的 evaluation case。 --- ## 5. 指标层次 ### 5.1 覆盖率指标 覆盖率回答“真实问题有没有被 Investibook 触达和诊断”。 核心口径： - 外部信号总量。 - 排除的非故障数量。 - 去重后的故障档案数量。 - 有 Investibook 分析的故障档案数量。 - 未覆盖故障档案清单。 - 未归因 Investibook 分析清单。 最重要的覆盖率是： ```text diagnosis_coverage = 有有效 Investibook 分析的故障档案数 / eligible 故障档案数 ``` 不要用 workspace 数或聊天数作为覆盖率分母。 ### 5.2 归因质量指标 归因质量回答“我们是否把同一个问题正确合并，把不同问题正确拆开”。 需要关注： - 新建故障档案数量。 - 自动关联到已有档案数量。 - 进入人工 review 的候选数量。 - 人工合并数量。 - 人工拆分数量。 - 被人工纠正的自动匹配数量。 这类指标不是业务价值本身，但它决定覆盖率是否可信。 ### 5.3 诊断质量指标 诊断质量回答“Investibook 对已覆盖问题分析得好不好”。 质量应分两层： - **Attempt 级**：某一次分析是否有帮助、是否误导、是否浪费。 - **Case 级**：这个故障档案最终是否被 Investibook 有效推进。 RCA 对比是主评估方式，用户反馈是辅助信号。 ### 5.4 ROI 指标 ROI 必须放在覆盖率和质量之后。 只有当我们知道“哪些真实故障被覆盖”和“诊断质量如何”之后，才有资格估算节省工时、缩短 MTTR、减少重复排障步骤和业务价值。 ### 5.5 回归改进指标 回归指标回答“Investibook 是否在持续变好”。 需要关注： - 从 RCA / 已解决故障生成了多少 regression case。 - 这些 case 覆盖了哪些组件、问题类型和诊断技能。 - 每日 / 每周回归通过率如何变化。 - 曾经失败的 case 是否在后续版本中被修复。 - 新 prompt、skill、工具链改动是否导致历史 case 回退。 --- ## 6. 周期报告输出 ### 6.1 日报 日报用于运营跟进，只回答短周期内需要处理的问题： - 昨天新增了哪些外部信号和故障档案。 - 哪些候选匹配需要人工确认。 - 哪些 eligible 故障还没有 Investibook 分析。 - 哪些 Investibook 分析无法归因。 - 哪些诊断失败、工具失败或用户负反馈需要立即跟进。 ### 6.2 周报 周报用于内部覆盖率和质量复盘，也可以提炼部分数据向上汇报。它固定回答： 1. 本周外部系统一共有多少问题信号？ 2. 其中多少是真正需要诊断的故障，多少被排除了？ 3. 去重后形成了多少个故障档案？ 4. 有多少故障档案被 Investibook 覆盖，覆盖率是多少？ 5. 哪些故障没有覆盖，哪些 Investibook 分析无法归因？ 6. 有 RCA 的样本里，Investibook 诊断质量如何？ 7. 哪些 case 应该沉淀为 regression case？ ### 6.3 月报 月报用于内部管理视角和长期改进，也可以作为向上汇报的数据来源。它重点看： - 覆盖率趋势和未覆盖原因变化。 - 诊断质量趋势和 RCA mismatch 类型。 - 高价值故障案例和业务影响。 - Token / infra 成本与节省工时的对照。 - regression case 增长、通过率和回退情况。 - 下个月最值得改进的入口、技能、数据源和工具链。 ### 6.4 报告计算方式 日报、周报、月报都按用户选择的时间范围重新计算，而不是读取不可变历史报告。 这意味着： - 人工合并 / 拆分故障档案后，历史时间范围的覆盖率会随之变化。 - TCOC 后续补充 RCA 链接后，历史时间范围的质量评估会补齐。 - eligibility 从 unknown 改为 eligible 或 not eligible 后，历史分母会变化。 - 如果需要对外留档，可以额外导出某次报告版本，但默认产品视图展示最新口径。 --- ## 7. 分阶段落地 ### Phase 1：建立可信分母 目标是先知道“上周到底有多少真实故障”。 交付： - 从 Jira 导入 TCOC / O11Y / ST / TCID issue。 - 排除非故障、重复项和明显噪声。 - 建立初版故障档案。 - 输出覆盖率和未覆盖清单。 这个阶段不评价诊断质量。 ### Phase 2：建立故障档案与人工校正闭环 目标是让同一个问题能够被正确归并，不同问题能够被正确拆开。 交付： - 新信号导入时生成候选故障档案。 - 支持自动关联、新建档案和人工 review。 - 支持人工合并、拆分、移动信号、标记非故障。 - 所有变更可审计，并能重算日报 / 周报 / 月报统计。 ### Phase 3：关联 Investibook 分析 目标是知道每个故障档案是否真的被 Investibook 分析过。 交付： - 将 workspace、session、Lark、AutoChat 归并为 analysis attempt。 - 将 attempt 关联到故障档案。 - 保留未归因 attempt 清单，避免把模糊使用算进覆盖率。 ### Phase 4：RCA 对比质量评估 目标是回答“分析得好不好”。 交付： - 抽取 Investibook 诊断结论。 - 抽取 RCA / 人工复盘结论。 - 对比根因、证据和建议动作。 - 输出 attempt 级和 case 级质量判断。 - 将 RCA 明确或已解决的高价值案例加入 regression case 候选池。 ### Phase 5：回归评测与持续改进 目标是把已解决案例转化为 Investibook 的持续改进资产。 交付： - 从 RCA / 明确解决的故障档案生成 regression case。 - 定期运行回归评测。 - 跟踪 prompt、skill、工具链改动对历史 case 的影响。 ### Phase 6：ROI 与价值复盘 目标是把覆盖率和质量转成业务价值。 交付： - 日报 / 周报 / 月报价值复盘。 - 高价值 case 复盘。 - 成本、节省工时和业务影响对照。 --- ## 8. MVP 范围 最小版本只做四件事： 1. 从 Jira 导入 TCOC / O11Y / ST / TCID issue，并对 TCOC 做非故障排除。 2. 建立故障档案，支持候选匹配和人工合并/拆分。 3. 将 Investibook 的 workspace / session / Lark / AutoChat 关联为 analysis attempt。 4. 输出日报和周报的 coverage review，先回答覆盖率、未覆盖、未归因和待人工确认。 MVP 不要求完整 ROI，也不要求所有 case 都有质量结论。只要能把分母、档案和覆盖关系讲清楚，就是第一阶段成功。 --- ## 9. 关键待确认 已明确： - TCOC、O11Y、ST、TCID 都从 Jira 获取。 - TCOC 如果需要 RCA，会通过 Jira issue 关联 RCA 文档链接，但 RCA 链接可能延迟出现。 - 日报、周报、月报面向 Investibook 团队内部；周报、月报可提炼关键数据用于向上汇报。 - 报告按选择时间范围重新计算，故障档案、RCA、eligibility 更新后历史报告视图也会同步变化。 仍需后续与数据 owner / TCOC owner 对齐： - TCOC 中哪些类型应判定为非故障。 - 故障档案匹配的自动关联阈值和人工 review 阈值。 - RCA 链接字段、RCA 文档格式和可用状态。 - 日报、周报、月报是否需要不同发布渠道。 - 哪些已解决故障应该生成 regression case，谁负责确认验收标准。 - 向上汇报需要哪些指标口径和脱敏要求。