请及时关注“高效运维(微信ID：greatops)”公众号，并置顶公众号，以免错过各种干货满满的原创文章。
有人说技术圈也是一个江湖，技术中的高手就是大侠，弹指如飞气定神闲间化问题于虚无；而初入江湖的菜鸟，手足无措望问题而怯步。
在行走江湖的过程中，我们不断积累功力，从菜鸟到技术牛人，经历了若干囧与惑，曾经让我们大惑不解的问题或许在现在看来很可笑，但正是这些问题成为我们成长中难以忘记的印记。
一、内存之争
1. 真的需要加内存？
曾在一家电商公司工作时，有一段时间开发部和运维部争执内存的使用率问题，最后运维部大获全胜。
事情起因:
开发部任务很紧，需要在六个月内上线一套新系统。
连续每月周末加班，加之代码测试工作没跟上，系统的BUG很多，到快上线的一个月，总感觉系统和前台运行慢，然后到处找原因。
运维部连续几天监控和分析，发现是代码方面的问题，但还没上报技术总监。
一日，一开发工程师似乎发现了问题的症结，向上面报告说是“系统内存占用率高，需要增加服务器内存”，并截图为证。
内存使用率为：14873/16062=92.6% ,所以导致系统运行慢。
开发部领导向技术总监汇报，说明情况并申请购买50根16G内存加到之前的服务器上。
由于新购50根服务器内存，需要增加一笔费用，上面批复的流程又比较长，上线的时间又快近了，技术总监有点犹豫，问运维部怎么看这个问题。
运维部拿出了几天来的分析结果，论证了是代码方面的问题，并就内存使用率向技术总监做了解释。
2. LINUX的可用内存到底怎样计算？
LINUX是尽可能使用内存的原则，内核会把剩余的内存申请为cache，而cache不属于free范畴。
当系统运行时间较久，会发现cached很大，对于有频繁文件读写操作的系统，这种现象会更加明显。
直观的看，此时free的内存比较小，但并不代表可用的内存小，当一个程序需要申请较大的内存时，如果free的内存不够，内核会把部分cache的内存回收，回收的内存再分配给应用程序。
所以对于linux系统，可用于分配的内存不只是free的内存，还包括cache的内存（其实还包括buffers）。
第一行是从OS的角度来看，因为对于OS，buffers/cached 都是属于被使用，所以他的可用内存是1188MB;
第二行是从应用程序角度来看，对于应用程序来说，buffers/cached 是等于可用的。
因为buffer/cached是为了提高文件读取的性能，当应用程序需要用到内存的时候，buffer/cached会很快地被回收。
所以从应用程序的角度来说，可用内存=系统free memory+buffers+cached。
由此看来LINUX的内存使用率实际为 :
1-(11289/16062)=30%
这样一分析，完全没有必要增加内存，主要还是要提升代码的质量和改善应用程序。
小结：
这次内存之争，用公司同事的话说“运维部很拉风，开发部很伤神”（以前开发部的人都很神气，领导都是表扬）。
经过开发部调整代码后，系统和前台运行都比以前快些和稳定了，运维部在公司一时人气大旺。
二、掩码之“惑”
从事网络运维的朋友，对掩码是再熟悉不过了，这个看似简单的问题曾让很多人都困惑过。
记得刚从事网络运维工作的时候，在一家系统集成公司，给甲方做项目。
工作中经常会需要提交一些网络策略，网络策略的模板都是固定的，一般是写好后先发邮件给甲方的网络主管，审批后由甲方的网络工程师进行开通。
一次提交网络策略的时候，对方的网络主管说你“这个掩码有问题，请细化”。
我忙打开邮件，仔细看了看网络策略，没看出有什么问题。
打电话与对方沟通，才明白对方认为这个源地址的掩码128太大，这样开策略会一下放行很多主机，所以需要细化缩小范围。
晕！子网掩码是用来表明一个IP地址的哪些“位”标识的是主机所在的子网，以及哪些“位”标识的是主机。
一个子网根据不同的划分可容纳的主机数是不同的，而且子网掩码不能单独存在，它必须结合IP地址一起使用。
在这里对方显然是误解了掩码的含义：
我们申请的策略只是开通 :
255.255.255.128 这个掩码所代表的子网段的 10.4.21.33 到 255.255.255.248 这个掩码所代表的子网段的 10.4.119.17 的TCP协议的 22 端口的访问权限。
很细化也很明确。
并不是他理解的开通这个 255.255.255.128 掩码段内的所容纳的126台主机的所有访问权限。
随即打电话再次沟通解释这个问题，对方终于有点明白了，策略顺利开通，此事告一段落。
当然，为避免误解，单机策略后来都统一成单一IP地址不再标注掩码。
在工作当中，发现网络不通是一种经常的现象。
遇到这种现象，相信许多人都会将精力集中在网络线缆、网卡驱动、网络设备、网卡参数方面;
而在检查网卡参数时，他们或许又将眼光聚焦在IP地址、网关地址、DNS服务器或DHCP服务器等重点参数上。
事实上，还有一个网络参数——子网掩码，同样也是非常重要的，如果我们忽略了它的设置或将它设置错误，同样也会带来网络不通的故障。
比如：
一台工作站的IP地址为 10.192.0.1，对应的子网掩码地址为 255.255.255.0 ;
另外一台工作站的IP地址为 10.192.1.1，对应的子网掩码地址为255.255.255.0 ;
那么他们就不处于相同的子网中，不能直接连通。
因为通过子网掩码地址我们可以看出前一台工作站所处的子网网络号为 10.192.0.0，后一台工作站所处的子网网络号为 10.192.1.0 。
再比方说 :
一台工作站的IP地址为 10.192.0.1，对应的子网掩码地址为 255.255.0.0;
另外一台工作站的IP地址为 10.192.1.1，对应的子网掩码地址为 255.255.0.0;
那么他们就处于相同的子网中。
因为通过子网掩码地址我们可以看出前一台工作站所处的子网网络号为 10.192.0.0，后一台工作站所处的子网网络号也为 10.192.0.0。
还有防火墙的策略还牵涉到正掩码和反掩码 :
如果是正掩码，比如：10.4.21.0/255.255.255.128 代表的是10.4.21.1~127这么多个地址;
如果想要标识单个主机的话 10.4.21.33/255.255.255.255 （大部分防火墙配置策略用的正掩码）；
如果是反掩码，前面的0表示严格匹配，后面的1表示不匹配。
比如 :
10.4.21.33 0.0.0.127，代表的是 10.4.21.0~127 这么多个地址。
这种正常的写法应该是：
10.4.21.0 0.0.0.127 (路由器的ACL大部分用反掩码）
子网掩码参数平时不被人重视，一旦由该参数引起网络不通故障，那么该故障的排除往往很容易让人多走弯路!
子网掩码是网络中的一个重要的知识点，在工作中你还会接触到正掩码、反掩码、可变长子网掩码、超网、前缀表示法、子网聚合等，我们对子网掩码的认识和理解也是不断加深的，学无涯而知也无涯。
三、TELNET的“囧”
telnet是大家很熟悉的一个程序，它是TCP/IP协议族中的一员，是Internet远程登陆服务的标准协议和主要方式。
工作中，我们在终端电脑上使用telnet程序，可以很方便的连接到远端服务器执行操作，也可以用它来测试远端服务器端口的开放。
09年的时候，我在一家上市公司做系统运维。
当时一个项目需要分公司的系统管理员能用XMANAGER远程登录到总公司的一台服务器上用LINUX的远程图形化安装一个商业软件。
我已在总公司的服务器上配置好了XMANAGER并在防火墙上放行了XMANAGER的UDP端口177。
对端分公司的系统管理员只要测一下UDP端口 177是否通，连上就可以了。
尼玛，结果分公司的管理员测了一下午都报XMANAGER端口不通。
我纳闷了，怎么会呢？
配置一点问题都没有，他到底是怎么测的？
我问他你用什么工具测的端口，他说是TELNET，并发来截图。
囧！TELNET只能测TCP端口，怎么能测UDP端口呢？
UDP端口是否开放，可以用NC、端口扫描工具等来测试。
NC来测试
[root@test ~]# nc -vuz 10.4.29.35 177
Connection to 10.4.29.35 177 port succeeded!
结果证明UDP 177端口正常监听，可连通。（注：NC测有时不准确）
或者nmap -sU -p 177 10.4.29.35来测，更准确。
或者直接用XMANAGER连上测一下
小的问题，小的细节，不容忽视，细节决定成败，做技术的一定要严谨和深入。
后续：
技术离不开理论，但更需在实践中去分析和论证。
每个问题，都有它的特点，或简单或复杂，同时我们对问题的思考是不断深入的，毕竟理性也是有一定局限性的。
从菜鸟到技术大牛，我们成长的路上都会遇到这样那样的“囧”与“惑”，WINDOWS有WINDOWS的玄妙，LINUX有LINUX的精深，程序语言亦是如此。
仰望星空，仍需脚踏实地。
唯有深入思考和历练，我们才能不断跨越“囧”与“惑”，走向真正的技术大牛！
