核心摘要

今天谈一下对于IT人员面对技术类分析和解决的一些思路和实践总结，在之前也谈到过，对于IT人员在后期不是简单的新业务功能的设计和开发能力，还要有问题分析和解决能力。

这类问题分析和解决本身又包括了两个方面内容。

• 其一是IT系统运行类问题和故障的分析和解决；
• 其二是面对复杂业务问题时候将其转化为技术解决方案能力。

IT人员应该关注自己思维能力的提升，这个思维能力实际上包括了分析和认知事物，独立的问题分析和解决两个层面的内容。

对于第一个层面在IT领域更多的就是架构设计的能力，将现实的业务需求和场景转化为抽象的架构设计语言和架构模型的能力。而第二个层面在IT领域里面即是面对问题或故障的时候进行问题分析诊断，假设和验证，快速解决的能力。

而对我们当前很多IT人员来说，实际上两个方面的能力都欠缺，既不能独立的进行整体架构设计，对负责的业务进行自顶向下，分而治之的建模和设计；也不能在面对生产环境关键故障或问题的时候快速定位，并找到根源快速解决。而是将自己大量的时间花费在重复的事务性工作上，花费在对各类新技术的狂热追求上。

不反对保持对新技术的学习兴趣，但是任何新技术，如果你实际的工作环境没有实践的机会，那么大量新技术下应该出现的类似性能，安全，可靠性等问题你都无法真正得到实践验证和解决。在这种情况下对新技术也只能够停留在理论阶段而无太大意义。

技术问题解决的关键点

我写过不少的关于技术问题分析和诊断的文章，这些问题基本也是来源于真实的项目实践，即使到现在有些问题也没有完全得到定位和最终解决，包括我们找了Oracle专家和顾问，也不是说马上就能够满足我们解决掉该技术问题。

简单来说，如果一个技术问题，你能够直接快速的根据异常或问题关键字在网上搜索到相关的答案，这种问题都谈不是真正有挑战的技术问题。

对于技术问题的解决，基于前面实践的问题定位，分析和解决的思路，我还是想谈下在解决技术问题中的一些关键点和思考逻辑方面的内容。

个人前期大量实践经验的积累，这个点相当重要，任何知识库，搜索都代替不了个人已有的知识经验积累。
1、为什么说工作经验很值钱？

往往就是你在一个专业领域有大量实践积累，大量问题分析解决经验积累。这些经验可以帮助你在遇到问题的时候快速地对问题进行预判和定位，包括提出最可能的假设路径。

当前解决问题，很多都是非结构化解决问题方法，即是优先提出最可能的假设，然后再去验证假设是否能够真正解决问题。那么有经验的人往往就最容易提出最可能的假设路径，而减少对各种不可能弯路的尝试。

一个问题本身有A到E五个独立假设路径，而最可能路径是A，你解决问题速度慢的原因往往就是你最后才假设和尝试到A路径并解决问题，而有经验的人往往一开始就选择了假设A进行验证。

要积累这种经验，必须在问题解决后及时复盘，将其抽象为经验和方法论。问题定位的重点就是缩小范围和确定边界。

一个问题出现了最重要的就是快速的定位。比如一个业务系统查询故障，要快速的定位是基础设施资源的问题，还是数据库和中间件的问题，还是说程序的问题。如果是程序的问题，又需要马上定位到究竟是前端的问题，还是逻辑层的问题或数据库的问题。只有快速的确定边界和定位问题，往往才能够有针对性的去解决问题。任何问题的定位都是追溯到引发问题的根源，而不是解决问题的表象，类似头痛医头脚痛医脚。

如何缩小范围和快速的确定边界：

 比如我们假设一个最简单的场景：问题的产生经历了A-》B的两个过程。那么如何快速的确定问题是在A阶段产生的还是在B阶段产生的呢？对于这个问题，我们有如下的问题定位方法和思路可以参考和借鉴：

• 替换法：比如将A替换为A1，如果问题消失，那么说明问题出在A阶段。
• 断点法：在A和B之间设置断点监控输出，判断A输出是否正常。
• 假设法：假设A阶段有问题，对A阶段的参数进行调整，观察问题是否解决。

当然还有其他很多的问题定位方法，但是对于所有问题定位和确定边界的方法中，最有效的仍然是类似于快速查找中的二分法，通过二分法可以快速的帮助我们缩小范围和定位问题。

我们进一步对上面逻辑举例说明，比如一个软件应用出现Bug的场景，如下图：

可以看到看到要分析和定位Bug为何困难？

