回归,带着满满的干货回来了

大家好,我是姜汁啤酒。

你可能觉得莫名其妙,从今年二月份这个经常上头版的网工兄弟,居然突然从51cto消失了,博客也不更新了?莫非,哥们,不会,和埃隆马斯克去火星了吧?

其实,需要给大家解释解释,我消失了三个月一共完成了两件大事。

  1. 我在51cto写了一个专栏:《老司机网络运维干货集锦》,里面涵盖了路由、交换、安全、QOS四大模块知识点,大家感兴趣的可以猛戳此链接详细了解:http://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》。

同样,若发现有任何纰漏,还请随时指正。

你的支持,我的动力。

记得点进去看看哦。