ES专家的灵魂拷问：为什么你提的技术问题极少能得到解答？

李猛 2021-12-18 10:31:00

作者介绍

李猛，数据领域专家，Elastic Stack国内顶尖实战专家，国内首批Elastic官方认证工程师21人之一。2012年入手Elasticsearch，对Elastic Stack技术栈开发、架构、运维、源码、算法等方面有深入实战经验。负责过多种Elastic Stack项目，包括大数据分析领域、机器学习预测领域、业务查询加速领域、日志分析领域、基础指标监控领域等。十余年技术实战从业经验，擅长大数据多种技术栈混合，系统架构领域。

序言

Elastic Stack是一个很庞大的技术栈体系，开源免费，群众基础大，应用领域非常广泛，那么应用时各种开发架构运维问题与疑惑也非常多，如果有非常好的交流沟通机制该多好？Elastic Stack也有很多社区，但非常多ES爱好者或技术从业者，都经常抱怨或提到，在很多ES相关社区提了问题都没人回复，久而久之就沉下去了。问题的根源在哪里呢？

2020年8月，机缘巧合之下，我开设了ES系列课程，随着学员人数越来越多，老师个人时间单位分配到学员的交流解答时间越来越少。为此，本文将探讨一种高效的提问和交流方式，推荐大家践行。

一、糟糕的方式

首先，来看看什么是糟糕的提问或者交流方式，相信各位看了之后会深有体会，因为大部分IT从业者应该是这么进行的，也很困惑。（注：以下截取多个真实的交流信息，若有不便，请告知删除，会尽力屏蔽个人信息）

1、无问题边界

图示：某学员的提问，一次性提了太多，根本无法回复

这种提问最大的问题就是范围太大，需要专业人士，持续很长时间，且可能需要持续多次交流才能解答完成，那接着问题就来了，哪个专业人士愿意陪提问者很长时间交流解答？

看到学员这种提问，基本上心理第一时间想到的就是，需要很长时间，打字是不可能完成了，必须得语音或者其它，最后的结果可能就是不回答了。

2、无上下文

图示：某学员在群组聊天讨论ES性能问题

这种无上下文提问讨论方式，经常会遇到，概率非常高，几乎多数人都是这样，提问者不提供上下文信息，直接想找人来解答分析，如果要解答，解答者需要几乎1v1的聊天方式进行，然后持续时间很长。

看到这种提问方式，也会让人产生不愿意回答的心理，因为需要消耗大量的精力和时间。有时候觉得提问者非常善于偷懒，如果让对方好好准备一下，多数人是极不愿意的，如果提问者准备上下文描述，测试环境信息，测试数据，测试方式等，预计也要消耗自己很多时间，所以就立马甩锅出来，看看有没有人陪提问者聊聊情况。

自开始了Elastic Stack咨询与培训，我遇到了很多以这种方式提问的朋友或学员，通常觉得对方问题复杂，都要求对方麻烦写个帖子啥的，有的会认真写个帖，按照要求尽可能描述信息，有的就没有下文了。

其实作为ES技术爱好者，我非常愿意解答这样的问题，但是类似这种性能的问题，需要消耗解答者太多的精力与时间进行分析，如果能站在解答者角度思考，能非常详细的写清楚自己的上下文，相信对于高手专家，应该可以很快判断出问题所在并解答。

本人有幸去过几次XX人民医院，医院大家都懂得，能不去则不要去，去之前已经深深的把自己的毛病以及前后因果都准备好了，所以挂号之后就是等，挂号时间比较长，真正见到医生，也就简单几分钟，医生也很明白了，开个药方就结束了。偶然也会注意前面挂号的病人，沟通交流是个大问题，医生问A，病人回答B，所以很佩服当医生的人的耐心和诊断能力。

3、遮遮掩掩

图示：模拟某学员隐藏式的交流提问

很多问题本身属于一种运维类型问题，最好的方式就是调试运行一下。与其聊天花那么多时间，不如直接把自己的问题完全暴露出来，这样对于别人几乎是一眼的事情，很快点出问题关键。

偏偏很多同学至今没有明白此类问题，一方面需要专家高手过来帮忙，一方面藏着掖着，等来的结果多数是“自己解决”。

