雷霆未来

故障现象：某应用服务器不定时地因为响应超时而报警，但是很快又超时解除，恢复正常，如此反复，让运维人员非常苦恼。原因分析：程序中某个单例对象（singleton object）中多处使用了 synchronized（this），由于this对象只有一个，所有的并发请求都要排队获得这唯一的一把锁。一般情况下，都是一些简单操作，获得锁，迅速完成操作，释放锁，不会引起线程排队。但是某个需要远程调用的操作也被加了 synchronized（this），这个操作只是偶尔会被执行，但是每次执行都需要较长的时间才能完成

故障现象：某应用发布后，数据库Load迅速飙升，超过报警值，回滚发布后报警消除。原因分析：发现该应用发布后出现大量数据库读操作，而这些数据本来应该从分布式缓存读取。检査缓存，发现数据已经被缓存了。检査代码，发现访问缓存的那行代码被注释掉了。原来工程师在开发的时候，为了测试方便，特意注释掉读取缓存的代码，结果开发完成后忘记把注释去掉，直接提交到代码库被发布到线上环境。经验教训：代码提交前使用dif命令进行代码比较，确认没有提交不该提交的代码。 加强 code review，代码在正式提交前必须被

故障现象：某应用更新某功能后，有少量用户投诉无法正常访问该功能，一点击就显示出错信息。原因分析：分析这些用户，都是第一次使用该功能，检查代码，发现程序根据历史使用记录构造一个对象，如果该对象为null，就会导致 NullPoint Exception经验教训：程序在处理一个输入的对象时，如果不能明确该对象是否为空，必须做空指针判断。 程序在调用其他方法时，输入的对象尽量保证不是null，必要时构造空对象（使用空对象模式）。...

故障现象：某网站发布后，数据库Load居高不下，远超过正常水平，持续报警。原因分析：检查数据库，发现报警是因为某条SQL引起的，这条SQL是一条简单的有索引的数据查询，不应该引发报警。继续检查，发现这条SQL执行频率非常高，远远超过正常水平。追查这条SQL，发现被网站首页应用调用，首页是被访问最频繁的网页，这条SQL被首页调用，也就被频繁执行了。经验教训：首页不应该访问数据库，首页需要...

故障现象监控发现某个时段内，某些应用突然变慢，内部网络访问延迟非常厉害。原因分析检查发现，该时段内网卡流量也下降，但是没有找到原因。过了一阵子才知道，原来有工程师在线上生产环境进行性能压力测试，占用了大部分交换机带宽。经验教训访问线上生产环境要规范，不小心就会导致大事故。 网站数据库有专门的DBA维护，如果发现数据库存在错误记录，需要进行数据订正，必须走数据订正流程，申请DB...

故障现象没有新应用发布，但是数据库服务器突然Load飙升，并很快失去响应。DBA将数据库访问切换到备机，Load也很快飙升，并失去响应。最终引发网站全部瘫痪。原因分析缓存服务器在网站服务器集群中的地位一直比较低，服务器配置和管理级别都比其他服务器要低一些。人们都认为缓存是改善性能的手段，丢失一些缓存也没什么问题，有时候关闭一两台缓存服务器也确实对应用没有明显影响，所以长期疏于管理缓存服务器。...

故障现象某应用服务器集群发布后不久就出现多台服务器相继报警，硬盘可用空间低于警戒值，并且很快有服务器宕机。登录到线上服务器，发现log文件夹里的文件迅速增加，不断消耗磁盘空间。原因分析这是一个普通的应用服务器集群,不需要存储数据,因此服务器里配置的是一块100GB的小硬盘，安装完操作系统、Web服务器、Java虚拟机、应用程序后,空闲空间只有几十GB了，正常情况下这些磁盘空间足够了，但是该应...