你还在等着用户反馈BUG?

简介: 译者按: 等待用户反馈BUG,一切都晚了!实时监控线上应用才是王道。原文: Why relying on your users to report errors is the dumbest thing you’ll ever do译者: Fundebug为了保证可读性,本文采用意译而非直译。

译者按: 等待用户反馈BUG,一切都晚了!实时监控线上应用才是王道。

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

译者: Fundebug

为了保证可读性,本文采用意译而非直译。另外,本文版权归原作者所有,翻译仅用于学习。

img_80d71b7ee4852f3ca80889368931b330.jpe

我们热爱coding。

当我们coding的时候,就如同从零建造一栋大楼。新的特性、新的功能、绝佳的设计都在每一次更新后被用户所使用,期待他们的喜爱和赞美。这样的一个过程让我们感到心灵上的慰藉和拥有为数不多的成就感。

然而,现实并没有想象中美好。

img_2ee17cd2758aec0619966248d0e5d06a.jpe

如果debug是移除bug的流程,那么编程就一定是将bug放进去的流程。

软件工程师将大量时间花在了其它事情上。他们需要参加各种会议、讨论需求、制定计划、将现有的冗余代码重构,以及还有一项花费时间很多的工作:修复bug。

我还没有遇到过一位喜欢在代码中去找bug的工程师,大概因为查找和复现一个bug往往要花费很多时间。

一直以来,debug就像大海捞针一样。他们需要亲自去发现问题的原因然后寻找解法,而不是依赖于用户的截屏反馈。

img_6af9fbcc5566d3592181c774664ec591.png

用户的截屏并不能告诉你足够的信息,往往你会问更多。

你用的哪个浏览器,什么版本,操作系统是哪个,可以具体一点告诉我刚刚你是怎么操作的吗,你之前在哪个页面,你是怎么到这个页面的?

就算问了用户这么多问题,也不一定能解决问题。

Debug总是要花很多时间,然而还是一头雾水。

坐等用户反馈真的好吗?

很多开发团队依然依靠用户反馈来改进产品,这其实是很荒谬的。

在快餐连锁店,客户用餐完毕之后,需要自己将没吃完的食物和用过的餐巾纸扔到垃圾桶。快餐店的食物可能一点也不好吃,客户没吃几口就扔到垃圾桶然后直接走掉。除非客户真的是一个爱抱怨的人而且恰好有时间,才会如实评价。否则,你只会认为一个客户吃完饭满意的离开了。

然而,他再也不会来这里吃了!

一些开发者会这么认为:如果没有用户反馈问题,那就代表我们的产品棒棒哒,对不对?认为“如果用户使用产品遇到问题,用户就会反馈”是比较局限的。最终你会发现只有1%的用户会反馈问题,然而事实上多得多。

开发者依靠很有限的信息去尝试debug一个问题,往往不能解决。

你开发的软件并没有你想象的那么完美!

一个在大型线上零售店工作的朋友跟我聊过他们解决公司线上订单系统的一个重大问题的故事。他们经过好几天的排查,都没有发现问题所在。最后决定使用一个专用工具来监控和诊断应用错误。

最终的发现令人惊恐!

八个服务器中的一个内存不足然后报错,导致用户的订单流程失败。也就是说:“每八个用户中有一个收到影响”。

发现和解决这个问题使得一个月的销售额提高了2万美元。事后评估发现总共影响了5000名用户,但是只收到2个用户反馈。虽然解决了bug大家都很开心,但这个错误导致了10万美元损失。

不建议这么做:一出错就给自己发邮件报警

你可以坐在电脑面前盯着错误日志流。当你休息的时候,可以雇一个小伙伴这么做。或则,当异常出现的时候,给自己发报警邮件(貌似是个不错的主意)。直到你真的这么做了,你就不会这么想了!

你需要意识到:对于小的个人项目,一有错误就通过邮件报警还可以。但如果业务量起来了,访问量打了,事情就会变得一团糟:

  • 由于版本以及兼容性,很多错误信息不完整
  • 很难去指定一个报警规则,报警变成噪音
  • 如果一个错误刚好在循环里面,可能一晚上给你发5万封邮件
  • 错误没有优先级或则严重性区别,混在一起
  • 当你查看了超过100封邮件以后,你再也不回去读它们了
