Log for Ubuntu 台灣社群
GitHub 似乎連區區三個 9（99.9%）的可用性都撐得很吃力 （★ 108 分）
GitHub 近一個月頻繁出現服務異常，2 月 9 日先後影響 GitHub Actions（自動化工作流程服務）、合併請求（pull request）、通知與 Copilot（AI 程式設計助理）。官方在 15:54 UTC 承認部分服務異常，通知延遲一度接近 50 分鐘，直到 19:29 UTC 才宣稱恢復正常。Copilot 另從 2 月 9 日 16:29 UTC 持續到 2 月 10 日 09:57 UTC 出現權限政策同步問題，讓部分使用者看不到新啟用的模型，顯示不只是附加功能，連核心開發流程周邊也受到波及。
報導指出，GitHub 先前改版狀態頁後，外界更難直接掌握過去 90 天的整體可用性。雖然有人根據公開狀態資料重建出非官方頁面，仍可看出 2025 年某些時段可用性曾跌破 90%。在雲端平台領域，業界常以 five nines（99.999% 可用性）作為高標，但 GitHub 連 three nines（99.9% 可用性）都顯得吃力；而 GitHub 對 Enterprise Cloud 客戶的 SLA（服務等級協議）雖寫明 99.9% 服務可用時間，也不是所有使用者都享有同等保證。文章最後提醒，企業不能只規劃正常運作，也必須把停機情境納入日常準備。
Hacker News 上較受重視的觀點，多把近期不穩定與 GitHub 持續遷往 Azure（微軟雲端平台）連在一起。有人翻出 GitHub 高層先前宣稱，全面轉向 Azure 會讓平台更快、更可靠，但留言普遍認為這類超大型基礎架構搬遷，往往會讓可靠性先惡化好幾年才可能回穩。也有人提到，GitHub 在微軟體系內長期維持某種程度獨立，如今被更深度整合後，內部轉換時程緊、外部協助有限，再加上公司把心力大量放在 Copilot 與其他 AI 功能，擠壓了原本應該優先處理的穩定性與維運品質。不少人還回想，早年外界催 GitHub 加快推出新功能，如今反而更懷念那種「無聊但可靠」的平台。
討論裡也有不少第一線案例與補充。有工程師貼出 GitHub Actions 的執行紀錄，顯示 runner（執行工作流程的代理程式）收到關機訊號，導致作業被取消，而客服只建議降低平行作業與 CPU、記憶體用量，讓部分團隊開始改用自架的 Jenkins（常見的 CI 工具）或 GitLab。另一些留言把焦點放在 GitHub Actions 的安全設計，批評可變參照與已知漏洞多年未修，近期甚至被攻擊者拿來污染大量 CI（持續整合）流程；也有人認為，現代 CI/CD（持續整合／持續交付與部署）靠層層 YAML（常見的設定檔格式）與抽象包裝，早已變得過度複雜。不過也有較保留的聲音提醒，非官方統計是把所有子服務一起計算，未必等於整個 GitHub 主站只有 90% 可用性，而且某些團隊近幾週幾乎沒受影響，仍認為 Codespaces（雲端開發環境）等功能很有價值。整體來看，討論氣氛偏向警惕：GitHub 仍是最完整的一站式開發平台之一，但越來越多人已開始認真評估分散風險與替代方案。
👥 41 則討論、評論 💬
https://news.ycombinator.com/item?id=47487584
GitHub 近一個月頻繁出現服務異常，2 月 9 日先後影響 GitHub Actions（自動化工作流程服務）、合併請求（pull request）、通知與 Copilot（AI 程式設計助理）。官方在 15:54 UTC 承認部分服務異常，通知延遲一度接近 50 分鐘，直到 19:29 UTC 才宣稱恢復正常。Copilot 另從 2 月 9 日 16:29 UTC 持續到 2 月 10 日 09:57 UTC 出現權限政策同步問題，讓部分使用者看不到新啟用的模型，顯示不只是附加功能，連核心開發流程周邊也受到波及。
報導指出，GitHub 先前改版狀態頁後，外界更難直接掌握過去 90 天的整體可用性。雖然有人根據公開狀態資料重建出非官方頁面，仍可看出 2025 年某些時段可用性曾跌破 90%。在雲端平台領域，業界常以 five nines（99.999% 可用性）作為高標，但 GitHub 連 three nines（99.9% 可用性）都顯得吃力；而 GitHub 對 Enterprise Cloud 客戶的 SLA（服務等級協議）雖寫明 99.9% 服務可用時間，也不是所有使用者都享有同等保證。文章最後提醒，企業不能只規劃正常運作，也必須把停機情境納入日常準備。
Hacker News 上較受重視的觀點，多把近期不穩定與 GitHub 持續遷往 Azure（微軟雲端平台）連在一起。有人翻出 GitHub 高層先前宣稱，全面轉向 Azure 會讓平台更快、更可靠，但留言普遍認為這類超大型基礎架構搬遷，往往會讓可靠性先惡化好幾年才可能回穩。也有人提到，GitHub 在微軟體系內長期維持某種程度獨立，如今被更深度整合後，內部轉換時程緊、外部協助有限，再加上公司把心力大量放在 Copilot 與其他 AI 功能，擠壓了原本應該優先處理的穩定性與維運品質。不少人還回想，早年外界催 GitHub 加快推出新功能，如今反而更懷念那種「無聊但可靠」的平台。
討論裡也有不少第一線案例與補充。有工程師貼出 GitHub Actions 的執行紀錄，顯示 runner（執行工作流程的代理程式）收到關機訊號，導致作業被取消，而客服只建議降低平行作業與 CPU、記憶體用量，讓部分團隊開始改用自架的 Jenkins（常見的 CI 工具）或 GitLab。另一些留言把焦點放在 GitHub Actions 的安全設計，批評可變參照與已知漏洞多年未修，近期甚至被攻擊者拿來污染大量 CI（持續整合）流程；也有人認為，現代 CI/CD（持續整合／持續交付與部署）靠層層 YAML（常見的設定檔格式）與抽象包裝，早已變得過度複雜。不過也有較保留的聲音提醒，非官方統計是把所有子服務一起計算，未必等於整個 GitHub 主站只有 90% 可用性，而且某些團隊近幾週幾乎沒受影響，仍認為 Codespaces（雲端開發環境）等功能很有價值。整體來看，討論氣氛偏向警惕：GitHub 仍是最完整的一站式開發平台之一，但越來越多人已開始認真評估分散風險與替代方案。
👥 41 則討論、評論 💬
https://news.ycombinator.com/item?id=47487584