網絡運維 - 你與真相就差一層窗戶紙

迴歸，帶着滿滿的乾貨回來了

你們好，我是薑汁啤酒。

你可能以爲莫名其妙，從今年二月份這個常常上頭版的網工兄弟，竟然忽然從51cto消失了，博客也不更新了？莫非，哥們，不會，和埃隆馬斯克去火星了吧？

其實，須要給你們解釋解釋，我消失了三個月一共完成了兩件大事。

1. 我在51cto寫了一個專欄:《老司機網絡運維乾貨集錦》，裏面涵蓋了路由、交換、安全、QOS四大模塊知識點，你們感興趣的能夠猛戳此連接詳細瞭解：https://blog.51cto.com/cloumn/detail/2 。目前專欄還剩路由篇待更新，其餘模塊已經完畢。

2. 這三個月跳了個槽，從資深工程師搖身一變成爲首席設計網絡師，事情相對也多了起來。加上剛到一個新地方怎麼都得裝一裝樣子，老油條們，你懂的。

由於上述兩件事，搞得最近忙的沒來得及更新博客。

今天正式迴歸後，原本想繼續更新我以前的數據中心繫列。可是考慮再三，索性想和你們聊聊我對於網絡運維的見解，以及寫這個專欄的出發點，同時也但願和志同道合的朋友們一塊兒分享分享網絡運維的看法。

網絡運維，痛並快樂着

當你由於這篇文章的標題，尤爲是網絡運維這四個字把你吸引進來時。

我大概知道你也是網絡運維同行的一份子，相信你有着對網絡技術的狂熱愛好和對技術細節的極致追求。

但是，有時候現實的工做和理想的追求每每會不當心就差了好遠，平常的網絡運維工做不只繁瑣，並且出的故障都是千奇百怪，讓人沒法琢磨透。

更不用提反覆無常的加班，通宵調整，割接等操做了。

可是苦中做樂，當每個故障都被解決之後，心裏那種酣暢淋漓的知足感，總會讓你可以短暫的忘卻身體的疲乏，享受片刻的歡愉和寧靜。

但是，我乘人之危的提一個疑問句。你以爲問題解決了，是完全分析透徹並從根源上解決了？ 仍是找了個變通方法，臨時處理掉問題？

仔細想一想，其實心裏五味雜陳，你不用說，我也懂。

有多少個故障，就有多少個故事

故事1：不作過濾的路由重分發

最近做爲首席設計師的角色入職新公司之後，花了些時間摸底公司網絡架構。聽了聽同事說說之前的故障案例，以及解決方案。

聽完之後，不由讓我以爲好笑，但又打寒顫。

一個經典的雙點雙向重分發場景。A和B均把MPLS和LAN的路由互相重分發到兩端的網絡內。結果有一天LAN內部某一條路由震盪，結果此路由非但沒消失。反而致使整個網絡三層環路。

最後的解決方法就是把B點的備用鏈路給斷掉，問題解決了，可是今後B鏈路再也沒有開啓過。

這就是所謂的解決方案。

我以爲滑稽，是由於很明顯此類的重分發必定要在A和B上面作路由過濾，千萬不能讓兩端的路由互相在A和B點之間互相發佈。

而我打寒顫，則是以爲如此重要的網絡節點竟然單點運行，並且將來還得爲了這個問題再次返工修改，費時費力。

最根本的緣由在於，當出故障之後，未能認真分析問題根源，並把它解決掉。而是草草收場，等待下一次隱患。

故事2：一臺小交換機形成的血案

上面的故事，是單獨的案例麼？

答案確定是「不」。

不知道你是否經歷過插入新的交換機結果把全網的VLAN沖掉的惶恐不安。

也許，當某些經驗不足的工程師接到無數的投訴之後，仍然百思不得其解，不就是插入一個交換機麼，怎麼可能會形成幾百米開外的其餘大樓網絡全掛了。

我相信若他知道全網VLAN信息全消失之後，加之VLAN數據庫歷來不備份的話，這次事故將是永生難忘的一堂課。

針對以上問題，不少朋友的解決方案就是：禁止一切Cisco交換機使用VTP協議，一切VLAN全網手工配置。

