调试网络

调试网络

 

作者: 北京—小武

邮箱：night_elf1020@163.com

新浪微博：北京-小武

网络问题调试无非是以前提及的配置问题和功能问题，但是很多对网络技术有一知半解而又要介于装A和装C之间的一些人对于网络无法弄清楚的。据说历史上最早的程序员是一位女性，她发现一个小虫子钻进了调试程序用的硬件设备，结果导致了程序运行的错误，所以程序的问题命为BUG。我们定位一个有固定步骤而导致报错的问题是非常容易的，少有经验的人只要看到错误信息了，只要下体力和时间，一步步跟进总能找到原因，不容易跟进的问题是那些不能容易复现或没有报错但是功能缺不正常的，尤其是多个功能在一起协作导致的异常更不容易定位。

定位网络问题首先得熟悉网络，熟悉数据包的每一层的头部结构，结构里的每一个字段的长度、意义，然后是熟悉报文在协议栈和网络设备被处理的详细流程，以及定位网络问题常用的命令（linux下的ifconfig\route\vconfig）、工具（wireshark,tcpdump命令）等，充分掌握和理解企业网、骨干网和IDC内部及之间的网络架构、常用技术和典型解决方案，这样才能知己知彼，包未至而心已明。

解决问题在于用审视的角度寻找那些不正常的东西，只用正常的思维去阅读代码对于定位或解决问题是没有实质用途的。在曾经有一个项目里，线上设备出现了问题，仅有错误的三句日志，然后就是看到了功能不正常。根据这几句日志来定位出出现BUG的原因以及如何彻底解决。类似的问题通过对网络的理解和代码的熟悉来复现和解决，我的经历中大概有一年多的时间在做这些事。很多同事很奇怪为什么他们没有想到，我尤其在和一个同事一起定位问题时发现了可能的原因，因为每当我怀疑一处可能和出现问题相关的地方时，他总是拍着胸脯说：“不可能，这块代码我很熟悉，这里不可能出现你说的那种情况！”然而最终事实证明，BUG就发生在他的眼皮底下，而且非常明显。那时我忽然有一种体会或者认识，寻找BUG其实是一种求解不等式的证明，因为大家对证明等式已经习惯了，而忽然让大家去寻找不等式却不知道如何下手，再加上自己对代码的习惯认识，往往略过去发生问题的根源，甚至不加上打印信息都不相信原来代码居然在这种输入下会这么个流程来响应。这样做是无法做好自测的，也是一种对编程能力没有很好控制的体现。

解决问题必须有系统正规的知识才能有正统的解决办法，否则仅从需求出发得出的非正宗解决方案只会给项目带来灾难。曾经有一个同事问我，能否在帮他们造一艘大船，因为他们想过去一条深河；我很奇怪，他们的项目需求只是翻过两个山头去给那边的景色拍几张照片；怎么会有深河哪？我就为他为什么需要船？他说你别问，能不能造吧？似乎那意思是说我不能造船就是我能力不行。我摆出立场——船我造过好几艘，而且有的都在海洋上飘了好几年都没有问题，我必须知道你要造船干什么我才能给造出合适的船。他无奈只能给我说，他们好不容易爬过第一个山头，发现第一个山头和第二个山头之间有一条稍宽且波涛汹涌的河，他们无法走过去，想我造艘船运他们过去。我听后很惊恐，我说就算我造除再好的船你们也过不去，因为我没有办法把船运到那个沟里，就算我运到了你们人也没有办法上船，就算你们上船了那艘船在汹涌的河沟里也无法行驶会有很大的危险。他问我那怎么办？脸色仍是一副不屑。我没有发出一丝声音，仅仅指着地图上标注的往河沟上游2公里处有一处石桥。他大笑起来：“我就知道我选择的这个路线方案是正确的。。。。”虽然没有任何损失，但是已经知晓这个哥们以后还是悠着点。而我们的销售卖我们的产品的时候很多时候也会这样，明明不理解自己公司产品的功能，卖出去了（其实是忽悠出去了）客户反馈说满足不了需求，然后销售就拉着研发去客户现场定位，最终疯的是研发，纵然占理。

项目中协作解决的问题有可能有人消极怠工或推卸责任，提出很多不可理喻的的要求。我有此定位问题时发现一个其他组维护代码的头文件中我项目组添加但是我们维护代码里都没有用到的宏，我很奇怪，就在一个其他的BUG修改时无意间删除了。结果编译的时候报错了，原来是其他组我无权限看到的代码里有引用，导致链接出错。我去找到了添加这个宏的同事，咨询他为什么这个宏只有那边的同事用，要咱们这边添加那？他很无奈的说，原来开发时他要提供给那组同事一个数值，而这个值就是这个宏所代表的那个数；但是那组一个女同事不同意直接用这个宏，说他们领导规定必须要提供函数接口，虽然这个宏所在的头文件也归那组管。我这个组的同事很郁闷觉得拿你们领导来压我啊，就没有提供接口只提供了这个宏。那位女同事很生气，直接邮件抄送给了两边的经理，并且给我组这位同事按了个不遵守公司流程的帽子。事情最终的解决就是各打50大板，函数接口那位女同事自己去封装，返回那个宏即可。工作中事情的发展往往是令人想不到的。

项目问题的解决还依赖于RD和QA的态度。曾经有次开发项目，因为项目完成后和设计有点出入，想等到测试完成后再一起修改，就先和负责测试的QA同事小A打了招呼，说最后统一会修改，并已经在项目下做了记录，小A表示知晓，可以等最后一起修改设计文档；后来由于项目紧急需要加快测试进度，就让QA同事小B加入测试。小B同事测试一看设计和实现有点不一致直接提出了BUG。这种情况就根本无法说清楚这个到底是BUG还是沟通的问题，因为QA的绩效是按照BUG的数目计算的。所以看重BUG数量的小B自以为见BUG就提是永远正确的，而研发的同事则认为很委屈，最后虽然也没有闹大但是二者以后的合作总是不愉快，而我们小组的研发同事对小B以后所发现的BUG都严格对待，能不提就不让提，对小A倒是多次积极主动让他多提BUG。

作为研发者，一定要紧跟新技术的发展，及时的了解网络问题中的典型解决方案，并且我们从标准里很多东西只是看到了规定，比如某些做法，某些规定的数值大小或范围，但是如果我们能有时间和精力去探测这些内容的来源或指定原因，肯定会有更大的收获。还有很多网络方面的内容，我们只是看到了其一方面的内容，如果仔细思考下对立面网络是应该如何处理的，往往是深入学习理解和创有所新的地方。学习，思考，实践，多与SDN群里的大神们交流，才能天天向上。