img_c6a3bdd9c311c4e33ef2dce570b6ed1f.jpe

你会开始忽略这些邮件,甚至把它们归类到一个单独的文件夹然后发现无从下手而很少去碰。毕竟,从几千封邮件中找到严重的问题并解决很不容易。

ELMAH - 记录程序异常

ELMAH (Error Logging Modules and Handlers) 是一个错误记录服务。它可以动态地加入到一个ASP.NET项目中,而不需要重新编译或则重新部署。ELMAH不支持所有的程序语言,他提供的功能也有点局限。ELMAH适用于小型的个人项目。

img_d976949c220cb4fe0eead12d1ef3c292.jpe

专业BUG监控

如果你想认真对待应用BUG,可以使用一个专业的BUG监控服务,比如国外的Raygun(或则我们Fundebug)。一个专业的BUG监控服务可以帮你:

  • 通过过滤和排序来定位严重错误
  • 配置多种报警方式,比如邮件、Slack、或则HipChat
  • 使用一个监控服务来追踪多语言多平台
  • 相似错误自动聚合
  • 团队协作齐力解决BUG

如果你使用简单的方案(直接邮件报警),那么你需要停下手头的工作,花费两三个小时去复现一个bug。这是非常浪费时间,非常低效的做法!如果一个团队注重快速迭代,那么他们会愿意为开发者节省花费的debug上的时间,去开发产品的新功能、新特性。

总结

我们希望技术实现自动修复软件BUG。不过,软件自愈依然还有一段距离。你可以使用一些错误监控服务来使得整个debug更加简单和高效。

在你的用户发现问题之前发现,并且不要单纯依赖用户反馈问题!

img_bb31b8cb2adb7b52a50d9e91733778b7.jpe

版权声明:
转载时请注明作者Fundebug以及本文地址:
https://blog.fundebug.com/2017/08/30/rely-on-users--to-report-error-is-not-good/

目录
相关文章
|
6月前
|
测试技术
如何高质量的做BUG分析
如何高质量的做BUG分析
206 0
|
6月前
|
测试技术
项目上线后发现bug,该怎么办?
项目上线后发现bug,该怎么办?
155 0
|
程序员
缺陷(bug)管理
理论上软件的缺陷是可修复的,不过有的修复成本比较高,不能追求软件的完美,根据风险来确定是否修复缺陷
|
监控 安全 架构师
抱歉,你测试的项目上线之后bug太多了!
抱歉,你测试的项目上线之后bug太多了!
|
Web App开发 关系型数据库 项目管理
|
测试技术
软件测试面试题:软件上线后有bug怎么处理?
软件测试面试题:软件上线后有bug怎么处理?
194 0
|
测试技术
如何处理不能复现的bug?软件测试工程师避坑指南
软件测试工作中常常会遇到不能复现的bug,遇到这种情况其实很正常,但是很多测试新手都按照自己的想法处理,没有提交bug,或者匆匆关闭bug。线上出现问题,就只能自己背锅了。
539 0
|
编解码 Java 数据库连接
追踪Bug的五项原则
  一个远程办公的团队比坐在一个办公室里的团队需要更强的纪律。首先,我指的是沟通的纪律。在teamed.io, 我们已经远程开发软件有五年之久。我们通过问题清单系统(原文为ticketingsystem如Github, JIRA, Trac,Basecamp 等)来严格地管理任务,并且不鼓励任何不正式的沟通方式,如Skype, HipChat, 邮件或者电话。每一个ticket对我们来说都是一个有自己生命周期、参与者和目标的独立任务。这些年,我们有一些教训想分享给大家。如果你的团队也是远程办公,你会发现这些内容很有用。
142 0
|
测试技术
关于线上bug
之所以想写下线上bug,因为发觉有些公司对线上bug的处理是比较严格甚至是很苛刻,涉及到的相关人可能会因此而背黑锅。 之所以会存在这样情况,因为公司各部门都有关联,特别是用户、老板的投诉,也给公司会造成直接口碑或经济等重大损失。
2357 0