【故障】我只是插了一根網線，全網中斷！？
請及時關注“高效運維(微信ID：greatops)”公眾號，並置頂公眾號，以免錯過各種乾貨滿滿的原創文章。
作者簡介
趙舜東
江湖人稱趙班長，曾負責武警某部指揮自動化架構和運維工作，2008年退役後一直從事網際網路運維工作。UnixHot運維社群創始人、《SaltStack入門與實踐》作者。
引言：“沒有經歷過故障的運維生涯是不完美的”—路人甲
在我們日常運維工作中，會遭遇各種各樣，甚至亂七八糟的故障。而且有些故障剛開始會讓你莫名其妙，但結果卻讓人苦笑不得。
這次分享，我想通過闡述個人運維生涯中的其中兩個故障作為引子，進而聊聊發生故障之前和之後，我們應該怎麼辦。
案例1：我只是插了一根網線，全網中斷！？
1、環境描述
某年某月某日，機房上架新的伺服器。我們的架構是伺服器上聯兩臺接入層交換，做埠 Bonding 。
每兩個機櫃都會有接入層交換機，所有接入層交換，雙鏈路上聯到匯聚層交換中。然後匯聚層交換執行MSTP+HSRP協議。
架構圖如下：我們的操作是要新增一個接入層交換，用來擴充套件網路規模。
2、故障現象
當時網路工程師（路人甲）正在準備登入匯聚層交換配置埠Trunk，其它人員配合機房工作人員走線。
當接入層交換的上聯網線拉到匯聚層交換機的機櫃的時候，作為負責人的我（領導不能閒著啊）就問網路工程師：插哪裡？回覆：兩臺匯聚層交換的23埠 。
插線誰不會啊，於是我就先把其中一根接入層交換機的線，插入了23埠。剛過去不到一分鐘，QQ群就有人反映打不開網站了，緊接著監控的系統各種報警就來了。
3、故障處理
1、我當時的第一反映，趕緊詢問網路工程師（路人甲）剛才執行了什麼操作，回覆剛登入到交換機上還沒有操作。可以排除他的誤操作。
2、然後詢問其它配合人員是否線上路上有插拔操作，同樣回覆沒有。
3、登入監控系統，發現報警的是主機無法連線，也就是網路不通，肯定是網路方面的原因。
4、開始思考在故障之前我們都幹了什麼？我馬上反映過來，我插了一根網線！雖然覺得不可思議，但是根據故障回滾的原則，我立即把網線拔掉，過了一會，故障恢復了。當時的想法就是這個黑鍋，我背定了，真心冤啊。
4、故障排查
網路工程師（路人甲），登入匯聚層交換後，發現該交換機的23埠之前開啟了portfast特性。
5、故障原因剖析
Portfast快速埠
是一個Cisco Catalyst交換機的一個特性，在STP（Spanning Tree Protocol）中，埠有5個狀態：disable、blocking、listening、learning、forwarding，只有forwarding狀態，端口才能傳送使用者資料。
一個埠接入裝置後，就會經歷blocking->listening->learing->forwarding，每個狀態的變化要經歷一段時間。這樣從pc接上網線，到能傳送使用者資料，需要進行等待的時間。但如果設定了portfast，那就不需要等待了。
好的，重點來了！portfast只能用在接入層，也就是說交換機的埠是接主機的才能啟用portfast，如果是接交換機的就一定不能啟用，否則會造成新的環路。（不過，Cisco也提供了BPDU guard特性去解決這個問題，但是我們沒有啟用）
那麼為什麼，這個匯聚層交換的23埠會開啟這個特性呢？原因是之前這個交換機確實有伺服器接入，後來架構拓展了，才只用來接入二層的接入層交換機。
小結
故障經常就是來的很突然，而且肯定會有各種奇葩的原因。甚至有的時候就是讓你還債，還是那句話“出來混，終究要還的。”
我們繼續看下一個故障，之間沒有任何關聯性。
案例2：NFS故障，服務全部宕機
1、環境描述
某APP後端API，Nginx+Python的架構，本地靜態檔案由Nginx處理，其它請求轉發到後端Python編寫的API上，埠9090，接入層負載均衡Nginx+Keepalived。簡單的架構圖如下：
2、故障現象
某年某月某日某時突然某後端API節點報警：API http code not 200。（Zabbix監控Nginx代理的某個介面）然後登陸檢視所有API服務，發現程序都在。手動測試每個節點的監控URL，發現確實無法訪問。
3、故障處理
1、檢視API的錯誤日誌，並未發現特別異常的報警，並沒有新版本釋出。
2、手動測試API監聽的埠，訪問正常。直接訪問Nginx代理的8080埠，發現不正常，懷疑Nginx和API之間的通訊存在問題。
3、這時有一個特殊情況就是api-nod1節點的訪問是正常的。
4、檢視其它節點Nignx錯誤日誌，發現有大量的URL 請求失敗，該URL對應某個使用者。例如/user/ID/xxx
5、通過對比發現api-node1和其它節點的唯一不同是api-node1節點運行了NFS，其它節點之前是掛載該節點的NFS。
4、故障排查
後端API會生成二維碼在各個伺服器上，由於資料量不大，所以在api-node1節點啟動了NFS，其它所有節點生成的二維碼全部寫入到這個NFS共享上。檢視發現該節點的NFS異常終止。手動啟動NFS和重啟所有API節點後，服務恢復正常。
5、故障原因剖析
通過仔細檢視報警才發現，之前api-node1這臺虛擬機器因為記憶體跑滿自動重啟了，但是NFS並沒有開機啟動（這個是另外一個問題，暫不討論），因為當時報警太多就沒有仔細看每個報警。
那麼為什麼NFS故障會導致api不能訪問呢，應該是某個介面功能不能使用才對？
經過分析，這個功能是使用者用來生成二維碼的介面，如果使用者發現生成失敗會不停的重試，那麼這些重試的api就會到nginx上，當然肯定都會失敗，因為NFS無法讀寫。
但是我們知道Nginx做後端健康檢查預設是無法指定URL的，突然這麼多重試的API請求到達Nginx都失敗了，那麼Nginx根據健康檢查策略就會認為後端伺服器宕機。然後就沒有然後了。。。
不過這個故障確實是多種因素疊加的一個效果。
好的，由於篇幅問題，就拿這兩個故障，來進行分析，看看我們能學到什麼東西。
反思：故障發生前我們能做什麼？
1. 操作的規範性
第一個故障的背景，其實我們已經制定好了機房上架的操作流程，每個人都知道自己應該幹什麼，但是並沒有按之前的操作計劃執行。
這是發生這個故障的根本原因，因為如果按流程，網路工程師肯定會發現這個埠的設定並修改。
還有就是非實際操作人員不能盲目介入，這也是操作規範性的一個例子，雖然我只是想幫個忙而已，但是幫了倒忙。
2. 建立完善的監控體系
監控體系的重要性不言而喻，不準備多說。但正如第二個故障案例，我們有監控，但是遇到的問題是當報警很多的時候，並沒有仔細的檢視所有監控，而是把api無法連線當作重點，而忽略了其它報警。
所以說，仔細的看報警，以及給故障進行準確的分級非常重要。
3. 故障處理流程
在發生故障前要儘可能的建立完善的故障處理流程，先幹什麼，後幹什麼，故障的分級、故障的職能性升級都要有確切的流程和文件。保證故障的處理人能夠合理的將故障解決，不能解決的及時進行故障升級。
反思：發生故障後我們能做什麼？
1. 恢復是故障管理的第一要務
ITIL的服務運營有一個故障管理的流程，故障管理的目標是儘可能快地恢復到正常的服務運營，將故障對業務運營的負面影響減小到最低。
那麼故障管理的大忌，就是試圖快速定位故障原因而忽略了故障處理流程。下面有個小段子，可以幫助你理解：
某電商系統，一次使用者系統升級，導致串號，也就是使用者A登入後，看到的是使用者B的帳號資訊。
領導問：怎麼辦？
開發人員：老闆，給我10分鐘，馬上修復這個bug。然後開發人員實際使用了8分鐘修程式碼並上線。結果故障依舊！
開發主管：你這水平不行啊，我來，我只需要5分鐘。
然後開發主管用了4分鐘修程式碼並上線。結果故障依舊！！
開發經理：你們都閃開，我只需要1分鐘。然後開發經理真的1分鐘修改程式碼並上線。結果故障依舊！！！（好吧，到這裡連小編都已經看不下去了）
老闆：誰能快速的恢復這個故障，我們已經故障整整13分鐘了！
這個時候運維甲奮力的擠進人群：我們有秒級回滾指令碼，所有節點回滾上一個版本並啟動不到1分鐘。
結果，1分鐘後，故障恢復了。
篇幅問題，這個故障就到這裡。我想無論你是老闆、經理、開發、測試、運維都應該已經明白了，不做過多的解釋了。
2. 故障覆盤
每一次發生故障後，運維負責人都需要牽頭進行故障的覆盤。開發、測試、運維要一起審查這次故障，搞明白是哪裡出了問題，我們應該怎麼避免這類故障的再次發生。
俗話說：故障是我們最好的老師。不過這個老師大家都不會喜歡。當然還需要我們詳細做好故障的記錄。
3. 問題管理
故障覆盤的目的和問題管理是相同的。ITIL的服務運營中，問題管理流程的目標是預防問題的產生及由此引發的故障，消除重複出現的故障，並對不能預防的故障儘量降低其對業務的影響。
所以我們可以在故障覆盤的時候，要把這個故障轉化為問題管理，全面分析故障的原因，務必徹底解決，而且每項工作一定要落實到具體的負責人。
好的，今天的軟文（趙班長又調皮了—小編注）分享就到這裡。故障這個話題比較大，無法面面俱到，大家可以加入“高效運維社群”一起討論交流。
GOPS2016 全球運維大會•上海站 已開始報名
運維發展至今，早已不是刀耕火種的時代，不應該仍然是“背黑鍋俠”，“背伺服器俠”。運維可以更高逼格、更高價值，運維明天可以更美好！
“重新定義運維”讓這些成為可能
匯聚整個行業的力量，集合海內外專家的智慧，我們在路上！
想在GOPS2016上海大會見到趙班長？您可以在文末留言哦
GOPS2016上海大會現已開始報名，可掃描下方二維碼，或點選文末“閱讀原文”連結，以瞭解詳情：
