51CTO讀者成長計劃社群招募，咨詢小助手（微信號：CTOjishuzhan）
撰稿 | 言征
四個月，16次中斷。Github真的惹惱了用戶了。
微軟旗下的GitHub為版本控制和協作提供了一個代碼托管平臺，在過去三個月發生了13起此類事件后，而就在剛剛過去的上周，該公司就發生三次服務中斷。
5月16日，GitHub首席安全官Mike Hanley發表了一篇博文《解決Github最近的可用性問題》中表示：“上周，GitHub發生了幾起可用性事件，包括長時間和短時間的可用性事件。此后，我們已經緩解了這些事件，所有系統現在都正常運行。”
Hanley補充道：“這些事件的根本原因并不相關，但總的來說，它們對組織和開發人員信任GitHub提供的服務產生了負面影響。這既不可接受，也不符合我們的標準?！?/p>
一、三起事件回溯及原因
該公司表示，這三起事件分別發生在5月9日、5月10日和5月11日，影響了GitHub提供的大部分關鍵服務。事件導致關鍵的GitHub服務中斷如下：
1.5月9日Git數據庫事件
日期：2023 年 5 月 9 日
事件：Git 數據庫因配置更改而降級
影響：10 個主要服務中有 8 個降級
據該公司稱，5月9日發生的事件由于配置更改而中斷了GitHub的數據庫。
Hanley在博客文章中表示：“5月9日，我們發生了一起事件，導致狀態門戶網站上的10項服務中有8項受到重大（紅色狀態）停機的影響。大部分停機時間僅持續了一個多小時?！?/p>
Git 推送錯誤率：在 11:30 左右，錯誤率從零上升到大約 30,000。匯率繼續在 25,000 和 35,000 之間波動，直到 12:30 左右，此時它回落到零。
Hanley解釋說，在中斷時，許多服務無法讀取新寫入的Git數據，導致了大范圍的故障，并補充說，中斷后，一些拉取請求和推送數據的事件后恢復時間延長了。
Hanley表示，此次中斷是由提供Git數據的內部服務的配置更改引發的。
“這一更改旨在防止連接飽和，之前曾在Git后端的其他地方成功引入。推出后不久，集群發生了故障切換。我們恢復了配置更改，并在幾分鐘內嘗試回滾，但由于內部基礎設施錯誤，回滾失敗了?！?/p>
2.5 月 10 日 GitHub App auth token 事件
日期：2023 年 5 月 10 日
事件：GitHub App 身份驗證令牌頒發因負載下降
影響：10 個主要服務中有 6 個下降
5月10日發生的這起事件是由于GitHub的應用程序身份驗證令牌發布能力下降，十分之六的關鍵GitHub服務也受到了影響。
Hanley在博客文章中表示：“5月10日，提供GitHub應用程序身份驗證令牌的數據庫集群發現GitHub App權限的寫入延遲增加了7倍（狀態為黃色）。在此次事件的大部分時間里，這些身份驗證令牌請求的失敗率為8-15%，但在短時間內達到了76%的峰值。”
5 月 10 日，為 GitHub 應用程序授權令牌提供服務的數據庫集群發現 GitHub 應用程序權限（狀態黃色）的寫入延遲增加了 7 倍。在這一事件的大部分時間里，這些授權令牌請求的失敗率為 8-15%，但在短時間內確實達到了 76% 的峰值。
延遲隨時間變化的線圖：顯示從 5 月 10 日星期三中午 12 點 30 分到 5 月 11 日星期四午夜從零跳到“3e14”附近波動。峰值延遲在此期間有 5 次接近“1e15”。
首席安全官解釋說，令牌頒發問題是由于管理GitHub應用程序權限的API“執行效率低下”造成的，并補充說該公司正在更新API以檢查安裝狀態的變化。
3.5月11日Git數據庫事件
日期：2023 年 5 月 11 日
事件：Git 數據庫因只讀副本丟失而降級
影響：10 個主要服務中有 8 個降級
該公司表示，由于讀取副本丟失，GitHub的數據庫于5月11日再次遭到攻擊。Hanley在博客文章中表示：“在Git數據庫事件中，Git讀寫是許多GitHub場景的核心，因此延遲和故障的增加導致GitHub Actions工作流無法提取數據或提取不更新的請求?！?/p>
隨著時間的推移成功操作的線圖，顯示大約 250 萬的典型值。該圖顯示在 13:30 下降到大約 150 萬次操作，隨后穩步增加回到 250 萬次，并在 14:00 恢復正常。
二、為什么這些事件會影響其他 GitHub 服務？
在博客中，Hanley表示：“我們希望我們的服務能夠盡可能地適應失敗。分布式系統中的故障是不可避免的，但不應導致多個服務嚴重中斷。在所有這三起事件中，我們都看到了普遍的退化。在 Git 數據庫事件中，Git 讀寫是很多 GitHub 場景的核心，因此延遲和故障增加導致 GitHub Actions 工作流無法拉取數據或拉取請求不更新。”
此外，在 GitHub Apps 事件中，對令牌發布的影響也影響了依賴令牌運行的 GitHub 功能。這是 GitHub Actions 中每個 GITHUB_TOKEN 的來源，以及用于授予 GitHub Codespaces 訪問存儲庫的令牌。它們也是保護私有 GitHub 頁面訪問的方式。當令牌發行失敗時，GitHub Actions 和 GitHub Codespaces 無法訪問它們運行所需的數據，因此無法啟動。
三、GitHub正在采取行動來避免類似事件
Hanley 表示，為了避免未來發生類似事件，公司正在幾個方面開展工作，例如仔細審查其內部流程，并進行調整，以確保變動始終得到更安全的部署。
“當然，并非所有這些事件都是由生產變化引起的，但我們認為這是一個需要改進的領域”。
此外，Hanley補充道：“除了標準的事件后分析和審查外，我們正在分析這些事件對各服務的影響范圍，以確定在哪里可以減少未來類似故障的影響?！?/p>
同時，GitHub正在努力提高“高成本、低容量查詢模式”的可觀測性、快速診斷和緩解此類問題的通用能力。其他措施包括解決數據庫故障轉移問題，以確保故障轉移始終在沒有干預的情況下完全恢復，并了解多個Git數據庫崩潰事件。
作為Github公司對透明度承諾的一部分，將會在月度可用性報告中發布了導致 GitHub 服務性能下降的所有事件的摘要?！拌b于最近這些事件的范圍和持續時間，我們認為現在與社區一起解決這些問題很重要。”
Hanley表示，5 月的可用性報告將包括這些事件和更多相關的進一步細節，以及關于提高 GitHub 可用性的進展的一般更新。
四、四個月持續發生服務性能下降事件
盡管github聲稱正在努力解決停機問題，但GitHub在過去四個月里持續發生了不少中斷事件，4月發生了4起，3月發生了6起，2月發生了3起。
五、用戶炸鍋了
一位Reddit用戶表示，對于Github的可用性問題由來已久，不僅僅是最近才有。Github或者其中的某些服務經常出現故障，并對該公司根本不屑于寫任何關于問題的東西剛到吃驚?！癆ctions經常崩潰，而他們與Codespaces的不斷停機是讓我的團隊遠離它的一個很大的動力?！贝送?，他還對于Github的狀態頁面事件歷史更新表示不滿。
有另一位網友回應：某云不更改狀態頁面的原因是因為這會引發一堆SLA積分和對客戶的補償。
也有不少網友附議：“每次我遇到代碼空間問題時，狀態頁面肯定也沒有顯示問題”、“我很清楚某些服務降級的頻率，在我們Slack的第三方狀態頻道中被發送垃圾郵件”、“哇，3月發生了20起事件，幾乎每個工作日發生一次”。
六、寫在最后
作為承載著無數良心代碼的平臺和社區，Github成為全球開發者的開源圣地，然而此次的服務中斷問題似乎點燃了用戶們對于Github時不時就“玩中斷”的不滿情緒。
正如Hanley所說，分布式系統中的故障是不可避免的。但給到用戶的可用性承諾卻是要遵守的。如果不能保障這一點，那SLA（service-level agreement）也就變成了空頭支票，有何意義？
參考鏈接：
https://www.infoworld.com/article/3696279/github-owns-up-to-service-issues-multiple-outages.html
https://github.blog/2023-05-16-addressing-githubs-recent-availability-issues/