4、互相不尊重

图示：模拟某学员无尊重式交流提问

有时候遇到很多提问，对于问题本身可能很复杂，但问题非常有意义，即使消耗时间与精力也愿意尝试一下，期待也有一定的行业经验收获。但是当你与提问者去深入交流分析问题，提问者各种绕圈子，各种藏私活，非常不敢于快速解决问题，从与提问者交流聊天能明显感受到，对方没有很尊重你，“我现在有问题，需要你来帮忙回答，至于你问我，不便于回答”，最终的结果还是“自己解决”。

5、白嫖式提问交流

图示：模拟某企业方问题排查交流

IT行业从业者平均薪资在国内确实属于高的，对于某些专业级专家来说，时间就是他的生命线，浪费他人时间，不尊重他人时间就是耍流氓。IT行业也很容易产生白嫖事件，试想大家都是为公司工作，工作遇到问题，需要借助外援解决，除了消耗本公司的人力时间成本，也需要消耗外援的时间成本，自己公司的实际成本由本公司老板承担，外援的时间成本就是尽量靠PUA来完成。

白嫖式的交流提问其实效率很低，开始偶然一两次还能行得通，但可以想象，如果贵司需要设计一个复杂的工业级的IT系统，仅仅靠白嫖就能完成的话，那也只能说这个系统本身没有行业门槛。时间久了，还会让人产生厌恶感，失去了一个强外援。

二、推荐的方式

前面写了一些糟糕的提问方式，接着来看看高效的提问或者交流方式应该是怎么样的，期望各位看了之后，也得到启示，并着重践行。

1、专家式交流

图示：模拟某领域技术专家的交流

专家式的交流非常轻松愉快，提问之前都已经准备好了自己的概要情况介绍，对方仅仅需要解答者一些肯定的回答交流，不需要过多的原理解释。问题也非常直接简单，作为回答者也非常简单，直接告知这个技术栈与他的期望是怎么样的。如果你不是专家类型的提问者，那么就要换一种方式，切勿采用长时间聊天方式来进行。

2、帖子式提问交流

图示：来自前公司某同事的帖子方式（注：帖子内容不便展开）

IT从业者要学会写帖子或者博客，这是一种软技能，也是一种优秀的沟通方式。试想，你在企业遇到很多应用场景与技术问题，你不能解决，需要借助外部专家，这些问题对于外部专家可能非常简单。但是外部专家毕竟不在贵司，也不了解贵司的业务场景与需求，也可能花费大量的时间与精力来应对这个问题。所以写得一个好帖子尤为重要。

写帖子方式，非常适合复杂的问题，尤其是各种性能之类的，语法糖之类、排查问题类的，这类问题有一个特点，需要有案例数据，有示范代码，否则仅凭几句语言描述根本不足以深入。

写帖子是一种能力，很多场合下比编程技能，编程技术更重要，甚至可以判断出提问者的素质水平，工作方式与工作思维。

3、互馈式的交流

图示：来自某学员的互馈式交流

三人行必有我师，专家或者老师也不是神人，也需要与其他人交流学习，每个人都有自己的擅长。IT领域涉及技术点非常多，很多东西不是研究下原理看看源码就可以了，也需要足够的实战与实践，但这些都需要消耗大量的时间与精力，如果可以互馈，那么将大大节约彼此的时间与精力，所谓共赢不过如此。

4、付费式交流解答

经常关注很多技术公众号，特别爱看原创者，有的原创者公众号会有一个打赏付款二维码，看完之后，如果觉得不错，可以打赏，金额随意，表达了打赏者对原创者的尊重与学习，自己获得了知识或者提升，付费是一种好的习惯，也是一种好的交流方式。

IT从业者涉及到的技术栈非常宽泛，面对的业务场景也非常复杂，每个人精力是有限的，知识面与经验是有明显局限的，承认别人专家的价值，尊重专家的劳动成果。

三、提问模板参考

谈了这么多，最后给大家输出一个有效的提问方式模板，供参考，也是我目前践行的方式，能理解的学员都在践行。

1、提问之前准备工作

