|
俗話說，天災(zāi)可怕，人禍更甚，最近的 GitLab 刪庫曾一度牽動了碼界尤其是運維圈的神經(jīng)，好在GitLab 官方開放積極的公關(guān)，才讓整個事件在肯定中得到平息。 平息歸平息，從這個事故中反映出來的問題卻值得我們引以為戒，隨著規(guī)模越來越復(fù)雜，說到軟件系統(tǒng)，我們已經(jīng)越來越習慣把它歸為“人”的問題，因為人類的不確定性，我們一直努力在開發(fā)中盡量減少之，而系統(tǒng)運行中用來防御人類破壞的功能更是占了越來越大的比重，也正如整個刪庫事件一樣，人禍成了系統(tǒng)運行中最難預(yù)測危害最大的不穩(wěn)定因素。 “人類是系統(tǒng)可靠性最大的勁敵”也逐漸成了DevOps的教旨，那么基于這點，今天我們就來簡單聊一下復(fù)雜軟件系統(tǒng)可靠性的提升問題，結(jié)合這幾年在DevOps摸爬滾打的經(jīng)驗，從“決策”“執(zhí)行”“限制”“反饋”四個不確定性溫床中摸索下解決方案。 決策
決策權(quán)現(xiàn)在還掌握在不靠譜的人類手里，我們只能先從這里下手。 不要疲勞駕駛我們姑且不論“8小時工作制”是否真正科學，所有腦力勞動，違背用腦規(guī)律甚至使之處于過載疲勞狀態(tài)，都會顯著降低腦部的能量轉(zhuǎn)換效率，大幅增加決策能力的不確定性，雖然針對疲勞的措施，納入法律的只有“疲勞駕駛”，但疲勞所帶來的危害卻越來越被人們關(guān)注。 這讓我想起當年為了盡快上線而挑燈夜戰(zhàn)導(dǎo)致腳本出錯用rsync –delete干掉一臺線上服務(wù)器的光榮事跡，而gitlab的刪庫事件也正是操作員疲勞狀態(tài)下進行線上操作所釀成的，更令人擔心的是，我們的大腦在疲勞的時候更容易放棄思考而輕易得出“這點疲勞礙不啥事”的結(jié)論（等同于醉酒），這必須引起警惕，雖然故障并不會選擇在我們清醒的時候來光顧，但在此還是要給出我的建議：科學用腦，將時間用在效率最高的地方。 pair防止單點故障已經(jīng)是系統(tǒng)運行可靠性老生常談的手段了，而對于決策者來說，一個搭檔，會讓決策的不確定性降低至少一半。運維工作的性質(zhì)導(dǎo)致我們并不能保證故障就要在我們清醒的時候發(fā)生，正如pair會讓開發(fā)人員盡可能的集中注意力，合理搭配雙方的高效時間，在進行線上系統(tǒng)重要操作的時候，多一雙眼睛盯著，操作失誤率會大幅提升——因為我們的pair絕不會是我們的完美復(fù)制品，這也是符合“系統(tǒng)多樣性帶來可靠性提升”的原理。 執(zhí)行
一個有序體應(yīng)當與熵戰(zhàn)斗，盡可能讓自己免受破壞，這是生命體的關(guān)鍵特性。 變化率一致性這次事故中，損壞丟失的數(shù)據(jù)并不是git代碼主庫，而是保存有issue、MR等信息的外掛數(shù)據(jù)庫，為了方便使用版本控制和沖突管理特性而建立在git庫基礎(chǔ)上的wiki也因此幸免于難。一個完整的workflow要被分割存在于兩個變化率不同的容器，讓我這潔癖碼農(nóng)始終覺得不大踏實，分割存儲不是備份冗余，后者的基礎(chǔ)是單點數(shù)據(jù)完整。 當然在討論中有朋友有提到，對于頻繁數(shù)據(jù)交換、開關(guān)、狀態(tài)流轉(zhuǎn)，傳統(tǒng)db較之git庫，有著先天的優(yōu)勢，但將已歸檔的流式數(shù)據(jù)合并入git庫中來獲得一致的數(shù)據(jù)變化率也不失為一個好辦法，所以個人覺得，數(shù)據(jù)變化率一致性上，還是有關(guān)注的必要。 多樣化冗余備份
在失去了熱備系統(tǒng)的環(huán)境下貿(mào)然執(zhí)行危險操作，等同于拋棄了安全帶去超速行駛，這種情況下，一塊石頭就能讓人飛出座椅，同樣一個簡單的rm -rf就能干掉單點主庫系統(tǒng)，所以“雙機/多機熱備”、“本地副本”這些健壯性必備的設(shè)施應(yīng)該始終作為安全帶存在，安全帶損壞時應(yīng)該對任何危險操作保持慎重。 而事故升級之后，“5套備份全部失效”應(yīng)該是此次事故中最閃亮的爆點了吧，乍一看，這個破壞力可謂勢不可擋，輕易穿透了5層防御將系統(tǒng)挑于馬下。但我們仔細分析官方所說的“5套備份”，卻發(fā)現(xiàn)從備份類型上卻只有一種：冷備份，只是它們使用了不同的參數(shù)而已。更不要說為重要數(shù)據(jù)所建立的“歸檔數(shù)據(jù)持久化轉(zhuǎn)儲”等業(yè)務(wù)級備份。 限制
如有必要，我們應(yīng)該限制或引導(dǎo)某個異常的決策，使之回到整體有序中。 危險行為限制人的行為比預(yù)想中危險得多，而這個危險通常來自于“人類并不知道這個行為有多危險”和“人類會蓄意執(zhí)行一個知道有多危險的行為”，所以對危險行為的限制是保證系統(tǒng)可靠性的第一個關(guān)口。 這其實是傳統(tǒng)運維圈中事實上的門規(guī)了：rm、mv、sudo等危險操作應(yīng)該使用alias等手段嚴格限制，使用盡量細化的權(quán)限認證，禁止直接使用root用戶…這些耳熟能詳?shù)姆烙胧┰诓僮飨到y(tǒng)沒有推出專門優(yōu)化之前，應(yīng)該是日常運維中必備的check list。 專項工具集與交付前諸多開發(fā)輔助工具同理，既然是自己人，那么破壞系統(tǒng)的行為并不是操作者希望的，為線上危險操作提供一系列具有安全邊界的工具，能夠有效防止人為不確定性造成的失誤和破壞，而持續(xù)優(yōu)化的工具會讓決策、操作更加便捷和高效，最常見的業(yè)務(wù)級后臺工具便是很好的例子。 對線上系統(tǒng)逐步建立工具集平臺，讓線上操作人員工作在安全的受限環(huán)境，是智能運維平臺的終究要面對的事情，這也是云概念逐漸深入人心的原因之一。 反饋
人的恐懼來源于未知，未知是最大的不確定性，而反饋則是唯一擺脫未知的方法。 服務(wù)有效性檢測“在部署的5套備份/復(fù)制方法中，沒有一套在可靠運行或當初設(shè)置正確”，在官方聲明中，這句話恐怕是最引人注目的了，為何到事故已經(jīng)發(fā)生的時候才了解到如此低級的錯誤呢？問題就出在那個最可怕的地方：對錯誤一無所知。 而直接原因則是，備份服務(wù)并沒有經(jīng)過充分測試便上線使用 和 回歸測試的缺失，并且，對于這種具有先天惰性的服務(wù)，并沒有進行定期演練，那么“日本日常地震自救演習大幅提高了生還率”這個看似八桿子打不著的事情用在這里是恰當?shù)摹?/p> 持續(xù)狀態(tài)報告在開發(fā)環(huán)節(jié)，我們逐漸認識了QA的重要性和必要性，努力對自己的產(chǎn)出質(zhì)量進行盡可能多的了解，而同樣重要的系統(tǒng)運行質(zhì)量檢測卻往往游離在我們的視線之外，這也是開發(fā)人員忽略的問題，隨著系統(tǒng)越來越復(fù)雜，交付后的系統(tǒng)質(zhì)量并不是一成不變，熵的存在讓系統(tǒng)健康度的持續(xù)監(jiān)測變得越來越重要，那么，持續(xù)、及時的反饋就變得尤為重要，“日報”、“定期檢測報告”、“實時可視化系統(tǒng)”都可以幫助我們獲取準確的反饋信息，從而針對異常做出快速反應(yīng)。 異常行為報警/預(yù)警一個“生命體”能夠及時反饋甚至預(yù)測危險，是其植物神經(jīng)最基本的功能，這也是一個“系統(tǒng)”相對于“軟件”最關(guān)鍵的區(qū)別。所以，針對系統(tǒng)本身的異常行為的及時報警和準確預(yù)警，成了系統(tǒng)抵御危險的重要機制，一般我們會更多的關(guān)注“安全性”而非“可靠性”，但對于有序體來說，這兩者是同一個概念。 對于刪庫事件中，rm -rf、磁盤容量持續(xù)大幅變化等可能影響到系統(tǒng)安全、可靠性的事件，如果能夠及時反饋給相關(guān)決策者，那么損失可能更容易挽救。 然而，說了這么多“反人類”的實踐，最后卻不得不承認，gitlab正是用了基于“人”的積極公關(guān)，才讓整個事故的損失降到最低，所以在人類還掌握著處理異常復(fù)雜不確定性的優(yōu)勢的時候，我們的工作重點暫時還需要放在“輔助人類高效決策”的方向。 |
|
|
