# Clinic 与 Investibook Cloud Case 手工对比报告

- 日期：2026-08-06
- 原始对比范围：`ST-2865`、`ST-2864`、`ST-2863`、`TCID-13001`
- 部署后回归范围：2026-07-30 至 2026-08-06 期间曾使用 Clinic 的 7 个 ST/TCID 诊断 case
- 模式：历史 replay、沿用各 case cutoff、只读诊断、手工比较
- 对比对象：Auto Oncall + Clinic 与 Auto Oncall + Investibook 的实际证据和最终诊断

## 核心结论

部署后，Clinic 的数据查询深度已经明显接近 Investibook：真实 replay 中已能把拓扑、指标、TopSQL、Slow Query 和 Loki 纳入同一个受控证据包。但最终诊断没有同步达到同样深度。

因此当前结论是：

1. **“Clinic 拿不到 TopSQL / Slow Query / Loki”不再成立。** `TCID-13001` 实际取得 TopSQL、Loki 和指标；`ST-2863` 实际取得 Slow Query 和 Loki；`ST-2864` 实际取得 TiFlash 拓扑、指标和日志。
2. **部分 source 仍不稳定。** `TCID-13001` 的 Slow Query 返回 `clinic_http_500`；`ST-2863` 的两次 TopSQL 查询返回同样错误。source 失败被保留为 gap，没有被误写成“无数据”。
3. **当前主要短板已经从“查不到数据”转成“证据压缩和最终收口会丢事实”。** `ST-2864` 和 `TCID-13001` 虽然取得了更深证据，最终 Jira 草稿仍被 publication guard 改写成同一段泛化结论。
4. **并非所有 case 都有提升。** `ST-2865` 的 36 个 TiKV 序列被压缩为前 20 个，导致告警节点没有进入最终证据，部署后结论反而比上一轮弱。
5. **Investibook 的原始调查在部分 case 仍更深，但不代表其最终结论更可靠。** 它在 `TCID-13001` 找到更多资源压力和热点查询线索，但 DDL 与告警窗口没有严格对齐，因果结论偏强；最终可发布回答同样未保留全部事实。

## 对比方法

- 原始四个 case 使用各自冻结的 Jira ticket、评论、附件和历史 cutoff。
- cutoff 后的人类回复、Auto Oncall 评论和后续处置不进入 replay 输入。
- Clinic 与 Investibook 都以 read-only 方式运行。
- 原始对比不使用自动化 comparator，结论来自逐 case 手工检查。
- 部署后回归使用 `mode=write`，按稳定 idempotency key 原位更新既有 Jira internal comment；没有新增重复评论，也没有客户可见回复。
- 最近一周受影响 case 的口径是：该窗口内成功 run 曾实际加载 Clinic provider，且属于 ST/TCID 诊断场景。配置语义问答 `ST-2855` 不属于本次多源诊断改动，未纳入。

## 原始四个 case：部署前后横向结果

| Case | 原始 Clinic | Investibook | 部署后 Clinic replay | 手工判断 |
|---|---|---|---|---|
| `ST-2865` TiKV memory | 识别多节点 TiKV 内存压力、无 OOM/restart | 证据覆盖未通过，preflight 终止 | 两个场景共执行 11 条多源查询，9 条指标查询完成；但 36 个序列只保留前 20 个，最终只能看到约 71%–76%，无法复现 >80% 告警节点 | Clinic 端到端仍优于 Investibook，但本次证据压缩造成回归 |
| `ST-2864` TiFlash storage | 错查 TiKV 内存，遗漏 TiFlash 容量 | 正确读取 Jira 中 Clinic 截图：3 个 TiFlash、约 85% 使用率、每节点约 600 GiB 剩余 | 正确选择 TiFlash 场景，取得拓扑、TiFlash 指标及 Loki；但最终草稿退化为“证据不足以确认具体写入” | 查询组件已纠正，最终诊断仍明显弱于原始 Investibook 报告 |
| `ST-2863` TiFlash query memory | 正确识别预测 RSS 约 4.76 GiB 超过 3.76 GiB limit | 证据覆盖未通过，preflight 终止 | 取得拓扑、Slow Query 和 Loki；TopSQL 查询失败。最终仍保留 TiFlash 内存上限这一直接机制，并拒绝给出固定 RCU 内存换算 | Clinic 明显更好，且部署后未丢失核心已确认事实 |
| `TCID-13001` DDL/TiDB memory | 因果边界正确，但最终回答泛化 | 原始调查取得 memory kill、热点查询、实例 CPU/延迟；DDL 与告警时间未严格对齐，最终也被收口 | TopSQL 返回 20 条聚合记录、Loki 返回 3 个实例/500 行、指标返回 13 个序列；Slow Query HTTP 500。最终草稿仍退化为与 `ST-2864` 相同的泛化结论 | Clinic 数据深度显著提高，但原始 Investibook 的调查叙述仍更深；两边最终可用诊断都不理想 |

