前段时间，我为我们的一个内部程序构建了一个系统，用于记录和分类应用程序崩溃。当时，我结合使用频率和累计损失时间（程序启动和崩溃之间的时间）来确定崩溃类型的优先级。它工作得相当好。
现在，The Powers That Be 希望对正在处理的每种类型的崩溃的成本 有可靠的数字。或者至少，看起来可靠的数字。我想我可以用总损失时间乘以某个似是而非的数字，但这似乎很狡猾。
是否有任何既定方法可以计算应用程序崩溃的实际成本？或者做不到这一点，发表的研究推测这种成本？
准确性是不可能的，但如果始终如一地应用并且清楚地记录其局限性，则基于正常运行时间的估计就足够了。感谢 Orion 的 Matt 抽出时间来回答这个问题。
【问题讨论】：
标签： crash statistics crash-reports
The Powers That Be 想要关于正在处理的每种类型的崩溃成本的可靠数字
我想乘坐热气球飞往火星，但这并不意味着这样的事情是可能的。
说真的，我认为你有责任告诉他们没有办法准确衡量这一点。告诉他们您可以对崩溃进行排名，或者您可以对数据实际执行的任何操作，但这就是您所拥有的一切。
类似于“我们实际上无法计算出它的成本。我们确实有关于运行时间等的数据，但附加成本的唯一方法是假装 X 分钟等于 X美元，尽管这在现实中没有根据”
如果您只是制作一些废话成本计算算法并且根本不推回，那么当管理层转身并使用这个任意编造的数字做一些愚蠢的事情（例如消防人员）或决定不修复时，您只能责怪自己任何崩溃，而是专注于利用它们与 sharepoint 门户互联网网络共享爱服务器 2013 的协同作用
更新：澄清一下，我并不是说你应该只依赖 100% 准确的统计数据，而放弃其他一切。
我认为重要的是你知道你在测量什么。您实际上不是在衡量成本，而是在衡量正常运行时间。因此，您应该提前了解它。如果您想估算成本，那很好，但我认为您需要明确这一点..
如果我要生成这样的报告，我会将其称为“崩溃正常运行时间报告”，并且可能会有一个名为“基于 5 美元/分钟的估计成本”的辅助字段。经理们得到了他们的成本估算，但很明显，实际报告是基于正常运行时间，而成本只是一个估算，以及估算的工作原理。
【讨论】：
我没有看到任何研究，但一个合理的启发式应该是这样的：
( 自上次应用程序崩溃发生时保存的时间 + 重新启动应用程序的时间) * 应用程序操作员的平均每小时费率。
如果崩溃对外部客户有一些影响，或者可能会延迟其他事情（例如，创建一个瓶颈，导致另一个人因为其他人的应用程序崩溃而坐等等待），那么估计会变得更加复杂。
也就是说，你的“能力”可能会对一个非常粗略的估计感到满意，只要它始终如一地应用并且他们可以看到它随着时间的推移如何变化。
【讨论】：
这里缺少一个因素 .. 大多数应用程序都有一个“屈曲”因素，崩溃突然开始“花费”更多，因为人们对您的应用程序提供的服务失去信心。一旦发生这种情况，让用户重新信任和使用系统的成本可能非常。
【讨论】：
这取决于...
在成本方面，唯一重要的是崩溃的业务影响，因此它取决于应用程序的类型。
对于可能的应用程序，可能无法确定业务影响。对于其他人来说，可能会有一些有意义的措施。
基于需求的措施可能很有意义 - 如果销售稳定，那么销售应用的停机时间可能会很有用。如果销售波动不可预测，那么这些措施就没那么有用了。
维修费用也可能有用。
【讨论】：