背景：

不久前，我建立了一个系统来为我们的一个内部程序记录和分类应用程序崩溃。当时，我结合使用频率和总计丢失时间(程序启动与崩溃之间的时间)来确定崩溃类型的优先级。它运作良好。

现在，要处理的各种崩溃的成本要有实数。或者至少看起来很扎实的数字。我想我可以使用总计的损失时间乘以一个合理的数字，但这似乎是不可靠的。

问题：

是否有任何确定的方法来计算应用程序崩溃的实际成本？否则，发表有关此类成本的研究报告会失败吗？

共识

准确性是不可能的，但是，如果连续应用并且明确记录了其局限性，则基于正常运行时间的估计就足够了。感谢Matt，Orion抽出宝贵的时间回答这个问题。

解决方案

回答

我还没有看过任何研究，但是合理的启发式方法如下：

(自发生崩溃后最后一次保存应用程序以来的时间+重新启动应用程序的时间)*应用程序操作员的平均每小时费用。

如果崩溃对外部客户产生了某些影响，或者可能会延迟其他事情(即造成瓶颈，使另一个人因为其他人的应用程序崩溃而坐在那里等待)，则估算变得更加复杂。

就是说，"存在的力量"可能会对很粗略的估计感到满意，只要它被一致地应用并且他们可以看到它随着时间的变化而变化。

回答

The Powers That Be want solid numbers on the cost of each type of crash being worked on

我想乘热气球飞向火星，但这并不意味着这样的事情是可能的。

认真地说，我认为我们有责任告诉他们没有办法准确地衡量这一点。告诉他们我们可以对崩溃进行排名，或者实际上可以对数据进行处理，但是仅此而已。

诸如"我们无法实际计算出多少费用。我们确实有运行所需时间的数据，依此类推，但是添加费用的唯一方法是假装X分钟等于X美元这是没有现实依据的"

如果我们只是制定一些废话成本计算算法而完全不退缩，则只有在管理层转机并使用这个随意编造的数字来做一些愚蠢的事情(例如消防员)，或者决定不解决任何崩溃和故障时，才有责任怪自己。而是专注于利用Sharepoint Portal Internet Web Sharing Love Server 2013的协同作用

更新：为澄清起见，我并不是说我们应该仅依靠统计数据达到100％的准确性，而放弃其他所有内容。
我认为重要的是我们知道要测量的内容。我们实际上并不是在衡量成本，而是在衡量正常运行时间。因此，我们应该提前做好准备。如果我们想估计可以的费用，但是我相信我们需要澄清一下。

如果要生成这样的报告，则将其称为"崩溃正常运行时间报告"，并且可能会有一个辅助字段，称为"基于每分钟5美元的估算成本"。经理们得到了他们的成本估算，但是很明显，实际的报告是基于正常运行时间的，成本只是一个估算，以及估算的工作方式。

回答

这里缺少一个因素。.大多数应用程序都有一个"扭曲"因素，其中崩溃突然开始增加了"成本"，这是因为人们对应用程序提供的服务失去信心。一旦发生这种情况，那么让用户重新信任和使用该系统可能会非常昂贵。

回答

这取决于...

就成本而言，唯一重要的是崩溃的业务影响，因此它取决于应用程序的类型。

对于可能的应用程序，可能无法确定业务影响。对于其他人，可能会有有意义的措施。

如果销售稳定，那么基于需求的措施可能会有意义，那么销售应用程序的停机时间可能会有用。如果销售波动无法预测，那么这些措施就没什么用了。

维修费用也可能有用。