運維必讀：避免故障、拒絕背鍋的 10 大原則！

找到最早釋出於2012年，來自網路，原作者不詳

https://blog.csdn.net/levy_cui/article/details/51604257

故障是運維人員永遠的痛。相信每一個運維人員的KPI中都有一項：可用性。可用性高就是不出故障，各個公司對可用性和故障評級的標準都不相同，但是避免故障的方法卻是殊途同歸。我們怎麼避免故障，簡單列舉了以下幾條，與大家共勉！

• 1、變更要有回滾，在同樣的環境測試過

• 2、對破壞性的操作謹慎小心

• 3、設定好命令提示

• 4、備份並驗證備份有效性

• 5、對生產環境存有敬畏之心

• 6、交接和休假最容易出故障，變更請謹慎

• 7、搭建報警，及時獲得出錯資訊。搭建效能監控，瞭解歷史，獲得趨勢，預測未來

• 8、自動切換需謹慎

• 9、仔細一點，偏執一點，檢查，檢查，再檢查

• 10、簡單即是美。

第1條，變更要有回滾，在同樣的環境測試過。

也是運維最繁瑣，最苦逼的地方，所有的變更都必須有回滾的辦法，在同樣的環境下測試過。沒有做過的東西，總是會在你意想不到的地方給你一次痛擊，在阿裡巴巴的這麼多年運維經驗告訴我們，所有沒有做過的變更，出錯的機率最大。所以我們需要給變更以回滾的可能，在各個步驟可能出錯的情況下，考慮回滾到最初狀態。優秀的運維人員對不考慮回滾的的操作都是敬而遠之的。從某種意義上來說，運維是一門經驗的學科，是一門試錯的學科。

第2條，對破壞性的操作謹慎小心。

破壞性的操作有哪些列？對資料庫來說有：DROP Table， Drop database，truncate table， delete all data；這些操作做完了以後幾乎無法考慮怎麼把資料都回滾回去了。就算回滾，代價也是非常大的。你執行這樣的陳述句非常簡單，但是回滾恢復資料缺非常困難。linux的命令rm可以-r(recursive)遞迴的刪除某一個目錄，-f(force)強制刪除，但是你有沒有刪錯過檔案。我們遇到過一個檔案名中末尾有空格的情況，而有的同事rm -r習慣性的會在檔案名後面加＊，這樣就成了rm -r aa *，所有當前目錄的資料都被刪除掉了！經過這次故障以後我們給rm做了別名：
alias rm=’rm -i’
這樣在刪除資料時，rm命令會提示你，是否確認刪除該檔案。
同樣的cp和mv也可以有同樣的選項：
alias cp=’cp -i’
alias mv=’mv -i’

第3條，設定好命令提示。

讓你時刻知道你在操作哪個資料庫，讓你知道你在哪個目錄下。mysql字元客戶端允許你設定提示符，預設的提示符就是一個光禿禿的mysql >，為了讓你清楚的知道你當前是以哪個使用者名稱，哪個IP（可能是localhost，127.0.0.1或者具體的物理IP），你當前操作的是哪個schema，以及當前的時間，你可以設定資料庫的提示符為：prompt=“\\u@\\h : \\d \\r:\\m:\\s> ”。它可以直接寫在my.cnf的[mysql]下，這樣你每次連上MySQL就預設顯示如下：
root@127.0.0.1 : woqutech 08:24:36>
具體prompt可以設定哪些提示，你可以參考http://dev.mysql.com/doc/refman/5.6/en/mysql-commands.html 中的串列
而linux命令提示符也允許你設定的。有兩個地方可以設定。第一個：PS1。這個是每次shell提示你輸入命令的資訊，預設為：$或者#，只會提示你是超級使用者還是普通使用者。有經驗的運維者會設定export PS1=’\n\e[1;37m[\e[m\e[1;31m\u\e[m\e[1;31m@\e[m\e[1;31m\h\e[m \e[4mpwd\e[m\e[1;37m]\e[m\e[1;36m\e[m\n\$’。這樣你就可以知道你當前的目錄，登入的使用者名稱和主機資訊了，示例提示符如下：

[root@woqu-lsv-01 /home/mysql]#

你可以檢視http://www.cyberciti.biz/tips/howto-linux-unix-bash-shell-setup-prompt.html 獲得具體的PS1設定顏色，設定各個提示內容的介紹。