引入问题既可能是我们的输入出现错误，我们面对的软硬件环境运行状态有问题，也可能是我们实际程序处理构成出现问题。即使你定位到程序处理问题，那么还可能是逻辑层，数据访问层或数据库多个点导致的问题。

2、善用搜索引擎

要明白，任何你遇到过的技术问题，往往都有前人遇到过，踩过坑，并总结和分享到互联网上面。因此善用互联网和搜索引擎，进行基于问题关键字的技术检索仍然是解决技术问题的关键途径。即使搜索引擎没有帮助我们解决最终的问题，往往也会帮助我们在搜索的过程中学习与该技术问题相关的很多知识。

要搜索，一个重点就是选择搜索的关键字，对于关键字的选择一次没有选择准确自己就要多次尝试和迭代，知道能够准确的描述问题为止，同时在搜索的过程中搜索的答案往往也可以帮助你进一步的细化关键字。

比如对于系统运行故障或问题，对于关键字的描述，应该包括：

• 从数据库，中间件和业务系统错误日志中提取关键字信息。
• 从你产生问题的环境，背景，场景中增加缩小检索范围的关键字信息。
• 从搜索到的网页中挖掘更加有意义的描述类似问题的关键字信息。

同时对于搜索而言，特别是技术问题的搜索，有官方知识库的要优先搜索官方的知识库，比如对于Oracle产品相关的技术问题，我们也会先搜索Oracle官方的Support网站，同时搜索类似StackOverFlow网站，这些网站往往有更加全部的技术问题解决文章。

搜索技术文章，国外的技术网站相对来说更加全面，而对于百度这块相对弱，很多国外技术网站内容都搜索不到，可以尝试Google或Bing搜索。

技术问题解决和复盘

在前期我们实施Oracle SOA项目的时候，遇到了将服务封装和注册接入到OSB后，客户端消费和调用服务出现消息报文内容被截断的问题。

由于该问题出现概率不高，并且消费端系统本身有重试机制，也暂时不影响到具体的OSB服务运行和使用。虽然到现在为止，造成该问题的原因究竟是客户端服务器配置，负载均衡，网络，报文本身，OSB套件本身的Bug缺陷等哪方面还没有最终确认，但是整个问题排查和分析过程还是有意义的。

在问题排查和分析过程中，对于各类超时时间的含义，OSB的一些关键配置，报文解析，Http Post报文发送长短连接，Tomcat的一些配置都进行了了解，同时通过该问题的分析，也发现了在技术问题分析过程中的一些问题，供后面在分析问题中借鉴和参考。

1、确定问题边界始终是最重要的。

客户端发送报文到服务器端接收报文，当前现象是客户端Log日志报文是完整的，而OSB上Log的日志报文不完整，那么究竟是客户端，服务端，还是网络传输过程中出现的问题？

这个问题边界的确定相当重要。

实际上在几天的问题分析和排查中对于问题边界一直没有最终确认，导致问题也一直没有很肯定的得到定位究竟在哪里，也导致最终问题没有得到明确的解决和排查。

比如上面说的消息报文不完整这个问题，要确定边界实际上常规思路也就两种，一种就是修改程序代码进行更加详细的日志记录，另外一种就是增加Trace监控。比如该问题可以在客户端进行Http或TCP Trace，同时在服务器端也进行Http TCP Trace，通过两边的Trace信息才能够最终确定问题的边界在哪里。

但是在生产环境很难这样去做，一个是接口服务调用并发量大导致Trace日志的量也巨大，而且不止这一个接口服务在调用，一个是协调的需要配合的资源也太多，很难去联合排查和跟踪。

2、问题复现很重要

故障的复现是我们分析和定位问题的一个基础，问题如果随机偶然发生往往是最难解决的。即当你面对问题的时候，你需要定位，那就需要问题能够复现才方便不断的去Debug或Trace。

在该问题的解决过程中，由于该异常是偶然出现，不定时而且是没有规律出现，这个也给我们排查问题造成了很大的麻烦。虽然在问题排查过程中，我将出现问题的异常日志，和前后正常的实例都进行了导出分析，对出现问题的服务器Server节点，调用方，调用时间段都进行了分析，但是没有明显的发现出现问题的规律究竟在哪里。

