同一个 P99，三种口径算出三个结论：指标定义该「全公司一张标准」还是「分场景各算各的」？

【背景】 做了 15 年技术文档，后来一头扎进指标体系搭建，踩得最多的坑不是算法，而是「口径」。举个真实到不能再真实的场景：同一套订单服务，同一个 P99，三个团队算出三个数——

• 网关侧按请求维度算，窗口 5 分钟，P99 = 86ms；
• 业务侧按「用户会话」聚合（一次会话内多次请求取最慢），P99 = 210ms；
• SRE 侧按副本分位（每个副本各算 P99 再取中位），P99 = 64ms。 三个数都对，但结论完全相反：网关团队说「达标」，业务团队说「劣化 40%」，SRE 说「很健康」。最后升级到我老板那里，花了一周才对齐。这不是个例，我换过三家团队，家家的 dashboard 上「同名指标」都能拆出 2~4 套算法。

【常见分歧，我观察到的三种做法】

1. 「全公司一张标准」派：指标字典统一管理，P99 就是 P99，谁都不能自定义。优点是跨团队可对比、汇报不扯皮；代价是长尾低频接口（一天几百个请求）用全局窗口算分位数基本是噪声，标准一统反而逼着大家「不用这个指标」。
2. 「分场景各算各的」派：每个服务按自身流量特征定窗口和聚合维度。优点是数字贴合业务真实体感；代价就是上面那出戏——同名不同义，跨团队拉通时全部要重新翻译。
3. 「分层命名」派：P99 只保留给网关侧的对外口径，内部一律叫 p99-per-replica、p99-per-session，用命名强制区分。优点是机器可读、歧义被挡在名字里；代价是指标数量膨胀，新人上手要先背一套命名法。

【我的倾向与理由】 我站第三种，但加一条硬约束：指标字典里每个指标必须带三样元数据——聚合维度（per-request / per-session / per-replica）、窗口长度、最小样本量。理由有两点：

• 从取舍看，「一张标准」省的是认知成本，赔的是数据有效性；「各算各的」保了有效性，赔的是可对比性。命名分层是唯一把两笔账都记在明面上的做法。
• 从落地看，口径问题 90% 不在计算层，在「沟通层」。名字不同，开会时就没人敢直接拿两个数比；名字相同，才会出现「你说达标我说劣化」的扯皮。让歧义显性化，比消灭歧义便宜得多。 当然这有代价：指标字典的维护成本会上升，谁来审、谁负责废弃旧口径，这恰恰是「一张标准」派最有力的反方论点——没有 owner 的指标字典最后都会烂掉。

【想听大家怎么选】

1. 你们团队的 P99 到底按什么维度、什么窗口算？有没有出现过「同名不同义」引发的事故或扯皮？
2. 低频接口（日请求量 < 1 万）的分位指标你们怎么处理——降采样、TopK、还是干脆只报超阈值计数？
3. 指标字典有没有 owner？没有 owner 的口径约定，你们靠什么机制让它活过半年？
4. 如果让你只给新团队定一条指标规范，你定哪条？