【运维心得】500 internal server error的另类解决

系统架构介绍

现象描述

误导

正确排查

问题解决

再次反思排查顺序

系统架构介绍

昨天临近下班，忽然用户报告了一个诡异的问题，由于隐私原因，系统就不截图了，只做一个描述。系统分前端和后端两部分，前端主要是静态页面+Jquery，向后端发送请求。后端提供数据返回，为Json格式，非常常见的架构。

现象描述

昨天的现象是：上午的时候系统没有问题，但是到了下午3点多，用户反映可以登录，但是系统卡顿，无法显示数据，希望我们重启服务。

由于之前有过类似的经历，一开始，也认为是由于网络卡顿的缘故，造成用户无法使用，但是经常查看，发现是所有的界面中，凡是请求数据的，都无法显示数据。F12查看一下，发现是server 500错误，第一感觉是后台服务出问题了！事后发现这个感觉是对的。

误导

但是，由于能够登录，说明数据库本身是好的，这一点误导了我，导致没有按照正确的思路去排查。

由于之前没有改动过任何代码，所以第一时间考虑是操作系统的问题，但为了排查顺序，还是先重启了服务，结果故障依旧。重启了数据库服务，结果故障依旧。

马上联系了运维，重启了整个服务器，结果故障依旧！

正确排查

排除了操作系统的问题，才想起来，应该先查看应用的日志！

排查了web服务的日志，没有发现异常。

然后开始排查系统的应用日志，终于发现了一些眉目：日志中有个关键词namespace Log 找不到了！

由于系统中用到了log4net，立马想到了是不是log相关的功能出问题了！

问题解决

由于已经过去了1个多小时，系统始终无法访问，有人已经建议，是不是重新部署系统？

死马当活马医，立马进行编译，顺便对比了一下本地和服务器上的文件，苍天有眼，终于发现了问题所在，服务器上少了log.dll这个文件！

立马把本地的log.dll文件拷贝上去，系统终于正常了！有人可能要问，为啥登录不受影响呢？因为登录当时没有做日志，只对数据操作进行了日志记录！

纳闷了，为啥好好的，这个文件就没有了呢？静心想了一下，之前碰到过杀毒软件删除文件的事情，一看，服务器上竟然安装了某卫士和某杀毒，这个全家桶都在！

立马去杀毒历史中查找，结果发现了问题所在，在下午1点半左右，杀毒自动扫描，把log.dll文件直接删除了！而且没有任何通知！如下图：

吓得赶紧把这个全家桶卸载，安装了另外一款轻巧的杀毒软件。问题解决！！！

再次反思排查顺序

今天再反思一下，感觉此次虽然解决了问题，但是解题顺序有点不对，正确的排查顺序应该如下：

F12首先定位错误，这一点，是对的，首先定位了是后台服务原因，都500了；

排查系统应用日志，如果能第一时间查这个日志，那么很快就能定位是dll文件丢失了，就不会大费周章的去重启服务和服务器了！

最后，给自己提个醒，今后千万不要随意安装全家桶，否则出现莫名其妙的问题，会让你发疯的！