colocation-interference-analysis

name	colocation-interference-analysis
description	用于分析离在线混部后的在线业务性能劣化、混部干扰、微架构计数器、PMU/topdown 指标、缓存压力、内存带宽、IPC 下降、纯在线基线与混部阶段对比等场景；单纯在线性能优化、无混部对比、只做通用 perf 调优时不要触发。

混部微架构干扰分析

概述

当用户提供在线业务在“纯在线阶段”和“混部阶段”的微架构指标时，使用本技能分析离线负载是否可能对在线业务造成干扰。结论应以“假设”形式给出，并明确证据、置信度、缺失信息和验证动作，不要在证据不足时直接判定根因。

必要输入

在做因果判断前，先确认是否缺少以下信息：

• 业务背景：在线服务类型、关注的延迟/吞吐目标、为什么对性能敏感。
• 纯在线时间段：只有在线业务运行的基线窗口。
• 混部时间段：离线负载启动后的对比窗口。
• 分析模式：两点快照分析，或时间区间趋势分析。
• 指标数据：原始计数器、派生指标，或 DevKit/topdown 这类文本报告；最好包含时间戳、采样时长和单位。
• 采集范围：节点、NUMA 节点、CPU core、进程、容器或 Pod。
• 已知事件：流量变化、扩缩容、重启、CPU 频率变化、迁移、发布、内核变化、限流、NUMA 位置变化等。

可选但很有价值的信息：

• 同一时间窗口内的在线业务 SLO/SLA 趋势。
• 离线负载类型以及启动/结束时间。
• CPU 型号和架构。
• cgroup 限制、cpuset、CPU manager 策略、NUMA 策略、缓存分区、MPAM/RDT/CAT 配置。

分析模式

模式一：两点快照分析

适用于没有部署监控系统、只能分别提供一次纯在线 topdown 报告和一次混部 topdown 报告的场景。该模式只能比较两个采样点的差异，重点是快速形成干扰假设和下一步验证计划。置信度通常不应超过“中”，除非两个采样窗口可比、外部混杂因素很少，并且业务 SLO 在混部窗口同步劣化。

模式二：时间区间趋势分析

适用于已部署监控系统，能够提供一段时间内连续 topdown 指标、在线业务 SLO、离线任务开始/结束时间和外部事件的场景。该模式应分析趋势、拐点、持续性、回落情况和指标间相关性，优先判断“离线任务介入前后是否出现可重复、可解释的瓶颈迁移”。

分析流程

1. 总结输入，并明确指出纯在线窗口和混部窗口。
2. 先做数据质量检查：
   • 两个窗口是否足够长、是否可比？
   • 纯在线基线是否稳定？
   • 单位和采样间隔是否一致？
   • 是否缺少关键指标？
   • 是否存在流量、发布、扩缩容、限流、频率变化等混杂因素？
3. 判断输入属于两点快照分析还是时间区间趋势分析，并采用对应策略，见 metrics.md。
4. 如果输入是 DevKit/topdown 文本报告，先抽取 Cycles、Instructions、IPC、Top-down 层级指标和 Bound(%)，再进行对比，见 metrics.md。
5. 在可能的情况下计算或要求补充派生指标，见 metrics.md。
6. 比较纯在线和混部阶段的变化方向与变化幅度，不只看绝对值；阈值、工作量变化和瓶颈迁移规则见 metrics.md。
7. 将指标变化匹配到可能的干扰模式，见 patterns.md。
8. 按可能性排序输出原因，并给出证据、反证检查、置信度和验证动作。
9. 需要补采数据时，给出可执行命令或采集项，见 collection.md。
10. 需要使用 DevKit 采集 topdown 数据时，见 devkit.md。
11. 除非证据和受控验证都支持，否则不要直接宣称“根因已确定”。

输出格式

按以下结构输出：

## 输入摘要

- 在线业务：
- 分析模式：
- 纯在线时间段：
- 混部时间段：
- 指标采集范围：
- 已知外部事件：

## 工程判断

用一句话先给结论：当前数据支持什么假设、不支持什么强结论、下一步优先验证什么。

## 数据质量

- 结论：充分 | 部分充分 | 不充分
- 问题：
- 置信度扣分项：
- 下一步需要补充的指标：

## 纯在线 vs 混部指标变化

| 指标 | 纯在线 | 混部 | 变化 | 解释 |
|---|---:|---:|---:|---|

## Top-down 层级变化

| 层级 | 指标 | 纯在线 Bound(%) | 混部 Bound(%) | 变化 | 解释 |
|---|---|---:|---:|---:|---|

## 瓶颈迁移判断

| 判断项 | 结论 |
|---|---|
| 一级瓶颈是否恶化 | |
| Backend 内部是否迁移 | |
| Memory 内部是否迁移 | |
| 是否支持混部干扰 | |

## 趋势分析

- 仅在时间区间趋势分析模式下输出。
- 离线任务介入前后的拐点：
- 是否持续劣化：
- 离线任务结束后是否回落：
- 与在线 SLO 的相关性：
- 主要瓶颈迁移：

## 可能的干扰模式

| 排名 | 模式 | 置信度 | 证据 | 反证检查 |
|---:|---|---|---|---|

## 分析

用清晰语言解释证据链。明确区分“观测事实”和“推断原因”。

## 验证计划

按诊断价值和实施成本排序列出下一步检查或实验。

## 缓解建议

只在验证计划之后列出有针对性的缓解动作。

置信度规则

• 高：多个独立指标指向同一类干扰，主要混杂因素已排除，并且在线业务 SLO 在同一窗口内发生变化。
• 中：指标趋势与某类干扰一致，但缺少一个关键反证检查或关键上下文。
• 低：只有单个弱信号，基线不稳定，或负载/流量在同一时间发生变化。

机械扣分规则：

• 只有两点快照：最高为中。
• 没有 SLO/QPS：最高为中低，只能分析微架构变化，不能确认业务影响。
• Instructions 变化超过 10%，且没有 request 归一化指标：降一级。
• PID、容器、采集范围或 CPU/NUMA 位置不一致：降一级。
• 没有 CPU 时间、频率或 cgroup throttling 数据：不能强判 CPU 算力竞争。
• 没有 LLC、内存带宽或 NUMA 数据：不能强判内存层级根因。

常见误区

• 不要把所有 IPC 下降都归因于 CPU 算力竞争；cache miss、内存带宽、频率、限流和 NUMA 都可能导致 IPC 下降。
• 不要直接比较不同时长窗口的原始计数器总量；应按时间、指令数、请求数或 CPU 时间归一化。
• 不要忽略在线流量变化；QPS 或请求类型变化可能伪装成混部干扰。
• 不要过度依赖单个 PMU 指标；优先构建跨 IPC、cycles、stall、cache、memory、branch、frequency 和 SLO 的证据链。
• 不要在提出验证实验之前给出泛化的缓解建议。
• 不要把两点快照分析包装成趋势分析；没有连续数据时，只能说明两个采样窗口的差异。
• 不要把父节点 Bound 的小幅变化误读为所有子项都稳定；Top-down 子项内部迁移也可能是关键线索。