11.7 高可用故障案例分析

1.故障 1

故障现象：

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

原因分析：

这是个普通的应用服务器集群，不需要存储数据，因此服务器里配置的是一块 100G 的小硬盘，

安装完操作系统，Web 服务器，Java 虚拟机，应用程序后，空闲空间只有几十 GB 啦，正常情况下磁盘空间足够，但是该应用的开发人员将 LOG 输出的 level 全局配置为 DEBUG。这样一次简单的 Web 请求就会产生大量的 LOG 文件输出，在高并发的用户请求下，很快就消耗完不多的饿磁盘空间。

2.故障 2

故障现象：

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

原因分析：

检查数据库，发现报警时因为某条 SQL 引起的，这条 SQL 是一条简单的有索引的数据查询，不应该引发报警。继续检查，发现这条 SQL 执行频率非常高，远远超过正常水平。追查这条 SQL，发现被网站首页调用，

首页是被访问最频繁的页面，这条 SQL 被首页调用，也就被频繁执行啦。

经验教训：

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

• 首页最好是静态的。

3.故障 3

故障现象：

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

原因分析：

程序中某个单例对象（singleton object）中多个方法使用了 synchronized 修饰符，由于 this 对象只有一个，即使执行不同方法，所有的并发请求也都要排队获得这唯一的一把锁。一般情况下，都是一些简单的操作，获得锁，迅速完成操作，释放锁，不会引起线程排队。但是某个执行远程调用的方法也被加上了 synchronized，这个方法只是偶尔被执行，但是每次执行都需要较长的时间才能完成，这段时间锁被占用，所有的用户线程都要等待，响应超时，这个方法执行完后释放锁，其他线程迅速执行，超时解除。

经验教训：

• 使用锁操作要谨慎，特别注意在有锁的方法中进行长时间的 IO 操作的时候。

• 针对使用锁的不同场景，使用不同锁对象，而不是简单的在所有方法上都使用 synchronized。

4.故障 4

故障现象：

没有新应用发布，用户并发请求也没有突然增加，但是数据库服务器突然 Load 飙升，并很快失去响应。

DBA 将数据库切换到备机，Load 也很快飙升，并失去响应。最终引发网站全部瘫痪。

分析原因：

缓存服务器在网站服务器集群中的地位一直比较低，服务器配置和管理级别都比其他服务器要低些。

人们都认为缓存时改善性能的手段，丢失一些缓存也没有什么问题，有时候关闭一两台缓存服务器也确实对应用没有明显影响，所以长期疏于管理缓存服务器。结果这次一个缺乏经验的工程师关闭了缓存服务器中全部的几十台 Memcached 服务器，导致了网站全部瘫痪的重大事故。

经验教训：

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

5.故障 5

故障现象：

某应用发布后，服务立即崩溃。

原因分析：

应用程序 Web 环境使用 Apache+JBoss 的模式，用户请求通过 Apache 转发到 JBoss。在发布时，Apache 和 JBoss 同时启动，由于 JBoss 启动时需要加载很多应用并初始化，花费时间较长，结果 JBoss 还没有完全启动，Apache 就 已经启动完毕开始接受用户请求，大量请求阻塞在 JBoss 进程中，最终导致 JBoss 崩溃。除了这种 Apache 和 JBoss 启动不同步的情况，网站还有很多类似的场景，

需要后台服务准备好，前台应用才能才能启动，否则就会导致故障。

经验教训：

• 在 Java 应用程序中加入一个特定的动态页面（比如只返回 OK 两个字母），启动脚本先启动 JBoss，然后在脚本中不断用 curl 命令访问这个特定页面。直到收到 OK，才启动 Apache。

6.故障 6

故障现象：

某应用主要功能时管理用户图片，接到部分用户投诉，标识上传图片非常慢，原来只要一两秒，现在需要几十秒，有时等半天，结果浏览器显示服务器超时。

原因分析：

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

经验教训：

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

隔离。

7.故障 7

故障现象：

监控发现某个时间段内，某些应用突然变慢，内部网络访问延迟非常严重。

原因分析：

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

经验教训：

• 访问线上生产环境要规范，不小心就会导致大事故。

• 滥用生产环境的一个例子：网站数据库有专门的 DBA 维护，如果发现数据库存在错误记录，需要订正数据，必须走数据订正流程，申请 DBA 协助。于是就有工程师为避免麻烦，直接写一段数据库更新操作的代码，悄悄放到生产环境应用服务器上执行，神不知鬼不觉的订正了数据。但是如果不小心写错了 SQL，后果可想而知。

8.故障 8

故障现象：

某应用发布后，数据库 Load 飙升，超过报警值，回滚发布后，报警消除

原因分析：

发现该应用发布后，出现大量数据库读操作，而这些数据本来应该从分布式缓存读取。检查缓存，发现数据已经被缓存啦。检查代码，发现访问缓存的代码被注释掉啦。原来工程师在开发的时候，为了测试方便，特意注释掉读取缓存的代码，结果开发完成后，忘记啊注释去掉，直接提交到代码库被发布到线上环境。

经验教训：

• 代码提交前使用 diff 命令比较代码，确认没有提交不改提交的代码。

• 加强 codereview，代码再正式提交前必须被至少一个其他工程师做过 codereview，并且共同承担因代码引起的故障责任。

9.故障 9

故障现象：

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

原因分析：

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

经验教训：

• 程序在处理一个输入的对象时，如果不能明确该对象是否为空，必须做空指针判断。

• 程序在调用其他方法时，输入的对象尽量保证不是 null，必要时构造空对象（使用空对象模式）