网站典型故障案例

写日志也会引发故障：

故障现象：应用服务器集群发布后不久就出现多台服务器相继报警，硬盘可用低于警戒值，并且很快有服务器宕机。登录到线上机器，发现log文件夹里的文件迅速增加，

不断消耗磁盘空间。

原因分析：该应用的开发人员将log输出的level全局配置为Debug。这样一次简单的web请求就会产生大量的log文件输出，在高并发的用户请求下，很快就消耗完不多的

磁盘空间。

经验教训：

• 应用程序自己的日志输出配置和第三方组件日志输出要分别配置。
• 检查log配置文件，日志输出级别至少为Warn，并且检查log输出代码调用，调用级别要符合其真实日志级别。
• 有些开源的第三方组件也会不恰当的输出太多的Error日志，需要关闭这些第三方库的日志输出，至于那些第三方库有问题，只有在遇到问题才知道。

高并发访问数据库引发故障：

故障现象：某应用发布后，数据库load居高不下，远超过正常水平，持续报警。

原因分析：检查数据库，发现报警时因为某条SQL语句引起的，这条语句是一条简单的有索引的数据查询，不应该引发报警。继续检查，发现这条SQL知识频率很高，远远

超过正常水平。追查这条SQL，发现该网站首页应用调用，首页是该访问最频繁的网页。这条SQL被首页调用，也就被频繁执行了。

经验教训：

• 首页不应该访问数据库，首页需要的数据可以从缓存服务器或者搜索引擎服务器获取。
• 首页最好是静态的。

高并发下锁引发故障：

故障现象：某应用服务器不定时的因为响应超时而报警，但是很快又超时解除，恢复正常，如此反复，运维人员非常苦恼。

原因分析：程序中某个单例对象中多处使用了synchronized（this）由于this对象只有一个，所有的并发请求都要排队获得这唯一的一把锁。一般情况下，都是一些简单的

操作，获得锁，迅速完成操作，释放锁，不会引起线程排队。但是某个需要远程调用的操作也加了synchronized，这个操作知识偶尔会执行，但是每次执行都需要较长的时间才能完成，这段时间锁被占用，所有的用户线程都要等待，响应超时，这个操作执行完后释放锁。其他线程迅速执行，超时解除。

经验教训：

• 使用锁操作要谨慎。

缓存引发故障：

故障现象：没有新应用发布，但是数据库服务器突然load飙升，并很快失去响应，ＤＢＡ将数据库访问切换到备机，load也很快飙升，并失去响应，最终引发网站全部瘫痪。

原因分析：缓存服务器在网站服务器集群中的地位一直比较低，服务器配置和管理级别都比其他服务器低一些，人们都认为缓存是改善性能的手段，丢失一些缓存也没什么问题，有时候关闭一两台缓存服务器也确实对应用没有明显影响，所以长期疏于管理缓存服务器。结果这次工程师关闭了缓存服务器集群中全部的十几台memcached服务器，导致网站全部瘫痪的重大故。

经验教训：

• 当缓存已经不仅仅是改善性能，而是网站架构不可或缺的一部分时，对缓存的管理就需要提高到和其他服务器一样的级别。

大文件读写独占磁盘引发故障：
故障现象：某应用主要功能是管理用户图片，接到部分用户投诉，表示上传图片非常慢，原来只需要一两秒，现在需要几十秒，有时等半天结果浏览器显示服务器超时。

原因分析：图片需要使用存储，最有可能出错的地方是存储服务器，检查存储服务器，发现大部分文件只有几百KB，而有几个文件非常大，有数百兆，读写这些大文件一次需要几十秒，这段时间，磁盘基本被这个文件操作独占，导致其他用户的文件操作缓慢。

经验教训：

• 存储的使用需要根据不同文件类型和用途进行管理，图片都是小文件，应该使用专用的存储服务器，不能和大文件共用存储，批处理用的大文件可以使用其他类型的分布式文件系统。

不好的编程习惯引发故障：

故障现象：某应用更新某个功能后，有少量用户投诉无法正常访问该功能，一点击就显示出错信息。

原因分析：分析这些用户，都是第一次使用该功能，检查代码，发现程序根据历史使用记录来构造一个对象，如果对象为null，就会导致NPE。

经验教训：

• 程序处理一个输入对象时，如果不能明确该对象是否为空，必须做空指针判断。
• 程序在调用其他方法时，输入的对象尽量保证不是null。必要时构造空对象。。