📚 课程目录第4章需求分析

4. 需求分析：如何从业务方获取准确、可量化的发布健康需求，避免歧义

发布健康口径的起点不是数据表，而是业务方口中的“我感觉这次发布有问题”。如果需求分析阶段没有消除歧义，后续的 Metric Design 无论多精妙，都会沦为“精确的错误”。本章聚焦于将模糊的“健康”诉求转化为可量化、可验证的指标需求。

4.1 歧义的三大来源

业务方与数据团队对“发布健康”的理解差异，通常来自以下三个维度：

歧义维度	业务方常见表述	数据团队理解陷阱
时间边界	“发布后马上看效果”	误以为“发布完成时刻”即为观察起点，忽略流量灰度、缓存预热等延迟
用户范围	“所有用户都没问题”	未区分实验组/对照组、灰度批次、白名单用户与全量用户
健康定义	“系统稳如老狗”	缺少具体阈值（如 P99 延迟 < 200ms）、对比基准（如环比前一周同时段）

常见反例： 业务方说“发布后错误率没涨”，数据团队直接取全量用户 24 小时平均错误率。结果灰度 10% 流量时错误率已翻倍，但被全量平均掩盖。根源在于未约定“观察窗口”和“对比基线”。

4.2 需求分析四步法：从“感觉”到“公式”

我们总结了一套标准化的需求分析流程，确保每次沟通都能产出可量化的指标定义。

界定发布单元： 明确是代码变更、配置变更还是模型更新？变更范围是单个服务、微服务群还是前端页面？
约定观察窗口： 确定“发布后”的起始时间（如灰度 10% 后 5 分钟）和结束时间（如全量后 2 小时），以及对比基准期（如发布前 1 小时）。
定义健康维度： 从可用性、性能、正确性、用户体验四个维度分别提问，避免笼统的“健康”。
量化阈值与对比逻辑： 每个维度必须附带“比较对象”（如 vs 基线、vs 上版本）和“判定条件”（如值 < X 或变化率 < Y%）。

实战技巧： 在需求文档中强制要求业务方填写“指标公式模板”：
[指标名称] = [分子] / [分母] ，在 [观察窗口] 内，对比 [基准期] ，阈值 [条件] 。
例如：发布错误率 = 发布后 P99 错误请求数 / 总请求数，在灰度 50% 后 10 分钟内，对比发布前 10 分钟，阈值 < 0.1%。

4.3 需求结构化：健康维度分解矩阵

将模糊的“发布健康”拆解为四个可独立量化的维度，每个维度对应一组典型指标和判定逻辑：

健康维度	核心问题	典型指标示例	量化判定逻辑
可用性	服务是否正常响应？	请求成功率、5xx 占比	成功率 ≥ 99.9% 且 5xx < 0.1%
性能	响应速度是否劣化？	P50/P95/P99 延迟	P99 延迟涨幅 ≤ 5%（vs 基线）
正确性	业务逻辑是否正常？	订单创建成功率、数据一致性校验通过率	核心业务成功率 ≥ 99.5%
用户体验	用户是否感知到异常？	JS 错误率、首屏时间、用户退出率	JS 错误率 < 0.5%，首屏时间涨幅 < 10%

4.4 需求分析流程可视化

下图展示了从业务方原始诉求到可量化指标定义的完整转换路径：

4.5 需求文档模板：避免遗漏的关键字段

每次需求沟通后，必须输出结构化的需求文档。以下字段缺一不可：

指标名称： 业务方和数据团队共同认可的名称，如“发布后核心接口错误率”。
指标公式： 明确分子、分母、聚合方式（如 sum、avg、percentile）。
发布单元标识： 用于关联变更记录（如 Git commit ID、发布单号）。
观察窗口： 起始时间偏移量、结束时间偏移量、窗口粒度（如 1 分钟）。
基线窗口： 对比基准的时间段，必须与观察窗口同维度（如同时段、同星期几）。
用户范围： 实验组/对照组、灰度批次、地域过滤条件。
判定阈值： 值或变化率，以及持续时长（如连续 3 个数据点超过阈值）。
告警级别： P0/P1/P2，对应不同的响应 SLA。

  最佳实践： 在需求评审会上，使用“反向验证法”——让业务方用自己定义的指标公式，手动计算一次历史发布的健康状态，看是否符合直觉。如果计算结果与业务方感受不一致，说明公式或阈值需要调整。

4.6 常见需求分析陷阱与应对

陷阱	表现	应对策略
幸存者偏差	只关注成功请求，忽略超时或失败的请求	强制要求指标分母包含所有请求，包括超时和异常
窗口漂移	观察窗口随发布时间动态变化，导致对比不公平	固定使用“发布完成时刻”作为 T0，所有窗口基于 T0 计算
指标堆砌	一次需求列出 20+ 个指标，无人关注核心	限定每个发布单元最多 5 个核心指标，其余作为辅助
阈值模糊	“错误率不能太高”	强制填写具体数值，并注明是值还是变化率