1.写日志引发的故障
现象：服务器发布不久出现多台服务器报警，硬盘可用空间过低，log文件迅速增加
原因：开发人员将log级别设置为debug
解决：程序自己的日志输出配置和第三方组件的日志输出分别配置；日志输出级别至少为warn；关闭一些输出过多error日志的第三方开源软件
2.并发访问数据库引发故障
现象：应用发布后，数据库load居高不下
原因：频繁访问的首页，调用了sql
解决：首页不该访问数据库，首页数据直接从缓存或搜索引擎获取
首页最好静态化
3.高并发下锁引起的故障
现象：服务器不时的因为响应超时报警
原因：某个单例对象中多处使用了synchronized(this)，某个远程调用方法也加了这个，每次执行都要很长时间，此时其他用户线程要等待
解决：谨慎使用锁
4.缓存引发故障
现象：没有发布新业务，数据库服务器load飙升
原因：有时候关闭一两台缓存服务器影响不大，长期疏于管理，无意关闭了缓存服务器集群中全部的服务器
解决：对缓存的管理提高到其他服务器一样的级别
5.应用移动不同步引起故障
现象：应用发布后，服务器崩溃
原因：应用模块启动快，已经开始接受用户请求，服务模块启动慢，大量请求阻塞。后台没准备好，前台就启动
解决：应用程序中加入一个特定页面（只返回OK），启动脚本先启动服务模块，脚本中不断curl命令访问这个页面，知道返回OK，才启动应用模块
6.大文件读写独占磁盘引发故障
现象：上传图片非常慢
原因：存储服务器中大部分文件很小，只有几个文件特别大，读写这个大文件时，独占磁盘，导致其他文件读写缓慢、
解决：大文件使用其他类型的分布式文件系统
7.滥用生产环境引发故障
现象：某些应用突然变慢，内部网络延迟厉害
原因：在生产环境上进行压力测试，占用了大部分交换机带宽
解决：小心访问线上环境。
8.不规范的流程引发故障
现象：应用发布后，数据库load飙升
原因：为了测试方便，注释了从缓存读取数据的代码，忘记放开注释
解决：加强代码检查，看有没有提交不该提交的代码。
9.不好的编程习惯引发的故障
现象：应用更新某功能后，少量用户投诉无法访问正常，点击显示出错信息
原因：这些都是第一次使用的用户，程序根据历史记录构造一个对象，为null，抛异常
解决：处理对象，不能确认是否为空时，必须做空指针判断，
输入对象尽量保证部位null，必要时构造空对象