俗話說，天災可怕，人禍更甚，最近的 GitLab 刪庫曾一度牽動了碼界尤其是運維圈的神經，好在GitLab 官方開放積極的公關，才讓整個事件在肯定中得到平息。

平息歸平息，從這個事故中反映出來的問題卻值得我們引以為戒，隨著規模越來越複雜，說到軟體系統，我們已經越來越習慣把它歸為“人”的問題，因為人類的不確定性，我們一直努力在開發中儘量減少之，而系統執行中用來防禦人類破壞的功能更是佔了越來越大的比重，也正如整個刪庫事件一樣，人禍成了系統執行中最難預測危害最大的不穩定因素。

“人類是系統可靠性最大的勁敵”也逐漸成了DevOps的教旨，那麼基於這點，今天我們就來簡單聊一下複雜軟體系統可靠性的提升問題，結合這幾年在DevOps摸爬滾打的經驗，從“決策”“執行”“限制”“反饋”四個不確定性溫床中摸索下解決方案。

決策

“機器人不得傷害人類，或因不作為使人類受到傷害。”——阿西莫夫.機器人三定律-1
“除非違背第一定律，機器人必須服從人類的命令。”——阿西莫夫.機器人三定律-2

決策權現在還掌握在不靠譜的人類手裡，我們只能先從這裡下手。

不要疲勞駕駛

我們姑且不論“8小時工作制”是否真正科學，所有腦力勞動，違背用腦規律甚至使之處於過載疲勞狀態，都會顯著降低腦部的能量轉換效率，大幅增加決策能力的不確定性，雖然針對疲勞的措施，納入法律的只有“疲勞駕駛”，但疲勞所帶來的危害卻越來越被人們關注。

這讓我想起當年為了儘快上線而挑燈夜戰導致指令碼出錯用rsync –delete幹掉一臺線上伺服器的光榮事蹟，而gitlab的刪庫事件也正是操作員疲勞狀態下進行線上操作所釀成的，更令人擔心的是，我們的大腦在疲勞的時候更容易放棄思考而輕易得出“這點疲勞礙不啥事”的結論（等同於醉酒），這必須引起警惕，雖然故障並不會選擇在我們清醒的時候來光顧，但在此還是要給出我的建議：科學用腦，將時間用在效率最高的地方。

pair

防止單點故障已經是系統執行可靠性老生常談的手段了，而對於決策者來說，一個搭檔，會讓決策的不確定性降低至少一半。運維工作的性質導致我們並不能保證故障就要在我們清醒的時候發生，正如pair會讓開發人員儘可能的集中注意力，合理搭配雙方的高效時間，在進行線上系統重要操作的時候，多一雙眼睛盯著，操作失誤率會大幅提升——因為我們的pair絕不會是我們的完美複製品，這也是符合“系統多樣性帶來可靠性提升”的原理。

執行

“除非違背第一及第二定律，機器人必須保護自己。”——阿西莫夫.機器人三定律-3

一個有序體應當與熵戰鬥，儘可能讓自己免受破壞，這是生命體的關鍵特性。

變化率一致性

這次事故中，損壞丟失的資料並不是git程式碼主庫，而是儲存有issue、MR等資訊的外掛資料庫，為了方便使用版本控制和衝突管理特性而建立在git庫基礎上的wiki也因此倖免於難。一個完整的workflow要被分割存在於兩個變化率不同的容器，讓我這潔癖碼農始終覺得不大踏實，分割儲存不是備份冗餘，後者的基礎是單點資料完整。

當然在討論中有朋友有提到，對於頻繁資料交換、開關、狀態流轉，傳統db較之git庫，有著先天的優勢，但將已歸檔的流式資料合併入git庫中來獲得一致的資料變化率也不失為一個好辦法，所以個人覺得，資料變化率一致性上，還是有關注的必要。

多樣化冗餘備份

在2017年1月31日23：00 左右 —團隊成員1認為， pg_basebackup 拒絕執行是因為 PostgreSQL 的資料目錄存在（儘管是空的），於是決定刪除該目錄。經過一兩秒鐘，他注意到他執行在 db1.cluster.gitlab.com，而不是 db2.cluster.gitlab.com。

