1. 程式人生 > >你還在等著用戶反饋BUG?

你還在等著用戶反饋BUG?

技術 足夠 服務器 screen copyright ng- 要花 ror 時間

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

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

譯者: Fundebug

為了保證可讀性,本文采用意譯而非直譯。另外,本文版權歸原作者所有,翻譯僅用於學習。


技術分享

我們熱愛coding。

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

然而,現實並沒有想象中美好。


技術分享

如果debug是移除bug的流程,那麽編程就一定是將bug放進去的流程。

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

我還沒有遇到過一位喜歡在代碼中去找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?