原本VTP帶來的巨大便利就由於對於協議理解不透徹，協議的便利和優點就完全喪失掉了。

故事3：Port-channel幹掉全網

個人一個朋友告訴我，他們配置Port-channel竟然也把全網幹掉了。

我說，這Port-channel該不會怪罪到VTP上了吧，人家但是完全躺槍了。他其實也不太明白，爲何配置一個簡單的Port-channel竟然可以把全網弄攤了，這網絡得有多麼的脆弱才行。並且，Port-channel平常工做中配置了無數遍，怎麼這一次就栽在這上面了。

不對，確定是軟件bug問題，或者什麼不可解釋的神祕力量？

一樣的，問題的根源沒有分析清楚。取而代之的則是全網禁止使用port-channel。

故事4：「裸奔」的網絡

相信你們都知道電腦「裸奔」是什麼意思，那何爲「裸奔」的網絡？

在我來看，裸奔的網絡有兩層含義。

第一：此網絡不存在任何安全措施可言，惡意***能夠來自內部或者外部，網絡設備很是容易淪陷。
第二：網絡存在的目的在於傳輸數據包，若發送的數據包沒法儘量的完整到達接收端，網絡設備沒有任何QoS保護措施保障數據包的傳輸，那麼此網絡設備也能夠稱做爲「裸奔的」網絡。

尤爲第二項，Qos的設計和部署對於工程師的理論知識要求較高，若對於QoS只知其一;不知其二的話，部署的Qos問題比不部署還嚴重。

故事還在繼續。。。

故事5：永不安全的防火牆

此標題頗有意思，由於它違背了常理。

按理說，防火牆是爲了加固網絡安全才部署的，怎麼說防火牆用不安全呢？

其實，防火牆是安全的，不安全的是人心。

仔細想一想平常運維中，常常有不少不懂網絡技術的人對你指手畫腳：

• 誰誰誰，個人網絡怎麼不通了？

• 爲何上不了這個網站了？

• 網速怎麼這麼慢啊？

最後這些非IT人士都統一得出一個結論，防火牆出問題了，他們不懂路由交換。只知道防火牆是阻擋一切的罪魁禍首。

這個鍋，防火牆背上了。

有上黑鍋的，天然也得有卸鍋人。因而，網絡運維工程師就成爲了拆彈專家，你須要仔細覈查防火牆的安全策略，路由，逐步排查故障，確保不是防火牆問題。

那如何覈查，防火牆的詳細工做原理和數據包處理流程是什麼? 問題分析邏輯是什麼？如何下手等？

此類問題常常困擾着你和我。

總結：咱們離真相只有一層窗戶紙

其實不少問題，咱們稍稍往前走一步，就能夠看見真相。

可是不少運維的朋友選擇在遇到奇葩問題的時候，退而求次其次，掩蓋住問題就好，何須費勁力氣往前衝呢？

也許短期以內問題被掩蓋了，被所謂的「解決掉了」。可是總有一天，這個問題就像星星之火同樣，捲土重來，把運維人員燒的外焦裏嫩。

因此，做爲一個過來人，我以爲頗有必要把本身平常追求問題根源的經驗分享出來，供你們參考。

而更重要的是，除了分享經驗之外，是但願經過有限的例子給你們展現一個處理故障和問題的思路。

平常運維中，你不可能套用某一個故障的具體處理辦法到另一個故障，可是處理故障分析思路卻能夠反覆使用。

介於此，我決定寫此專欄，但願本身所學所思的東西可以幫助到你們，可以有所啓發。

此專欄經過「網絡路由篇」，「網絡交換篇」，「網絡安全篇」，「QoS篇」四大典型技術模塊，分別給各位講述運維中的網絡設計思路和一些運維的技術難題。相信你通讀完各個模塊之後，會刷新你對於某些知識的認知。

傳送門以下：
老司機網絡運維乾貨集錦

若你在平常運維中，還須要瞭解其餘方面的問題，請給我留言。我會根據各位的反饋，繼續迭代《網絡運維乾貨集錦 II 》，《網絡運維乾貨集錦 III》。

一樣，若發現有任何紕漏，還請隨時指正。

你的支持，個人動力。

記得點進去看看哦。