作者簡介

趙舜東，江湖人稱趙班長，曾負(fù)責(zé)武警某部指揮自動化架構(gòu)和運(yùn)維工作，2008年退役后一直從事互聯(lián)網(wǎng)運(yùn)維工作。UnixHot運(yùn)維社區(qū)創(chuàng)始人、《SaltStack入門與實(shí)踐》作者。

引言

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

在我們?nèi)粘＿\(yùn)維工作中，會遭遇各種各樣，甚至亂七八糟的故障。而且有些故障剛開始會讓你莫名其妙，但結(jié)果卻讓人苦笑不得。

這次分享，我想通過闡述個人運(yùn)維生涯中的其中兩個故障作為引子，進(jìn)而聊聊發(fā)生故障之前和之后，我們應(yīng)該怎么辦。

案例1：我只是插了一根網(wǎng)線，全網(wǎng)中斷!?

1.環(huán)境描述

某年某月某日，機(jī)房上架新的服務(wù)器。我們的架構(gòu)是服務(wù)器上聯(lián)兩臺接入層交換，做端口 Bonding 。

每兩個機(jī)柜都會有接入層交換機(jī)，所有接入層交換，雙鏈路上聯(lián)到匯聚層交換中。然后匯聚層交換運(yùn)行MSTP+HSRP協(xié)議。

架構(gòu)圖如下：我們的操作是要新增一個接入層交換，用來擴(kuò)展網(wǎng)絡(luò)規(guī)模。

2.故障現(xiàn)象

當(dāng)時網(wǎng)絡(luò)工程師(路人甲)正在準(zhǔn)備登錄匯聚層交換配置端口Trunk，其它人員配合機(jī)房工作人員走線。

當(dāng)接入層交換的上聯(lián)網(wǎng)線拉到匯聚層交換機(jī)的機(jī)柜的時候，作為負(fù)責(zé)人的我(領(lǐng)導(dǎo)不能閑著啊)就問網(wǎng)絡(luò)工程師：插哪里?回復(fù)：兩臺匯聚層交換的23端口 。

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

3.故障處理

我當(dāng)時的第一反映，趕緊詢問網(wǎng)絡(luò)工程師(路人甲)剛才執(zhí)行了什么操作，回復(fù)剛登錄到交換機(jī)上還沒有操作。可以排除他的誤操作。

然后詢問其它配合人員是否在線路上有插拔操作，同樣回復(fù)沒有。

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

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

4.故障排查

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

5.故障原因剖析

Portfast快速端口

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

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

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

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

小結(jié)

故障經(jīng)常就是來的很突然，而且肯定會有各種奇葩的原因。甚至有的時候就是讓你還債，還是那句話“出來混，終究要還的。”

我們繼續(xù)看下一個故障，之間沒有任何關(guān)聯(lián)性。

案例2：NFS故障，服務(wù)全部宕機(jī)

1.環(huán)境描述

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

2.故障現(xiàn)象

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

3.故障處理

查看API的錯誤日志，并未發(fā)現(xiàn)特別異常的報警，并沒有新版本發(fā)布。

手動測試API監(jiān)聽的端口，訪問正常。直接訪問Nginx代理的8080端口，發(fā)現(xiàn)不正常，懷疑Nginx和API之間的通信存在問題。

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

查看其它節(jié)點(diǎn)Nignx錯誤日志，發(fā)現(xiàn)有大量的URL 請求失敗，該URL對應(yīng)某個用戶。例如/user/ID/xxx

通過對比發(fā)現(xiàn)api-node1和其它節(jié)點(diǎn)的唯一不同是api-node1節(jié)點(diǎn)運(yùn)行了NFS，其它節(jié)點(diǎn)之前是掛載該節(jié)點(diǎn)的NFS。

4.故障排查

后端API會生成二維碼在各個服務(wù)器上，由于數(shù)據(jù)量不大，所以在api-node1節(jié)點(diǎn)啟動了NFS，其它所有節(jié)點(diǎn)生成的二維碼全部寫入到這個NFS共享上。查看發(fā)現(xiàn)該節(jié)點(diǎn)的NFS異常終止。手動啟動NFS和重啟所有API節(jié)點(diǎn)后，服務(wù)恢復(fù)正常。

5.故障原因剖析

