Loading... # GitHub 可用性危机分析：三个九都难以维持 # 一、新闻概述 ## 1. 标题 GitHub 在勉强维持三个九的可用性方面举步维艰 ## 2. 发布时间 2026 年 2 月 10 日 12:39 UTC ## 3. 来源 The Register（技术媒体） # 二、核心内容 ## 1. 事件摘要 ### A. 主要内容 GitHub 近期频繁出现服务中断和性能问题，其可用性甚至难以维持三个九（99.9%）的标准。 ### B. 核心亮点 - 2026 年 2 月 9 日发生多起服务故障 - Actions、Pull Requests、通知和 Copilot 全部受影响 - 通知延迟长达 50 分钟 - Copilot 策略传播问题持续 17 小时 - 2025 年某个时段正常运行时间曾降至 90% 以下 ## 2. 关键信息 ### A. 故障时间 2026 年 2 月 9 日 15:54 UTC 开始确认问题 ### B. 受影响服务 - GitHub Actions - Pull Requests - 通知服务 - GitHub Copilot ### C. 恢复时间 2026 年 2 月 9 日 19:29 UTC 确认恢复正常 ## 3. 背景介绍 ### A. 服务等级协议 GitHub Enterprise Cloud 的 SLA 规定 99.9% 的正常运行时间，但不对所有用户做出保证。 ### B. 行业标准 五个九（99.999% 的正常运行时间）是云计算行业的金标准，但许多供应商连 90% 都难以维持。 # 三、详细报道 ## 1. 主要故障事件 ### A. 2026 年 2 月 9 日服务中断 ```mermaid graph LR T1[15:54 UTC] --> A[确认部分 GitHub 服务出现问题] T2[16:29 UTC] --> B[Copilot 策略传播问题开始] T3[17:57 UTC] --> C[通知延迟降至约 30 分钟] T4[19:29 UTC] --> D[确认服务恢复正常] T5[次日 09:57 UTC] --> E[Copilot 问题完全解决] style T1 fill:#e1f5ff style T2 fill:#ffe1e1 style T3 fill:#fff4e1 style T4 fill:#e1ffe1 style T5 fill:#e1e1ff ```  **问题详情**： - 通知延迟：最高达 50 分钟 - Copilot 策略传播：新启用的模型无法在用户访问时显示 - 故障持续时间：约 3.5 小时（主要服务） - Copilot 故障：持续约 17 小时 ### B. 历史可用性问题 根据非官方重建的状态页面数据，GitHub 在 2025 年某个时段的正常运行时间曾降至 90% 以下。 ## 2. 技术细节 ### A. 可用性标准对比 | 可用性等级 | 正常运行时间 | 年度停机时间 | 适用场景 | |-----------|-------------|-------------|---------| | 一个九 | 90% | 36.5 天 | 消费级服务 | | 两个九 | 99% | 3.65 天 | 一般业务 | | 三个九 | 99.9% | 8.76 小时 | 企业服务（GitHub SLA） | | 四个九 | 99.99% | 52.56 分钟 | 高可用服务 | | 五个九 | 99.999% | 5.26 分钟 | 关键基础设施 | ### B. 状态页面变更 GitHub 更新了其状态页面的设计，使得以下操作变得更加困难： - 查看过去 90 天的整体运行情况 - 可视化服务的整体可用性 - 快速评估系统稳定性 ## 3. 相关事件 ```mermaid graph LR A[GitHub 服务问题] --> B[Actions 故障] A --> C[Pull Requests 故障] A --> D[通知延迟] A --> E[Copilot 故障] B --> F[CI/CD 中断] C --> G[代码协作受阻] D --> H[团队沟通延迟] E --> I[AI 编程助手失效] ```  # 四、影响分析 ## 1. 对开发者的影响 ### A. 开发工作流中断 - CI/CD 管道因 Actions 故障而停止 - 代码审查和合并流程受阻 - 团队协作效率下降 ### B. AI 编程辅助失效 - Copilot 服务中断影响开发者生产力 - 策略传播问题导致新模型无法访问 ## 2. 对企业客户的影响 ### A. SLA 争议 - Enterprise Cloud SLA 规定 99.9% 正常运行时间 - 实际可用性可能难以达到承诺标准 ### B. 业务连续性风险 - 频繁的服务中断影响关键开发项目 - 需要制定故障应急预案 ## 3. 行业影响 ### A. 云服务可靠性信任危机 - 云服务难以维持基本的可用性标准 - 五个九的承诺在现实中难以实现 ### B. 微软旗下服务稳定性质疑 - GitHub 作为微软子公司，其服务质量引发关注 - 与其他微软服务的稳定性问题相呼应 # 五、各方反应 ## 1. 用户反馈 - 社区对 GitHub 频繁故障表示不满 - 开发者担心依赖单一平台的风险 ## 2. 行业观察 - 云服务可靠性普遍下降 - 企业应规划故障应对策略 ## 3. 相关报道 - Zig 编程语言因微软 AI 痴迷而退出 GitHub - GitHub 计划对自托管运行器收费后撤回决定 # 六、经验教训 ## 1. 服务设计启示 ### A. 透明度问题 - 状态页面设计变更降低了透明度 - 用户难以评估服务的整体可用性 ### B. 监控与告警 - 需要独立的第三方监控 - 用户应自行监控关键服务 ## 2. 客户应对策略 ### A. 多平台部署 - 避免过度依赖单一代码托管平台 - 考虑自托管或混合部署方案 ### B. 故障预案 - 制定服务中断时的应急预案 - 建立离线工作能力 ## 3. 行业思考 ### A. SLA 现实性 - 供应商需要更现实的可用性承诺 - 客户应理性评估 SLA 条款 ### B. 可靠性投资 - 云服务商需要投资基础设施可靠性 - 简化架构以提高稳定性 *** ## 参考资料 1. [GitHub appears to be struggling with measly three nines availability - The Register](https://www.theregister.com/2026/02/10/github_outages/) 最后修改：2026 年 03 月 23 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