并非所有的bug都值得改，也可以不改。
作为软件开发者，最想做的事情就是给客户建立并发布最完美的产品和功能。但你也知道，软件开发并不容易，每次修改肯定都会引入bug。毕竟，就像迪杰斯特拉说过的那样，“如果说调试是去除软件bug的过程，那么编程就是引入bug的过程。”
由于这些bug会影响到客户，你可能会强烈地希望改正应用程序中的每个bug。
而这几乎是不可能做好的。
应用程序稳定性和零bug
没有完全无bug的应用程序，因此拥有一个有效处理bug的策略是非常重要的。因此，应用程序稳定性目标对于敏捷团队十分重要。稳定性可以定义为在特定的发布中，每次交互会话中的成功的应用程序交互的百分比。这个值就是用户使用应用程序时遇到的崩溃（未处理的错误）的百分比。
对可用性的思考有助于理解稳定性目标。你可能已经很熟悉“五个九”的可用性（https://en.wikipedia.org/wiki/High_availability#%22Nines%22），而且你也知道即使100%的目标似乎可以达到，也没必要去追求。超过某个点只有，高可用性带来的回报几乎降为零，而成本却非常高，使得高可用性不再有收益。Sean Hull在《为何高可用性被过誉了》（https://www.iheavy.com/2012/04/01/the-myth-of-five-nines-why-high-availability-is-overrated/）一文中谈过这一点。
“实际上，维持五个九的标准的高可用性就要花掉很多钱。”
稳定性也很相似。超过某个点之后，由于构建新特性的高昂机会成本，继续修改bug的代价变得非常高。因此，你需要像可用性目标那样确定稳定性的目标，而且这个目标不应该是100%。
原因如下……
敏捷统治世界
敏捷开发已经成为最主流的软件开发过程，已经取代了瀑布式开发，成为构筑软件的事实标准。在VersionOne发布的2018年敏捷开发报告（https://explore.versionone.com/state-of-agile/versionone-12th-annual-state-of-agile-report）指出，97%的受访者都说他们的组织在使用敏捷开发。敏捷团队能以更快的速度构建和发布软件。许多实践，如持续部署，能让开发者能更快速地进行迭代，比如每周迭代，甚至每天迭代一次。更快的发布周期使得上线后的bug修复变得更容易，因此在发布之前修正每个bug的重要性已经没那么高了。但是，敏捷开发留给传统的QA和测试过程的时间也变少了，从而增加了bug进入产品的风险。
那么，怎样才能在快节奏的开发和bug之间取得平衡？你需要有个关于应用程序稳定性的反馈回路，以便使用稳定性监视工具进行跟踪。
客户的选择
客户能够选择他们使用的应用，因此要想留住客户，那么发布高质量、可靠的应用是非常重要的。举个我们都见过的常见例子。你要去开个会，于是你打开了一个打车因公。但很讨厌的是，Uber不好用而且崩溃了。但会还是要去开的，所以你使用Lyft及时地赶到了会场。由于这种情况太容易发生了，因此你可能会强迫自己改正每个导致这种情况的bug。但Jeff Atwoods提出了个很重要的问题（https://blog.codinghorror.com/not-all-bugs-are-worth-fixing/）：
“怎样才能区分出用户可能会遇到的bug，和用户可能根本不会遇到的bug？”
这个问题很重要，而且可以想像，竞争对手也在试图回答这个问题，所以他们会通过快速发布新功能来改进产品。
客户端的西部世界
并非所有bug都是平等的，在客户端应用中尤为如此。
JavaScript现在非常火，69%的开发者都使用JavaScript（https://insights.stackoverflow.com/survey/2018/#technology-programming-scripting-and-markup-languages），使之成为了最流行的编程语言。JavaScript的难题之一就是，在部署到浏览器之后，应用程序的行为可能会有区别。由于数量庞大的浏览器种类、版本、扩展和其他影响应用程序稳定性的因素，使得考虑所有可能情况几乎是不可能的。而且由于有这么多变种，许多稳定性问题其实都是极端情况，不会影响到绝大多数用户。例如，由于Internet Explorer 6现在使用的人非常少，而且它的行为十分怪异，因此调查IE6造成的bug基本上没什么用。
移动应用也给开发者带来了类似的挑战。安卓设备之间的碎片化现象非常严重。你知道吗？2015年市场上有24000种不同的安卓设备（https://opensignal.com/reports/2015/08/android-fragmentation/）！
移动设备上的部署的结果更难以预料，因为设备和设置会呈现巨大的区别，从而与应用交互时可能会造成各种问题。与JavaScript相似，许多bug都是极端情况，只会 影响到极其罕见的一部分手机。
花上几个小时去修改只影响到少数几个用户的bug是十分不划算的。
功能还是bug？二选一
正如Eric Sink所写的那样（https://ericsink.com/articles/Four_Questions.html），“关于软件质量的决定很困难且很重要，做出这些决定需要非常高的只会。有时‘bug’不应该被修改。”那么，怎样考虑bug的问题更合适？
将稳定性变成团队的KPI。
选一个能够达到的目标，将其作为团队有意义的努力方向。稳定性目标可以通过数据驱动的方式帮你在工程资源方面作出决策。在做sprint计划时，是应该分配时间修改问题，还是应该全力朝着产品地图努力？应用程序的稳定性可以帮你作出决定。
花些时间重新射审视监视数据是值得的，这样可以确保你能得到重要的反馈，或者了解是否需要改进策略。我留下几个问题供读者思考：
团队是否在考虑应用程序稳定性？
你在修复bug和构建新功能之间如何抉择？
你的团队怎样跟踪bug并设定bug修复的优先级？
原文：https://blog.bugsnag.com/application-stability-monitoring/
作者：Kristine Pinedo，bugsnag的社区内容管理。
译者：弯月，责编：郭芮