把 P99、错误率、连接池饱和度合成单一服务健康分时，线性加权几乎失效——你们线上用的是非线性格子还是分段扣分？阈值怎么定、怎么防指标间重复扣分？

【背景】 我做了 15 年技术文档，其中 8 年在帮团队搭指标体系与告警规则。最近接手一条核心交易链路（QPS ~5k，P99 基线 45ms，5xx 错误率基线 0.1%，HikariCP 池 50），想把三项指标合成一个 0–100 的"服务健康分"，用途有二：

1. on-call 值班时一眼判断"要不要升级 / 拉人"；
2. 周会复盘时量化"这周比上周好还是差"，给非技术 PM 一个可比较的数字。

【现象】 我试了最直觉的线性加权（P99 占 40%、错误率 30%、池饱和度 30%），跑了两周数据后发现两个硬伤：

• 池饱和度从 60% → 95% 只扣 30%×(95−60)/100 ≈ 10.5 分，分数从 100 掉到 89.5，值班的人看不出"pending 线程已经在堆积了"——实际风险已质变。
• P99 从 45ms 涨到 200ms（基线 4 倍），按"超出基线比例折算"只扣了约 31 分，分数 69，看起来"还行"，但用户侧已经大面积超时了。

根本原因：线性加权假设"每 1% 的恶化代价相同"，但服务退化是非线性的——80%→95% 的池饱和度风险远大于 50%→60%。

【已尝试与结果】 a) 线性加权：如上，分数变化太"温"，预警提前量不足。 b) 简单分段扣分（饱和度 <50 扣 10、50–80 扣 30、>80 扣 60）：方向对了，但边界（50、80）全凭经验拍，换个人接手就改，且三指标各自独立分段后没有"交叉效应"——池 90% + P99 200ms 同时出现时，分数没有体现出"这是同一个根因在双重表达"。 c) 参考了社区两篇高热度内容：《连接池不是越大越好》(id=18) 里关于 pending 线程与 active 占比的讨论，以及《线上告警挂哪个指标最靠谱：P99、错误率、QPS、CPU——我见过 5 种流派》(id=1511) 里"不要只看一个指标"的共识。思路认同，但两篇都没给出"怎么把多个指标合成一个分数"的具体方法。

【期望得到的答案形态】

1. 合成方法：你们线上（或你维护过的系统）把多项指标合成单一分数时，具体用的是哪种——非线性格子（2D/3D 查表）、分段扣分（每段斜率递增）、sigmoid/logistic 映射、还是其他？请说清选型理由。
2. 阈值/格子怎么定：基于 90 天历史 P99 分布回测？SLO burn rate？还是 PM 拍板？有没有"用历史事故数据反推格子边界"的具体步骤（哪怕 3 步即可）？
3. 指标间相关性 / 重复扣分：池饱和度高和 P99 高通常指向同一个根因（连接池瓶颈），分数会不会"双重惩罚"导致分数虚低？你们怎么处理——去相关（只取其一）、降权、还是接受重复扣分当作"严重度加成"？
4. 可复现最小例子：给一段 Python 伪代码或 SQL（哪怕 20 行），让新团队能照着搭出第一版，再迭代。

我倾向的非线性方案是：对每个指标做 piecewise-linear 映射（0–100 → 0–10 扣分），斜率随恶化程度递增；再做 2D 交叉格子（如"池饱和度 × P99 超出比"）捕捉联合恶化。但这个方案我没有线上验证过，想听你们踩过的坑。