当我们谈论一个服务的可用性时，「三个九」这个数字频繁出现在 SLA（Service Level Agreement，服务等级协议）中。99.9% 看起来是一个很漂亮的数字，但如果将其转化为实际的停机时间，这个承诺的工程含义就变得具体而现实了。本文从 SLA 数学出发，结合近期 GitHub 可用性争议，深入分析可用性承诺背后的业务与技术权衡。

三个九的数学含义

要理解 99.9% 可用性的真实含义，首先需要进行简单的数学换算。一年有 365 天、8760 小时、525600 分钟。99.9% 可用性意味着在全部可用时间中，服务有 0.1% 的时间处于不可用状态。

年度停机时间的计算公式为：年度总分钟数 × (1 - 可用性百分比)。对于 99.9%，计算过程为 525600 × 0.001 = 525.6 分钟，约等于 8 小时 45 分 36 秒，这就是工程实践中常说的 8.76 小时。折算到每月，大约是 43.8 分钟；折算到每周，大约是 10 分钟。这个数字是 SLA 承诺的「预算」，一旦实际停机超过这个时间，服务商就可能触发赔偿条款。

值得注意的是，这个计算基于全年连续运行的前提。如果服务并非 24×7 全天候运行，例如某些只在工作时间活跃的企业内部系统，计算方式需要调整。但在云服务的语境下，标准做法是以自然年或日历季度为计量周期，SLA 通常按季度考核。

不同可用性级别的对比

为了更好地理解三个九在可用性谱系中的位置，有必要将其与更高和更低的 SLA 级别进行对比。两个九（99%） 意味着每年约 87.6 小时（超过 3.5 天）的停机时间，这个级别通常被认为难以满足企业级需求。三个九（99.9%） 是大多数 SaaS 服务的标准承诺，属于「够用但不惊艳」的水平。四个九（99.99%） 对应每年约 52.56 分钟的停机时间，这需要显著的工程投入，通常只有核心基础设施服务才会承诺。五个九（99.999%） 意味着每年仅 5.26 分钟停机，这是电信级和金融交易系统的专属领地。

从三个九提升到四个九，可不是简单地优化一下代码就能实现。所需投入大约是原来的十倍：需要更完善的冗余设计、更精细的故障隔离、更快速的自动恢复机制，以及更严格的变更管理流程。这也就是为什么大多数面向开发者的 SaaS 工具选择三个九作为甜点区间。

GitHub 可用性争议的启示

2026 年初，GitHub 经历了多次引人关注的宕机事件。根据 The Register 论坛的讨论，GitHub 在 2025 年 10 月的可用性一度跌破 90%，实际停机时间超过 14 小时，这远低于其宣称的 99.9% 承诺。一位用户在论坛中指出，按照 GitHub 自己的状态页数据，2025 年 10 月其多个核心组件的可用性仅为 89.9%，这意味着该月的实际可用性甚至低于两个九。

GitHub 的 SLA 条款规定了服务补偿机制：当季度可用性在 99.0% 至 99.9% 之间时，客户可获得 10% 的服务额度返还；当可用性低于 99.0% 时，返还比例提升至 25%。然而，这种补偿对于依赖 GitHub 进行日常开发的团队来说杯水车薪。一次数小时的宕机可能导致整个团队的 CI/CD 流水线停滞、代码合并受阻、版本发布延迟 —— 这些隐性成本远超服务补偿的价值。

从技术角度看，GitHub 近年来在推进从自有基础设施向 Azure 的大规模迁移。根据 The New Stack 的报道，GitHub 内部文档显示这一迁移的优先级甚至高于新功能开发，原因是其位于弗吉尼亚的数据中心容量已经触及瓶颈。MySQL 集群等核心组件的迁移尤其复杂，这在一定程度上解释了近期稳定性下降的原因。

工程投入与业务预期的平衡

对于工程团队而言，理解 SLA 的数学含义是做出合理可用性承诺的前提。三个九看似是一个保守的目标，但实现它需要一系列基础设施保障：多区域冗余部署、自动故障检测与恢复、灰度发布与快速回滚能力、完善的监控告警体系。这些能力缺一不可。

然而，可用性并非越高越好。需要根据业务场景进行权衡。对于一个面向消费者的营销网站，95% 的可用性可能已经足够，因为用户对暂时无法访问的容忍度较高。但对于核心 CI/CD 系统、代码仓库这类研发基础设施，停机直接导致生产力停滞，此时三个九是最基本的要求，如果有条件应争取四个九。

另一个容易被忽视的因素是「碎片化停机」与「集中停机」的区别。假设全年有 8 小时停机时间，如果均匀分散在每周 10 分钟左右，对团队的持续干扰可能比一次 8 小时的集中宕机更大。前者让人始终处于「不知道什么时候会出问题」的焦虑中，后者虽然影响剧烈但至少可以提前安排应对。评估可用性时，不应只看总时长，还要考虑停机的分布模式。

面向开发者的实操建议

作为依赖 SaaS 服务的开发者，有几个具体的实践可以降低单一服务故障对自己的影响。首先，建立本地镜像或备份机制。对于代码仓库这类核心资产，定期同步到自建的 GitLab 实例或其他托管服务可以在主服务宕机时快速切换。其次，将关键流水线多样化。如果你的 CI/CD 严重依赖 GitHub Actions，考虑同时配置 Jenkins、GitLab CI 或其他备用方案，确保在 Actions 不可用时仍能完成构建与部署。

在 SLA 评估层面，关注服务商的可用性历史而非仅仅看承诺数字。GitHub 的案例表明，承诺三个九并不意味着实际达到三个九。查阅服务商的历史状态页、第三方监控数据（如 DownDetector）、社区反馈，都是评估可靠性的有效手段。对于高 SLA 要求的核心系统，在合同中明确赔偿条款也至关重要 —— 虽然赔偿无法完全弥补业务损失，但至少能在财务层面形成约束。

最后，对于团队管理者，明确业务连续性策略。当 GitHub 宕机时，团队是否有预案？是否可以暂时改为本地开发？是否有替代的代码审查流程？这些问题的答案不取决于服务商承诺的 SLA 等级，而取决于团队自身的风险管理意识。

总结

99.9% 可用性意味着每年约 8.76 小时的停机预算，这个数字看似不大，但对于高频依赖研发工具的团队而言，每一次意外的宕机都可能打乱工作节奏。GitHub 的案例提醒我们，即便是行业头部服务商，其实际可用性也可能与承诺存在显著落差。理解 SLA 的数学含义不是为了接受低可用性，而是为了在此基础上做出更理性的工程决策：在合理成本范围内追求更高的可靠性，同时为不可避免的故障做好准备。

参考资料