排查错误的步骤

  工作中经常遇到程序员查问题，半天查不出来，然后找到我这里来协助，然而，问题几乎都是些容易排查的问题。

  造成这种现象的原因都是排查问题的步骤，多数程序员在找问题的时候都是理所当然的认为是程序中的这个位置导致的，然后去改，改后了发现原来不是，然后再次去猜，循环重复这一步骤，最后要么查不出来，要么猜对了，然而已经不知道都改了些什么，也不知道是怎么改对的。

  当然，并不是不可以猜，当你有足够的线索和经验可以判定是某一处的问题的时候，这么做可以快速完成工作，但是希望能设定一个时间，一旦超过这个时间，还是改用按部就班的方式来查找。所谓按部就班就是说从问题表现出来的那一点一点的推进，举个例子：

  前几天我们的系统突然无法上传图片了，由于完全没有改动过程序，所以可能是nginx或者fastdfs出问题了，而应用和静态资源访问没有问题，所以最大可能是fastdfs出了问题，于是让运维去看3个fastdfs服务器有没有问题，然而似乎服务器和服务状态一切正常，硬盘似乎也还有不少空间。

  这个时候就需要从错误出现的点一点一点往后推了，也就是上传的应用--》nginx--》fastdfs，这个问题其实在应用的错误日志中就写的很清楚了：tracker_query_storage_fail,error no:28, error info No space left on device。于是去查看硬盘空间和配置：

    

    tracker.conf的配置项reserved_storage_space的值为10%，而当前环境下剩余空间已不足10%。

  以下是运维整理的解决办法：

    解决办法一：根据实际空间情况修改tracker.conf配置项reserved_storage_space的值

    解决办法二：添加一块新硬盘挂载

    1. fdisk –l

    

    /dev/vdb是新的200G硬盘

    2. fdisk /dev/vdb   (新建100G分区)

    

    3. 格式化文件系统为ext3

    mkfs -t ext3 /dev/vdb1

    4. 挂载（挂载的时候注意做好文件备份）

    mount /dev/vdb1 /fastdfs/storage/

    

    5. 配置开机自动挂载

    查看新硬盘的UUID：

    blkid /dev/vdb1

    

    配置/etc/fstab,将新硬盘开机自动挂载到/fastdfs/storage/下

    

  总结：其实一开始从应用日志开始看，就省了运维排查的时间，当然如果经验足够，查看硬盘空间的时候顺便看了配置的硬盘空间使用百分比，也就省了之后看日志的时间，所以，我们需要做的就是找一个平衡点，一定时间内依赖经验，超过时间即判断经验不足，采取按步推进的方式。