程式碼託管平台的自動化服務，短短四天內二度出狀況。台灣時間十月六日凌晨，GitHub通報代管的工作執行環境分派出現延遲，大批自動化工作流程卡在等待狀態，部分工作甚至執行失敗，約兩小時四十三分鐘後才恢復正常。
凌晨三時十一分，平台首先通報服務效能下降。隨後官方確認，問題出在代管的工作執行環境，也就是自動化工作啟動前必須先取得的運算資源。
由於工作流程需要先取得執行環境才能開始，當分派出現延遲，工作就會停在等待狀態。凌晨四時三十九分，官方進一步確認，除了啟動變慢，部分工作也出現執行失敗的情況。
直到五時五十四分，官方宣布自動化服務恢復正常。從最初通報算起，整起事故持續約兩小時四十三分鐘。
受影響的不只是自動化服務。五時九分，官方表示部分使用者無法正常開啟儲存庫清單、授權及帳務頁面，隨後連靜態網站託管服務也出現效能下降。
自動化服務恢復後，官方繼續處理其他受影響的服務，直到六時四十九分，才宣布整起事故結束。
截至目前，官方尚未公布這次執行環境異常的原因，只表示後續會提供完整的事故分析。這也讓外界無法確認，這次問題是否與四天前的另一起事故有關。
回顧四天前，十月一日也曾發生類似的執行環境啟動延遲。當時官方確認，問題來自上游雲端服務的流量限制，部分請求收到「請求過多」的回應，造成工作啟動延遲。
那起事故同樣持續約三小時。事故結束後，同一天稍晚又出現另一波異常，部分組織與企業用戶無法正常開啟帳務及授權頁面，直到九時三十二分才全面恢復。
官方目前沒有說明，十月六日凌晨的兩波事故是否具有共同原因。對高度依賴自動化流程的開發團隊來說，連續兩次中斷無疑是一記警鐘。
這類服務是許多團隊軟體建置、測試與部署的命脈。一旦停擺，程式碼從提交到上線的整條流水線都會被迫暫停，影響的不只是工程師的工作節奏，還有產品的發布時程。
接下來值得關注的，是官方承諾的完整事故分析。只有釐清根本原因，才能判斷這是偶發事件，還是基礎架構上更深層的問題正在浮現。
