转载

技术问题解决01(4.13)

对于一个技术人员，对于各类技术难点一定要有一种迎难而上的积极心态，真正有很辣手的问题来了一个技术人员应该保持足够的亢奋，要知道任何技术难题的解决，往往都是你技能提升的关键点和突破。

抛开硬件故障不谈，一个正常运行的软件系统往往并不会突然出现故障，一个故障的出现往往都伴随着你做了各种操作，或软件系统收到了异常输入。比如我们常说的一个软件系统重新进行了变更的部署，因为性能优化的原因进行了相关参数的修改和调整，或者说一个软件系统接收到类似大数据，大并发或其它不合常理的异常输入。这些往往才是导致软件系统出现故障的真正原因。

基于以上假设，我们实际排查问题的方式和逻辑就应该很清晰。如果是我们自身做了相关的变更或调整，那么首先就要考虑对变更进行回退看能否恢复，如果能够恢复那问题就能精确定位到所做的变更上。如果是软件系统的输入有问题，那么我们首先要考虑的就是采用同样的输入是否能够重现问题，如果能够重现，那问题定位和具体的Debug就相对简单了。

异常日志记录是我们分析和诊断问题的基础，但是仅仅采用异常日志关键字进行解决问题方法的搜索往往很难快速的进行问题定位，而这里面最重要的还是要搞清楚问题的发生场景，对应的中间件，数据库环境究竟是如何的？我们当时做的操作过程是如何的？从这些场景里面提取关键字辅助信息。

异常关键字信息 + 场景辅助关键字信息 =》快速精准的定位问题。

对于接口问题的定位，我们始终有一个关键方法，就是确定问题的边界，而确定问题的边界很重要的又是二分。比如我们对于ESB暴露发的接口服务出现异常，往往我们最先要判断的就是业务系统提供的原始服务是否有异常，如果原始服务本身有异常，那么就先解决原始服务的问题。如果原始服务本身OK，那么说明问题出在在ESB端。

其次，如果业务系统调用ESB接口服务有异常，我们首先要做的是模拟业务系统，比如采用SOAPUI工具去调用接口服务，如果调用正常，那么说明问题出在消费端代码程序上。如果SOAPUI工具调用也出现异常，那么说明问题出在ESB总线或原始业务系统提供的服务上面。

另外我们在解决问题的时候一定要考虑问题的范围，同时由范围来考虑问题可能出现点。比如ESB总线运行的服务，是所有服务都有问题，还是部分服务有问题，如果是部分服务那又要分析这些服务具备哪些共性特征。比如都是JMS类服务，还是路由服务，还是都是查询类服务出现问题。通过这种不断的范围缩小，以方便我们精确的去定位问题。比如仅仅只是JMS消息出现问题，那么我们就应该去检查JMS消息中间件的运行情况和配置，而不是整个ESB总线都要去检查。包括如果已经分析出来是JMS消息有问题，那么还可以进一步分析是所有JMS消息都有问题，还是哪一类有问题，那么有问题的这类JMS消息和没有问题的一类究竟异同点在哪里？所有的不同点往往就是最终问题的产生根源点。

一个问题暴露到前端往往就是简单的404,500异常或错误，但是在后端往往经过了多层调用和处理，或者由底层问题不断的向上抛出导致了最终问题表象。那么这个时候往往最难的是在通过日志分析搞清楚问题的产生链条，只有理清了问题产生链条往往才容易追溯到具体的问题产生根源点，彻底解决问题。

原文 http://blog.sina.com.cn/s/blog_493a84550102xc63.html

正文到此结束