工作中的十大棘手难题

最近一两年的时候，写代码的时间逐渐减少，除了负责几个小系统之外，更多的时间用在解决客户问题上。接触的问题多了，发现真的是什么样的问题都有可能发现在客户环境上，当然，这不能一味地说系统的问题。系统确实存在不足的地方，但是，有时候环境、客户人为操作等很多因素，都会带来或小或大的问题。下面列举一下接触客户问题以来，碰到的十大棘手问题。呵呵，说是棘手，也不一定很棘手的，但不少问题要解决起来肯定是有些麻烦的。

1、偶尔出现的

偶尔再现的问题，也就是不稳定重现，有时会有问题，有时没问题。这种问题真的很让人纠结，所以把它放在第一位。此类问题可能不一定是很难，但是却很考验你的耐性、注意力及解决问题时所考虑到的宽度和广度。举一个例子，有客户说，服务器从其它机器上取回来的数据，有时候会少几条，有时却不会少。根据这种场景，如果有客户在使用你的系统，也报了这样的问题，应该怎样处理呢？

2、关于某个数是怎么计算出来的

这个可能不算什么验证，不过有时候却很耗时。如果这个模块是自己开发的，具体计算公式、逻辑自己都比较清楚的，那这个就不算问题，也不用花多少时间。

3、与其它工具对比的

某一次，客户问我，怎么你系统算出来的内存使用率与Linux上自带的工具不一样呢？与第二条类似，需要对系统使用的计算规则及其它第三方系统都比较熟悉。还有一次，客户问我为什么Linux Cache不计入到已使用内存中， 这个由于客户不熟悉Linux系统，如果自己也不熟悉，那就不知道怎么解释了。

4、系统集成方面的

与第三方系统集成时，经常会碰到一些麻烦的问题，比如数据丢失，或集成时工作不正常之类。给我印象最深的就是SSO（单点登录）的功能了，与AD做了集成，有时候在客户环境就会报AD用户不能正常登录。有时候客户在AD服务器那边修改了数据，导致存储在我们系统这边的数据出现重复记录。有时还会碰到什么跨域访问之类的问题或需求。

5、协议方面的

通过某协议跟目标机器建立连接，会出现连接失败导致不能收集数据，连接不稳定，个别查询出问题，增加连接数容易导致连接中断等各种各样的问题。比如通过WMI容易出现占用资源过多的情况，连接多增多的情况会出现严重性能问题。再比如WinRM参数比较多，有些客户喜欢搞搞研究的，不小心改了某个参数，导致数据不能收集，但客户又没那么老实或是想不起来改了什么，只好下功夫去慢慢排查了。协议方面的知道如果经常使用还好，如果有一段时间不使用，下一次再使用，感觉就什么都记不起来了那样。

6、是否会对其它模块造成影响的

这类型的问题说难倒没有那么难，但还是有些麻烦。比如，如果客户想在平台删除某个子系统的一条对象，但是又担心会影响到历史数据或是其它数据，来跟你确认能不能删除，会不会带来其它不良影响的。由于子系统不是你负责的，你可能也不那么清楚里面的逻辑，这种情况下即使你知道不会对其它模块或其它数据造成影响的，也还是打上十二分精神，小心谨慎，因为，如果连同其它数据也一起被删除了，那后果会不会有点严重呢，毕竟客户有说明了。当然，即使客户没特别说明，我们也是要万分谨慎的。

7、客户安全规定的

这个也不算会很难的，但是这里不得不说的是，有些客户的内部规定实在很强大啊。比如说，有些客户内部规定，重启个服务，拿个系统日志，做个什么参数更改之类的，都要走审批流程，这样一来一回，一个星期过去了，才顺利拿到系统日志，最后不得不说，时间都去那里了。还有些客户的敏感部门，安全意识实在太强大了，不给你检查系统的，系统日志也不直接提供给你，他们可能会把一些信息，如机器名称、IP等他们认为敏感的数据，清除之后，再把这样的日志给你，这样的日志，分析起来无形中增加了困难。

8、跟客户环境相关的

这个不用解释，相信很多人都会遇到，就是这样的问题只有客户环境才有，咱们是无法重现的。最近一个客户报上一个问题，说有300多个子系统连接上服务器，就经常出现子系统连接中断的情况，导致有些数据不能正常收集。哎，这种情况我们可以花费了好大的精力，搭建环境、模块场景来测试，结果就是不能重现客户的问题。没办法，把所有相关的人叫在一起，对着客户的日志，一条一条地分析，是不是有资源占用了，是不是LOCK有问题啊。。。这样的问题，给你碰上一个你就知道什么感受了。

9、前后两个版本表现不一致的

这类型的也很容易理解，就是新版本和旧版本在某些功能上的表现会有些差异。当然，如果这种差异确实是个问题，而且客户不接受的，那还是自己的事情没做好，系统兼容性没做好，那就老老实实地给客户解决问题吧。给我印象最深的就是，我手上的一个生成报表的功能，客户一直在使用旧版本了，后来为了升级JDK，就想着升级我们的报表工具，升级完成后，对比旧系统和新系统生成的报表，发现在新系统上生成的报表，有一列某些内容向右移动了几个像素的位置，这时候如果在那个地方显示的内容多了一些，就会出现内容重叠的问题，大部分情况是没问题的，这个问题真不容易发现，在旧系统上就不存在这个问题，所以还是我们的工作没做好。这个问题，我可以连接花了一周的时间，查找问题，对比代码，最后终于给我找出来了，毕竟不是所有东西都是自己负责的，需要些时间是处理这个问题也是正常的。

10、有需要开网络会议却又在“相反”时区的

虽然这种情况不多，但有时候时间上确实有些不好安排。有些客户在白天12点时，我们是晚上1点，碰到这样的客户要跟我们开会时，只好减少睡眠了。有一次，好不容易协调好时间，下等6点半开会的，结果网络慢得要命，远程操作客户机子时，点击一下鼠标都要等上好几秒才有反应，本来计划要开一个小时的会议，结果给拖到了快9点钟，下次吸取了教训，先吃饭饭再开会。还有一次，本来说是早上6点开会的，结果改了时间，提前半个小时，发了邮件我没看到，技术支持和其它区域的开会就跟客户在开着，6点的时候闹钟一叫，马上起来，结果发现会议都差不多开会了。。。

除了这类型的问题，当然还有其它各种各样的问题，比如内存溢出、数据库数据过多等问题，这些问题虽然也很难解决，但是我觉得不少这问题，都会有一条主线，顺着这条主线，从上到少，解决起来有种水到渠成的感觉，有个别的这种问题解决起来还很轻松。除了以上列举的问题，我相信，以后总会有其它形形色色的问题等着我，当然，我们开发的也要主动出击，测试的也要加把劲，多覆盖各种各样的场景，降低问题发生在客户的可能性，这样，才是解决问题的根本之道，这样，客户使用起来也比较轻松，也就会越来越喜欢使用我们的产品。