书中例举了一些故障案例，同样的现象，原因可能不尽相同。以下说的原因仅供参考
1. 写日志引发故障
现象：应用发布后不久，多台服务器相继报警，硬盘可用空间低于警戒值。
原因：日志输出的level全局配置为Debug。
教训：（1）应用程序自己的日志输出配置和第三方组件日志输出要分别配置；（2）日志级别设置为Warn。
2. 高并发访问数据库引发的故障
现象：某应用发布后，数据库Load居高不下，远超正常水平，持续报警
原因：某条SQL被网站首页调用
教训：（1）首页不应该访问数据库，首面需要的数据可以从缓存服务器或者搜索引擎服务器获取；（2）首面最好是静态的
3. 高并发情况下锁引发的故障
现象：某应用服务器不定时地因超时而报警，但是很快又解除超时报警
原因：某个单例对象中多处使用了synchronized，其中某个需要远程调用的操作也用了synchronized，这个操作只是偶尔会被执行，但是每次执行都需要较长的时间才能完成
教训：使用锁操作要谨慎
4. 缓存引发的故障
现象：数据库服务器负载突然飙升，并很快失去响应。
原因：工程师不小心关闭了所有的缓存服务器
教训：缓存不仅仅是改善性能，而是成为网站架构不可或缺的一部分
5. 应用启动不同步引发的故障
现象：某应用发布后，服务器立即崩溃
原因：前台服务器先于后台服务器启动完毕，有大量请求过来时，后台服务器还没启动好，一直处于阻塞状态
教训：后台服务器启动完毕，再启动前台服务器
6. 大文件读写独占磁盘引发的故障
现象：某应用主要功能是管理用户图片，上传图片非常慢
原因：图片服务器和其它存储服务器共用同一个服务器，当其它服务器读写大文件时，图片上传至服务器进行存储时，将会被阻塞。
7。 滥用生产环境引发的故障
现象：监控发现某个时段内，某些应用突然变慢，内部网络访问延迟非常厉害
原因：有工程师在线上生产环境进行性能压力测试，占用了大部分交换机带宽
8. 不规范的流程引发的故障
现象：某应用发布后，数据库Load迅速飙升，超过报警值，回滚发布后报警消除
原因：工程师在开发的时候，为了测试方便，把读取缓存的代码给注释掉了，发布时忘记去掉注释。
9. 不好的编程习惯引发的故障
现象：某应用更新某功能后，有少量用户投诉无法正常访问该功能，一点击就出错
原因：代码中根据历史记录构造一个对象，并未进行null值判断。