## 原始 Investibook 结果的关键边界

### ST-2864

Investibook 的容量结论来自正确理解 Jira 附件中的 Clinic 截图，并非独立查询得到：

- 3 个 TiFlash 节点；
- 每节点约 3.9 TiB；
- 每节点约 600–607 GiB 可用；
- 利用率约 84.6%–85%；
- 节点间基本均衡。

Clinic API 在原始手工验证中也能直接取得同等数据，因此该 case 的差异主要来自场景选择与最终解释，而不是 Clinic 后端缺数据。

### TCID-13001

Investibook 原始调查的优势是将指标、日志和查询候选组织成了较完整的调查线索；不足是没有把 DDL 精确窗口与后续告警窗口严格对齐，同窗口相关性被表达成了偏强的因果关系。它证明了诊断叙述可以更深，但不能作为已确认根因直接采用。

## 部署后 7 个受影响 case replay

部署版本：`692e850ea64427827be52bc0425306df5e95c283`。

| Case | Run DB ID | Clinic 多源证据 | 最终结果 | Jira internal comment |
|---|---:|---|---|---:|
| `ST-2864` | 120028 | 2 个 batch；拓扑、指标、Loki 完成 | 查询纠正，最终事实被泛化收口 | 23430476 |
| `TCID-13001` | 120029 | TopSQL、Loki、指标完成；Slow Query HTTP 500 | 多源事实未进入最终诊断 | 23428753 |
| `ST-2863` | 120030 | 3 个 batch；拓扑、Slow Query、Loki 完成；TopSQL HTTP 500 | 保留 TiFlash memory-limit 直接机制 | 23422952 |
| `ST-2865` | 120031 | 2 个 batch；9 条指标查询完成 | 序列截断漏掉告警节点，结论弱化 | 23432370 |
| `TCID-12973` | 120032 | 两个场景均未产出 evidence artifact | 只能按已缓解处理，未确认升级因果 | 23327373 |
| `ST-2860` | 120033 | provider evidence prohibited，未进入 Clinic 查询 | 只保留指标口径矛盾和人工核查要求 | 23375446 |
| `ST-2857` | 120034 | provider acquisition prohibited / supplied evidence unavailable | 未建立 IP—TiKV 映射和直接机制 | 23362487 |

汇总：7/7 run 状态为 `succeeded`；其中 4 个 case 实际产生 8 个 Clinic 多源 batch，共 46 条 bounded query：23 条完成、20 条为空、3 条失败。另 3 个 case 没有产生新的 Clinic batch，不能计为证据查询成功。

## Jira 与运行状态核验

- 7 条评论均使用原有 comment ID 原位更新；
- 7 条评论逐条从 JSM API 读回，均为 `public=false`；
- 5 条正文与数据库保存值逐字一致；另外 2 条仅由 Jira 将 Markdown 有序列表/行内代码转换为 wiki markup，语义正文一致；
- replay 完成后 `queued` / `running` job 均为 0；
- staging pod 为 1/1 Ready、0 restart，`/healthz` 与 `/readyz` 均返回 200；
- customer-visible reply 保持关闭。

## 最终判断

如果问题是“Investibook 查数据更好，但是诊断更弱吗”，部署后的答案是：

- **查数据层面：差距已经显著缩小。** Clinic 现在能真实取得 TopSQL、Slow Query、Loki、拓扑和指标；Investibook 不再天然拥有更宽的数据面。
- **原始调查叙述层面：Investibook 在 `ST-2864`、`TCID-13001` 仍更深。** 它更善于把附件或多源线索组织成一条可读的调查链。
- **最终诊断层面：Clinic 当前仍偏弱，而且弱点主要在证据压缩与 publication guard。** 已取得的事实可能因序列截断或整段安全改写而消失。
- **可靠性层面：两边都需要因果边界。** Investibook 有偏强归因风险，Clinic 则有过度保守并丢失已确认事实的风险。

所以不能下结论说本次部署已经让 Clinic 全面达到 Investibook 深度。更准确的是：**Clinic 的多源 evidence 查询能力已经验证有效；最终诊断深度只在 `ST-2863` 保持住，`ST-2864`、`TCID-13001` 和 `ST-2865` 仍暴露出明确缺口。**