GitHub 1個月崩了3次，99.9% uptime成了笑話

「Scarcely a day goes by without an outage at a cloud service. Forget five nines – the way things are going, one nine is looking like an ambitious goal.」

這是 The Register 的原話。翻譯過來：云服務現在幾乎天天崩，別想什么五個9了，能保住一個9（90%可用性）都算你志向遠大。

GitHub 這個月把這個黑色幽默變成了現實。

2月9日：一次"小故障"的4小時劇本

UTC 時間 15:54，微軟的這只"觸手"（The Register 的毒舌用詞）終于承認"部分 GitHub 服務"出了問題。Actions、Pull Request、通知系統、Copilot，全線中招。

官方措辭很克制："通知延遲約50分鐘"。

到 17:57，延遲"優化"到了30分鐘。直到 19:29 才宣布恢復正常——從發現問題到完全恢復，將近4個小時。對于全球寫代碼的人來說，這就是半個工作日的蒸發。

但這還沒完。

Copilot 的麻煩持續到第二天。從 2月9日 16:29 到 2月10日 09:57，整整17個半小時，部分用戶的策略同步出問題。GitHub 的原話是：「這可能導致新啟用的模型在用戶嘗試訪問時無法顯示」。

翻譯：你花錢買了新功能，但系統不讓你用。

99.9% uptime承諾 vs 90%現實

GitHub 企業版 SLA 寫的是 99.9% 可用性。按這個標準，全年停機時間不能超過 8.76 小時。

但第三方重建的狀態頁數據顯示，2025年某個時間點，GitHub 的可用性跌破了 90%。

這里有個細節：GitHub 改過狀態頁設計，把歷史趨勢藏得更深了。細節確實都在，但你想一眼看清過去90天的整體表現？比以前費勁。

這種設計選擇很有意思——當產品表現不穩定時，降低信息的易讀性，本身就是一種危機公關。

Copilot 的尷尬：旗艦功能成了故障重災區

Copilot 是 GitHub 的現金牛，也是微軟 AI 戰略的前哨站。但過去一個月，它頻繁出現在故障公告里。

策略同步延遲、模型加載失敗、響應超時——這些問題直接影響付費用戶體驗。更麻煩的是，Copilot 的故障往往不像網站宕機那樣"可見"，用戶可能花半小時排查自己的網絡，才發現是服務端的問題。

這種"隱性故障"的 UX 成本，很少被計入官方的事故復盤。

五個9神話的終結

行業曾經把 99.999%（五個9）當作云服務的黃金標準，對應全年停機 5.26 分鐘。

現在的情況是：有些廠商連 90% 都守不住。The Register 的嘲諷并非夸張——按 90% 計算，全年停機時間高達 876 小時，折合 36.5 天。

GitHub 當然不是最差的。但它是開發者基礎設施的核心節點，它的每一次抖動，都會通過 CI/CD 管道、自動化部署、協作流程層層放大。

一個團隊因為 Actions 故障無法合并代碼，可能錯過發布窗口；一個開發者因為 Copilot 宕機被迫手寫 boilerplate，可能多加班兩小時。這些成本不會出現在 GitHub 的財報里。

給用戶的實用清單

既然云服務的高可用承諾正在貶值，開發者需要調整預期和策略：

第一，把 GitHub 的 SLA 當作參考值，而非保證。 99.9% 只針對企業版客戶，免費用戶和普通付費用戶不在保護范圍內。設計系統時，按 95% 可用性做容災規劃更現實。

第二，關注第三方狀態監控。 GitHub 官方狀態頁的信息架構變化，意味著你需要額外工具來追蹤歷史趨勢。重建的狀態頁 feed 是個備選，但記得交叉驗證。

第三，Copilot 這類 AI 功能要有 fallback。 策略同步延遲、模型不可用——這些問題不會觸發全站故障頁面，但會靜默影響你的工作流。準備一套離線替代方案，比如本地代碼片段庫或傳統自動補全。

第四，CI/CD 管道加超時和重試機制。 Actions 故障時，無限重試只會浪費 runner 配額。設置合理的超時閾值，關鍵流程準備備用 runner 或本地執行方案。

第五，定期演練"GitHub 不可用"場景。 不是開玩笑——測試一下如果明天完全無法訪問倉庫，你的團隊能多大程度上繼續工作。結果可能會讓你重新考慮代碼托管策略。

GitHub 的故障記錄里，有一條用戶評論被頂到了前面：「我們付企業版的錢，部分原因就是不想自己維護 GitLab 實例。但現在我開始算這筆賬了。」