2. 核心概念：延迟诊断的三大维度、资源边界定义与清单化验收的四个阶段

在“策略即代码”的交付体系中，API 延迟诊断不再是事后救火，而是交付前的资源边界清单化验收。要完成这一闭环，首先需要统一三个核心概念：延迟诊断的三大维度、资源边界的定义方法，以及清单化验收的四个阶段。本章将逐一拆解，为后续的策略编写与自动化验收奠定基础。

2.1 延迟诊断的三大维度：网络、计算、存储

任何一次 API 请求的端到端延迟，都可以被分解为三个独立的物理与逻辑维度。只有分维度测量，才能精准定位瓶颈，避免“头痛医脚”。

2.2 资源边界定义

资源边界是清单化验收的“度量单位”。没有清晰的边界，延迟诊断就会陷入“谁的锅”的争论。在策略即代码的框架下，资源边界必须满足以下三个属性：

• 可观测性（Observable）： 边界内的所有资源必须暴露可采集的延迟指标（如 P50/P99/P999、错误率、吞吐量）。
• 可隔离性（Isolatable）： 当边界内出现延迟异常时，能够通过熔断、限流、降级等手段进行局部止血，不影响全局。
• 可审计性（Auditable）： 边界的变更（如扩缩容、配置修改、代码发布）必须记录在案，并与延迟基线进行比对。

常见的资源边界定义示例：

2.3 清单化验收的四个阶段

清单化验收是将延迟诊断从“经验驱动”升级为“策略驱动”的关键流程。它包含四个递进阶段，每个阶段都对应明确的输入、动作与输出。

1. 阶段一：基线采集（Baseline Collection）
   • 输入： 已定义的资源边界清单。
   • 动作： 在无压力、无变更的稳定窗口期，采集每个边界的 P50/P99/P999 延迟、错误率、吞吐量。
   • 输出： 一份“黄金指标基线表”，作为后续验收的参考锚点。
2. 阶段二：策略注入（Policy Injection）
   • 输入： 基线表 + 业务 SLO 要求。
   • 动作： 将延迟阈值、熔断条件、限流规则编写为可执行的策略代码（如 OPA、Kubernetes VPA/HPA 配置）。
   • 输出： 策略即代码的 YAML/HCL 文件，与资源边界清单绑定。
3. 阶段三：预生产验证（Pre-Production Validation）
   • 输入： 策略代码 + 预生产环境的流量回放或压力测试。
   • 动作： 在预生产环境执行策略，验证策略是否按预期触发（如限流生效、熔断打开），并对比延迟指标是否在基线范围内。
   • 输出： 验证报告，标记“通过/不通过”的资源边界。
4. 阶段四：交付验收（Delivery Acceptance）
   • 输入： 验证报告 + 变更工单。
   • 动作： 只有所有资源边界均通过预生产验证，且延迟指标未出现退化，才允许将变更交付至生产环境。
   • 输出： 数字签名的“交付许可”，附带有清单化验收的完整审计日志。

2.4 阶段间的关键检查点

在每个阶段之间，建议设置以下检查点，防止问题向下游传递：

• 基线采集 → 策略注入： 检查基线数据是否覆盖所有资源边界，是否存在数据缺失或异常抖动。
• 策略注入 → 预生产验证： 检查策略代码是否通过语法校验和单元测试，是否与基线阈值一致。
• 预生产验证 → 交付验收： 检查验证报告中是否存在“不通过”的边界，是否已记录根因分析。