#可用性定义与度量

你所在公司的系统可用性是多少？「五个 9」「四个 9」——这些数字听起来很厉害，但它们到底意味着什么？

• 四个 9（99.99%）：全年允许约 52 分钟的不可用时间
• 五个 9（99.999%）：全年只允许约 5.3 分钟的不可用时间

看起来差距不大？实际上差了 10 倍。大多数互联网公司能达到三个 9 就已经不错了，要稳定维持五个 9，需要付出的成本是三个 9 的数倍甚至数十倍。

#可用性的数学定义

#经典公式

可用性 = 系统正常工作时间 ÷ (系统正常工作时间 + 系统故障时间) × 100%

这个公式看起来很简单，但「系统正常工作时间」和「系统故障时间」的定义往往比想象中复杂：

• 计划内停机算不算？数据库升级、代码发布，这些算故障吗？
• 部分功能不可用算吗？购物车能用但支付失败，算系统不可用吗？
• 响应变慢算吗？系统还在响应，但 TP99 延迟从 50ms 飙升到 5s，用户体验已经严重下降。

#不同的度量维度

可用性不是单一指标，而是多个维度的综合：

绝大多数情况下，我们讨论的「可用性」默认指请求维度的可用性，即成功请求占总请求的比例。

#可用性计算示例

#场景一：时间维度

假设一个系统在一个月内有如下记录：

• 计划内维护：2 小时（数据库升级）
• 计划外故障：30 分钟（服务器宕机）

total_minutes = 30 * 24 * 60  # 43200 分钟
available_minutes = total_minutes - 120 - 30  # 42950 分钟
availability = available_minutes / total_minutes  # 99.65%

#场景二：请求维度

total_requests = 1_000_000
failed_requests = 50
availability = (total_requests - failed_requests) / total_requests  # 99.995%

#两种维度的差异

同样是 99.65% 的可用性：

• 时间维度：整个系统在 99.65% 的时间内可用
• 请求维度：系统在 99.65% 的请求中正常响应

这两种维度的含义不同。如果系统长时间正常但在某次故障中大量请求失败，请求维度的可用性会明显低于时间维度。反之亦然。

#可用性等级（行业标准）

业界通常用「N 个 9」来表示可用性等级：

#不同等级适用的场景

#可用性度量中的常见陷阱

#陷阱一：只算故障时间，不算故障范围

系统宕机 10 分钟，全站不可用，可用性受损严重。但如果只是某个边缘功能不可用，影响范围小得多，但「可用性」数字可能看起来一样差。

正确做法：区分不同服务的可用性，对核心路径单独计算。

#陷阱二：忽略响应质量

系统虽然在响应，但 TP99 延迟从 50ms 变成 5s——用户体验已经很差了，但按照「请求成功就算正常」的标准，可用性数字没有变化。

正确做法：引入延迟相关的 SLA，结合可用性和响应质量综合评估。

#陷阱三：平均主义掩盖峰值问题

假设系统 99% 的时间完美运行，但某次 1% 的时间窗口内有 50% 的请求失败。平均下来可用性仍然「看起来不错」，但这段时间的用户体验是灾难性的。

正确做法：引入 SLI 细粒度指标，监控滑动窗口内的可用性，而不仅仅是总体平均值。

#测量可用性的工具链

#监控系统

# Prometheus 告警规则示例：可用性监控
groups:
- name: availability
  rules:
  # 5xx 错误率超过 0.1% 立即告警
  - alert: HighErrorRate
    expr: |
      sum(rate(http_requests_total{status=~"5.."}[5m]))
      / sum(rate(http_requests_total[5m])) > 0.001
    for: 1m
    labels:
      severity: critical

  # 可用性低于 99.9% 告警
  - alert: AvailabilityBelowSLO
    expr: |
      (1 - sum(rate(http_requests_total{status=~"5.."}[1h]))
      / sum(rate(http_requests_total[1h]))) < 0.999
    for: 5m
    labels:
      severity: warning

#外部监测

内部监控只能测内部视角，还需要外部监测工具（如 Cloudflare、Better Uptime）从真实用户视角测量可用性。

#本章总结

核心要点：

1. 可用性 = 正常运行时间 ÷ 总时间，但「正常运行」的边界需要明确定义
2. N 个 9 是行业标准，每提升一个 9，成本往往呈指数增长
3. 可用性是多维度的：时间、请求、数据、功能，维度不同结论不同
4. 平均数掩盖峰值问题：滑动窗口细粒度监控比总体平均更有价值
5. 可用性需要结合延迟：只有可用性数字不够，响应质量同样重要

理解可用性的定义和度量方法，是制定 SLA、设计容错机制的基础。下一节我们将深入 SLA 的制定和谈判。