内容简介：2018/10/21 GitHub 發生重大的異常，服務中斷超過 24h。事後官方釋出完整的事件分析報告，包含非常詳盡的事件過程、架構、應變等。這篇是我當時整理在 SRE 社群的簡譯，如同電影主要是例行性維運，網路短暫中斷，造成資料庫同步問題，產生一連串事件。其中最久的還是怎麼還原資料，不同資料中心資料同步以及同步過程要處理的問題。中間有遇到服務降級 (degrade)、網站反應變慢 (資料抄寫未完成)、非同步作業等問題 … 。
2018/10/21 GitHub 發生重大的異常，服務中斷超過 24h。事後官方釋出完整的事件分析報告，包含非常詳盡的事件過程、架構、應變等。這篇是我當時整理在 SRE 社群的簡譯， 原始連結 。
如同電影 薩利機長 ，SRE 應該要多閱讀 異常事件報告 ，從中學習應變的方法與經驗，同時也了解別人的 系統架構 為何如此設計，有什麼問題？
摘要
主要是例行性維運，網路短暫中斷，造成資料庫同步問題，產生一連串事件。其中最久的還是怎麼還原資料，不同資料中心資料同步以及同步過程要處理的問題。中間有遇到服務降級 (degrade)、網站反應變慢 (資料抄寫未完成)、非同步作業等問題 … 。
這個事件，讓 Github 整個組織認真思考 Site Reliability Engineering 的重要性。
事件時間軸
時間軸的摘要如下 (文長，沒照翻 …):
10/21 22:52 UTC
更換 100G 光纖設備的常規維護工作，導致 US East 海岸網路接口與 US East 資料中心短暫中斷 43 秒。這中斷的過程，原本在 US East 負責 Master DB 無法將資料同步到 US West 的資料中心。此時負責 管理 MySQL Cluster 的機制 ( Orchestrator ) 自動處理 failover，重導網路流量到 US West，也就是 Master 原本在 US East 改為 US West 資料中心。
Orchestrator 是 MySQL HA and Replication 的管理服務，他使用 Raft 一致演算法實作分區容錯與共識機制。
10/21 22:54 UTC (事件後兩分鐘)
內部監控系統監控到數個異常訊息，發出內部 Alert ，好幾位工程師進入處理狀態。23:02 (事件後 10 分鐘) 確認是 資料庫叢集的拓墣問題。
10/21 23:07 UTC (事件後 15 分)
Responding Team 決定手動暫停 (Lock) 所有部署程序，避免額外的問題。23:09 (事件後 17 分) Responding Team 把網站狀態燈調整成 黃燈 ，三分後 (23:11) #事故協調小組 加入，兩分鐘後決定調整狀態為 紅燈 。
10/21 23:13 UTC (事件後 21 分)
確認問題原因，Database Engineering Team 進來，主要研究有哪一些配置需要手動調整，讓 US East Database 重新配置成 Master ，同時要把 Cluster 的 Slave 從 US West 抄完，這段時間 US West 已經寫入 40 分鐘的資料了。此外，已經有一些資料寫入 US East ，但還沒被寫回 US West，這同時還要避免又從 US West 重新寫回 US East … (好亂啊 orz …)
10/21 23:19 UTC (事件後 27 分)
確認有一些 DB 查詢動作，像是 Push 要先暫停，研究過後決定執行部分的降級 (degrade)，包含了 webhook delivery、GitHub Page Build。選擇的策略就是以資料完整性高於功能的易用性。
10/22 00:05 UTC (事件後 01h13m)
在 Incident Response Team 裡的工程師們，開始規劃 #解決資料不一致 以及 MySQL failover 的實踐。計畫是從備份還原資料、同步在兩個資料中心的副本資料、回到正常服務的資料庫拓墣架構、還原暫停在 Queue 裡的排程任務。這時候對外公告上述的 計畫
MySQL 每四個小時備份一次，這樣的資料存在公有雲好幾年了（沒寫哪朵雲）。資料回復的量有好幾個 TB，也就要花好幾個小時。主要的時間都花費在資料傳輸，做資料完整的檢查 (checksum, prepare, load, test …)。在這意外之前，我們從不需要重蓋整個資料庫叢集，和回覆整個資料。
10/22 00:41 UTC (事件後 01h49m)
還原程序開始執行，工程師監控執行程序。其他團隊開始研究如何加速還原。
10/22 06:51 UTC (事件後 07h59m)
US East 資料中心，好幾座資料庫叢集已經還原，然後開始從 US West 抄寫新資料回來。這會導致頁面讀取資料非常的慢，因為如果讀取新的資料 (US East 還沒有)，那麼就要先等資料從 US West 寫回來之後，但這段資料傳輸是跨美西到美東的網路。
這時候團隊發現可以直接從 US West 資料中心還原資料，不會被下載的速度限制。同時可以利用 Replication 抄寫機制，這時候 對外公告還要兩小時 完成。
10/22 07:46 UTC (事件後 08h54m)
在 GitHub Blog 發佈一篇 異常公告訊息 ，說明異常原因是因為網路區段異常，造成資料不一致現象。為了確保資料完整性，暫停了部分功能和內部發佈程序。
10/22 11:12 UTC (事件後 12h20m)
Master 資料庫已經切回 US East，讓網站的響應速度變快，但是因為有部分的副本 (Slave) 還是落後幾個小時的資料，這個延遲造成使用者發現資料不一致。實際上副本寫入是非線性的，所以將讀取的請求分散到各個副本，讓資料慢慢一致。
寫入的負載程度會開始在歐洲和美洲的上班時間，所以還原花費的時間會比原本預估的還要長
10/22 13:15 UTC (事件後 14h23m)
這是 Github.com 流量尖峰，網站的回應速度變慢。事件回應小組針對這個狀況持續討論。事件之前已經決定在 US East 公有雲上增加副本。只要這些機器就緒，就可以提供更多服務。
10/22 16:24 UTC (事件後 17h32m)
一但複本同步完成，將執行故障移轉回到原本的拓墣架構，解決延遲和可用性問題。當我們還在處理這些資料的時候，覺得資料完整性優先，所以保持服務為 紅燈 。
10/22 16:45 UTC (事件後 17h53m)
到這個時間，已經完成恢復，提升回應，服務幾乎 100% 恢復。但是還有五百萬的 hook 事件、八萬的 Page 建置在 Queue 裡。開始處理這些資料，約有 20 萬的 webhook 因為 TTL 過期了，所以我們找出了這些 event，條整 TTL 重新執行。
為了避免這個問題，未來會先進入 degrated 狀態，確認服務恢復了，在開始啟動這些 event 處理的程序，確保系統效能不被影響。
10/22 23:03 UTC (事件後 01d01h11m)
所有暫停的 webhook 和 Page Build 已經處理完了，所有系統狀態確認正常運作。 切換裝態為綠燈 。
想法
去年在DevOpsDays 演講 有分享很多這樣的想法，主要核心概念就是
預防甚於治療
以下是當時簡報的結論：
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
perl进阶
Randal L.Schwartz、brian d.foy、Tom Phoenix / 韩雷 / 人民邮电出版社 / 2015-10-1 / 69
本书是Learning Perl一书的进阶。学完本书之后，您可以使用Perl语言的特性编写从简单脚本到大型程序在内的所有程序，正是Perl语言的这些特性使其成为通用的编程语言。本书为读者深入介绍了模块、复杂的数据结构以及面向对象编程等知识。 本书每章的篇幅都短小精悍，读者可以在一到两个小时内读完，每章末尾的练习有助于您巩固在本章所学的知识。如果您已掌握了Learning Perl中的内容并渴......一起来看看 《perl进阶》 这本书的介绍吧!