在失去了熱備系統的環境下貿然執行危險操作，等同於拋棄了安全帶去超速行駛，這種情況下，一塊石頭就能讓人飛出座椅，同樣一個簡單的rm -rf就能幹掉單點主庫系統，所以“雙機/多機熱備”、“本地副本”這些健壯性必備的設施應該始終作為安全帶存在，安全帶損壞時應該對任何危險操作保持慎重。

而事故升級之後，“5套備份全部失效”應該是此次事故中最閃亮的爆點了吧，乍一看，這個破壞力可謂勢不可擋，輕易穿透了5層防禦將系統挑於馬下。但我們仔細分析官方所說的“5套備份”，卻發現從備份型別上卻只有一種：冷備份，只是它們使用了不同的引數而已。更不要說為重要資料所建立的“歸檔資料持久化轉儲”等業務級備份。

限制

“機器人不得傷害人類整體，或因不作為使人類整體受到傷害。”——阿西莫夫.機器人三定律-0

如有必要，我們應該限制或引導某個異常的決策，使之回到整體有序中。

危險行為限制

人的行為比預想中危險得多，而這個危險通常來自於“人類並不知道這個行為有多危險”和“人類會蓄意執行一個知道有多危險的行為”，所以對危險行為的限制是保證系統可靠性的第一個關口。

這其實是傳統運維圈中事實上的門規了：rm、mv、sudo等危險操作應該使用alias等手段嚴格限制，使用盡量細化的許可權認證，禁止直接使用root使用者…這些耳熟能詳的防禦措施在作業系統沒有推出專門優化之前，應該是日常運維中必備的check list。

專項工具集

與交付前諸多開發輔助工具同理，既然是自己人，那麼破壞系統的行為並不是操作者希望的，為線上危險操作提供一系列具有安全邊界的工具，能夠有效防止人為不確定性造成的失誤和破壞，而持續優化的工具會讓決策、操作更加便捷和高效，最常見的業務級後臺工具便是很好的例子。

對線上系統逐步建立工具集平臺，讓線上操作人員工作在安全的受限環境，是智慧運維平臺的終究要面對的事情，這也是雲概念逐漸深入人心的原因之一。

反饋

“黑暗蝕心智，目盲迷此廳”——暗黑3.目盲之書

人的恐懼來源於未知，未知是最大的不確定性，而反饋則是唯一擺脫未知的方法。

服務有效性檢測

“在部署的5套備份/複製方法中，沒有一套在可靠執行或當初設定正確”，在官方宣告中，這句話恐怕是最引人注目的了，為何到事故已經發生的時候才瞭解到如此低階的錯誤呢？問題就出在那個最可怕的地方：對錯誤一無所知。

而直接原因則是，備份服務並沒有經過充分測試便上線使用 和 迴歸測試的缺失，並且，對於這種具有先天惰性的服務，並沒有進行定期演練，那麼“日本日常地震自救演習大幅提高了生還率”這個看似八杆子打不著的事情用在這裡是恰當的。

持續狀態報告

在開發環節，我們逐漸認識了QA的重要性和必要性，努力對自己的產出質量進行儘可能多的瞭解，而同樣重要的系統執行質量檢測卻往往遊離在我們的視線之外，這也是開發人員忽略的問題，隨著系統越來越複雜，交付後的系統質量並不是一成不變，熵的存在讓系統健康度的持續監測變得越來越重要，那麼，持續、及時的反饋就變得尤為重要，“日報”、“定期檢測報告”、“實時視覺化系統”都可以幫助我們獲取準確的反饋資訊，從而針對異常做出快速反應。

異常行為報警/預警

一個“生命體”能夠及時反饋甚至預測危險，是其植物神經最基本的功能，這也是一個“系統”相對於“軟體”最關鍵的區別。所以，針對系統本身的異常行為的及時報警和準確預警，成了系統抵禦危險的重要機制，一般我們會更多的關注“安全性”而非“可靠性”，但對於有序體來說，這兩者是同一個概念。

對於刪庫事件中，rm -rf、磁碟容量持續大幅變化等可能影響到系統安全、可靠性的事件，如果能夠及時反饋給相關決策者，那麼損失可能更容易挽救。

然而，說了這麼多“反人類”的實踐，最後卻不得不承認，gitlab正是用了基於“人”的積極公關，才讓整個事故的損失降到最低，所以在人類還掌握著處理異常複雜不確定性的優勢的時候，我們的工作重點暫時還需要放在“輔助人類高效決策”的方向。