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