同时该问题具有很高的随机性，往往是第一次调用不成功，但是同样的报文在第二次或第三次就调用成功，同时每次对于报文的截断长度都不相同。这导致很难分析具体什么场景下调用不成功。即由于问题不能在特定的输入条件下重现，导致我们很难对问题进行进一步的分析和定位，也导致我们很难去进行特定的跟踪和边界确定。同时也很难在测试环境对该问题进行进一步的分析，和各种参数条件修改后的测试和验证。以上都导致问题很难快速定位和分析，只能够大范围的场景+异常的关键字搜索，然后搜索到相关的可能解决方案后，一个个的去尝试看是否能够解决。

但是，这种方式带来巨大的问题，即：由于测试环境问题不复现，我们无法在测试环境做这个事情。那么搜索到的解决方案验证只能够在生产环境做，但是生产环境根据规定是绝对不允许随意去修改配置和调整参数的。这也正是我们看到很多大型IT项目上线，往往会预留3个月左右的试运行期间，在试运行期间生产环境的日常运维和配置修改不会严格受控管理，方便及时分析和解决问题。

3、网上搜索很难搜索到完全一致的异常场景

由于项目采用的Oracle SOA Suite 12c套件产品，当前在国内并没有大范围的应用，如果用百度搜索基本搜索不到有用信息，改用Google或Bing很多信息也无法搜索到。

因此在该问题的排查过程中，我们基本都Oracle Support网站进行了所有相关知识点的排查，同时选择各类关键字进行搜索引擎的搜索，其中包括了:

• Weblogic Tomcat Post Timeout KeepAliveOSB-
• 长连接 超时 OSB-382030
• Failed to parse XML text等

但是并没有搜索到完全一致的场景。

对于一个最相似的关于Failed to parse XML document的场景，我们进行了相关的调整，即将KeepAlive设置为False，同时对Post Timeout设置为120秒，但是仍然出现在120秒超时时间到达后任何没有Post到完整的请求而导致超时的问题。
由于无法搜索到完全类似的场景，也导致我们很难根据网上给出的方法进行进一步测试和验证。而该问题对于Oracle顾问也只能给出进行Tcp Trace的无用建议。

4、关键基础技术知识缺乏，导致问题分析和提出假设不合理

在原来问题的分析和解决中，由于搜索引擎往往会给出完全类似的场景，我们只需要根据搜索引擎给出的排查思路对问题进行排查即可。因此解决起来效率很高，对于具体底层原理性的内容我们并不需要掌握和了解，只需要能够选择合适的关键字，通过搜索引擎搜索到最合适的内容然后进行排查即可。

但是这次问题，特殊点就在于搜索引擎根本无法给出完全类似的文章。这就导致需要基于问题提出各种合理的假设，并对假设进行逐一验证。

那么如何提出合理的假设？

这里就涉及到对于TCP底层协议，各个超时值的含义和原理，Tomcat Server的参数配置，OSB代理服务的解析过程，Weblogic的关键参数配置和含义，负载均衡策略，乃至Docker容器和IP映射等很多内容都有技术积累才可能提出最合理的思路。

比如在排查过程中，我会想到是否需要将Tomcat 的MaxPostSize值调大的假设，但是该异常是Tomcat向Weblogic Server进行Post请求发送数据，对于Tomcat 的MaxPostSize根本不会影响到这个Post请求，而只有Weblogic上的Post Size才会有影响。这个假设本身就不合理。而要快速的判断这些假设不合理，你就必须提前有这些关键的基础技术知识和背景积累。

包括对于Keep Alive长连接，Keep Alive的Time out超时时间设置是否会对该服务异常调用操作影响，实际上由于对Keep Alive长连接和各类Timeout的具体含义理解的并不深入，也使得很难判定究竟是否有影响，也只能是注意尝试去排除可能性，这些也都导致了很难快速的定位出问题根源究竟在哪里。

5、涉及到外围干系人协同时问题解决困难

这个也是解决服务接口问题的一个关键影响。对于接口服务运行问题，往往涉及到业务系统消费方，业务系统提供方，OSB服务总线，网络，负载均衡设备等多个相关因素和厂商。

对于一个问题的排查往往需要协调多方的资源在约定的时间相互配合才能够完成，这些都直接导致排查难度很大，很难依靠个人一方力量就完成。

在原来类似大项目实施过程中，也经常会遇到这些接口问题的分析和排查，往往也都是问题造成严重影响后，各方才会真正重视该问题，并各自协调资源形成联合的问题排查团队进行问题分析和排查，最终才能够解决问题。

虽然截止现在问题没有得到最终解决，但是整个分析过程仍然有意义。

以上是对于技术类问题分析和解决的一些思考和总结，供大家参考。

觉得本文有用，请转发、点赞或点击“在看”聚焦技术与人文，分享干货，共同成长更多内容请关注“数据与人”