農歷大年初四(一月最后的一天)GitLab.com的一個數(shù)據(jù)庫發(fā)生了災難性的事故,。經過努力,,最終丟失了6個小時(5:20pm UTC ~ 11:25pm UTC,Jan 31,,2017 )的數(shù)據(jù),。“這起事件影響了數(shù)據(jù)庫(包括問題和合并請求),但是沒有影響git代碼庫(代碼庫和維基),。” 所以對用戶來說多少有點安慰,,因為并非所有數(shù)據(jù)全部丟失。所幸GitLab運氣不錯,,損失不是太大,,而且公開事故過程,沒有躲貓貓,,獲得大家的好評,。但問題還是比想象的嚴重,值得分析,。
1. 讓我們簡單回顧一下事情的經過 第一次事故
采取的措施:
第二次事故
采取的措施:
第三次事故
2. 問題分析 正如Simon Riggs說,手工刪除數(shù)據(jù)庫目錄是非常危險的,,恢復備份這樣操作也很關鍵,。這樣的事情應該交給工具去做,所以他順便為自己的公司2ndQuadrant做了廣告(repmgr 3.3,,Barman 2.1),。也如左耳朵耗子特別對“人肉運維”吐槽一番“直接到生產線上敲命令是一種非常不好的習慣”,說了一句名言“人管代碼,,代碼管機器,,而不是人管機器”。 相對“rm -rf”這樣的命令,,工具會好多了,。即使用工具,也不能解決問題,,人在昏頭的時候,,用工具也會干錯事情。所以有人說,,這樣重要的工作,,需要兩個人干,一個人操作,另一個人在旁邊看著,,這樣對企業(yè)會增大成本,,特別是在緊急情況下,不一定能找到人,。在本案中,,這位同學因為troubleshooting沒下班,另外一位值班同學這時是不是該來了,?兩個人一起商量著解決問題會好多了,,災難就可能不出現(xiàn)了。難道YP童鞋一直埋頭干活,,沒有及時和其他人溝通,? 或者像銀行那樣,遇到高風險的操作,,需要上一層主管授權,。在troubleshooting時,似乎不現(xiàn)實,。重要的操作,,還是可以電話請示一下。即使不請示,,在技術上可以咨詢一下同事,,確認一下問題的癥結所在,是不是會更好些,?而不是自己猜測“可能是pg_basebackup拒絕工作”而盲目操作,。即使單獨行動,碰到這樣關鍵的問題,,這位同學是不是也應該自行檢查一遍再提交,?對于新型公司,估計平時的培訓也不到位,,缺少風險意識,,維護人員的素質有待提高。 從人,、流程看,,問題是明顯的。但技術問題就更多了,,除了上面說的操作和max_wal_senders設置,、以及max_connections原來的值,正如Gitlab官在Google DOC描述所碰到的問題,,有9項之多,,加上max_connections的錯誤設置正好十項:
可見環(huán)境配置、備份,、快照等漏洞百出,,最終沒有損失24小時的數(shù)據(jù),,或多或少有運氣的成分,否則更糟糕,。本質上看,,也還是人的問題,說明Gitlab管理層只關注用戶數(shù)增長,、業(yè)務的發(fā)展,,而對系統(tǒng)的容錯性、可用性/可靠性重視明顯不夠,。許多時候,,管理層也是不見棺材不落淚,需要吃一塹長一智,,平時對質量不重視,,出了問題以后才會重視質量。這次出了問題,,倒是好事情,,Gitlab會吸取教訓,對系統(tǒng)的安全,、可靠性會重視起來,,完善系統(tǒng)的架構和復制、備份機制等,。 當然,,最徹底解決問題是通過技術手段來解決,正如左耳朵耗子一再說的“不得不用更好的技術去設計出一個高可用的系統(tǒng),!別無它法,。” 如多節(jié)點復制的分布式系統(tǒng)、區(qū)塊鏈技術等,。對于Gitlab 這樣的公司,,應該有高端人才加盟幫它構建高可用的系統(tǒng),可以構建良好的發(fā)布,、運維基礎設施,。如果缺乏人才,還是可以通過流程,、管理等解決,。解決一個問題,主要還是從三個方面:
為了方便記憶,三個方面記為PPT,。多從這三個方面找原因,,多問為什么,采用5 Whys 方法,,找出根本原因,,加以解決。本問題的深層次原因可能就在思想深處,,管理層缺少“可靠性”的質量意識,,即使是技術方案的改善,也需要人力,、物力的大投入,,需要決心去改變系統(tǒng)的架構,這也需要“質量”去驅動,。 參考文章:
|
|
來自: king9413 > 《數(shù)據(jù)庫》