提问之前一定要梳理清楚问题的背景、来龙去脉，基于什么场景做了什么操作产生了什么问题？自己做了哪些尝试了（尝试1、尝试2、。。。），最终搞不定，想听听大家的方案？多学会用英文搜索，借助：stackoverflow，elastic英文论坛、google等都是最棒的工具之一。（注：本段内容摘录自铭毅天下）

2、简化自己的核心问题

一句话能写出的核心问题，尽量简化，抓住要点，考验语文水平的时刻来了，看吧，IT不仅仅是理工科类专业技能竞争，也是文科类语言组织形式的竞争。

3、描述问题的业务背景

详细描述当前需求背景，业务场景，最好是有图有真相，尽量细致，不要没有业务场景边界，纯粹讨论技术怎么做，这种问题没有终点，除了1v1随聊，没有其它有效办法。

4、描述问题现象表现

详细描述自己当前的问题以及表现形式，帮助你解决问题的人，并不能切身感受你的问题，需要仅可能描述的非常细致、到位、全面。最好有图有真相，也要有必要的日志或者程序运行结果等。

5、准备案例数据

很多复杂问题，即使专家也不一定能立马回复你，那么需要准备好相应的案例示范数据，而不要产生简单几句描述，让专家看了自己准备，那么此种问题的解决概率大大降低。

6、准备案例代码

案例代码是一种非常直接有效的表达方式，很多人并不能有效表达编写自己的背景场景，但是可以贴案例代码，专家高手看到案例代码，多数都能在第一时间发现问题所在，即使不能，你提供的案例代码，也能让别人方便测试运行，找出问题。仅仅凭提问者几句语言描述，这不厚道，也不是有效的方式，可能提问者本身的语言表达就是问题所在。

7、贴出尝试过的结论结果

提问者在此之前应该做过一些尝试实验，如果有结果结论，也尽量贴出来，别面后来者还在提问者的问题里打转。最好是有图有真相，也有数据结果。

8、写出期望的解决方式与结果

基于前面的描述与实验，也必须写出自己的期望结果，期望解决方式，过往者遇到同样问题的专家者或者其它人看到你的期望与方式，很快能判断此路是否通，如果不通，也是一种结论结果。

9、留下联系方式

既然敢于提问，也需要留下自己有效的联系方式，很多社区虽然提供了发布帖子的地方，但是有很多问题，专家看了之后也需要尽快与你1v1简单沟通一下才能给出方案方向，不仅仅要社区，也需要IM沟通。

10、问题要悬赏

悬赏能大大加快问题解决时间成本，进而缩减各种隐性成本。企业是盈利性公司组织，企业问题多数也会非常复杂，企业也不可能拥有所有专业人才，即使头部大厂也不能，需要开放心态，既然解决了企业问题，那么企业悬赏是应该的。

11、用Markdown格式编写

IT从业者必备，写Markdown是一种文化风格，布局漂亮、大纲清晰、可写文字描述、可贴图票、可贴代码等等。好的格式，能让解决问题的专家看起来舒服很多，会多停留一刻时间。

12、发布到专业社区组织

写好了记得发布到专业社区或者组织，不要去发一些公认的垃圾站点。

13、找到专家

找到专家前请准备好以上写的帖子内容，然后发给专家，待专家确定回复时间。

14、破案留存

如果问题解决了，得到期望的结果，那么最好提问者可以稍微整理一下，写出来，发布到社区，供后续的人使用，本着我为人人，人人为我的精神，重复的问题不再有人问，即使有人提问也以通过搜索引擎来解决。

结语

相信各位看了以上，都会有所思考，尊重彼此，尊重时间，提问者要站在解答者角度思考。其它领域的技术社区是不是也存在相同的问题呢？一起行动吧，先从自我做起，不轻易提问，提问就要准备充分。

以上仅仅发表个人的一些见解，若有不同观点，欢迎在评论区拍砖讨论。

>>>>

参考资料

• elasticsearch.cn  ES中文社区

  https://elasticsearch.cn/

• gper  咕泡教育社区

  https://gper.club

• How-To-Ask-Questions-The-Smart-Way  参考国外

  https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/blob/main/README-zh_CN.md

• smart-questions  参考国外

  http://www.catb.org/~esr/faqs/smart-questions.html

dbaplus社群欢迎广大技术人员投稿，投稿邮箱：[email protected]