一根網(wǎng)線引發(fā)的血案-趙班長(zhǎng)談運(yùn)維

--運(yùn)維的故障哲學(xué)

51CTO學(xué)院IT課程1折起秒殺，12月12日0點(diǎn)萬(wàn)人秒殺準(zhǔn)時(shí)開(kāi)啟，我是51CTO學(xué)院高級(jí)講師趙班長(zhǎng)，跟大家分享一些個(gè)人經(jīng)驗(yàn)。

“沒(méi)有經(jīng)歷過(guò)故障的運(yùn)維生涯是不完美的”--路人甲

在我們?nèi)粘＿\(yùn)維工作中，會(huì)遭遇各種各樣，甚至亂七八糟的故障。而且有些故障剛開(kāi)始會(huì)讓你莫名其妙，但結(jié)果卻讓人苦笑不得。這次分享，我想通過(guò)闡述個(gè)人運(yùn)維生涯中的其中兩個(gè)故障作為引子，進(jìn)而聊聊發(fā)生故障之前和之后，我們應(yīng)該怎么辦。

一、我只是插了一個(gè)網(wǎng)線，全網(wǎng)中斷

環(huán)境描述

某年某月某日，機(jī)房上架新的服務(wù)器。我們的架構(gòu)是服務(wù)器上聯(lián)兩臺(tái)接入層交換，做端口bonding。每?jī)蓚€(gè)機(jī)柜都會(huì)有接入層交換機(jī)，所有接入層交換，雙鏈路上聯(lián)到匯聚層交換中。然后，匯聚層交換運(yùn)行MSTP+HSRP協(xié)議。架構(gòu)圖如下：我們的操作是要新增一個(gè)接入層交換，用來(lái)擴(kuò)展網(wǎng)絡(luò)規(guī)模。

故障現(xiàn)象

當(dāng)時(shí)網(wǎng)絡(luò)工程師(路人甲)正在準(zhǔn)備登錄匯聚層交換配置端口Trunk，其他人員配合機(jī)房工作人員走線，當(dāng)接入層交換的上聯(lián)網(wǎng)線拉到匯聚層交換機(jī)的機(jī)柜的時(shí)候，作為負(fù)責(zé)人的我(領(lǐng)導(dǎo)不能閑著啊)就問(wèn)網(wǎng)絡(luò)工程師插哪里，回復(fù)：兩臺(tái)匯聚層交換的23端口。

插線誰(shuí)不會(huì)啊，于是我就先把其中一根接入層交換機(jī)的線，插入了23端口。剛過(guò)去不到一分鐘，QQ群就有人反映打不開(kāi)網(wǎng)站了，緊接著監(jiān)控的系統(tǒng)各種報(bào)警就來(lái)了。

故障處理

