本文翻譯自 GitHub 官方部落格《Introducing the GitHub Availability Report》
原文連結：https://github.blog/2020-07-08-introducing-the-github-availability-report/
翻譯：HelloGitHub-丫丫 | 校對：HelloGitHub-小魚乾
什麼是可用性報告？
從歷史上看，GitHub 對影響服務可用性的重大事件會發表事後評論。無論我們是分享新的基礎設施投資，還是詳細的網站停機時間，我們的信念是，可以通過相互學習共同成長為一個行業。 這個月，我們很高興介紹下 GitHub 可用性報告。
你能期待什麼？
在每個月的第一個星期三，我們將釋出一份描述 GitHub 可用性的報告，包括對可能發生的任何事件的描述，並向您介紹我們是如何發展工程系統和響應實踐。您會期待這些更新，它包括對已有事件的總結，以及對我們認為是新奇事件的技術解釋，幷包含幫助世界各地的工程師學習如何大規模改進產品運營的資訊。
為什麼我們要做可行性報告？
可用性和效能是一個核心特性，包括 GitHub 如何響應服務中斷。我們努力設計高可用、容錯系統，我們希望這些每月更新可以回憶起 GitHub 高於 99% 的可用時間。當事情不按計劃進行時，比起等待分享特別有趣的事件資訊，我們更傾向於告知你所有可能影響你的事件。我們的希望是，通過提高我們的訊息透明度、分享我們學到的東西，而不是簡單地在狀態頁面上報告停機時間的分鐘，從而讓每個人都可以從我們的經驗中受益。在 GitHub，我們非常誠摯地對待您的這份信任，我們希望這是您幫助我們對不斷改進我們的卓越運營和我們的產品功能負責的一種方式。
五月和六月的可用性報告
在 5 月和 6 月，我們經歷了四次不同的事件，導致 GitHub.com 缺乏可用性或服務降級。
UTC 5 月 5 日 00：45（持續 2 小時 24 分鐘）
在事件發生期間，共享資料庫表的自動增量 ID 列超過了 MySQL Integer 型別（Railsint（11)）：2147483647 可以表示的大小。當我們試圖往列中插入較大整數時，資料庫拒絕了該值，Rails 引發了 ActiveModel::RangeError，這導致 API 端的 500s 延遲。
這影響了依賴於獲得安裝令牌的 GitHub 應用程式。最受影響的 GitHub 內部應用程式包括 Actions、Pages 和 Dependabot。
GitHub 的監控系統當前在表達到主鍵所用大小的 70% 時會發出警報。我們在擴充套件我們的測試框架，以包含 int / bigint 外來鍵不匹配的 linter。
UTC 5 月 22 日 16：41（持續 5 小時 09 分鐘）
在原定的維護操作（MySQL 主例項失敗）期間，在新升級的 MySQL 主伺服器上 MySQL 程式經歷了一次新的崩潰。為了減輕崩潰帶來的影響，我們手動將流量重定向到原始主伺服器。但是，崩潰的 MySQL 主伺服器已經提供了大約 6 秒的寫流量。此時，啟動了從新主伺服器恢復副本的操作，這大約需要 4 個小時，叢集重新配置需要 1 個小時才能重新啟用完全讀取能力。在這近 5 個小時裡，在 web 見面和 API 中看到資料寫入到受影響資料庫叢集之前，使用者可能已經觀察到了延遲。
我們已經執行了多個內部模擬演習（gameday exercise），以應對類似的拓撲不一致，及繼續訓練我們的故障轉移系統以減少故障恢復時間。
UTC 6 月 19 日 8： 52（持續 51 分鐘）
為改進 UI 的更好 A / B 實驗工具引入了一種未知的依賴關係，依賴於獨立應用提供的特定、動態生成檔案的存在。
在應用部署期間，由於上游應用程式限制了較高的檢索率，因此很大一部分的應用程式部署無法生成檔案。這導致了參與實驗的使用者中有一定比例會出現應用程式錯誤。經過檢測，我們能夠禁用此檔案需求，這將恢復對所有使用者的服務。
接下來，A / B 和多元實驗的配置將在內部快取，以確保依賴關係的成功傳播。
UTC 6 月 29 日 12：03（持續 2 小時 29 分鐘）
作為維護的一部分，資料庫團隊在 6 月 22 日星期一推出了一個更新版本的 ProxySQL。一週後，我們的一個主資料庫叢集上的 MySQL 主節點出現故障，並被一個新主機自動替換。幾秒鐘內，新升級的主伺服器崩潰。 Orchestrator 的防止互相踢皮球機制阻止了隨後的自動故障轉移。 在我們手動恢復服務後，新的主伺服器又開始耗盡 CPU 資源，並再次崩潰。 為了恢復，我們回滾到 ProxySQL 舊版本並禁用了應用程式中 ProxySQL 新版本所需的變更。 完成此操作後，我們可以允許在主節點上進行寫操作而不會崩潰。
我們正在分析應用程式日誌、MySQL 核心轉儲和我們的內部遙測，作為繼續調查 CPU 耗盡問題的一部分，以避免類似的故障模式繼續。
總結
作為一個組織，我們繼續在可行性方面投入大量資金。我們把這裡討論的每一件事視為一個寶貴的機會來學習和成長。我們的系統和流程繼續基於這些學習而發展，我們期待著在未來的更新中分享我們的進展。
請按照我們的狀態頁面進行實時更新，並檢視我們的部落格下個月的可用性報告。
2020 年 7 月 2 日
HelloGitHub 推出的「譯文亦舞」系列
如果小夥伴們有什麼有趣的英文文章也可以留言把連結發給我（題材：GitHub、程式設計、程式設計師）。
關注我們的公眾號，加入我們吧