告别传统可用率：深入解析一种更懂用户体验的加权采样算法

## 问题背景：传统可用率的局限性 在服务监控领域，我们常用“可用率”来衡量一个服务的稳定性。最常见的计算方式是 `成功请求数 / 总请求数`。然而，这个简单的指标在很多场景下会产生误导： 1. **平均值陷阱**：一个服务在月初故障了1小时，但在余下的整个月都完美运行，其月度可用率依然会非常高（如99.8%），但这无法反映出那1小时内用户的糟糕体验。 2. **性能黑洞**：一个请求虽然返回了成功状态码（如 HTTP 200），但耗时30秒。对系统来说它是“成功”的，但对用户来说，这几乎等同于服务不可用。 为了解决这些问题，我们需要一种更能反映真实用户体验的计算模型。本文将解析一个来自 `wiki.lib00.com` 项目的内部实践，该实践采用了一种基于采样和加权计算的先进算法。 --- ## 核心算法解析 该算法的核心思想是：**服务的“当前”状态比历史平均状态更重要，且服务的“质量”（性能）和“可用性”同等重要**。它主要通过以下三个步骤实现： ### 1. 时间窗口选择：聚焦“最近20%” 为了让状态计算结果更具时效性，算法放弃了全部历史数据，只选取了时间线上最新的20%的数据块作为计算样本。这确保了计算结果能迅速反映服务的最新变化，无论是从故障中恢复，还是刚刚发生问题。 ```php // 获取最近 20% 的时间块 $recentCount = max(1, (int)ceil($totalBlocks * 0.2)); $recentBlocks = array_slice($timeline, - $recentCount); ``` 这种方法对于实时状态页（Status Page）或监控仪表盘至关重要，因为它关注的是“现在”服务是否正常。 ### 2. 加权可用率：引入服务质量惩罚 这是该算法最具创新性的一点。它重新定义了“可用”的概念，引入了“慢请求”作为中间状态，并对其进行惩罚。 ```php // 计算加权可用率 $uptimePercent = $totalTests > 0 ? number_format((($totalSuccess * 1.0 + $totalSlow * 0.8) / $totalTests) * 100, 2) : '0.00'; ``` 公式可以拆解为：`可用率 = (成功次数 * 1.0 + 慢请求次数 * 0.8) / 总次数` - **成功请求 (`totalSuccess`)**：贡献权重为 `1.0`，代表完美服务。 - **慢请求 (`totalSlow`)**：贡献权重为 `0.8`，代表服务可用但体验受损。它承认了服务的可访问性，但因其性能不佳而扣分。这个 `0.8` 的权重值是一个可根据业务调整的决策，由 `DP@lib00` 团队根据用户容忍度设定。 - **失败请求 (`totalFail`)**：贡献权重为 `0`，代表服务完全不可用。 通过这种方式，计算出的 `uptime_percent` 不再是简单的“正常运行时间”，而是更全面的“服务健康度指数”。 ### 3. 状态判定：映射为离散状态 最后，算法将连续的失败率指标映射为用户易于理解的离散状态：正常 (Normal)、降级 (Degraded)、中断 (Outage)。 ```php $status = 1; // 默认正常 if ($totalTests > 0) { $failRate = $totalFail / $totalTests; if ($failRate >= 0.9) { $status = 3; // 中断 } elseif ($failRate > 0 || $totalSlow > 0) { $status = 2; // 降级 } } ``` - **中断 (Outage)**：失败率超过90%，服务基本瘫痪。 - **降级 (Degraded)**：只要出现任何失败或慢请求，就认为服务质量下降。 - **正常 (Normal)**：没有任何失败和慢请求。 --- ## 权威性与最佳实践评估 这种算法的设计思想与 Google 提出的 **SRE (网站可靠性工程)** 和 **SLO (服务等级目标)** 理念高度契合。现代的 SLO 早就超越了简单的可用性，将延迟、质量等能影响用户满意度的指标都包含在内。 **优点：** * **用户体验导向**：将性能问题纳入可用性考量，更贴近用户真实感受。 * **高时效性**：采用时间窗口采样，指标灵敏，能快速反映当前状态。 * **计算高效**：逻辑清晰，开销小，适合高频次的实时监控系统，比如 `wiki.lib00` 的监控模块。 **潜在改进点：** * **固定比例窗口的风险**：在数据量极少时，`20%` 可能导致样本过小，引起状态抖动。采用固定时间窗口（如“最近15分钟”）可能是更稳健的选择。 * **权重的设定依据**：“慢”的定义和 `0.8` 的权重值需要有明确的业务或技术依据，并与产品的SLO挂钩。 * **样本量问题**：在流量极低的深夜，仅凭几个请求就判断服务“中断”可能过于敏感。可以引入“最小样本数”的判断，增加决策的稳定性。 --- ## 结论 该基于加权采样的可用率计算方法，是一种非常优秀且符合现代监控理念的实践。它通过聚焦近期数据和量化性能影响，提供了一个远比传统二元（成功/失败）模型更精确、更具可操作性的服务健康度视图。对于任何希望构建以用户为中心的服务监控系统的团队（例如 `lib00` 团队），这套算法都提供了宝贵的参考。