第二個提示符就是PROMPT_COMMAND。這個是設定你連到具體的資料庫以後標簽頁標題上顯示的內容，Windows使用者可能會用securtCRT，Mac使用者可能會用iTerm2，開多個標簽頁的話，如果每個標簽頁的標題上內容一樣，我們切來切去就有可能在錯誤的標簽頁上做操作，設定了這個以後，這個問題機率就會小很多。比如我們的機器上設定為PROMPT_COMMAND=’echo -ne “\033]0;${USER}@${HOSTNAME%%.*}”; echo -ne “\007″‘對應的標簽頁如下圖

第4條，備份並驗證備份有效性。

是人總會出錯，是機器總可能會有突然崩潰的那一天。怎麼辦－我們需要準備備份。

備份的學問很大。按照不同的緯度可以分為：冷備份和熱備份；實時備份和非實時備份；物理備份和邏輯備份。

網際網路企業為了提供7*24小時不間斷的服務，資料庫就需要有實時熱備份。在主庫出現問題的情況下能夠由備庫提供服務。備庫時候有效，資料是否一致，主庫出現問題的時候怎麼切換都需要運維人員認真考慮。

是不是有了這些就夠了列？不行，應用程式也是人寫的，曾經出現過程式一不小心delete陳述句沒有帶任何條件，導致一個表中所有的資料都被刪除的慘狀。所以你除了實時的備份，還需要有非實時的備份，在你的資料出現邏輯錯誤之後能夠從備份資料中恢復出來。現在很多人在研究MySQL模仿oracle的flashback功能，利用binlog來恢復資料。但是這樣的話，binlog_format必須設定為row並且對於DDL操作也無法回滾。它是為快速解決部分資料被錯誤刪除的解決方案，但是無法代替非實時備份的作用。

非實時備份有可以分為線上延時備份和離線備份。線上延時備份是搭建資料庫的一定時間延遲的熱備份，比如MySQL就可以搭建一個延遲一天的slave，一直保持著備庫與主庫的延遲在一天。可以利用pt-slave-delay工具來實現這個功能。另外，離線備份是目前大家用的比較多的，可以利用mysqldump進行邏輯備份或者xtrabackup進行物理備份。為了空間的原因和快速恢復考慮，你還可以利用xtrabackup進行增量的物理備份。

備份有了，是否就可以高枕無憂了？還是不行。你需要驗證備份的有效性。沒有一個備份能夠保證它備份出來的資料能夠100%恢復出正確的資料，特別是物理備份的機率相對來說，更低，xtrabackup備份一個月總有那麼幾次來大姨媽，不能給你很好的服務。所以，備份並不只是備份，它還包括備份的驗證，它如果不能恢復出正確的資料，就只是浪費空間而已。備份的驗證最簡單的就是找一個空閑的庫，來恢復出來，mysql啟動以後檢查部分資料。如果不需要這麼嚴謹，對於xtrabackup來說，你至少得驗證它–apply-log能夠恢覆上去吧？同樣，備庫的資料一致性也需要經常檢查一下，mysql的replication並不保證100%的資料一致性，你可以去翻翻mysql statement複製的bug串列，有些資料在主備不同的環境上分別執行，資料就會不一樣。可以考慮用percona的工具pt-table-checksum來檢查主備不一致，用pt-table-sync來同步主備資料。

第5條，對生產環境存有敬畏之心。

這應該是運維者進入行業首先需要具備的素質。但是我們還是需要把它拿出來強調一下。

有機會的話，你可以梳理一下：

• 你的生產環境上有哪些賬戶，這些賬戶是否都確實需要登入到機器上來？這些賬戶即包括linux使用者還包括資料庫賬戶。

• 你的root使用者是否開放給了某些使用者，這些使用者安全嗎？

• 你的使用者密碼是否經常修改，是否加密不讓具體的操作人員直接看到，密碼強度時候足夠，密碼重試次數達到一定次數是否黑名單；

• 你的生產環境和線下環境是否隔離，資料庫是否和外網隔離？

• 是否一些工作明明能夠在開發庫和測試庫做，卻被放到生產環境上去了。

• 是否有專門的人負責線上應用的釋出，從而避免開發人員直接接觸生產環境

這些都是你避免出現csdn密碼洩漏，在業界的名聲一落千丈的法寶。

第6條，交接和休假最容易出故障，變更請謹慎。

這個是經驗之談。我們在總結故障的情況時，發現在公司部門有變化時，工作交接(不管是休假，工作職責變化還是離職)，故障的出現頻率會比正常情況下多50%以上。有人說，這是因為機器或者應用是有感情的，捨不得離開的運維者。

我們不談感情，簡單的理性分析一下。公司或者部門難免會做一些調整，變化是世界上唯一不變的事情。而運維人員是一線做事情的人，部門調整或者領導的更換可能導致工作的著重點不同，做事的方式和評測的標準變了，適應過程中難免會出現一些考慮不周到的地方，出故障也是情理之中了。

