帮朋友写了一下运维人员的招聘信息，顺带出了3个面试问题。既然是必备技能，那么也就应该视为运维人员的技术常识了，然而一些人的回答让我直接就懵逼了……最近赚钱赚爽了，抽空写一下怎样快速定位故障环节。
招聘要求里面也就是常规的那些信息，我只增加了一条奇葩一点的：
扫雷游戏成功率高于50%，或者有其他途径证实逻辑严谨性亦可。
面试问题：
1，某个服务器无法连接
2，某个服务程序挂了
3，某个服务器只接受内网连接，我们想让公司的办公电脑连接上这个服务器，说出你知道的途径或者方法
两个问题要求说明如何判断前故障环节，说明判断流程。
以应聘者的角度来分析一下这几个题。首先在要求里面已经明示了要求逻辑严谨，那么我认为脑子正常或者认真看了招聘信息的人都应该能判断到，这个职位对人员的要求里面有一项是“严谨”，不管你平时怎么松散，至少在应聘过程中，你装也要装的严谨一些吧。同时呢，很明显的是前两个问题都不具有绝对的标准答案，而且这种问题放在面试环节，目的就是考察应聘者的知识、经验的广度和深度。单就第一个问题来说，深究的话这个问题我随意思索一下都能写一本书出来，然而前两个问题又是运维人员最常遇到的故障，所以，出这两个题可以最直接的看出应聘者的经验情况、对常见故障的判断能力以及动手解决的能力。不论简历里面吹的天花乱坠，又或者你在top 500企业维护了多少万台服务器，我只相信那句我常说的话：经历不等同于经验。再退一步讲，如果前两个问题都不能有一个逻辑清晰的判断流程，那么作为运维人员是绝对不够格的。
第三个题跟这个企业的业务相关，而且有点偏门，按我的看法，做网络或者系统运维的人一般来说只要能讲出2种方法就可以，能讲出3种就算不错的。本文暂不讨论第三题。
看第二个题，我给朋友的原话：
第二个问题： 1，看程序日志，如果有，看看是否日志里面表明原因，如果有原因，解决，如果没有，下一步 2，看看系统日志有没有表明原因，如果有，尝试解决，如果没有，下一步 3，如果有调试模式，进程序的调试模式，看看原因为何，解决，如果没有调试模式，下一步 4，找开发商或者去google吧
因为面试问题里面只需要判断故障环节，所以我给的答案其实不需要里面的解决问题，只需要定位到故障即可。假设遇到这种情况，那么按照我的这个答案，可以在最短时间内判断出问题在哪里。当然这里讲的是通用情况，在有些前提下，是可以一步到位找出故障环节的，这种情况不在讨论之列。在操作系统正常的情况下，任何程序挂了，运维人员都应该第一时间去看日志，这个应该也算是常识了。不过我当时在打游戏，随手敲了几句给朋友的，其实还有一些常规应该看的，比如内存情况，cpu情况等等。
最后看第一个问题，这个问题太过于宽泛，而且我给朋友的答案里面涉及到具体的业务信息，不方便直接复制，所以手工写一点东西吧
不论服务器还是路由器或者网关这类设备，我们统称为“节点”。当遇到某个网络节点无法连接的时候，可以由近及远，也可以由远及近，思路和方法都是一致的。解决任何问题的第一阶段是找到问题在哪，科学的说法就是判断故障环节。这一阶段的思路和方法就是通过不断的证明来逐步缩小不可证明的范围，如同写代码一样，也和扫雷一样，调试的时候是不能假设某一行代码运行正常的，有时候需要正面证明，有时候需要侧面证明，总之呢，是通过事实来确定问题在哪/雷在哪，招聘信息里面那个扫雷的要求就是这么来的。
比如一个网络节点忽然连不上了，我会这么做：
天寒地冻，为了少打字，下面的步骤将工作计算机称为W，其他服务器称为O，出现故障的服务器称为S，S的网关称为G，同时呢，S、W和O位于不同的基础运营商线路。
1，通过W连接O，如果可以连接，则证明W的公网线路正常，故障环节位于W的网关到S之间的某个环节，可以进行步骤2了；如果不能连接，则“几乎”可以立刻证明故障位于W自己的网络，这种情况自己解决吧，一般是迅雷、视频客户端这种事，要么就是下毛片多了。。。如果O和S都在境外，那么“有可能”是S的基础运营商问题。
2，通过O来试试看能否连接S。如果可以，则能够证明S工作正常，这种情况就可以松一口气，一般是公网路由问题，慢慢等或者联系S的运营商要求解决；如果不能，则证明S存在不确定性，也就是上面说的“不可证明的范围”扩大了，需要往下进行步骤3。
3，测试W到G的连通性。如果连接正常，那么到此为止，可以直接定位故障环节为S；如果连接不正常，往下进行步骤4。
4，测试O到G的连通性，如果能通，则也可以证明故障环节为S自身；如果不通，则一般是基础运营商的线路问题了，如果S在境外，那么八成是国际出口或者S机房的线路问题，发个工单让他们解决吧。
后续以及可能遇到的情况太多，我就不再写了，这个题考察的是经验和思维逻辑，在运维工作中，不论遇到多大多小的问题，按照上面的判断逻辑都可以在最短时间内定位到故障环节。同时呢，上面写出的步骤也不一定非要这么来，比如第3步完全可以首先进行，根据情况进行后续判断。总之，证明可以证明的，通过已经证明的来尽量缩小问题范围，最终得出的结果就是故障环节。