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社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn
最新评论
访客 2021年09月03日

有没有1000多张表

访客 2021年08月28日

metrics =》 metrix 错误

访客 2021年08月25日

只看到如何避免,如何减少书写慢 sql

访客 2021年08月25日

没看到如何治理呀

访客 2021年07月23日

果然k8s不是神!

活动预告