GitHub於周一（8月17日）發生大規模服務故障，API、Git Operations、Actions、Issues、Pages、Pull Requests及Webhooks等多項核心服務受到影響。網站服務與API流量錯誤率一度達20%，儲存庫封存檔及原始內容下載錯誤率更曾升至50%。
事故自世界協調時間（UTC）8月17日13時40分、即臺北時間8月17日21時40分開始，直到UTC 8月17日21時15分、即臺北時間8月18日5時15分，GitHub才宣布完全排除問題，整起事故歷時約7小時35分鐘。
多項開發與協作服務接連受影響
隨著事故持續，GitHub陸續將Actions、Pull Requests、Issues、API Requests、Webhooks、Pages及Git Operations標示為效能下降或可用性下降。
其中，GitHub Actions是用於軟體開發自動化的服務，能在程式碼更新後自動執行測試、建置及部署。相關服務異常除了限制開發者存取與協作程式碼，也可能使軟體開發、測試及發布流程受到阻礙。
GitHub在UTC 16時36分表示，已找到造成事故的「問題元件」（problematic component）並採取修正措施，主要服務開始恢復。到了UTC 16時59分，GitHub宣布API Requests、Actions、Git Operations、Issues、Pages、Pull Requests及Webhooks的異常均已獲得緩解。
服務恢復後仍出現反覆異常
不過，服務在初步恢復後再次出現問題。Git Operations及Issues先後發生效能下降，API Requests也重新出現可用性問題。GitHub表示，雖然已修正相關問題元件，但多項服務仍受到殘餘影響，後期問題主要集中於零星的身分驗證失敗。
GitHub部分停用驗證權杖重試機制後，整體情況有所改善。事故最後僅剩部分應用程式出現零星的Copilot驗證失敗，直到UTC 21時15分才正式宣布事故完全解決。
真正事故原因仍待調查
截至目前，GitHub尚未公布造成此次故障的真正原因，僅表示會在完成調查後，進一步揭露詳細分析。因此，現階段仍無法確認問題元件與驗證權杖異常之間的完整因果關係。
GitHub近期接連發生長時間事故
這次事件也是GitHub近期再次發生的長時間服務事故。8月6日，GitHub Actions才曾發生超過9小時的故障。當時GitHub在例行更新服務期間遭遇一連串問題，復原過程又碰上容量及工作分派異常，使服務恢復時間進一步延長。
在8月6日事故的高峰期，71%的工作流程發生基礎設施故障；在其餘工作流程中，另有75%延遲超過5分鐘。
GitHub事後說明，雖然大多數Actions工作已在Azure執行，但負責連接GitHub主系統與Actions的服務仍完全運行於GitHub自家資料中心。自家資料中心容量不足，是當時事故復原速度緩慢的因素之一。
針對相關限制，GitHub已決定加速將Actions相關服務移往Azure，期望取得更多容量，並提升系統因應突發負載的能力。不過，這項調整與本次8月17日事故的直接關聯，仍有待GitHub後續調查報告確認。
Reference Link : ithome.com.tw