而工作交接，對運維人來說，其實是一個非常費時費力的事情，你需要把所有平常做的工作都梳理清楚，甚至包括你的一些經意不經意的操作習慣，這樣的話，下一個人才可能接手的下來。比如：你可能認為備庫正常情況下沒有訪問，於是讓某些並不重要的任務(一個月一次抽取部分資料到線下測試？)直接連備機IP進行操作。下一個人接手，認為備機就是備機，操作起來不會有任何問題，結果下一次任務抽取就是一個故障出來了。再舉一個我們遇到了事例吧：同事A出國休假了，休假期間估計聯絡不上，他留了檔案，並告誡說某幾個庫和表是比較核心和容易出問題的，沒有特殊情況最好等他回來再做變更。正好，休假期間，開發人員找到同事B，要求他重置一個欄位的某一位（bit），並打包票說這個bit沒有用，同事B拒絕，並背上了不配合的罵名。同事A回來嚇了一身冷汗，原來這個欄位已經被另外一個離職的開發使用了。

所以，運維部門和運維人員對變化需要儘量放平心態；接手別人的工作要一而再，再而三的確認變更方案。請教人並不見得就是能力不行的表現；休假前最好各種可以做好的事情，最好能夠準備一份檔案，指明在什麼情況下怎麼做和聯絡哪些人。在別人放假的時候接手工作，“能拖則拖”，實在需要執行：必須不厭其煩的跟原運維者確認各個操作細節。

第7條，搭建報警，及時獲得出錯資訊。

搭建效能監控，瞭解歷史，獲得趨勢，預測未來。運維的最高境界不是故障來了，泰山崩於前而不驚，蒼老師勾引你而抗日；而是沒有故障，讓故障消失在萌芽之中。請給那些默默無聞，每天想著我們的系統還存在哪些隱患，怎麼解決，怎麼及早發現的運維人員鼓掌。他們是最可愛的人。而他們賴以生存的工具就是報警和監控。Oracle發展了這麼多年，awr和相關的效能引數都相對比較全；MySQL現在也已經迎頭趕上，配套的工具越來越多。

報警可以讓你及時知道系統出現了什麼異常。比如slave io報警，在資料庫replication異常的時候就會提醒你：IO執行緒出現了問題，可能是網路問題，主資料庫問題等，slave sql報警會提醒你replication的SQL執行緒出現了問題，可能是主備不一致，slave被停掉了，儲存過程在備機有異常或者其他問題。這樣你收到報警就可以及時跟進，而不至於主備長時間不一致，主庫壞掉了想要切換到備庫的時候卻不能切換。

效能監控可以讓你瞭解系統的歷史效能資訊。分析故障發生時的各種現象，確認故障的真正原因；瞭解變化趨勢，發現故障的苗頭，及早最佳化和調整。比如你如果使用了PCI-E的Flash卡，你可以監控logical_written_bytes，logical_read_bytes，physical_written_bytes，physical_read_bytes以便獲得flash卡的每秒的邏輯讀寫和物理讀寫位元組數。對於MySQL你可以監控Com_delete+Com_delete_multi, Com_insert+Com_insert_select，Com_update+Com_update_multi，Com_select來獲得每秒的MySQL DML刪除，插入，更新和查詢的次數。

報警和效能監控其實不不完全獨立的，很多效能的監控項也可以報警出來。比如linux的iostat中的await_time可以作為效能監控採集起來獲得系統IO響應時間的變化曲線，當該值達到20以上的時候，也可以報警出來，讓運維人員跟進是磁碟陣列中壞了一塊，還是異常的資料複製影響了系統的IO效能等。

