编 写：袁 亮
时 间：2015-01-20
说 明：php后端程序人员简单排错能力
一、说明
能力强不强是通过解决问题来体现的，不能解决问题的话，其他的都是白搭
ps:不要觉得错误莫名其妙，我这边明明是好的，用户那边有问题，就怀疑是电脑有问题啊，服务器有问题啊什么的，mysql有问题啊之类
99%的问题，都是程序上的问题，没能重新，只是你没重现出那个特殊的情况
二、常见错误类型
1、网站打不开，不能访问
2、能打开页面，但是页面显示不正常，比如白页，404等
3、操作失败，比如不能发帖，不能删帖等
4、逻辑错误，比如帖子的回复数不对，页面缓存一直错误
5、页面打开很慢，性能问题，超时，卡等
6、定时脚本执行结果不符合预期
三、网站不能访问
当有人反馈，网站打不开的时候，可以参考以下几个步骤来进行排查
ps：需要确定的是，直接访问不了，而不是访问的时候页面出错，访问出错请参考第四条
1、要到相应的链接及报错截图，自己打开电脑访问下，是否能正常
2、如果自己能正常访问，使用阿里测或者17测看下，是否正常
3、如果17测等不能正常访问，看下是否是自己加了host所以能正常访问
4、如果17测等有些不能正常访问，需要让对方ping下这个域名是到哪个ip
这个时候需要看该域名是否使用了CDN加速，如果使用了可能是CDN节点有问题
如果ping的ip和自己的电脑一样，那就需要看下对方访问出错的截图，是否是因为cookie头过长等原因导致不能访问
5、通过以上步骤，基本上都能搞定该类问题
四、页面能打开，但是显示不正常
该问题指的是，已经能正常由apache返回数据，但是返回的页面和正常页面不同
1、查看http返回头状态码（firebug或者chrome里，网络中都能很容易看到）
2、500
如果有显示报错，根据报错信息查看哪边出问题即可
如果直接白页，查看apache错误日志中的报错信息即可，或者复制一个临时文件出来，开启报错查看也可
3、404
是否是文件被删了
还是rewrite规则写的有问题，导致没有找到相应文件
也有可能是程序逻辑中判断，比如哪个资源没有了，所以显示的404，需要根据具体的代码逻辑来查找
4、502
一般来说，这是由nginx返回的，说明后端apache的响应时间过久
查看apache日志，找到超时的请求，看下执行了多久
在程序中的响应地方记录log，看是哪段代码超时了
一般来说，都是sql语句导致，查看对应数据库的慢查询sql即可快速找到，然后优化
5、200
页面如果显示错误信息等，根据错误提示调试代码即可
如果没有显示，可以查看apache错误日志
页面排版错误等，直接按F12查看调整或者查看源代码，一般来说html代码有问题，源代码里都会标红等，一眼就能看到
页面错误还有很大一种可能是静态文件缓存：CDN缓存，nginx缓存，浏览器缓存等等需要注意
重要：如果是正式项目中，页面有显示报错信息，务必将报错关闭，不允许在线上开启报错
五、操作失败
页面等能正常访问，但是进行相应操作的时候失败，比如发帖，删帖等
1、自己操作一遍，看下是否能成功
在操作测试的时候，请以真实的数据去测试，并及时删除，不要乱写什么test之类的进行测试
并且在测试完之后，马上将测试数据通过正常操作删除
2、如果自己能成功，其他人失败，看是否有失败的提示信息
比如权限不足，有违禁词等等，根据提示找到为什么失败
3、需要通过修改程序来debug的话，请务必保证在以下两种情况（线上项目）
3.1 项目有测试机
在测试机上进行调试，debug，改完之后，通过svn上线到线上版本
3.2 没有测试机，并且比较紧急的话
将相应的操作文件copy一份出来，然后输出调试，找到问题出在哪
改完之后，copy回去之前，先备份原文件，并diff比对下两个文件，保证没有改了多余的地方
copy覆盖回去之后，必须要进行全面测试，保证之前出问题的情况不会出现，以及正常操作的时候也没问题
不要出现原来的问题解决了，但是带来了新的问题
4、在3满足的情况下，参考以下的debug步骤
第一步就是开启报错，80%的问题，开启报错之后就能知道是什么问题了（或者看错误日志）
不要从头开始看代码，指望着看出来问题，这是不现实的，我很讨厌别人跟我在说，我在看
根据问题状况，定位到哪边出的问题，比如发帖之后，posts表没有插入数据，那就先找到插入posts表的代码在哪
找到这段代码的时候，可以通过var_dump，die看下这段代码是否执行到了，是否执行成功
如果执行不成功，sql的话，直接输出这条sql，放在phpmyadmin里执行看报错
如果没有执行到的话，向前找节点（if else判断等)），看是在哪一步判断导致没有运行到该出
在大段代码，设置debug节点的时候，不要很秀气的每次一行一行的设置，那会疯掉的
最简单的二分法，400行代码，出问题，先在200行左右var_dump，die一次，不行，就100行的地方，再不行，就50行的地方
5、注意事项
有些时候觉得有些bug莫名其妙，总是重现不了，需要考虑下，用户的情况跟你是不一样的
比如账号不同，比如cookie不同，比如当前电脑的时间不同，比如发了一些特殊符号等等都有可能导致用户出问题
之前还出现过一次因为bing爬虫爬取错误链接然后导致缓存出错的问题，这个问题在解决之前也是觉得莫名其妙
六、逻辑错误
比如帖子的回复数不对，用户的积分不对，用户付完钱，结果订单被取消等等
1、这种问题，一般来说都比较麻烦，首先需要知道的是有哪些地方涉及到该逻辑
2、猜测哪些操作可能导致该问题的出现，比如用户的积分多了，是不是该减积分的地方没减，加的时候加多了？
3、针对比较可能出问题的操作点，重新操作，看是否有问题
七、页面性能
该类问题比较大，只列几个粗略的方向
1、查看apache日志，找到最慢的那些请求和平均的请求时间，定位哪些访问有问题
2、找到对应请求，设置时间点，找到慢的程序块
3、具体分析，打印相应的块执行时间，找到问题点
4、查看mysql慢日志是一种比较快能定位到问题，一般来说web项目卡都是数据库层面出了问题
八、定时脚本执行未达到预期
1、确定定时脚本是否有执行
查看定时脚本执行log，是否有
如果没有，则查看下报错log，根据报错log调整
复制要执行的脚本，其他操作都不执行，只输出一个最简单的内容，修改定时脚本的执行时间，每分钟执行，看是否正常
2、脚本有执行，但是结果和预期不同
定时脚本编辑的时候，必须在各个关键节点输出日志
出问题之后，根据自己记录的log日志，查看哪一步跟预期不同
如果之前未记录，则根据问题表象，在相应节点输出相应的log，可以临时执行该定时脚本，查看是哪边出的问题