通過仔細(xì)查看報警才發(fā)現(xiàn)，之前api-node1這臺虛擬機(jī)因?yàn)閮?nèi)存跑滿自動重啟了，但是NFS并沒有開機(jī)啟動(這個是另外一個問題，暫不討論)，因?yàn)楫?dāng)時報警太多就沒有仔細(xì)看每個報警。

那么為什么NFS故障會導(dǎo)致api不能訪問呢，應(yīng)該是某個接口功能不能使用才對?

經(jīng)過分析，這個功能是用戶用來生成二維碼的接口，如果用戶發(fā)現(xiàn)生成失敗會不停的重試，那么這些重試的api就會到nginx上，當(dāng)然肯定都會失敗，因?yàn)镹FS無法讀寫。

但是我們知道Nginx做后端健康檢查默認(rèn)是無法指定URL的，突然這么多重試的API請求到達(dá)Nginx都失敗了，那么Nginx根據(jù)健康檢查策略就會認(rèn)為后端服務(wù)器宕機(jī)。然后就沒有然后了。。。

不過這個故障確實(shí)是多種因素疊加的一個效果。

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

反思：故障發(fā)生前我們能做什么?

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

第一個故障的背景，其實(shí)我們已經(jīng)制定好了機(jī)房上架的操作流程，每個人都知道自己應(yīng)該干什么，但是并沒有按之前的操作計劃執(zhí)行。

這是發(fā)生這個故障的根本原因，因?yàn)槿绻戳鞒?，網(wǎng)絡(luò)工程師肯定會發(fā)現(xiàn)這個端口的設(shè)置并修改。

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

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

監(jiān)控體系的重要性不言而喻，不準(zhǔn)備多說。但正如第二個故障案例，我們有監(jiān)控，但是遇到的問題是當(dāng)報警很多的時候，并沒有仔細(xì)的查看所有監(jiān)控，而是把a(bǔ)pi無法連接當(dāng)作重點(diǎn)，而忽略了其它報警。

所以說，仔細(xì)的看報警，以及給故障進(jìn)行準(zhǔn)確的分級非常重要。

3.故障處理流程

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

反思：發(fā)生故障后，我們能做什么?

1.恢復(fù)是故障管理的第一要務(wù)

ITIL的服務(wù)運(yùn)營有一個故障管理的流程，故障管理的目標(biāo)是盡可能快地恢復(fù)到正常的服務(wù)運(yùn)營，將故障對業(yè)務(wù)運(yùn)營的負(fù)面影響減小到最低。

那么故障管理的大忌，就是試圖快速定位故障原因而忽略了故障處理流程。下面有個小段子，可以幫助你理解：

某電商系統(tǒng)，一次用戶系統(tǒng)升級，導(dǎo)致串號，也就是用戶A登錄后，看到的是用戶B的帳號信息。

領(lǐng)導(dǎo)問：怎么辦?

開發(fā)人員：老板，給我10分鐘，馬上修復(fù)這個bug。

然后開發(fā)人員實(shí)際使用了8分鐘修代碼并上線。結(jié)果故障依舊!

開發(fā)主管：你這水平不行啊，我來，我只需要5分鐘。

然后開發(fā)主管用了4分鐘修代碼并上線。結(jié)果故障依舊!!

開發(fā)經(jīng)理：你們都閃開，我只需要1分鐘。然后開發(fā)經(jīng)理真的1分鐘修改代碼并上線。結(jié)果故障依舊!!!(好吧，到這里連小編都已經(jīng)看不下去了)

老板：誰能快速的恢復(fù)這個故障，我們已經(jīng)故障整整13分鐘了!

這個時候運(yùn)維甲奮力的擠進(jìn)人群：我們有秒級回滾腳本，所有節(jié)點(diǎn)回滾上一個版本并啟動不到1分鐘。

結(jié)果，1分鐘后，故障恢復(fù)了。

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

2.故障復(fù)盤

每一次發(fā)生故障后，運(yùn)維負(fù)責(zé)人都需要牽頭進(jìn)行故障的復(fù)盤。開發(fā)、測試、運(yùn)維要一起審查這次故障，搞明白是哪里出了問題，我們應(yīng)該怎么避免這類故障的再次發(fā)生。

俗話說：故障是我們最好的老師。不過這個老師大家都不會喜歡。當(dāng)然還需要我們詳細(xì)做好故障的記錄。

3.問題管理

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

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

【編輯推薦】