網絡運維 - 你與真相就差一層窗戶紙
大家好，我是姜汁啤酒。
你可能覺得莫名其妙，從今年二月份這個經常上頭版的網工兄弟，居然突然從51cto消失了，博客也不更新了？莫非，哥們，不會，和埃隆馬斯克去火星了吧？
其實，需要給大家解釋解釋，我消失了三個月一共完成了兩件大事。
-
我在51cto寫了一個專欄:《老司機網絡運維幹貨集錦》，裏面涵蓋了路由、交換、安全、QOS四大模塊知識點，大家感興趣的可以猛戳此鏈接詳細了解：http://blog.51cto.com/cloumn/detail/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》。
同樣，若發現有任何紕漏，還請隨時指正。
你的支持，我的動力。
記得點進去看看哦。
網絡運維 - 你與真相就差一層窗戶紙