# 三个九 SLA 的数学真相：8.76 小时停机意味着什么 > 从 99.9% 可用性的 8.76 小时年度停机时间出发，分析 SLA 承诺与工程投入的权衡，给出面向开发者的实操参数。 ## 元数据 - 路径: /posts/2026/03/23/github-three-nines-sla-math/ - 发布时间: 2026-03-23T22:50:06+08:00 - 分类: [systems](/categories/systems/) - 站点: https://blog.hotdry.top ## 正文 当我们谈论一个服务的可用性时，「三个九」这个数字频繁出现在 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 的数学含义不是为了接受低可用性，而是为了在此基础上做出更理性的工程决策：在合理成本范围内追求更高的可靠性，同时为不可避免的故障做好准备。 --- **参考资料** - The Register: [GitHub appears to be struggling with measly three nines availability](https://forums.theregister.com/forum/all/2026/02/10/github_outages/) - GitHub Docs: [GitHub Enterprise Service Level Agreement](https://docs.github.com/en/site-policy/site-policy-deprecated/github-enterprise-service-level-agreement) - Uptimia: [How much downtime is "three nines" (99.9%)?](https://www.uptimia.com/three-nines) ## 同分类近期文章 ### [好奇号火星车遍历可视化引擎：Web 端地形渲染与坐标映射实战](/posts/2026/04/09/curiosity-rover-traverse-visualization/) - 日期: 2026-04-09T02:50:12+08:00 - 分类: [systems](/categories/systems/) - 摘要: 基于好奇号2012年至今的原始Telemetry数据，解析交互式火星地形遍历可视化引擎的坐标转换、地形加载与交互控制技术实现。 ### [卡尔曼滤波器雷达状态估计：预测与更新的数学详解](/posts/2026/04/09/kalman-filter-radar-state-estimation/) - 日期: 2026-04-09T02:25:29+08:00 - 分类: [systems](/categories/systems/) - 摘要: 通过一维雷达跟踪飞机的实例，详细剖析卡尔曼滤波器的状态预测与测量更新数学过程，掌握传感器融合中的最优估计方法。 ### [数字存算一体架构加速NFA评估：1.27 fJ_B_transition 的硬件设计解析](/posts/2026/04/09/digital-cim-architecture-nfa-evaluation/) - 日期: 2026-04-09T02:02:48+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析GLVLSI 2025论文中的数字存算一体架构如何以1.27 fJ/B/transition的超低能耗加速非确定有限状态机评估，并给出工程落地的关键参数与监控要点。 ### [Darwin内核移植Wii硬件：PowerPC架构适配与驱动开发实战](/posts/2026/04/09/darwin-wii-kernel-porting/) - 日期: 2026-04-09T00:50:44+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析将macOS Darwin内核移植到Nintendo Wii的技术挑战，涵盖PowerPC 750CL适配、自定义引导加载器编写及IOKit驱动兼容性实现。 ### [Go-Bt 极简行为树库设计解析：节点组合、状态机与游戏 AI 工程实践](/posts/2026/04/09/go-bt-behavior-trees-minimalist-design/) - 日期: 2026-04-09T00:03:02+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析 go-bt 库的四大核心设计原则，探讨行为树与状态机在游戏 AI 中的工程化选择。