专栏首页Fundebug你还在等着用户反馈BUG?

你还在等着用户反馈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。

我还没有遇到过一位喜欢在代码中去找 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 更加简单和高效。

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

版权声明

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

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 三问助你Debug

    原文: Three Questions About Each Bug You Find

    Fundebug
  • 我们应该如何给需求排序?

    开发产品的时候,我们每天都会面对各种各样、没完没了的需求,有的来自外部用户的反馈,有的来自内部团队的idea,有的是产品的BUG,有的是新的功能...

    Fundebug
  • GraphQL快速入门教程

    传统的api调用一般获取到的是后端组装好的一个完整对象,而前端可能只需要用其中的某些字段,大部分数据的查询和传输工作都浪费了。graphQL提供一种全新数据查询...

    Fundebug
  • 如何参与一个Apache开源项目

    本文介绍如何参与Apache项目,从最初的user到contributer做起,目标成为commiter

    WindyQin
  • 不要小看日本的AI公司

    有家日本AI创业公司,把这个当成奋斗目标挂在嘴边。而且还放言说,如果他们全速前进,肯定能干成世界第一。

    量子位
  • localStorage简单封装设置失效时间

    localStorage和cookie 的区别不详细对比,但是localStorage存储数据的时候有一点需要我们注意的。

    日薪月亿
  • 怎么快速判断 PHP 是 32 位还是 64位

    Swoole Compiler 加密是不支持使用 Debug 版本或 32 位的 PHP 的

    沈唁
  • 120页高清汽车构造图解

    作为一个机械工程师,你可以没有车,但对车的结构一定要有所了解。今天我们把车大卸八块看看看,构造图一目了然,还等神马,开始我们的拆车之旅吧!

    钱塘数据
  • ExtJs十二(ExtJs Mvc图片管理之二)

    接着图片管理一http://www.cnblogs.com/aehyok/archive/2013/04/27/3048278.html。

    aehyok
  • 面向开发人员的十大 NodeJS 框架

    Node.js 是基于 Chrome V8 javascript 引擎构建的开源、跨平台运行时环境。事件驱动的非阻塞 I/O 模型使 NodeJS 框架 能够开...

    疯狂的技术宅

扫码关注云+社区

领取腾讯云代金券