故障是運維人員永遠的痛。相信每一個運維人員的KPI中都有一項：可用性?？捎眯愿呔褪遣怀龉收?，各個公司對可用性和故障評級的標準都不相同，但是避免故障的方法卻是殊途同歸。我們怎么避免故障，簡單列舉了以下幾條，與大家共勉！
1、變更要有回滾，在同樣的環(huán)境測試過
運維最繁瑣，最苦逼的地方，所有的變更都必須有回滾的辦法，在同樣的環(huán)境下測試過。沒有做過的東西，總是會在你意想不到的地方給你一次痛擊，在阿里巴巴的這么多年運維經驗告訴我們，所有沒有做過的變更，出錯的概率最大。所以我們需要給變更以回滾的可能，在各個步驟可能出錯的情況下，考慮回滾到最初狀態(tài)。優(yōu)秀的運維人員對不考慮回滾的的操作都是敬而遠之的。從某種意義上來說，運維是一門經驗的學科，是一門試錯的學科。
2、對破壞性的操作謹慎小心
破壞性的操作有哪些列？對數據庫來說有：DROP Table， Drop database， truncate table， delete all data；這些操作做完了以后幾乎無法考慮怎么把數據都回滾回去了。就算回滾，代價也是非常大的。你執(zhí)行這樣的語句非常簡單，但是回滾恢復數據缺非常困難。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[4m`pwd`\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、備份并驗證備份有效性
是人總會出錯，是機器總可能會有突然崩潰的那一天。怎么辦呢？我們需要準備備份。備份的學問很大。按照不同的緯度可以分為：冷備份和熱備份；實時備份和非實時備份；物理備份和邏輯備份。互聯(lián)網企業(yè)為了提供7*24小時不間斷的服務，數據庫就需要有實時熱備份。在主庫出現問題的情況下能夠由備庫提供服務。備庫是否有效，數據是否一致，主庫出現問題的時候怎么切換都需要運維人員認真考慮。
是不是有了這些就夠了呢？不行，應用程序也是人寫的，曾經出現過程序一不小心 delete 語句沒有帶任何條件，導致一個表中所有的數據都被刪除的慘狀。所以你除了實時的備份，還需要有非實時的備份，在你的數據出現邏輯錯誤之后能夠從備份數據中恢復出來?，F在很多人在研究 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 列表，有些數據在主備不同的環(huán)境上分別執(zhí)行，數據就會不一樣?？梢钥紤]用 percona 的工具 pt-table-checksum 來檢查主備不一致，用 pt-table-sync 來同步主備數據。
5、對生產環(huán)境存有敬畏之心
這應該是運維者進入行業(yè)首先需要具備的素質。但是我們還是需要把它拿出來強調一下。有機會的話，你可以梳理一下：
- 你的生產環(huán)境上有哪些賬戶，這些賬戶是否都確實需要登錄到機器上來？這些賬戶即包括 Linux 用戶還包括數據庫賬戶。
- 你的 root 用戶是否開放給了某些用戶，這些用戶安全嗎？
- 你的用戶密碼是否經常修改，是否加密不讓具體的操作人員直接看到，密碼強度時候足夠，密碼重試次數達到一定次數是否黑名單？
- 你的生產環(huán)境和線下環(huán)境是否隔離，數據庫是否和外網隔離？
- 是否一些工作明明能夠在開發(fā)庫和測試庫做，卻被放到生產環(huán)境上去了？
- 是否有專門的人負責線上應用的發(fā)布，從而避免開發(fā)人員直接接觸生產環(huán)境？
6、交接和休假最容易出故障，變更請謹慎
這個是經驗之談。我們在總結故障的情況時，發(fā)現在公司部門有變化時，工作交接（不管是休假、工作職責變化還是離職），故障的出現頻率會比正常情況下多50%以上。有人說，這是因為機器或者應用是有感情的，舍不得離開的運維者。
我們不談感情，簡單的理性分析一下。公司或者部門難免會做一些調整，變化是世界上唯一不變的事情。而運維人員是一線做事情的人，部門調整或者領導的更換可能導致工作的著重點不同，做事的方式和評測的標準變了，適應過程中難免會出現一些考慮不周到的地方，出故障也是情理之中了。而工作交接，對運維人員來說，其實是一個非常費時費力的事情，你需要把所有平常做的工作都梳理清楚，甚至包括你的一些經意不經意的操作習慣，這樣的話，下一個人才可能接手得下來。比如：你可能認為備庫正常情況下沒有訪問，于是讓某些并不重要的任務（一個月一次抽取部分數據到線下測試？）直接連備機IP進行操作。下一個人接手，認為備機就是備機，操作起來不會有任何問題，結果下一次任務抽取就是一個故障出來了。再舉一個我們遇到了事例吧：同事A出國休假了，休假期間估計聯(lián)系不上，他留了文檔，并告誡說某幾個庫和表是比較核心和容易出問題的，沒有特殊情況最好等他回來再做變更。正好，休假期間，開發(fā)人員找到同事B，要求他重置一個字段的某一位（bit），并打包票說這個 bit 沒有用，同事B拒絕，并背上了不配合的罵名。同事A回來嚇了一身冷汗，原來這個字段已經被另外一個離職的開發(fā)使用了。所以，運維部門和運維人員對變化需要盡量放平心態(tài)；接手別人的工作要一而再，再而三的確認變更方案。請教人并不見得就是能力不行的表現；休假前最好各種可以做好的事情，最好能夠準備一份文檔，指明在什么情況下怎么做和聯(lián)系哪些人。在別人放假的時候接手工作，“能拖則拖”，實在需要執(zhí)行：必須不厭其煩的跟原運維者確認各個操作細節(jié)。
7、搭建報警，及時獲得出錯信息
搭建性能監(jiān)控，了解歷史，獲得趨勢，預測未來。運維的最高境界不是故障來了，泰山崩于前而不驚，蒼老師勾引你而抗日；而是沒有故障，讓故障消失在萌芽之中。請給那些默默無聞，每天想著我們的系統(tǒng)還存在哪些隱患，怎么解決，怎么及早發(fā)現的運維人員鼓掌。
他們是最可愛的人。而他們賴以生存的工具就是報警和監(jiān)控。Oracle發(fā)展了這么多年，awr 和相關的性能參數都相對比較全；MySQL 現在也已經迎頭趕上，配套的工具越來越多。報警可以讓你及時知道系統(tǒng)出現了什么異常。比如 slave io 報警，在數據庫 replication 異常的時候就會提醒你：IO線程出現了問題，可能是網絡問題，主數據庫問題等，slave sql 報警會提醒你 replication 的 SQL 線程出現了問題，可能是主備不一致，slave 被停掉了，存儲過程在備機有異?；蛘咂渌麊栴}。這樣你收到報警就可以及時跟進，而不至于主備長時間不一致，主庫壞掉了想要切換到備庫的時候卻不能切換。性能監(jiān)控可以讓你了解系統(tǒng)的歷史性能信息。分析故障發(fā)生時的各種現象，確認故障的真正原因；了解變化趨勢，發(fā)現故障的苗頭，及早優(yōu)化和調整。比如你如果使用了PCI-E 的 Flash 卡，你可以監(jiān)控logical_written_bytes，logical_read_bytes，physical_written_bytes，physical_read_bytes以便獲得 flash 卡的每秒的邏輯讀寫和物理讀寫字節(jié)數。對于MySQL你可以監(jiān)控Com_delete+Com_delete_multi, Com_insert+Com_insert_select，Com_update+Com_update_multi，Com_select來獲得每秒的 MySQL DML 刪除，插入，更新和查詢的次數。報警和性能監(jiān)控其實不不完全獨立的，很多性能的監(jiān)控項也可以報警出來。比如 linux 的 iostat 中的 await_time 可以作為性能監(jiān)控采集起來獲得系統(tǒng)IO響應時間的變化曲線，當該值達到20以上的時候，也可以報警出來，讓運維人員跟進是磁盤陣列中壞了一塊，還是異常的數據拷貝影響了系統(tǒng)的IO性能等。
8、自動切換需謹慎
現在數據庫的HA很多都是進行自動切換的，這樣運維人員深夜起來手工切換到備庫的機會就會少很多。切換也會快速很多。但是，它帶來的副作用也不容忽視。
現在業(yè)界使用的HA軟件非常多，heartbeat 由于很多SA兼作DBA的運維比較熟悉，在 MySQL 自動切換也是不少的。一般來說，它會通過 mysqladmin ping 來探測MySQL 是否存活，如果發(fā)現異常，那么他就會切換 VIP 和 MySQL 資源到備庫。
但是此時備庫的數據延遲是否為0，主庫 crash 之后 binlog 的數據是否全部都同步到備庫上去了，備庫的 read_only 是否關閉，這些 heartbeat 都不管。我們想象一下，主庫上應用提交了一筆訂單，結果發(fā)生了切換，這筆訂單沒有同步到備庫上，賣家也就損失了一個銷售單，對客戶，對公司都是非常大的影響。
當然，自動切換也不能全盤否定，它能夠更快速的將應用切換到新的熱備份備庫上，應用的不可用時間大大縮短。只是我們要好好利用這一把雙刃劍，仔細評估它的影響，降低或者去除副作用，讓它為我們服務。
9、仔細一點，偏執(zhí)一點，檢查，再檢查
之前我跟一個資深的運維學習線上操作的時候，覺得這家伙有點變態(tài)，他在做一個變更的時候，會先提前一兩周發(fā)送郵件并電話手機的通知相關人；在測試機上寫好腳本，召集大家 review 操作步驟和腳本；測試完成以后拷貝到生產環(huán)境；登錄對應機器，“打開，關閉，打開，關閉”該腳本；跟相關人員再次確認執(zhí)行的操作，順序，時間點，可能的影響和回滾是否都準備好了；執(zhí)行前還要退出這個機器，然后再登錄進去，“打開，關閉”腳本；最后才在后臺運行腳本，在另外一個窗口登錄著，隨時ps和查看結果輸出。期間姿勢端正，呼吸急促而均勻，眼神凝重。操作的人不覺得累，倒是一邊學習的人很累。
當我做到一定程度，我也開始這樣了。醫(yī)學上，這種好像叫做強迫癥。唉，提前通知會讓大家都有準備，也避免了臨時相關人員過來說這個操作和其他操作有依賴需要調整操作時間的問題；召集大家 review 步驟和腳本是為了讓大家一起來看看整個過程中還有哪些依賴沒有考慮到或者哪些細節(jié)沒有注意到，三個臭皮匠頂一個諸葛亮在運維來說是金科玉律；“打開，關閉，打開，關閉”是為了一再確認腳本拷貝過來是否正確，目錄時候正確，思考在測試環(huán)境運行和在生產環(huán)境運行有什么不一樣的；退出再登錄機器是為了確認我登錄的機器確實沒有錯；在后臺運行是擔心網絡突然中斷，我的腳本運行到一半怎么辦；調整呼吸和端正姿勢是為了對這個操作的敬重，對自己工作和運維工作的尊重。以 MySQL 使用 flash 卡為例吧。flash 算是一個比較新的事務，提供的IO比普通磁盤是幾個數量級的提升。要想在生產環(huán)境使用，首先我們需要對他進行詳盡的評估和破壞性測試，設置各種參數，考慮他們在各種場景下使用的配置；24小時不間斷的進行半個月讀寫操作，中途突然掉電；高并發(fā)，高吞吐量下的測試；溫度濕度極限測試；預留空間釋放測試等等。然后我們會嘗試在測試庫上部署試用，收集和修改各個配置已達到最穩(wěn)定，最高性能的配置；運行穩(wěn)定以后我們才考慮在線上備庫使用，并且主備要求異構；適當的時機切換為使用新的 flahs 卡為主庫，萬一出現了問題，還可以切換回原主機。
這里也跟大家簡單介紹一下 screen 命令，這個命令會在服務器段開啟一個 session，就算你的網絡斷掉了，你的腳本也會自動在后臺運行。screen -S woqutech 可以開啟一個 woqutech 命令的后臺 session；如果你的網絡斷掉了，你可以用screen -S woqutech 連上之前的 session 繼續(xù)進行操作。IBM的文檔庫中有一個非?？孔V的文檔：
http://www.ibm.com/developerworks/cn/linux/l-cn-screen/。
10、簡單即是美
最后一條有點禪的意境了。它和 Unix 思想不謀而合。我們總是面臨著各種誘惑：新的系統(tǒng)架構，新的更智能的命令和工具，最新的硬件平臺，功能更全的HA軟件等。他們總是以各種各樣的方式吸引我們，most exciting，unbelievable，讓你欲罷不能。你可以在線下安裝，測試，怎么搞都行。但是如果想要在生產環(huán)境下使用起來，那就得經過非常詳細，非常漫長，各種方式驗證其穩(wěn)定性的過程。
能夠使用系統(tǒng)內置命令的話，就不用考慮其他要專門下載安裝的軟件了；腳本本身就能完成的功能，就沒有必要專門找一個功能豐富的軟件來做；Linux 本身自帶的字符界面比那些復雜的圖形界面要簡潔方便；MySQL 的一些分區(qū)，生僻函數，沒有必要的話不要使用。
他們是最可愛的人。而他們賴以生存的工具就是報警和監(jiān)控。Oracle發(fā)展了這么多年，awr 和相關的性能參數都相對比較全；MySQL 現在也已經迎頭趕上，配套的工具越來越多。