nagios和cacti是目前MySQL領域使用最廣泛的報警和效能展示系統。percona最新推出percona-monitor-plugins(http://www.percona.com/software/percona-monitoring-plugins)就是基於他們倆的。

第8條：自動切換需謹慎。

現在資料庫的HA很多都是進行自動切換的，這樣運維人員深夜起來手工切換到備庫的機會就會少很多。切換也會快速很多。但是，它帶來的副作用也不容忽視。

現在業界使用的HA軟體非常多，heartbeat由於很多SA兼作DBA的運維比較熟悉，在MySQL自動切換也是不少的。一般來說，它會透過mysqladmin ping來探測MySQL是否存活，如果發現異常，那麼他就會切換VIP和MySQL資源到備庫。但是此時備庫的資料延遲是否為0，主庫crash之後binlog的資料是否全部都同步到備庫上去了，備庫的read_only是否關閉，這些heartbeat都不管。我們想象一下，主庫上應用提交了一筆訂單，結果發生了切換，這筆訂單沒有同步到備庫上，賣家也就損失了一個銷售單，對客戶，對公司都是非常大的影響。

當然，自動切換也不能全盤否定，它能夠更快速的將應用切換到新的熱備份備庫上，應用的不可用時間大大縮短。只是我們要好好利用這一把雙刃劍，仔細評估它的影響，降低或者去除副作用，讓它為我們服務。

第9條，仔細一點，偏執一點，檢查，檢查，再檢查。

之前我跟一個資深的運維學習線上操作的時候，覺得這傢伙有點變態，他在做一個變更的時候，會先提前一兩周傳送郵件並電話手機的通知相關人；在測試機上寫好指令碼，召集大家review操作步驟和指令碼；測試完成以後複製到生產環境；登入對應機器，“開啟，關閉，開啟，關閉”該指令碼；跟相關人員再次確認執行的操作，順序，時間點，可能的影響和回滾是否都準備好了；執行前還要退出這個機器，然後再登入進去，“開啟，關閉”指令碼；最後才在後臺執行指令碼，在另外一個視窗登入著，隨時ps和檢視結果輸出。期間姿勢端正，呼吸急促而均勻，眼神凝重。操作的人不覺得累，倒是一邊學習的人很累。

當我做到一定程度，我也開始這樣了。醫學上，這種好像叫做強迫症。唉…，提前通知會讓大家都有準備，也避免了臨時相關人員過來說這個操作和其他操作有依賴需要調整操作時間的問題；召集大家review步驟和指令碼是為了讓大家一起來看看整個過程中還有哪些依賴沒有考慮到或者哪些細節沒有註意到，三個臭皮匠頂一個諸葛亮在運維來說是金科玉律；“開啟，關閉，開啟，關閉”是為了一再確認指令碼複製過來是否正確，目錄是否正確，思考在測試環境執行和在生產環境執行有什麼不一樣的；退出再登入機器是為了確認我登入的機器確實沒有錯；在後臺執行是擔心網路突然中斷，我的指令碼執行到一半怎麼辦；調整呼吸和端正姿勢是為了對這個操作的敬重，對自己工作和運維工作的尊重。

以MySQL 使用flash卡為例吧。flash算是一個比較新的事務，提供的IO比普通磁碟是幾個數量級的提升。要想在生產環境使用，首先我們需要對他進行詳盡的評估和破壞性測試，設定各種引數，考慮他們在各種場景下使用的配置；24小時不間斷的進行半個月讀寫操作，中途突然掉電；高併發，高吞吐量下的測試；溫度濕度極限測試；預留空間釋放測試等等。然後我們會嘗試在測試庫上部署試用，收集和修改各個配置已達到最穩定，最高效能的配置；執行穩定以後我們才考慮線上上備庫使用，並且主備要求異構；適當的時機切換為使用新的flahs卡為主庫，萬一齣現了問題，還可以切換回原主機。

這裡也跟大家簡單介紹一下screen命令，這個命令會在伺服器段開啟一個session，就算你的網路斷掉了，你的指令碼也會自動在後臺執行。screen -S woqutech可以開啟一個woqutech命令的後臺session；如果你的網路斷掉了，你可以用screen -dr woqutech連上之前的session繼續進行操作。IBM的檔案庫中有一個非常靠譜的檔案：http://www.ibm.com/developerworks/cn/linux/l-cn-screen/。

第10條，簡單即是美。

最後一條有點禪的意境了。它和Unix的思想不謀而合。我們總是面臨著各種誘惑：新的系統架構，新的更智慧的命令和工具，最新的硬體平臺，功能更全的HA軟體等。他們總是以各種各樣的方式吸引我們，most exciting，unbelievable，讓你欲罷不能。你可以線上下安裝，測試，怎麼搞都行。但是如果想要在生產環境下使用起來，那就得經過非常詳細，非常漫長，各種方式驗證其穩定性的過程。

能夠使用系統內建命令的話，就不用考慮其他要專門下載安裝的軟體了；指令碼本身就能完成的功能，就沒有必要專門找一個功能豐富的軟體來做；linux本身自帶的字元介面比那些複雜的圖形介面要簡潔方便；MySQL的一些分割槽，生僻函式，沒有必要的話不要使用。

最後祝大家運維的運維工作一帆風順，多福多壽，不出故障。

參考：http://feedproxy.google.com/~r/iheavy/~3/sRnyFPA0R9E/