網路管理員應該如何應對系統宕機？

在去年的世界盃比賽期間，nate silver和他在地窖裡的通靈巫師也犯了錯誤——他是如何做到如此精準的**呢?確實錯了。他們完全**錯了德國與巴西的比賽結果。正如silver所描述的，這是一場完全不可能**準確的比賽。

在體育和範圍更小的政治領域，遇到這種事情也只能是吞下苦果，接受這個偶然事件——統計行業中稱為黑天鵝，然後繼續原本的生活。

但是作為網路管理員，我們知道在it行業中不應該採取這種方式。

按照我的經驗，當it系統出現黑天鵝事件時，管理層通常會對這種事件諱莫如深。隨後就會召開乙個「經驗總結會」，目的是傳遞精神保證以後不再發生類似的系統宕機事件。

警告：

不要花太多的時間去研究可能發生的事情

這裡我並不是說，在發生故障之後，我們就可以無憂無慮地忽視所有已經學到的經驗教訓。相反，我們要遠離它。在故障消失之後，你通常能夠發現未來避免問題發生的方法。在發生意外事件之後，乙個it組織應該做的第一件事就是未來是否能夠**故障，或者說是否有時候歷史資料不足以確定一種固定的概率。

如果是後者，那麼我可以告訴你，你更應該將精力投入到其他地方。更好的方法是什麼?不要花時間都確定一種可能性是否存在，而應該去發現和克服it每天都會遇到的常見問題。現在很多人都忽視了這種策略。

不信?那我們來看另乙個例子，這不是乙個虛構的公司，我知道這個公司曾經遇到一次嚴重的it故障，因此遭受了近10萬美元的損失。管理層當然非常不安。公司很快建立了乙個工作小組去確定故障的根源，然後推薦一些措施避免將來發生相同的故障。聽起來很合理，是嗎?

這個工作小組由5位來自於伺服器、網路、儲存、資料庫和應用程式團隊的成員構成。他們花了三個月時間和每個月超過100個人時的時間去調查問題根源。保守地估算，假設這家公司的每小時人力成本為50美元。那麼5人、100個小時、3個月折算過來就是近12.5萬美元。

現實：

並非想象的那樣合理

是的，最終不僅所有根源問題都找到了——至少找到了大部分，而且也新增了**，(可能)**下次相同事件的爆發。聽起來似乎並不差。但是要記住一點：這家公司花費了比原先故障的損失還多2.5萬的資金去建立乙個系統宕機解決方案，而這個方案還不一定能準確地預報類似事件的發生。

似乎它並不是很合理。

你可能會想：「但是，你覺得我們應該關注於什麼呢?畢竟，我們的職責就是和公司其他同事一起守住底線(不讓系統宕機)。」

在這個例子中，另乙個並非虛構的公司發現頻寬使用峰會並且一直很高。當傳輸速率下降到最低，然後nic招聘錯誤，並且最終卡死。問題是，在監控頻寬使用率時，停止響應或消失的網絡卡上並沒有發出警報(公司監控了最後連線的ip，因此遠端終端中斷時wan鏈路並沒有發出警報。)

經驗：

設定乙個包含警報和監控的框架

現在可以這樣考慮，按照我的經驗，正確的監控和警報可以將發現和診斷這種nic故障問題的時間縮短為15分鐘。僅此而已。不需要任何其他的措施，至少在這個案例中不需要。但是，這種簡單的措施可以將宕機損失減少750美元。

我知道這些數字聽起來並不太震撼。但是，要知道中等規模的公司可能每年就可能輕鬆遇到100次nic故障。如果沒有監控這些問題，加起來就是30萬美元的損失，而如果部署警報則每天可以節省7.5萬美元。

這還不算**nic故障和提前更換網絡卡所避免的損失。如果我們估計使用**監控能夠避免掉50%的故障，那麼可能節省的費用可能在19萬美元以上。

同樣，我並不是說不應該去做好應付黑天鵝事件的準備工作，但是如果預算比較緊張，有時候一些針對常見問題的簡單警報所能避免的損失要高於去**和防止可能不出現的「大問題」。

畢竟，nic故障並不是大問題。甚至我認為nate silver也認同這一點。