作者介紹
李猛，資料領域專家，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