问题像缝纫机上的丝线
杂乱而复杂
需要慢慢捋清
才能找到线的源头
“在么？”
“我使用XX框架启动报错，你帮忙看下？”
“我代码报错了，谁能帮我看下？”
“我发现一个诡异的问题”
生活中我们经常可以看到一些无效的问题，在开发运维工作中，经常可以看上面这些提问。比较有意思的例子是，工作中突然有个人找你，就说了句“在么？”。等你方便时回复了“在，什么问题？”的时候，对方没回应。过了一会儿，对方又冒了一句“还在么？”。 有一种像 TCP 连接需要做三次握手确认，这种交流是特别低效的。低效的问题有很多种，不能让对方快速清晰知道问题背景、具体问题的都算的上无效问题。然而在自己身上也有类似的经历。
今天和师兄联调一个接口，发现了一些数据不符合预期。 于是我没想太多，就自然而然的将页面数据截图发给他，并且红色框框圈出问题的数据，直接发给他。然后说了句， “你这个数据有些问题，辛苦帮忙看下哈”。
我以为大家对项目的整体链路，整体设计都很清晰，只要轻轻点下问题就可以。结果一个简单的问题，却讨论半天，解释问题是什么。最后师兄抛出了一句，“你下次说问题题时注意这些细节，建议说明背景、期望得到什么结果、实际是什么”。那一瞬间对自己冲击很大，是得好好思考下自己的反馈问题方式，学习如何能够高效表达一个问题，提高效率。
在平时生活或工作中，我们也经常能遇到别人向你寻求帮助或提问，或在遇到问题时也会让身边相关的人帮忙。社会合作体系导致我们必然会和身边的人共同协作完成工作，也有越来越多的问题需要反馈、沟通。大家时间都很忙，如果提出一个无效的问题往往耗费大家时间，影响效率。本文就说说自己的一些总结，希望对大家都有帮助。
01 首先遇到问题时，不要马上问别人
先自己排查，上网查询。一般我们生活中或开发中遇到的很多问题都是别人经历过的，而且网上资源丰富。通过搜索引擎工具，大部分问题我们都可以查到，避免问身边人一些低效的问题。 比如当自己想要投资理财，买基金，于是问专业人士“基金是什么，基金与活期的区别是什么？”。
自己排查问题的过程可以提高自己解决问题能力，正如一些InfoQ 的大神说的一样，问题见多了你就成为大神。 见多了，积累多了你的能力就上去了。就像古代的一些名将，都是历经大大小小战役以后。
另外，自己排查问题，明确背景、明确问题的本质，而不是只看到问题的表象。将反馈的问题提前定位，捋清楚, 看是否真的是对方的问题。避免查到最后是自己问题，却反馈给对方，出现尴尬的局面。
02 提炼问题的核心
简单提炼问题的核心，通过简单的一句话能够描述出问题的核心和本质。根据专业领域不同，带上专业领域相关关键词，能够让对方一眼大致知道问题类型是什么，问题是什么。避免用了一大段详细描述以后，对方还不知道是什么问题。
类似一篇文章的核心思想、作文标题，能够一看就看出问题。 避免使用“在么?”, “系统起不来了” 等非常抽象的词描述。以我的例子， “xx 接口返回的数据结果不符合预期”。这个也类似一个问题的代号，后续只要说这个标题大家都知道是哪个问题，方便沟通。
理解任何时期都需要对它进行定义，这样才能在头脑中清除地知道正在谈论的是这个东西，而不是其他东西。
03 清晰描述问题具体问题、期望的目标和现状
下面就是需要清晰描述具体问题是什么，最好包含期望达到的目标是什么，以及目前遇到的现状。例如：
问题：xx 接口调用时返回的数据结果中的 总数和成功数字不符合预期。
期望：结果中的总数应该大于成功数量。 成功数量是实际执行成功的数量，不含有失败等数量。总数包含所有的数值。
现状: 总数小于了成功数量。
该过程主要让问题具体化，让对方更加明确问题所在。如果可能最好是加上相关截图、日志，证明事实真的是这样。 避免出现质量同学和开发同学反馈问题时，开发同学习惯性用“我这边运行好好的，肯定是你使用有问题”来辩驳。
04 问题的场景，如何复现该问题
一个问题能够复现，就解决了90%。 发现问题时，将问题出现的场景、条件捋清楚。场景是说明通过哪些步骤、哪些场合下发生问题，通过什么方式能将问题复现。这些方便对方定位问题，提高排查效率。
有些问题是在极端条件下才能产生，开发平时也注意不到。如果仅仅是反馈问题，在他的认知里不可能会出现这个错误，他就会反驳你。所以场景和复现手段是非常必要的，一个程序会因为不同变量做出不同反应，这引起问题的变量就是场景。描述的过程尽可能的具体，避免使用你和对方理解不同的概念，导致歧义。
05 补充信息，比如自己排查阻塞点
尽可能多地补充问题信息，能够让对方快速排查到问题。比如操作系统、操作系统版本、框架版本、具体排查的日志等。也可以将自己已经排查的点和相关日志贴出，说明目前阻塞的点在哪里，怀疑可能出错的地方。补充更多更详细的信息，也是避免双方理解不同导致的误会，影响沟通效率。
每个领域不同，补充的信息也就不同。比如注册中心相关问题，需要说明那个订阅者无法订阅到哪个发布者的xxx服务。 所以可以提供的信息如下：
服务： xxxx
发布者： xxxx , IP xxx.xxx.xxx.xxx
订阅者：xxxx , IP xxx.xxx.xxx.xxx
06 问问题之前自己过一遍
提问前最好自己过一遍，看有哪里描述不清晰的，哪里表达不通顺，以及是否可以通过现有的这套描述可以让对方很清晰的知道问题所在。
07 我自己的一套模板
问题： XXX 版本的 XXX 接口 调用返回的数据不符合预期
期望：xxx 接口的执行总数应该大于执行成功数量。执行成功数量应该只统计成功执行的数值不能包含其他值。
现状：接口返回的成功数量大于执行总数；成功数量也不是具体的成功数值。
场景：
- xxxx
- xxxx
- xxxx
补充：
- 客户端机器 ip xxxx
- 服务端机器 ip xxxx
- 请求流水号 xxxx
- 我排查的日志详情 xxx
最后对方帮你把问题解决完了，不要忘了说声感谢。
更多精彩，关注微信公众号
