如何计算事故的“成本”？[关闭]

Question

背景：

前段时间，我为我们的一个内部程序构建了一个用于记录和分类应用程序崩溃的系统。当时，我结合使用频率和累计损失时间（程序启动和崩溃之间的时间）来确定崩溃类型的优先级。它运作得相当好。

现在，当权者希望获得可靠的数字 成本 正在处理的每种类型的崩溃。或者至少，数字 看 坚硬的。我想我可以使用总损失时间乘以一些合理的数字，但这似乎很狡猾。

问题：

是否有任何既定的方法来计算应用程序崩溃的实际成本？或者如果做不到这一点，已发表的研究推测此类成本？

---

共识

准确性是不可能的，但如果一致地应用并且清楚地记录其局限性，则基于正常运行时间的估计就足够了。谢谢马特、猎户座花时间回答这个问题。

Answer 1

我还没有看到任何研究，但合理的启发式是这样的：

（自上次发生崩溃时保存应用程序以来的时间 + 重新启动应用程序的时间） * 应用程序操作员的平均小时费率。

如果崩溃对外部客户产生一些影响，或者可能延迟其他事情（即，），则估计会变得更加复杂。创建一个瓶颈，导致另一个人因为其他人的应用程序崩溃而坐下来等待）。

也就是说，你的“当权者”很可能会对一个非常粗略的估计感到满意，只要它始终如一地应用，并且他们可以看到它随着时间的推移如何变化。

Answer 2

当权者希望获得有关正在处理的每种类型事故的成本的可靠数据

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

说真的，我认为你有责任告诉他们，没有办法准确衡量这一点。告诉他们您可以对崩溃进行排名，或者您实际上可以对数据执行的任何操作，但这就是您所拥有的全部。

比如“我们实际上无法计算出它的成本是多少。我们确实有关于运行时间等的数据，但附加成本的唯一方法是假装 X 分钟等于 X 美元，即使这没有现实基础”

如果你只是制定一些废话成本计算算法并且根本不反击，那么当管理层转身并使用这个任意编造的数字做一些愚蠢的事情（例如消防人员）或决定不修复任何崩溃时，你只能怪自己相反，专注于利用其与 Sharepoint 门户互联网网络共享 Love Server 2013 的协同作用

更新： 澄清一下，我并不是说你应该只依赖 100% 准确的统计数据，而放弃其他一切。
我认为重要的是你知道你在测量什么。您实际上不是在衡量成本，而是在衡量正常运行时间。因此，您应该坦率地说明这一点。如果您想估算成本，那没问题，但我相信您需要明确这一点。

如果我要制作这样的报告，我将其称为“ Crash Uptime Report”，也许有一个名为“基于5美元/分钟的估计成本”的次要字段。经理们获得了成本估算，但是很明显，实际报告基于正常运行时间，成本只是一个估计，以及估算的工作原理。

Answer 3

这里缺少一个因素..大多数应用程序都有一个“弯曲”因素，崩溃突然开始“损失”更多，因为人们对您的应用程序提供的服务失去了信心。一旦发生这种情况，那么就可以 非常 让用户重新信任和使用该系统的成本高昂。

Answer 4

这取决于...

在成本方面， 仅有的 重要的是 商业冲击 崩溃的程度，因此这取决于应用程序的类型。

对于许多应用程序，可能无法确定业务影响。对于其他人来说，可能有一些有意义的措施。

基于需求的衡量标准可能很有意义 - 如果销售稳定，那么销售应用程序的停机时间可能会有用。如果销售波动不可预测，那么这些措施的用处就不那么大了。

维修费用也可能有用。