# 一、写日志引发故障
【故障现象】：应用服务集群发布后不久就出现多台服务器相继报警，硬盘可用空间低于警戒值，并且很快有服务器宕机。登录在线上服务器，发现 log 文件夹里面的文件迅速增加，不断消耗磁盘空间。
【原因分析】：这是一个普通的应用服务器集群，不需要存储数据，因此服务器使用的是一块 100GB 的小硬盘，安装完操作系统、Web 服务器、Java 虚拟机、应用程序后，空闲空间就剩几十GB，正常情况下这些磁盘的空间足够，但是该应用的开发人员将 log输出的 level全局配置为 Debug。这样一次简单的 web请求就会产生大量的 log文件输出，在高并发的用户请求下，很快就消耗完不多的磁盘空间。
TIP
OFF：OFF Level是最高等级的，用于关闭所有日志记录。
FATAL：FATAL Level指出每个严重的错误事件将会导致应用程序的退出。
ERROR：ERROR Level指出虽然发生错误事件，但仍然不影响系统的继续运行。
WARN：WARN Level表明会出现潜在错误的情形。
INFO：INFO Level表明 消息在粗粒度级别上突出强调应用程序的运行过程。
DEBUG：DEBUG Level指出细粒度信息事件对调试应用程序是非常有帮助的。
TRACE：TRACE Level最详细的日志信息。
ALL：ALL Level是最低等级的，用于打开所有日志记录。
【经验教训】：①、应用程序的日志输出配置和第三方组件日志输出要分别配置；②、检查生产 log配置文件，日志输出级别至少为 WRAN，并且检查 log输出代码调用，调用级别要符合其真实日志级别。③、有些开源的第三方组件也会不恰当地输出太多的 Error日志，需要关闭这些第三方库的日志输出。
# 二、高并发访问数据库故障
【故障现象】：某应用发布后，数据库 Load居高不下，远超过正常水平，持续报警。
【原因分析】：检查数据库，发现报警是因为某条 SQL 引起的，这条 SQL 是一条简单的有索引的数据查询，不应该引发报警。继续检查，发现这条 SQL 执行频率非常高，远远超过正常水平。追查这条 SQL，发现被网站首页应用调用，首页是被访问最频繁的网页，这条 SQL 被首页调用，也就被频繁执行。
【经验教训】：①、首页不应该访问数据库，需要的数据可以从缓存服务器或者搜索引擎服务器获取。②、首页最好是静态的。
# 三、缓存引发的故障
【故障现象】：没有新应用发布，但是数据库服务器访问突然飙升，并很快失去响应。DBA 将数据库访问切换到备库，Load 也很快飙升，并失去响应。最终引发网站全部瘫痪。
【原因分析】：缓存服务器在网站服务器集群中的地位一直较低，服务器配置和管理级别都比其他服务器要低一些。认为缓存时改善性能的手段，丢失一些缓存也没关系，有时候关闭一两台缓存服务器也确实对应用没有明显影响，所以长期疏于管理缓存服务器。结果这次缺乏经验的工程师关闭了缓存服务器集群中全部的十几台缓存服务器，导致网站瘫痪的重大事故。
【经验教训】：当缓存已经不仅仅是改善性能，而是成为网站架构不可或缺的一部分时，对缓存的管理就需要提高到和其他服务器一样的级别。
# 四、应用启动顺序引发的故障
【故障现象】：某应用发布后立即崩溃。
【原因分析】：应用程序 WEB环境使用 Nginx+Jetty 的模式，用户请求通过 Nginx 转发给 Jetty。在发布时，Nginx 和 Jetty 同时启动，有于 Jetty 启动需要加载很多应用并初始化，花费时间较长，结果 Jetty 还没有完全启动，Nginx 就应经启动完成开始接收用户请求，大量请求阻塞在 Jetty 进程中，最终导致 Jetty 崩溃。网站中还有很多类似的场景，都需要后天服务准备好，前台应用才能启动，否则就会出现故障。
【经验教训】：在应用程序中加入一个特定的动态页面，启动脚本先启动 Jetty，然后在脚本中不断用 curl 命令访问这个特定页面，直到返回目标数据，才启动成功。
# 五、大文件读写独占磁盘引发的故障
【故障现象】：应用主要功能是管理图片，部分用户上传图片时非常慢，原来只需要一两秒，现在需要几十秒，有时等半天结果浏览器显示服务器超时。
【原因分析】：图片需要使用存储，存储服务器大概率出错。检查存储服务器，发现大部分文件只有几百 KB，而又几个文件非常大，有数百兆，读写这些大文件一次需要几十秒，这段时间，磁盘基本被这个文件操作独占，导致其他用户的文件操作缓慢。
【经验教训】：存储的使用需要根据不同文件类型和用途进行管理，图片都是小文件，应该使用专用的存储服务器，不能和大文件公用存储。批处理用的大文件可以使用其他类型的文件分布式文件系统。
# 六、高并发情况下锁引发的故障
【故障现象】：某应用服务器不定时地因为响应超时而报警，但是很快又超时解除，恢复正常，如此反复，让运维人员非常苦恼。
【原因分析】：程序中某个单例对象中多处使用了 synchronized(this)，由于 this 对象只有一个，所有的并发请求都要排队获得这个唯一的锁。一般情况下，都是一些简单的操作，获得锁，迅速完成并释放锁，不会引起线程排队。但是某些时候需要调用远程的操作也被加了 synchronized(this)，这个操作只是偶然执行，但是每次执行都需要很长时间才能完成，这段时间锁被占用，所有的用户线程都要等待，响应超时，这个操作执行完后释放锁，其他线程迅速执行，超时解除。
【经验教训】：使用锁操作需要谨慎。
# 七、滥用生产环境引发的故障
【故障现象】：监控发现某个时间段，某个应用突然变慢，内部网络访问延迟非常厉害。
【原因分析】：检查返现，该时段内网卡流量下降，最后发现有功能在线上生产环境进行性能压力测试，占用了大量交换机带宽。
【经验教训】：访问线上生产环境要规范，不小心就会导致大事故。网站数据库有专门的DBA 维护，如果发现数据库存在错误记录，需要进行数据订正，必须走数据订正流程，申请 DBA 协助。于是就有工程师为避免麻烦，直接在代码中写一段操作数据库的代码，悄悄放到生产环境服务器上执行，神不知鬼不觉地修改了数据。但是如果不小心写错了SQL，后果不堪设想。
# 八、不规范的流程引发的故障
【故障现象】：某应用发布后，数据库 Load 迅速飙升，超过报警值，回滚发布后报警消除。
【原因分析】：发现该应用发布后出现大量数据库读操作，这些数据本应该从分布式缓存中读取。检查缓存发现数据存在。检查代码发现访问缓存的那行代码被注释了。工程师为了方便开发和测试，特意注释掉读取缓存的代码，开发完成后忘记去掉注释，直接提交到代码库到线上环境。
【经验教训】：①、自查：代码提交前使用 diff 命令进行代码比较，确认没有提交不该提交的代码。②、加强 code review，代码在正式提交前必须被至少一个其他工程师做过 code review，并且共同承担代码引发的故障责任。
# 九、不好的编程习惯引发的故障
【故障现象】：应用更新某功能后， 有少量用户无法正常访问该功能，一点击就显示错误信息。
【原因分析】：分写这些用户，都是第一次使用该功能，检查代码，发现程序根据历史使用记录构造一个对象，如果该对象为 null，就会导致 NullPointException。
【经验教训】：①、程序在处理一个输入的对象时，如果不能明确该对象是否为空，必须做空指针判断。②、程序在调用其他方法时，输入的对象尽量保证不是null，必要时构造空对象。
# 十、幂等问题
【故障现象】：很多年前，笔者在一家大型电商公司做 Java程序员，当时开发了积分服务。当时的业务逻辑是，用户订单完结后，订单系统发送消息到消息队列，积分服务接到消息后给用户积分，在用户现有的积分上加上新产生的积分。由于网络等原因会有消息重复发送的情况，这样也就导致了消息的重复消费。当时笔者还是个初入职场的小菜鸟，并没有考虑到这种情况。所以上线后偶尔会出现重复积分的情况，也就是一个订单完结后会给用户加两次或多次积分。
【解决方案】：后来我们加了一个积分记录表，每次消费消息给用户增加积分前，先根据订单号查一遍积分记录表，如果没有积分记录才给用户增加积分。这也就是所谓的“幂等性”，即多次重复操作不影响最终的结果。实际开发中很多需求重试或重复消费的场景都要实现幂等，以保证结果的正确性。例如，为了避免重复支付，支付接口也要实现幂等。
# 十一、带宽资源耗尽
【故障现象】：带宽资源耗尽导致系统无法访问的情况，虽然不多见，但是也应该引起大家的注意。来看看，之前遇到的一起事故。场景是这样的。社交电商每个分享出去的商品图片都有一个唯一的二维码，用来区分商品和分享者。所以二维码要用程序生成，最初我们在服务端用 Java生成二维码。前期由于系统访问量不大，系统一直没什么问题。但是有一天运营突然搞了一次优惠力度空前的大促，系统瞬时访问量翻了几十倍。问题也就随之而来了，网络带宽直接被打满，由于带宽资源被耗尽，导致很多页面请求响应很慢甚至没任何响应。原因就是二维码生成数量瞬间也翻了几十倍，每个二维码都是一张图片，对带宽带来了巨大压力。
【解决方案】：如果服务端处理不了，就考虑一下客户端。把生成二维码放到客户端APP处理，充分利用用户终端手机，目前Andriod，IOS或者React都有相关生成二维码的SDK。这样不但解决了带宽问题，而且也释放了服务端生成二维码时消耗的CPU资源（生成二维码过程需要一定的计算量，CPU消耗比较明显）。外网带宽非常昂贵，我们还是要省着点用啊！