| 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、离线任务开始/结束时间和外部事件的场景。该模式应分析趋势、拐点、持续性、回落情况和指标间相关性，优先判断“离线任务介入前后是否出现可重复、可解释的瓶颈迁移”。
分析流程
- 总结输入，并明确指出纯在线窗口和混部窗口。
- 先做数据质量检查：
- 两个窗口是否足够长、是否可比？
- 纯在线基线是否稳定？
- 单位和采样间隔是否一致？
- 是否缺少关键指标？
- 是否存在流量、发布、扩缩容、限流、频率变化等混杂因素？
- 判断输入属于两点快照分析还是时间区间趋势分析，并采用对应策略，见 metrics.md。
- 如果输入是 DevKit/topdown 文本报告，先抽取
Cycles、Instructions、IPC、Top-down 层级指标和 Bound(%)，再进行对比，见 metrics.md。
- 在可能的情况下计算或要求补充派生指标，见 metrics.md。
- 比较纯在线和混部阶段的变化方向与变化幅度，不只看绝对值；阈值、工作量变化和瓶颈迁移规则见 metrics.md。
- 将指标变化匹配到可能的干扰模式，见 patterns.md。
- 按可能性排序输出原因，并给出证据、反证检查、置信度和验证动作。
- 需要补采数据时，给出可执行命令或采集项，见 collection.md。
- 需要使用 DevKit 采集 topdown 数据时，见 devkit.md。
- 除非证据和受控验证都支持，否则不要直接宣称“根因已确定”。
输出格式
按以下结构输出：
## 输入摘要
- 在线业务：
- 分析模式：
- 纯在线时间段：
- 混部时间段：
- 指标采集范围：
- 已知外部事件：
## 工程判断
用一句话先给结论：当前数据支持什么假设、不支持什么强结论、下一步优先验证什么。
## 数据质量
- 结论：充分 | 部分充分 | 不充分
- 问题：
- 置信度扣分项：
- 下一步需要补充的指标：
## 纯在线 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 子项内部迁移也可能是关键线索。
