GitHub 8月17日大故障：下載、Actions、Copilot全面受影響，暫未公布根因

GitHub 8月17日遇上的，不是「睇唔到 code」咁簡單。今次故障波及網站及 API、repository archive 和 raw file 下載、Pull Requests、Issues、Actions、Webhooks、Git operations、Pages、GitHub Copilot，亦包括部分企業登入及帳戶配置功能。

事故高峰期間，網站及 API 流量約有 20% 請求出錯；repository archive 及 raw repository content 下載的錯誤率則約為 50%。 不過，這些數字代表受影響請求的錯誤率，並不等於 20% 的 GitHub 用戶完全離線，亦不代表所有 repository 流量有一半失敗。

由調查到逐步恢復：事件時間線

GitHub 約於 13:40 UTC 開始調查服務效能問題，即美國東岸時間（EDT）上午 9:40。 問題很快由個別服務擴散至開發者日常工作所依賴的多個環節，包括讀取程式碼、審查及合併改動、執行自動化測試，以及部署軟件。

GitHub 其後表示已鎖定「有問題的元件」並採取修正措施。公司在美國東岸時間 下午 12:36 的更新中稱，平台已呈現明顯恢復跡象，但服務仍未完全穩定。

恢復並非一次過完成。GitHub 的狀態頁顯示，多項主要服務先恢復正常，但部分應用程式的 Copilot 認證問題仍然存在。 其他事故追蹤資料則指，整體事件約於 21:15 UTC 完結，意味由最初嚴重受阻到完全處理，歷時明顯長過核心服務初步恢復的時段。

到底有幾嚴重？

目前最清楚的影響指標如下：

• 網站體驗及 API 流量： 錯誤率約 20%。
• Archive 下載及 raw repository content： 錯誤率約 50%。
• 開發工具： Pull Requests、Issues、Actions、Webhooks、Git operations 及 Pages，在不同時段出現效能下降或無法使用。
• AI 編程： GitHub Copilot 受影響，而且在部分核心服務恢復後，仍有間歇性認證故障。
• 企業身份管理： SAML、OIDC 認證、SCIM provisioning 及 Team Sync 均有受影響報告，部分企業可能無法可靠地讓員工登入或管理存取權限。

換句話說，受影響的不只是開發者手動開網頁操作，亦包括由 API、webhook、CI/CD pipeline 和企業單一登入（SSO）串連起來的自動化流程。一個請求失敗，可能會連帶令程式碼下載、測試、部署或權限驗證卡住。

點解星期一朝早令影響更大？

事故在美國星期一早上開始，正值不少工程團隊開始一週工作的時間。很多團隊會在早上第一輪工作處理 code review、Pull Requests、持續整合測試、部署及工作安排；偏偏 Actions、Pull Requests、API 及 Webhooks 都在受影響之列。

因此，團隊遇到的未必只是一個功能暫時失靈，而可能是同一條交付鏈上的幾個步驟同時報錯：開不到 repository、開不到合併請求、workflow 無法啟動，或者 webhook 未能觸發後續系統。

停機追蹤網站的數字亦因時間及統計方式不同而有落差。一份報道指，Downdetector 在太平洋時間上午 8:12 前收到超過 10,000 宗報告；另一份恢復報道則指高峰接近 3,000 宗。 這些不是受影響用戶的精確人數，因為這類平台只計算主動提交的報告，數字也會受地區、時間及統計方法影響。

GitHub 已做了甚麼？仍然未交代甚麼？

GitHub 的公開更新目前可以確認三件事：

1. 工程團隊調查多項服務同時出現的高錯誤率及效能問題。
2. 公司找到涉及事故的問題元件，並採取修正措施。
3. 主要平台服務開始恢復後，GitHub 仍繼續進行緩解工作，包括處理部分 Copilot 應用程式的間歇性認證失敗。

但截至現有公開資料，GitHub 尚未交代該元件究竟是甚麼、實際採取了哪項修正措施，亦未證實容量壓力就是今次事故的直接原因。AI 流量增長及基礎設施限制，確實是 GitHub 較廣泛的可靠性討論一部分；不過，在正式事後報告公布前，不能把它們當成 8月17日故障的已確認根因。

這次故障如何反映 GitHub 2026 年的可靠性壓力？

今次事故並非發生在真空之中。GitHub 的 2026年7月可用性報告記錄了 8 宗事故。其中 7月8日的一宗持續超過 7 小時，影響 Web UI、REST API、GraphQL API、Actions、Packages、Copilot 及部分 Enterprise Cloud 環境的 Git operations。

GitHub 亦曾表示，平台流量正快速增加，主要推動力之一是 AI 輔助及 agentic development 工作流程。公司提出的應對方向包括把更多容量搬到 Azure、將服務拆分成更獨立的元件，以及減少共用故障點。

容量規模的變化尤其值得留意。相關報道指，GitHub 原本計劃把容量提高至當時的 10 倍，但到 2026年2月已判斷需要按 30 倍於當時規模的需求作設計。 另有報道提到涉及 Azure 及額外多雲容量，包括 AWS；不過，這些基建計劃本身並不能證明就是今次 8月事故的原因。

問題的核心在於，今日的 GitHub 已不只是存放 Git repository 的地方。它同時是協作平台、自動化及交付系統、企業身份管理層，以及 AI 編程服務。當多個工作流程依賴同一批共用元件時，一個局部故障就可能擴大成影響程式碼存取、審查、build、部署、webhook 和 AI 輔助的連鎖事故。

企業及開發團隊可以吸取甚麼教訓？

這次故障並不足以證明開發者即將集體離開 GitHub，現有證據亦不支持預測一輪即將出現的大規模平台遷移。不過，對把 GitHub 放在生產交付核心位置的企業來說，事故再次提醒大家檢視「如果平台失效，團隊還能不能工作」這個假設。

較實際的準備包括：

• 保留 repository 備份或鏡像；
• 令 CI/CD 設定盡量可移植，不要完全綁死單一平台；
• 寫清楚緊急發佈及回滾程序；
• 預先安排在 SSO、webhook 或 hosted runner 無法使用時的替代流程。

這些措施無法消除平台風險，但可以減少下一次服務中斷的「爆炸半徑」。

至於 8月17日事故的最終判斷，仍要等 GitHub 的 postmortem。就目前證據而言，最穩妥的結論是：GitHub 出現了一次廣泛而具連鎖性的服務中斷，repository 下載及多項相互連接的開發工作流程受到嚴重影響；平台分階段恢復，而底層故障原因仍未由 GitHub 公開說明。