你還在等着用戶反饋BUG?

譯者按: 等待用戶反饋BUG,一切都晚了!實時監控線上應用纔是王道。編程

原文: Why relying on your users to report errors is the dumbest thing you’ll ever do瀏覽器

譯者: Fundebug服務器

爲了保證可讀性,本文采用意譯而非直譯。另外,本文版權歸原做者全部,翻譯僅用於學習。併發

咱們熱愛coding。工具

當咱們coding的時候,就如同從零建造一棟大樓。新的特性、新的功能、絕佳的設計都在每一次更新後被用戶所使用,期待他們的喜好和讚美。這樣的一個過程讓咱們感到心靈上的慰藉和擁有爲數很少的成就感。學習

然而,現實並無想象中美好。操作系統

若是debug是移除bug的流程,那麼編程就必定是將bug放進去的流程。翻譯

軟件工程師將大量時間花在了其它事情上。他們須要參加各類會議、討論需求、制定計劃、將現有的冗餘代碼重構,以及還有一項花費時間不少的工做:修復bug。debug

我尚未遇到過一位喜歡在代碼中去找bug的工程師,大概由於查找和復現一個bug每每要花費不少時間。設計

一直以來,debug就像大海撈針同樣。他們須要親自去發現問題的緣由而後尋找解法,而不是依賴於用戶的截屏反饋。

用戶的截屏並不能告訴你足夠的信息,每每你會問更多。

你用的哪一個瀏覽器,什麼版本,操做系統是哪一個,能夠具體一點告訴我剛剛你是怎麼操做的嗎,你以前在哪一個頁面,你是怎麼到這個頁面的?

就算問了用戶這麼多問題,也不必定能解決問題。

Debug老是要花不少時間,然而仍是一頭霧水。

坐等用戶反饋真的好嗎?

不少開發團隊依然依靠用戶反饋來改進產品,這實際上是很荒謬的。

在快餐連鎖店,客戶用餐完畢以後,須要本身將沒吃完的食物和用過的餐巾紙扔到垃圾桶。快餐店的食物可能一點也很差吃,客戶沒吃幾口就扔到垃圾桶而後直接走掉。除非客戶真的是一個愛抱怨的人並且剛好有時間,纔會如實評價。不然,你只會認爲一個客戶吃完飯滿意的離開了。

然而,他不再會來這裏吃了!

一些開發者會這麼認爲:若是沒有用戶反饋問題,那就表明咱們的產品棒棒噠,對不對?認爲「若是用戶使用產品遇到問題,用戶就會反饋」是比較侷限的。最終你會發現只有1%的用戶會反饋問題,然而事實上多得多。

開發者依靠頗有限的信息去嘗試debug一個問題,每每不能解決。

你開發的軟件並無你想象的那麼完美!

一個在大型線上零售店工做的朋友跟我聊過他們解決公司線上訂單系統的一個重大問題的故事。他們通過好幾天的排查,都沒有發現問題所在。最後決定使用一個專用工具來監控和診斷應用錯誤。

最終的發現使人驚恐!

八個服務器中的一個內存不足而後報錯,致使用戶的訂單流程失敗。也就是說:「每八個用戶中有一個收到影響」。

發現和解決這個問題使得一個月的銷售額提升了2萬美圓。過後評估發現總共影響了5000名用戶,可是隻收到2個用戶反饋。雖然解決了bug你們都很開心,但這個錯誤致使了10萬美圓損失。

不建議這麼作:一出錯就給本身發郵件報警

你能夠坐在電腦面前盯着錯誤日誌流。當你休息的時候,能夠僱一個小夥伴這麼作。或則,當異常出現的時候,給本身發報警郵件(貌似是個不錯的主意)。直到你真的這麼作了,你就不會這麼想了!

你須要意識到:對於小的我的項目,一有錯誤就經過郵件報警還能夠。但若是業務量起來了,訪問量打了,事情就會變得一團糟:

  • 因爲版本以及兼容性,不少錯誤信息不完整
  • 很難去指定一個報警規則,報警變成噪音
  • 若是一個錯誤恰好在循環裏面,可能一夜給你發5萬封郵件
  • 錯誤沒有優先級或則嚴重性區別,混在一塊兒
  • 當你查看了超過100封郵件之後,你不再回去讀它們了

你會開始忽略這些郵件,甚至把它們歸類到一個單獨的文件夾而後發現無從下手而不多去碰。畢竟,從幾千封郵件中找到嚴重的問題並解決很不容易。

ELMAH - 記錄程序異常

ELMAH (Error Logging Modules and Handlers) 是一個錯誤記錄服務。它能夠動態地加入到一個ASP.NET項目中,而不須要從新編譯或則從新部署。ELMAH不支持全部的程序語言,他提供的功能也有點侷限。ELMAH適用於小型的我的項目。

專業BUG監控

若是你想認真對待應用BUG,可使用一個專業的BUG監控服務,好比國外的Raygun(或則咱們Fundebug)。一個專業的BUG監控服務能夠幫你:

  • 經過過濾和排序來定位嚴重錯誤
  • 配置多種報警方式,好比郵件、Slack、或則HipChat
  • 使用一個監控服務來追蹤多語言多平臺
  • 類似錯誤自動聚合
  • 團隊協做齊力解決BUG

若是你使用簡單的方案(直接郵件報警),那麼你須要停下手頭的工做,花費兩三個小時去復現一個bug。這是很是浪費時間,很是低效的作法!若是一個團隊注重快速迭代,那麼他們會願意爲開發者節省花費的debug上的時間,去開發產品的新功能、新特性。

總結

咱們但願技術實現自動修復軟件BUG。不過,軟件自愈依然還有一段距離。你可使用一些錯誤監控服務來使得整個debug更加簡單和高效。

<!-- 現在持續集成逐漸被普遍使用,你能夠幾分鐘內快速定位bug、修復bug併發布到生產環境,而不須要等待幾週一度的產品更新。 -->

在你的用戶發現問題以前發現,而且不要單純依賴用戶反饋問題!

版權聲明:

轉載時請註明做者Fundebug以及本文地址:

https://blog.fundebug.com/2017/08/30/rely-on-users--to-report-error-is-not-good/

相關文章
相關標籤/搜索