GitHub 每個月都會公開一份維運報告，說明前一個月平台發生了哪些問題。這篇 2026 年 7 月的報告提到，當月共發生 8 起會讓部分服務變慢或無法使用的事件，其中包含一次影響 GitHub Actions 長達 9 小時的當機，是這個月最嚴重的一次，也讓 GitHub 承認沒有達到自己設定的服務水準承諾。
報告詳細列出每次事件的原因，例如 7 月 8 日因為自動化程式改動了虛擬機器上的一項設定，導致服務彼此找不到對方；7 月 19 日則是伺服器的加密憑證到期後沒有自動換發，讓執行工作的機器連不上伺服器；另外還有資料庫、DNS 與 Redis 快取叢集在維護時發生的連鎖問題，GitHub 都逐一寫出根本原因與修復方式。
這份報告值得注意的地方，在於 GitHub 選擇公開承認自己「沒有做到承諾」，而不是只報喜不報憂，例如加強憑證到期監控、替 SSH 認證功能補上更完整的自動測試，並在資料庫工具中加入更嚴謹的檢查機制，避免同樣的問題重複發生，這種透明度也是許多軟體公司值得學習的做法。
這則新聞比較偏產業與維運面，跟寫程式的技巧關聯不大，不過如果孩子將來想從事「維持網站與服務不當機」的工作，也就是維運工程師，這篇報告是很好的例子，可以看到大公司如何有系統地記錄問題、找出原因，並且持續改善，而不是出事後就算了。
平台功能系統維運軟體工程