解决问题的能力取决于解决问题的态度，思路和方法。态度上对问题要保持敏感性，即使是对轻微的问题。再者心态上要基于沟通和理解的态度来解决问题，最后因为问题牵涉多方利益，所以对待问题也要保持谨慎的态度。在解决问题的思路和方法上，要多看日志，熟悉代码；再者要模块测试和断点分析；最后要对错误信息进行理解和搜索，这个主要基于解决问题的经验以及对业务系统的熟悉程度。对于程序员解决问题的相关能力分析可以参见程序员的核心竞争力是什么？ http://www.zhihu.com/question/27180582
遇到问题后，平庸的程序员的解决效率，和优秀程序员相比就会有天壤之别。程序员解决问题的解决效率，不外乎对bug的分析、定位，以及 思考。
1. 了解症状：首先出bug了，有症状，症状表现为push没有下发，或者下发文案或者链接问题，或者没有按时下发，确定症状发生的时间，涉及的业务场景，涉及用户（when，where，who，what）
2. 看异常日志及其上下文：然后看日志，首先看此时的业务日志是否有error和php日志等错误日志。
3. 【关键】分析异常日志定位问题代码，问题数据：如果有日志，分析什么场景下会打印这条日志。
(1) 如果是业务日志，搜索全局业务代码，搜索框架代码，如果涉及底层的开源的，将日志google和百度之，或者咨询相关人士。
(2) 找到该条日志所在路径，定位出问题的代码模块，这样可以缩小搜索代码的范围，搜索相应的代码（业务代码，框架代码，开源代码）定位代码中异常日志打印位置，并且可以看看问题时间上下都打印了哪些日志，根据问题代码跟踪日志的上下文。
(3) 找到问题代码之后，从下往上回溯，分析各种引起异常的可能。
(4) 某一个线上bug出现可能跟刚上线的代码相关，跟业务变更相关，跟异常数据相关，跟大量处理请求相关，跟大数据相关。
所以一旦出bug，分析上述相关因素是否会引起该异常（最近是否有代码变更，是否上游有业务变更，是否有大量请求，是否有异常数据等）。如果没有日志，尽量将问题进行复现。（没日志或者问题不可复现的可能性基本都比较低）
4. 复现问题：如果问题能够复现，则在开发机上根据猜想打日志，根据日志找到问题的症结—问题复现的关键在于找到问题数据
如果是系统问题，比如cpu使用率过高，内存过高，队列过长等
cpu使用率过高，首先top定位是哪个程序或者代码引起的问题，再看看当时的业务数据。
如果内存过高，也是使用top定位问题代码，同时看看相应的业务数据。
分析程序是io密集还是cpu密集，若是cpu密集看load和进程调度（上下文切换数，中断数等），io密集看磁盘io和网卡流量。内存不足的时候看swap换入换出，磁盘不足看磁盘空间。
如果队列过长，要么是消耗慢，要么是写入快所以才产生堆积。消耗慢或者写入的时候会不会打日志，若会看看日志。写入快可以看看上游写入数据的增长情况，消耗慢看看下游消耗数据的速度，接入下游服务或者下游服务是否出现什么问题。
问题排查其实就是一个侦探破案的过程
（1）报警：（业务投诉，系统监控）
（2）找线索：确定案发时间，地点，涉及人物和事件（找寻异常日志（error，php的log等），异常日志发生时间，异常日志上下文，问题代码上下文，业务监控数据和系统监控数据，上线变更记录等）
（3）侦探推理：根据蛛丝马迹（异常日志上下文），按照常规逻辑（代码逻辑）推理出什么情况下会出现如此场景（会打印异常日志），最后发现证据找到嫌疑犯（当时的业务数据或系统参数）
（4）还原现场：通过审判嫌疑犯来还原作案过程，逐步验明真凶从而侦破案件(通过处理异常业务数据，我们可以复现问题，还原现场，从而验证我们的猜想)
一些类比：
- –线索：日志
- –常规逻辑：代码
- –嫌疑犯或者凶手：异常业务数据，配置参数等
这个过程中保留现场非常重要。如果有摄像头会让破案更好，同理如果保有各种日志对排查问题会非常有帮助（业务日志，系统日志，业务和系统自动监控）。破案者需要善于逻辑推理，同时对人性和人类行为动机有一定的认识，这样才能理解凶手的作案动机。比如一般谋杀分为：情杀，仇杀，财杀等。同理，排查问题首先要对代码要非常熟悉，其次要注意打印一些日志来保存现场，同时要完善监控。若是系统问题，有时候需要对os，计算机网络，redis的系统基本机制有所了解。
综合案例分析
（问题排查结合具体代码，日志，业务数据），因为涉及到具体工作，所以简略之
- 报警：业务监控有一个数据包没有处理，同时日志监控报有php fatal的log
- 找线索：找到php的fatal log，显示在代码某处程序内存用完，程序内存不足。根据代码提示确定问题代码。
- 侦查：问题代码处用到了数组存储用户信息，从下往上回溯看，除非用户信息超过了程序的内存。但是一般用户信息都不会超过程序内存，显然是某个用户的用户信息异常。而且别的数据包都没丢弃，为什么偏偏这个数据包被丢弃了？于是看看到底是哪一个数据包被丢弃。并看看是运行到哪的时候程序打印出php的fatal的log，从而定位出问题数据包。
- 还原现场：将问题数据包在测试机上采用与线上同样的代码进行处理，以使问题复现，如果问题复现了，就逐步打上日志跟踪，看具体出错的环节是哪，最后定位到具体的问题uid，原来这个用户信息有异常，删除这个用户的废弃数据后，就不会再出现该问题。