聊技术，不止于技术

“现场软件有问题...”

“在家的时候还是好的....”

不知道大家在日常工作中有没有遇到过类似上述的对话场景，事情发生的流程基本是这样的：从客户那儿收到需求，在家里完成开发，然后发往现场升级，最后现场崩溃……

对于做TO B业务的公司技术人员，遭遇这样的问题想必是家常便饭了。

所以今天作者就结合个人的工作经历，聊一聊现场软件定位的那些事儿。

1

现场的人员技术不行吗？

“在家里都测试过是好的，怎么到现场就不行了，肯定是你哪里操作有问题。”

在接到现场的问题报告后，可能大部分工程师都会如此回复。软件更新包发过去了，升级手册也发过去了，还会出现问题，肯定是现场人员没有按照手册正确操作。

但事实真是如此吗?

别的暂且不说，在接到问题报告的时候，没有第一时间询问问题发生的现象，就盲目猜测是现场人员的操作问题，这是不讲科学的。

很多次事实也证明了并不是现场人员的操作错误，或者说技术不行。

对待问题，我们要讲科学。

2

在家里的时候真的就是好的吗？

其实软件有问题很正常，是太正常了。

在接到问题报告的电话后，其实我们应该先停下来想一想，想一想是不是软件在家里的时候真的没问题，各个场景是否都考虑清楚了，都测试过了吗？

是不是因为改动很小，自信没有问题所以没有测试就发过去了，还是因为时间紧，问题没有考虑全面，有遗漏的场景？

很多的案例也证明了，其实软件在家里的时候就是有问题的。

所以工程师不能凭主观臆断回答现场，而是要先考虑一下是不是自己这边的问题。

3

解决问题的第一步是定义问题。

上面这句话也可以理解为，解决问题的第一步是知道要解决的问题是什么。

在工作中，经常会遇到这样的工程师，在还没有弄清楚现场问题是什么的情况下，就开始给出解决方案了，什么调大内存、修改配置、重启软件，最后忙活了一大圈，问题还是没有解决，最后现场人员也逐渐失去了耐心...

在给出具体解决方案之前，起码要清楚需要解决的问题是什么。

其实，软件的问题定义比生活中其他问题的定义要简单的多，软件的问题无非是程序卡死、抛出异常堆栈、数据没收到、数据没发出去等。而在生活中，让你找到女朋友为什么生气的问题定义，可比软件难得多了。

所以，在接到问题报告后，要先静下心来听听现场人员的反馈，一起找出问题是什么。

4

解决问题的第二步是描述问题。

在知道了问题是软件卡死或者抛出异常堆栈，又或是其他什么情况后，接下来我们就需要现场人员详细地描述问题，越详细越好。

这里可能需要工程师的引导，通过和现场人员的进一步沟通，我们需要了解软件的具体版本问题出现时的现象、配置项的信息、异常堆栈的信息、现场网络的情况、计算机内存的情况及问题的复现步骤等等。

通过上述有效沟通，我相信绝大部分工程师心里都有点底了，也能够大概猜测出问题的原因了。

5

能复现的问题都不是问题。

通过上述沟通得到的信息，然后能在家里稳定复现的问题都不是问题。

有了问题定义、问题描述，而且能稳定复现问题，我们离解决问题还远吗?

6

一定要测试。

软件的任何改动，哪怕只是很小的改动，一定要测试。

此外，所有已发现的问题和已解决的问题，都需要加入到回归测试中进行回归。

并且测试一定要尽量自动化，很简单，因为没人想反复手动测试。

写在最后

因为在个人的工作经历中，遇到过很多软件现场定位的问题，所以今天就这个话题聊了聊。

在遇到问题时，先不要认为是别人的问题，要讲科学。

然后想想是不是自己有些地方没有考虑清楚。

其次弄清楚问题的定义，引导现场人员详细地描述问题。

解决问题后一定要进行测试，测试尽量自动化。

现在可以把升级后的软件发给现场了，不知道这次会不会崩溃……

没事，大不了就再来一遍，心态一定要好。

完~

聊技术，不止于技术。

在这里我会分享技术文章、管理知识以及个人的思想感悟，欢迎点击关注。

ITPub博客

软件现场问题定位的那些事儿

最新文章