1. 我當(dāng)時(shí)的第一反映，趕緊詢問(wèn)網(wǎng)絡(luò)工程師(路人甲)剛才執(zhí)行了什么操作，回復(fù)剛登錄到交換機(jī)上還沒(méi)有操作?？梢耘懦恼`操作。

2. 然后詢問(wèn)其他配合人員是否在線路上有插拔操作，同樣回復(fù)沒(méi)有。

3. 登錄監(jiān)控系統(tǒng)，發(fā)現(xiàn)報(bào)警的是主機(jī)無(wú)法連接，也就是網(wǎng)絡(luò)不通，肯定是網(wǎng)絡(luò)方面的原因。

4. 開(kāi)始思考在故障之前我們都干了什么?我馬上反映過(guò)來(lái)，我插了一根網(wǎng)線!雖然覺(jué)得不可思議，但是根據(jù)故障回滾的原則，我立即把網(wǎng)線拔掉，過(guò)了一會(huì)，故障恢復(fù)了。當(dāng)時(shí)的想法就是這個(gè)黑鍋，我背定了，真心冤啊!

故障排查：

網(wǎng)絡(luò)工程師(路人甲)，登錄匯聚層交換后，發(fā)現(xiàn)該交換機(jī)的23端口之前開(kāi)啟了portfast特性。

故障原因剖析：

Portfast快速端口是一個(gè)Cisco Catalyst交換機(jī)的一個(gè)特性，在STP(Spanning Tree Protocol)中，端口有5個(gè)狀態(tài)：disable、blocking、listening、learning、forwarding，只有forwarding狀態(tài)，端口才能發(fā)送用戶數(shù)據(jù)。

一個(gè)端口接入設(shè)備后，就會(huì)經(jīng)歷blocking->listening->learing->forwarding，每個(gè)狀態(tài)的變化要經(jīng)歷一段時(shí)間。這樣從pc接上網(wǎng)線，到能發(fā)送用戶數(shù)據(jù)，需要進(jìn)行等待的時(shí)間。但如果設(shè)置了portfast，那就不需要等待了。

好的，重點(diǎn)來(lái)了!portfast只能用在接入層，也就是說(shuō)交換機(jī)的端口是接主機(jī)的才能啟用portfast，如果是接交換機(jī)的就一定不能啟用，否則會(huì)造成新的環(huán)路。(不過(guò)，Cisco也提供了BPDU guard特性解決這個(gè)問(wèn)題，但是我們沒(méi)有啟用。)

那么為什么，這個(gè)匯聚層交換的23端口會(huì)開(kāi)啟這個(gè)特性呢?原因是之前這個(gè)交換機(jī)確實(shí)有服務(wù)器接入，后來(lái)架構(gòu)拓展了，才只用來(lái)接入二層的接入層交換機(jī)。

故障經(jīng)常就是來(lái)的很突然，而且肯定會(huì)有各種奇葩的原因。甚至有的時(shí)候就是讓你還債，還是那句話“出來(lái)混，終究要還的。”我們繼續(xù)看下一個(gè)故障，直接沒(méi)有任何關(guān)聯(lián)性。

二、NFS故障，服務(wù)全部宕機(jī)

環(huán)境描述：

某APP后端API，Nginx+Python的架構(gòu)，本地靜態(tài)文件由Nginx處理，其他請(qǐng)求轉(zhuǎn)發(fā)到后端Python編寫的API上，端口9090，接入層負(fù)載均衡Nginx+Keepalived。簡(jiǎn)單的架構(gòu)圖如下：

故障現(xiàn)象：

某年某月某日某時(shí)突然某后端API節(jié)點(diǎn)報(bào)警，API http code not 200。(Zabbix監(jiān)控Nginx代理的某個(gè)接口)，然后登陸查看所有API服務(wù)，發(fā)現(xiàn)進(jìn)程都在。手動(dòng)測(cè)試每個(gè)節(jié)點(diǎn)的監(jiān)控URL，發(fā)現(xiàn)確實(shí)無(wú)法訪問(wèn)。

故障處理：

1.查看API的錯(cuò)誤日志，并未發(fā)現(xiàn)特別異常的報(bào)警，并沒(méi)有新版本發(fā)布。

2.手動(dòng)測(cè)試API監(jiān)聽(tīng)的端口，訪問(wèn)正常。直接訪問(wèn)Nginx代理的8080端口，發(fā)現(xiàn)不正常，懷疑Nginx和API直接的通信存在問(wèn)題。

3.這時(shí)有一個(gè)特殊情況就是api-nod1節(jié)點(diǎn)的訪問(wèn)時(shí)是正常的。

4.查看其他節(jié)點(diǎn)的Nignx錯(cuò)誤日志，發(fā)現(xiàn)有大量的請(qǐng)求用戶的一個(gè)URL失敗。例如/user/ID/xxx

5.通過(guò)對(duì)比發(fā)現(xiàn)api-node1和其他節(jié)點(diǎn)的唯一不同是api-node1節(jié)點(diǎn)運(yùn)行了NFS，其他節(jié)點(diǎn)之前是掛載該節(jié)點(diǎn)的NFS。原因是：后端API會(huì)生成二維碼在各個(gè)服務(wù)器上，由于數(shù)據(jù)量不大，所以在api-node1節(jié)點(diǎn)啟動(dòng)了NFS，其他所有節(jié)點(diǎn)生成的二維碼全部寫入到這個(gè)NFS共享上。查看發(fā)現(xiàn)該節(jié)點(diǎn)的NFS異常終止。手動(dòng)啟動(dòng)NFS和重啟所有API節(jié)點(diǎn)后，服務(wù)恢復(fù)正常。

故障原因剖析：

通過(guò)仔細(xì)查看報(bào)警才發(fā)現(xiàn)，之前api-node1這臺(tái)虛擬機(jī)因?yàn)閮?nèi)存跑滿自動(dòng)重啟了，但是NFS并沒(méi)有開(kāi)機(jī)啟動(dòng)(這個(gè)是另外一個(gè)問(wèn)題，暫不討論)，因?yàn)楫?dāng)時(shí)報(bào)警太多就沒(méi)有仔細(xì)看每個(gè)報(bào)警。那么，為什么NFS故障會(huì)導(dǎo)致api不能訪問(wèn)呢?應(yīng)該是某個(gè)接口功能不能使用才對(duì)。

經(jīng)過(guò)分析，這個(gè)功能是用戶用來(lái)生成二維碼的接口，如果用戶發(fā)現(xiàn)生成失敗會(huì)不停的重試，那么這些重試的api就會(huì)到nginx上，當(dāng)然肯定都會(huì)失敗，因?yàn)镹FS無(wú)法讀寫。但是，我們知道Nginx做后端健康檢查默認(rèn)是無(wú)法指定URL的，突然這么多重試的API請(qǐng)求到達(dá)Nginx都失敗了，那么Nginx根據(jù)健康檢查策略就會(huì)認(rèn)為后端服務(wù)器宕機(jī)。然后，就沒(méi)有然后了。不過(guò)，這個(gè)故障確實(shí)是多種因素疊加的一個(gè)效果。

好的，由于篇幅問(wèn)題，就拿這兩個(gè)故障，來(lái)進(jìn)行分析，看看我們能學(xué)到什么東西。

三、故障發(fā)生前，我們能做好什么

1.操作的規(guī)范性

第一個(gè)故障的背景，其實(shí)我們已經(jīng)制定好了機(jī)房上架的操作流程，每個(gè)人都知道自己應(yīng)該干什么，但是并沒(méi)有按之前的操作計(jì)劃執(zhí)行。這是發(fā)生這個(gè)故障的根本原因，因?yàn)槿绻戳鞒?，網(wǎng)絡(luò)工程師肯定會(huì)發(fā)現(xiàn)這個(gè)端口的設(shè)置并修改。

還有就是非實(shí)際操作人員不能盲目介入，這也是操作規(guī)范性的一個(gè)例子，雖然我只是想幫個(gè)忙而已，但是幫了倒忙。

2.建立完善的監(jiān)控體系

監(jiān)控體系的重要性不言而喻，不準(zhǔn)備多說(shuō)。但正如第二個(gè)故障案例，我們有監(jiān)控，但是遇到的問(wèn)題是當(dāng)報(bào)警很多的時(shí)候，并沒(méi)有仔細(xì)的查看所有監(jiān)控，而是把a(bǔ)pi無(wú)法連接當(dāng)作重點(diǎn)，而忽略了其他報(bào)警。所以說(shuō)，仔細(xì)的看報(bào)警，以及給故障進(jìn)行準(zhǔn)確的分級(jí)非常重要。

3.故障處理流程

在發(fā)生故障前要盡可能的建立完善的故障處理流程，先干什么，后干什么，故障的分級(jí)、故障的職能性升級(jí)都要有確切的流程和文檔。保證故障的處理人能夠合理的將故障解決，不能解決的及時(shí)進(jìn)行故障升級(jí)。

四、發(fā)生故障后，我們能做好什么

1.恢復(fù)是故障管理的第一要?jiǎng)?wù)

ITIL的服務(wù)運(yùn)營(yíng)有一個(gè)故障管理的流程，故障管理的目標(biāo)是盡可能快地恢復(fù)到正常的服務(wù)運(yùn)營(yíng)，將故障對(duì)業(yè)務(wù)運(yùn)營(yíng)的負(fù)面影響減小到最低。那么，故障管理的大忌，就是試圖快速定位故障原因而忽略了故障處理流程。下面有個(gè)小段子，可以幫助你理解：

某電商系統(tǒng)，一次用戶系統(tǒng)升級(jí)，導(dǎo)致串號(hào)，也就是用戶A登錄后，看到的是用戶B的帳號(hào)信息。領(lǐng)導(dǎo)問(wèn)怎么辦：

開(kāi)發(fā)人員：老板，給我10分鐘，馬上修復(fù)這個(gè)bug。然后開(kāi)發(fā)人員實(shí)際使用了8分鐘修代碼并上線。結(jié)果：故障依舊。

開(kāi)發(fā)主管：你這水平不行啊，我來(lái)，我只需要5分鐘。然后開(kāi)發(fā)主管用了4分鐘修代碼并上線。結(jié)果：故障依舊。

開(kāi)發(fā)經(jīng)理：你們都閃開(kāi)，我只需要1分鐘。然后開(kāi)發(fā)經(jīng)理真的1分鐘修改代碼并上線。結(jié)果：故障依舊。

老板：誰(shuí)能快速的回復(fù)這個(gè)故障，我們已經(jīng)故障整整13分鐘了!這個(gè)時(shí)候運(yùn)維甲奮力的擠進(jìn)人群：我們有秒級(jí)回滾腳本，所有節(jié)點(diǎn)回滾上一個(gè)版本并啟動(dòng)不到1分鐘。結(jié)果：1分鐘后，故障恢復(fù)了。

篇幅問(wèn)題，這個(gè)故障就到這里。我想無(wú)論你是老板、經(jīng)理、開(kāi)發(fā)、測(cè)試、運(yùn)維都應(yīng)該已經(jīng)明白了，不做過(guò)多的解釋了。

2.故障復(fù)盤

每一次發(fā)生故障后，運(yùn)維負(fù)責(zé)人都需要牽頭進(jìn)行故障的復(fù)盤。開(kāi)發(fā)、測(cè)試、運(yùn)維要一起審查這次故障，搞明白是哪里出了問(wèn)題，我們應(yīng)該怎么避免這類故障的再次發(fā)生。俗話說(shuō)：故障是我們最好的老師。不過(guò)，這個(gè)老師大家都不會(huì)喜歡。當(dāng)然還需要我們?cè)敿?xì)做好故障的記錄。

3.問(wèn)題管理

故障復(fù)盤的目的和問(wèn)題管理是相同的。ITIL的服務(wù)運(yùn)營(yíng)中，問(wèn)題管理流程的目標(biāo)是預(yù)防問(wèn)題的產(chǎn)生及由此引發(fā)的故障，消除重復(fù)出現(xiàn)的故障，并對(duì)不能預(yù)防的故障盡量降低他對(duì)業(yè)務(wù)的影響。

所以我們可以在故障復(fù)盤的時(shí)候，要把這個(gè)故障轉(zhuǎn)化為問(wèn)題管理，全面分析故障的原因，務(wù)必徹底解決，而且每項(xiàng)工作一定要落實(shí)到具體的負(fù)責(zé)人。

推薦課程：

云計(jì)算與自動(dòng)化運(yùn)維實(shí)踐視頻課程套餐

http://edu.51cto.com/pack/view/id-298.html

趙舜東

江湖人稱趙班長(zhǎng)，51CTO學(xué)院高級(jí)講師，在學(xué)院開(kāi)設(shè)10門精品課程。曾負(fù)責(zé)武警某部指揮自動(dòng)化架構(gòu)和運(yùn)維工作，2008年退役后一直從事互聯(lián)網(wǎng)運(yùn)維工作。UnixHot運(yùn)維社區(qū)創(chuàng)始人、《SaltStack入門與實(shí)踐》作者。