从问题定位谈基础的重要性

线上服务出故障了，如何快速定位问题？除了运用经验（以前遇过类似的问题），基础也很重要。

某天下午TIM官网突然无法访问（502错误），官网是纯静态页面，挂在nginx服务器下，我们下午也没有做发布。那么，问题出现在什么地方呢？下面就讲讲我定位、解决问题的思路及步骤，具体如下：

1. nginx进程是否挂了？nginx进程运行正常。实际上，如果nginx进程真的挂了，织云的监控也会自动重启进程。

2. 进程既然还在，那就看看nginx的access.log、error.log，找到故障的时间点，查看其日志上下文抓取关键信息。从nginx日志这里，我得到了关键信息：open() "xxx.html" failed (Permission denied)，没有文件权限。之前一直跑得好好的，为什么突然就没有文件权限了？先解决问题再找原因吧。

3. 既然没有文件权限，说明运行nginx的用户没有读取TIM官网静态文件的权限，那么，我们只要把整个TIM官网静态文件目录的权限改成nginx运行用户可读取即可。修改文件目录权限后，TIM官网可以正常访问了。至此，问题解决了。现在，我们可以来看看这个故障问题是怎么产生的？

4. 我们下午没有做过TIM官网变更，为什么突然就没有文件权限了？是谁改了文件权限？既然是这台服务器上的文件权限被更改了，那必然有用户登录过这台机器修改权限。我们可以先尝试找出在故障时间点登陆过的用户，看看有哪些。查了系统的日志后，我得到了一个关键信息：只有user_00这个用户在故障时间点登录过。

5. user_00是织云发布系统默认使用的用户，那是不是有人用织云修改过我们TIM官网的文件权限了。我们可以进一步看看user_00的目录是不是有变更了，接着发现services目录下有一个TIM CGI的织云包在故障的时间点被创建了。我在织云上找到这个包，看了包的明细后，终于找到原因了：这个织云包有一个安装后置脚本，会修改TIM官网静态文件夹的权限，从而导致了这次的故障。（为什么这个TIM CGI的织云包会去修改TIM官网静态文件夹权限呢？如何防止以后再次出现类似情况呢？这是另外一个话题了，在本文就不展开）

以上五点就是我定位、解决TIM官网故障问题的思路及步骤，最后，也比较快速地定位解决了问题。实际上，我以前是没有遇到过这类问题的。在没有相关经验的前提下，如何快速定位问题？这就引出我想表述的一个观点：基础很重要，理解原理懂得运用一些工具能帮你快速定位问题，以下是我定位、解决这个问题用的一些基础知识（与上述解决问题的思路、步骤相对应）：

1. 检测进程用到了Linux指令：ps、grep。

2. Nginx日志相关知识可以帮你定位问题，查看日志用到Linux指令：cat、tail、grep。

3. 判断问题所在运用到了Linux文件权限知识（r、w、x），Nginx运行用户知识（worker）；解决问题用到了Linux指令：chmod、chown。

4. 判断谁在故障时间点登陆过用到了Linux用户登陆相关的知识（在/var/log/secure有登陆记录）。

5. 这里用到的织云相关的知识，Linux用户文件目录相关知识（/home下边有普通用户的主目录）。

总结以上五点，其实就是用了Linux、Nginx的相关基础知识，再加上织云的一点常识，就可以快速定位、解决问题了。这些基础并没有太大的技术难度，但是你必须掌握，而且需要比较熟练地掌握，以便更好更快地分析、解决问题。

举个例子，查找大小为10GB的access.log含"2017-03-09 21:46"的关键字的行的上下50行，你要能快速地写出高效准确的命令（文件大应使用tail命令搜索而不用cat，通过管道符“|”把内容传给grep来过滤关键字，并通过grep的-C选项来定位上下n行）。

本文尝试通过一个小案例来说明基础的重要性。其实，不仅是Linux、Nginx基础，还有TCP/IP、HTTP、数据库等基础也非常重要。一些跟具体的编程语言无关的知识，平时看上去用处不大（写些简单的业务代码，并不需要这些知识），但真正遇到比较复杂的业务场景或者是比较诡异的bug时，这些基础知识往往就能用上了。