你還在等著用戶反饋BUG?

Lavender 發(fā)布于2019-08-21 16:20 / 772人閱讀

摘要：譯者按等待用戶反饋，一切都晚了實時監(jiān)控線上應(yīng)用才是王道。他們需要親自去發(fā)現(xiàn)問題的原因然后尋找解法，而不是依賴于用戶的截屏反饋。最終你會發(fā)現(xiàn)只有的用戶會反饋問題，然而事實上多得多。事后評估發(fā)現(xiàn)總共影響了名用戶，但是只收到個用戶反饋。

譯者按: 等待用戶反饋BUG，一切都晚了！實時監(jiān)控線上應(yīng)用才是王道。

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

譯者: Fundebug

為了保證可讀性，本文采用意譯而非直譯。另外，本文版權(quán)歸原作者所有，翻譯僅用于學(xué)習(xí)。

我們熱愛coding。

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

然而，現(xiàn)實并沒有想象中美好。

如果debug是移除bug的流程，那么編程就一定是將bug放進(jìn)去的流程。

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

我還沒有遇到過一位喜歡在代碼中去找bug的工程師，大概因為查找和復(fù)現(xiàn)一個bug往往要花費很多時間。

一直以來，debug就像大海撈針一樣。他們需要親自去發(fā)現(xiàn)問題的原因然后尋找解法，而不是依賴于用戶的截屏反饋。

用戶的截屏并不能告訴你足夠的信息，往往你會問更多。

你用的哪個瀏覽器，什么版本，操作系統(tǒng)是哪個，可以具體一點告訴我剛剛你是怎么操作的嗎，你之前在哪個頁面，你是怎么到這個頁面的？

就算問了用戶這么多問題，也不一定能解決問題。

Debug總是要花很多時間，然而還是一頭霧水。

坐等用戶反饋真的好嗎？

很多開發(fā)團(tuán)隊依然依靠用戶反饋來改進(jìn)產(chǎn)品，這其實是很荒謬的。

在快餐連鎖店，客戶用餐完畢之后，需要自己將沒吃完的食物和用過的餐巾紙扔到垃圾桶。快餐店的食物可能一點也不好吃，客戶沒吃幾口就扔到垃圾桶然后直接走掉。除非客戶真的是一個愛抱怨的人而且恰好有時間，才會如實評價。否則，你只會認(rèn)為一個客戶吃完飯滿意的離開了。

然而，他再也不會來這里吃了！

一些開發(fā)者會這么認(rèn)為：如果沒有用戶反饋問題，那就代表我們的產(chǎn)品棒棒噠，對不對？認(rèn)為“如果用戶使用產(chǎn)品遇到問題，用戶就會反饋”是比較局限的。最終你會發(fā)現(xiàn)只有1%的用戶會反饋問題，然而事實上多得多。

開發(fā)者依靠很有限的信息去嘗試debug一個問題，往往不能解決。

你開發(fā)的軟件并沒有你想象的那么完美！

一個在大型線上零售店工作的朋友跟我聊過他們解決公司線上訂單系統(tǒng)的一個重大問題的故事。他們經(jīng)過好幾天的排查，都沒有發(fā)現(xiàn)問題所在。最后決定使用一個專用工具來監(jiān)控和診斷應(yīng)用錯誤。

最終的發(fā)現(xiàn)令人驚恐！

八個服務(wù)器中的一個內(nèi)存不足然后報錯，導(dǎo)致用戶的訂單流程失敗。也就是說：“每八個用戶中有一個收到影響”。

發(fā)現(xiàn)和解決這個問題使得一個月的銷售額提高了2萬美元。事后評估發(fā)現(xiàn)總共影響了5000名用戶，但是只收到2個用戶反饋。雖然解決了bug大家都很開心，但這個錯誤導(dǎo)致了10萬美元損失。

不建議這么做：一出錯就給自己發(fā)郵件報警

你可以坐在電腦面前盯著錯誤日志流。當(dāng)你休息的時候，可以雇一個小伙伴這么做。或則，當(dāng)異常出現(xiàn)的時候，給自己發(fā)報警郵件（貌似是個不錯的主意）。直到你真的這么做了，你就不會這么想了！

你需要意識到：對于小的個人項目，一有錯誤就通過郵件報警還可以。但如果業(yè)務(wù)量起來了，訪問量打了，事情就會變得一團(tuán)糟：

由于版本以及兼容性，很多錯誤信息不完整

很難去指定一個報警規(guī)則，報警變成噪音

如果一個錯誤剛好在循環(huán)里面，可能一晚上給你發(fā)5萬封郵件

錯誤沒有優(yōu)先級或則嚴(yán)重性區(qū)別，混在一起

當(dāng)你查看了超過100封郵件以后，你再也不回去讀它們了

你會開始忽略這些郵件，甚至把它們歸類到一個多帶帶的文件夾然后發(fā)現(xiàn)無從下手而很少去碰。畢竟，從幾千封郵件中找到嚴(yán)重的問題并解決很不容易。

ELMAH - 記錄程序異常

ELMAH (Error Logging Modules and Handlers) 是一個錯誤記錄服務(wù)。它可以動態(tài)地加入到一個ASP.NET項目中，而不需要重新編譯或則重新部署。ELMAH不支持所有的程序語言，他提供的功能也有點局限。ELMAH適用于小型的個人項目。

專業(yè)BUG監(jiān)控

如果你想認(rèn)真對待應(yīng)用BUG，可以使用一個專業(yè)的BUG監(jiān)控服務(wù)，比如國外的Raygun（或則我們Fundebug）。一個專業(yè)的BUG監(jiān)控服務(wù)可以幫你：

通過過濾和排序來定位嚴(yán)重錯誤

配置多種報警方式，比如郵件、Slack、或則HipChat

使用一個監(jiān)控服務(wù)來追蹤多語言多平臺

相似錯誤自動聚合

團(tuán)隊協(xié)作齊力解決BUG

如果你使用簡單的方案(直接郵件報警)，那么你需要停下手頭的工作，花費兩三個小時去復(fù)現(xiàn)一個bug。這是非常浪費時間，非常低效的做法！如果一個團(tuán)隊注重快速迭代，那么他們會愿意為開發(fā)者節(jié)省花費的debug上的時間，去開發(fā)產(chǎn)品的新功能、新特性。

總結(jié)

我們希望技術(shù)實現(xiàn)自動修復(fù)軟件BUG。不過，軟件自愈依然還有一段距離。你可以使用一些錯誤監(jiān)控服務(wù)來使得整個debug更加簡單和高效。

在你的用戶發(fā)現(xiàn)問題之前發(fā)現(xiàn)，并且不要單純依賴用戶反饋問題！

版權(quán)聲明:
轉(zhuǎn)載時請注明作者Fundebug以及本文地址：
https://blog.fundebug.com/201...