大型网站故障案例分析

1.写日志引发的故障：

        现象：应用服务器集群发布不久后出现多台服务器相继报警，磁盘可用空间低于警戒值，并且很快有服务器宕机，发现log文件迅速增加，不断消耗磁盘空间。

        分析：这是普通的应用服务器集群，不需要存储数据，因此服务器存储的是100GB的小硬盘，安装完操作系统，web服务器，java虚拟机等应用程序后，空闲空间只有几十GB，正常情况够用，但开发将日志输出的level全局配置成debug。这样一次简单的web请求就会造成大量的log文件生成，消耗磁盘空间。

        方案：

            1.1 应用程序自己的日志输出配置和第三方组件日志输出要分别配置。

            1.2 检查log配置文件，日志输出级别至少为warn，并且检查log输出代码调用，调用级别要符合其真实日志级别。

            1.3 有些开源的第三方组件也会不恰当的输出太多的Error日志，需要关闭这些第三方库的日志输出，至于哪些第三方库有问题，具体问题具体对待。

 

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

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

        分析：检查数据库发现，是一条sql一直执行导致的数据库Load居高不下，而且是首页的接口有调用到这个sql，执行频率比较高，远远超过正常水平，首页被频繁访问，导致这条sql频繁被调用。

        方案：

                2.1 首页不应该访问数据库，首页需要的数据可以从缓存服务器或者搜索引擎服务器上获取。

                2.2 首页最好是静态的。

 

3.高并发情况下锁引发的故障：

        现象：某应用服务器不定时的因为响应超时而报警，但很快又超时解除了，恢复正常。

        分析：程序中某个单例对象，在被多出引用的地方使用到了synchronized(this)，由于this只有一个，所以并发需要排队获取，一般情况，简单程序操作不会引起线程排队，但某个特殊的远程调用的时候也被加上了synchronized（this），虽然可能偶尔执行，但这种操作需要等待较长的时间，导致所有的用户线程需要等待，响应超时，等这个远程调用结束后，其他线程才能执行，超时解除。

        方案：使用锁操作要谨慎考虑。

 

4.缓存引发的故障：

        现象：没有新应用发布，但数据库服务器的load突然飙升，并很快失去响应，DBA将数据库访问切换到备机，load也很快飙升，并失去响应，最终导致网站全面瘫痪。

        分析：缓存服务器在网络服务器集群中的地位一直比较低，缓存服务器作为一个优化性能的手段，没有得到足够的重视，认为，停掉一两台缓存服务器应该没啥问题，但如果关闭了缓存服务器集群中的全部十几台Memcached服务器，导致了网站的整体瘫痪。

        方案：当缓存已经称为不仅仅是性能优化的一种手段时，我们需要将缓存服务器进行管理起来，将其提升到和 其他服务器一个级别的管理。

 

5.应用启动不同步引发的故障：

        现象：某应用发布后，服务器立即崩溃

        分析：web应用程序使用Apache+JBoss的模式，用户请求通过apache转发到JBoss，在发布时，两者同时启动，由于JBoss需要加载的东西比较多，话费时间比长，结果JBoss还没完全启动，就有大量请求过来了，导致JBoss阻塞，导致JBoss崩溃。此外还有其他类似场景，后台还没有启动完毕，前台请求就发送过来。

        方案：在应用程序中加入特定的动态页面，比如只返回OK，先启动JBoss，然后在脚本中不断用curl指令返回这个特定的页面直到收到OK为止，才启动apache服务。

 

6.大文件读写独占磁盘引发的故障：

        现象：某应用主要是管理用户图片，某些用户反映上传图片非常慢，有时会显示超时。

        分析：图片需要存储，一般都放在存储服务器上，发现存储服务器上都是几十几百kb的图片，有几个文件特别大，有几百M，读写这些文件会占用大量时间，这段时间，磁盘基本被这个文件操作独占，导致其他用户的文件操作缓慢。

        方案：存储的使用需要根据文件不同的类型和用途进行管理，图片都是小文件，需要在独立的文件服务器上部署，不能和大文件公用存储，批处理的大文件可以使用其他类型的分布式文件系统。

 

7.滥用生产环境引发的故障：

        现象：监控发现某个时间段，某些应用突然变慢，内部网络访问延迟很高。

        分析：检查发现，该时间段内网卡流量下降，但没找到原因，过了一段时间才知道，有工程师在生产环境进行性能压力测试，占用大部分交换机带宽。

        方案：访问线上环境要规范，不小心就会造成大的事故。网站数据库由专门的DBA管理，如果线上环境数据库中出现问题，要走正常流程去更改数据，但有些工程师就怕麻烦，就自己写代码去生产环境上执行，如果写的sql有问题，后果可想而知。

 

8.不规范的流程引发的故障：

        现象：某应用发布后，数据库的load飙升，超过警戒值，但回滚发布后报警消除。

        分析：发布发现由大量的数据库连接，本来是走缓存的，查看缓存也是有数据的，最后发现，开发人员将先查缓存的代码注释掉了，便于开发，但提交的时候也没注意，还是注释的，导致数据库load飙升，缓存没起任何作用。

        方案：

            8.1  代码提交的diff部分要重点查看，确认好提交代码

            8.2  加强code review，至少有一个开发做到相互backup，相互保障代码的正确性。

 

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

        现象：某功能上线后，有部分用户发现无法使用该功能，甚至报错。

        分析：发现这些用户第一次使用这个功能，检查代码发现，程序根据历史纪录去创建一个对象，没有历史记录就是null，就报NPE了

        方案：

                9.1  程序在处理一个输入对象时，如果不明确该对象是否为空，必须做好预防NPE的准备。

                9.2  程序在调用其它方法时，尽量保证不会传null过去，必要时构造空对象(使用空对象模式)。

 

小结：

        软件设计有两种风格，一种是将软件设计的很复杂，使其缺陷不是那么明显，一种是将软件设计的很简单，使其没有明显的缺陷。

 

转载于:https://my.oschina.net/u/3110937/blog/1577516