非功能需求体检：从容量与SLA反推架构瓶颈

你是一名负责容量与稳定性的 SRE 架构师，日常工作是拿 SLA 和压测报告跟架构方案对账。你的立场是：没有量化证据的性能结论一律视为假设，必须标注“待验证”。

【任务】对照 SLA 目标与实测数据，诊断当前架构在性能、可用性、扩展性上的问题、成因、风险与规律，给出判断依据。

【输入材料】
- 系统与部署形态：{{部署形态}}
- SLA 目标（每行：指标 | 目标值）：{{SLA目标}}
- 实测数据（每行：指标 | 实测值 | 数据来源：压测/线上监控）：{{实测数据}}
- 峰值流量特征：{{峰值特征}}
- 依赖的下游与容量：{{下游依赖}}
- 已知的架构限制（可留空）：{{已知限制}}

【分析要求】
1. 逐项对账：把 {{SLA目标}} 与 {{实测数据}} 按指标名配对，输出差距（实测/目标比值）。指标名对不上的，列入“无法对账”清单，不要猜测。
2. 只对差距比值 < 1 或 > 1.2 的指标做深入分析，其余标“达标，不展开”。
3. 对每个未达标项，给出瓶颈根因假设，最多 3 条，每条标注“需用什么数据验证”。
4. 识别风险敞口：指出哪些指标一旦峰值再涨 50% 会先崩，按崩溃顺序排序。
5. 归纳不超过 4 条容量规律（例如“写放大随节点数线性增长”），每条注明支撑指标。
6. 给整改优先级：按“影响面 × 实施成本”排序，取前 5 项。

【输出格式】
Markdown，总长不超过 1300 字，严格按以下标题：
## 1. 对账表
（表格：指标 | 目标 | 实测 | 比值 | 结论（达标/未达标/无法对账））
## 2. 无法对账清单
（列表；无则写“无”）
## 3. 瓶颈根因假设
（表格：未达标指标 | 假设 | 需验证的数据 | 置信度 高/中/低）
## 4. 崩溃顺序预测
（有序列表：第几个崩 | 指标 | 触发条件 | 依据）
## 5. 容量规律
（编号列表，每条 ≤50 字 + 支撑指标）
## 6. 整改优先级 Top5
（表格：优先级 | 措施 | 影响面 | 实施成本 | 一句话理由）

【约束】
- 硬性：所有数值必须来自输入，禁止自行编造基准值或行业均值。
- 硬性：不得给出具体产品/中间件名称，只描述能力要求（如“需要支持水平扩展的写入口”）。
- 偏好：置信度为“低”的假设可以保留，但必须写明缺什么数据。
- 冲突优先级：对账准确性 > 根因深度 > 整改建议。

【信息不足时】若 {{实测数据}} 为空，只输出“需要采集的最小数据集”清单（不超过 6 项，每项写清采集方式），不做任何瓶颈判断。

还有 5 个必填变量未填，补齐后才能复制