目录
- 线上问题处理心得
- 总结
线上问题处理心得
1、保持良好的心态
每次客户让我们帮忙查线上问题的时候，都会告诉我们，这个问题很紧急，希望我们可以尽快查询出结果。
其实越是遇到这种紧急的问题，我们越需要保持内心平静，用平常心去对待；反之，心情越急躁，处理问题的效率就越低。
总之，遇到问题，不要急躁，保持良好的心态，会更利于问题快速有效的解决。
2、打好基础
一个系统都是由多个模块组成的，在一个团队里，除了项目经理对整个系统熟悉外，其他的成员都是各自负责某些模块。
客户在遇到线上问题，需要让我们去处理的时候，他们一定会根据模块对应的负责人去进行分配，或者找项目经理；然后项目经理在分配任务的时候，也一定是以模块对应的负责人为依据。
以我自己为例，在上海团队里，我负责福利、医院自付额、预授权、财务这些模块，所以在这些模块出现的问题的时候，客户会直接来咨询我，而不是去找其他同仁，因为我可以最快速的给到客户答复。
所以，对于我们自己所负责的模块，我们应该熟悉到哪种程度呢？
答案：成为团队和客户里，对你所负责模块熟悉度掌握最好的那个人；对于代码逻辑，你是团队里第一熟悉的人；对于业务知识，你要做到比客户还要了解。
习武之人，他们每天练的最多的是什么？
就是基本功。
对于我们也一样，只有基础打牢了，在遇到问题的时候，我们才会更有底气，才不会慌张，才能更有条不紊的去处理。
3、敢于质疑
一般客户在让我们查询问题的时候，都会简要的跟我们说明一下问题，可能是一段话，或者是截一张图片，如下：
“Nottingham-0812060的2018年外部保单号是MSH-CCIC-GEP-040529，保单号MSH-G-000-015389, http://192.168.1.88:7021/ui/ 可以查到有3000元的体检年上限，目前P121943517 FV Hospital在医院网站登录时，显示没有体检福利。”
这段话是Karlen总结问题之后发给我，让我帮忙去查的，对于这段话，我总结一下是什么呢，大致如下：
用P121943517账号登录Provider网站，去查询Nottingham-0812060这个客户2018年度的保单信息，结果发现没有显示体检福利。
其实问题也就是我上述总结的那样，但是这段话中“http://192.168.1.88:7021/ui/ 可以查到有3000元的体检年上限”这一句，会跟人带来误导作用。
88:7021这个环境对应的数据库是预生产库，并不是正式库，Karlen是觉得预生产库里面的数据也是新的，由于我们无法访问正式环境，也许可以去预生产环境进行查询。
后来我就自己分别去正式数据库，以及预生产数据库里面查询该客户信息，情况如下：
正式库里面：
该客户有2018年度的保单
有设置体检福利
但是是设置在给付责任层，且和其它给付责任共用同一条规则
预生产库里面：
该客户只有2017年度的保单
有设置体检福利
但是是设置在缴费责任层，是单独设置了一条规则
根据查询得出来的结果有2点：
1、预生产库与正式库里面的数据并不同步，我们不能拿预生产库来查找问题；
2、该客户在2018年度有设置体检福利，那么在网站上就应该显示出来。
体检福利的数据来源是通过Webservice返回的，那么我就想知道Webservice返回的结果到底是什么，但是由于我们无法访问正式库，那就很难得到结果，这时候应该怎么办呢？
这种时候我们就需要请客户帮忙，请他们帮忙协助我们去查询正式库。
有了客户的帮助，我得到了Webservice返回的结果，其中体检福利这个栏位，接口返回的结果是：<wellnessFlag><![CDATA[NO]]></wellnessFlag>
返回结果是一个大写的NO，对于这个结果，我产生了疑问，因为对于<wellnessFlag>这个字段，我曾经改过它的返回值，它是绝对不会返回一个大写的NO的，就算返回了NO，也应该是一个小写的No。
于是，我去找了客户那边的开发人员，说明了我的问题，他们答应去正式环境看一下程式发布的情况。
客户查找完，返回给我的结果是，我之前做的需求，提交的程式中，有一支程式没有发布到正式环境。
后来客户也紧急发布了这支程式，发布之后再去网站上面进行查询，体检福利这一栏位的显示值，由NO变为了Yes。
总结
本次的分享，我并没有分享具体遇到一个问题的查找方法，第一步要做什么，第二步要做什么，我觉得这些随着大家经验的累积，都会找到适合自己的处理问题的方式。
我分享的是我个人认为在处理问题时，比较重要的几点，而这几点，其实是一个渐进的过程。
遇到问题，首先心态很重要，不管你遇到的问题，是否是你所熟悉的，都不要慌张急躁，保持内心平静，头脑清晰，就算是再大再难的问题，都是需要一步一步去分析处理。
第二点打好基础，这一点不是说掌握就能掌握到的，它在于你自己平时的学习、总结，是一个长期的过程，贵在坚持。
就像我在前面第3点举的那个实例，对于返回的结果<wellnessFlag><![CDATA[NO]]></wellnessFlag>，如果我对自己所负责的模块掌握的不够的话，那我就不可能发现返回结果异常这个问题。
最后一点，是要敢于去质疑。客户告诉你的，并不见得就是完全正确的，他们只会告诉你，他们表面上看到的问题是什么，而这种描述是很片面的，不要因为这些片面的描述就把你的解题思路固定到某一个点上。
还拿我在前面第3点举的那个实例来说，如果我把我的注意点都放在“http://192.168.1.88:7021/ui/ 可以查到有3000元的体检年上限”这句话上的话，那我可能会在这个错误的方向上，纠结很久。
相信数据，相信你自己所查询到的结果。
每个人都有一套属于自己的处理问题的方式，而以上只是我的一些心得，仅限于和大家分享交流，共同进步。
写于2018年8月14日
Anne