【文章摘要】
最近，某局点支持人员反映某模块重启之后话单业务量下降，希望研发人员帮助查找问题原因。
本文对该问题原因的查找过程进行了详细的介绍，为相关软件问题的分析及解决提供了有益的参考。
在某局点，有一个软件系统实现话单的生成功能。某天，该局点的现场支持人员发来邮件，反映现场某话单分拣模块重启之后生成的话单的量较之前有大幅度的降低。其邮件中表达的意思有这几个：
(1) 现场人员只是将该模块重启了，并未修改任何配置。
(2) 重启之后模块(图1中的话单分拣模块A)生成的每个话单文件的大小只有重启之前的几十分之一，下降得相当的厉害。
(3) 在现场还部署了另一个相同的话单分拣模块(图1中的话单分拣模块B)，也进行了重启操作，但其生成的话单的量并未下降。
收到邮件之后，我们迅速展开了对问题的排查。在排查问题之前，我们了解了现场各个模块的部署情况，如图1所示。
图1 现场部署图
我们请现场支持人员返回了话单转换模块、话单分拣模块A和话单分拣模块B的日志及相关的话单文件。在寻找具体的原因之前，我们很纳闷的是话单分拣模块A和话单分拣模块B是完全一样的，为什么一个有问题而另一个没有问题？我们基本上排除了话单分拣模块A的程序有问题的可能性，转而寻找其它方面的原因。
话单分拣模块A的程序处理的大致流程如图2所示。
图2 话单分拣模块A的程序处理流程
从图2可以看出，话单分拣模块A要将从源文件目录中扫描到的文件中的记录进行一定的筛选，然后将满足条件的记录按照特定算法写入结果文件中。图1中的最终话单A即是结果文件。
为了准确地定位问题原因，我们恢复了现场的环境，即采用与现场一样的程序版本、配置和数据库环境。我们根据现场返回的日志，选取了特定时段的源话单文件来运行，发现生成的最终话单与现场生成的最终话单是完全一样的。这进一步排除了程序有问题的可能性。
那么，问题原因到底是什么呢？
既然程序没有问题，那是不是源话单中满足分拣条件的记录本来就变少了呢？我们详细查看了配置文件，里面涉及到分拣条件的配置如下：
FieldFilter=(11:4),(11:7),(11:8),(11:9),(11:10),(11:11)
其意思是只有源话单的每条记录的第11个字段的值等于4，7，8，9，10，11时，该条记录才能够被挑出来生成结果话单，否则会被过滤掉。
我们在重启之后的源话单文件中查询了一番，发现第11个字段的值等于4，7，8，9，10，11的记录确实很少。“巧妇难为无米之炊”，既然源头都少了，那么结果变少就不足为奇了。
我们又在重启之前的源话单文件中查询了一番，发现第11个字段的值等于4，7，9，10，11的记录数与重启之后对应的记录数相当，但第11个字段的值等于8的记录数明显比重启之后该字段为8的记录数多很多。难道这就是话单业务量下降的原因？
我们马上联系现场支持人员查看第11个字段的值等于8的记录的产生过程，发现确实是该过程异常导致源话单中满足筛选条件的话单记录减少，最终导致了整个话单业务量的下降。
现场进行相应的操作之后，第11个字段的值等于8的记录又出现了，话单业务量也就逐渐达到了重启模块之前的水平。
通过本次问题排查，我们总结出的经验有以下几个：
(1) 系统出问题的地方并不限于最直观表现出现象的模块。当我们发现“认为有问题”的模块无问题时，应该着手排查其上游模块，直到查明问题的原因为止。
(2) 软件是程序、文档和数据的集合。在排查问题的过程中，我们不光要查看程序代码，对于程序用到的配置文件等，也要细细查看。
(3) 为了排查程序问题，我们要尽量掌握比较全面的信息(包括程序日志、数据库信息等)，这样有利于复现问题，最终定位问题。
吴军老师在《文明之光》一书中说：“办法总比问题多”。确实，只要我们善于总结，善于分析，那么任何程序问题都是可以解决的。
(本人微博：http://weibo.com/zhouzxi?topnav=1&wvr=5，微信号：245924426，欢迎关注！)
