几次处理客户问题小感

今天是3.15， 最近处理阿里旺旺的一些客户问题有了些感受，一直想记录一下，难得今天有写东西的兴致，就落笔谈谈处理阿里旺旺消费者问题的一些经验吧。

 我们的旺旺已经有了崩溃处理系统，当阿里旺旺客户端崩溃时，可以将现场的崩溃信息发送到服务器用来事后定位问题，但还是会有一些功能性的非崩溃的问题会出现。这个时候，客户一般通过会先找到客服，然后客服再找工程师来解决问题。

确定现场

旺旺是什么版本的？操作系统是什么版本的？出问题时使用的是哪个网站的什么帐号？进行了哪些操作？有没有一些其他异常情况？出错时的日志拿回来了没有？在解决问题之前必须要能看到或者收集现场，否则花力气去解决问题都是没有意义的。

这个步骤一般有经验的客服同事都会替我们工程师事先收集好，工程师也可以请客服同事向客户帮忙收集一些额外信息。接下来工程师要做的就是根据这些现场来做一些准备。

详细准备

客户一般会允许工程师远程到她/他的机器上一到两次来定位问题，因此在远程前做好详细的准备是非常重要的。机会可能只有一次！

我认为的详细准备是：日志的分析, 用来做验证的测试，验证通过后对应的解决方案， 创造环境自己先验证以及准备相关工具来帮助定位问题等。

首先我要说说日志的重要性。

最近组内做的代码review我提到最多的就是出错的日志没有打。我发现很多工程师都不太爱写出错日志信息，有些时候遇到一个错误，直接return掉就完事了，包括我自己。以前一直认为太多的注释对代码美观影响太大，又或代码某些地方基本上不太可能出现错误，或者出现错误程序运行下去也没有用了，于是乎就干脆不写。据几次我和同事处理客户问题的经验来看，有几次便是因为出错时的日志信息不够丰富，非常难定位问题，最后花了相当大的代价。 对于商业程序，日志的确可以不用过多，但是该加的地方一定要加，譬如出错，重要的流程记录等等，严格一点的， 日志也可以review一下。

我们的旺旺平台运用了大量的COM技术，由于其复杂和特殊，HRESULT的返回值真可以说是性命攸关。任何一个hr的值都该判断一下，出错的地方更要加上日志等等。

准备在客户机器上做验证的测试方案。

有些时候我们分析完了日志和现场，有了几个怀疑点。根据这些怀疑点，我们可以准备做几个测试方案，用来验证我们的判断。同时准备验证通过后对应的解决方案，毕竟解决当前这个客户的当前这个问题是最重要的！因此这个步骤一定要详细准备。

创造环境自己预先验证模拟

准备好解决方案后，我一般会在自己设置的环境上先做一下验证，譬如用户的问题操作系统是xp sp3,那么可以先在一个sp3的系统上先验证一下。就算没有合适的环境，熟悉一下操作步骤，这样等真正远程到客户机器上去时也能不慌不忙，心中有数。

请别的同事review一下方案

这点也很关键，最近有一次我事先详细准备了测试方案以及对应的解决办法，但是还是由于个人粗心，在修改代码编译出客户能用的组件时，有个地方没有注意细节，导致第一次远程用户机器时虽然已经能验证我的判断，却不能解决。条件允许的情况下，找个好心肠的同事来review一下你的方案看来也是非常有帮助的。

工具

可以准备一些适当的小工具，到时候传到用户机器上，用来帮助查找问题。客户端这边譬如spy++,apispy, process explorer, DependencyWalker,  tcp view , filemon, regmon(或者process monitor)等等,  选取一两个对自己查找问题有帮助的工具。

放松，不紧张

远程到用户的机器后，操作一般都比本地机器操作缓慢很多，据我自己经验，一定要放松，不要紧张

不要太相信客户，相信自己的判断力

这是最后一条，也是最重要的一条。我有两次就栽在这个上面。有一次一个阿里旺旺插件开发商的技术人员告诉我插件模拟的订购信息拿不到了，而其他人的机器上不会出现这样的问题。于是我和他一起，用了很多方法来定位他的问题，最后发现是他描述的情况和真实发生的情况不符，他自己可能也没注意到。如果中间相信自己的判断力，早一点做一些怀疑假设，也许不会消耗那么多无谓的时间，毕竟时间就是生命:) .