The Powers That Be want solid numbers on the cost of each type of crash being worked on
I want to fly in my hot air balloon to Mars, but it doesn't mean that such a thing is possible.
Seriously, I think you have a duty to tell them that there is no way to accurately measure this. Tell them you can rank the crashes, or whatever it is that you can actually do with your data, but that's all you've got.
Something like "We can't actually work out how much it costs. We DO have this data about how long things are running for, and so on, but the only way to attach costs is to pretend that X minutes equals X dollars even though this has no basis in reality"
If you just make some bullcrap costing algorithm and DON'T push back at all, you only have yourself to blame when management turns around and uses this arbitrary made up number to do something stupid like fire staff, or decide not to fix any crashes and instead focus on leveraging their synergy with sharepoint portal internet web sharing love server 2013
Update: To clarify, I'm not saying you should only rely on stats with 100% accuracy, and just give up on everything else. What I think is important is that you know what it is you're measuring. You're not actually measuring cost, you're measuring uptime. As such, you should be upfront about it. If you want to estimate the cost that's fine, but I believe you need to make this clear..
If I were to produce such a report, I'd call it the 'crash uptime report' and maybe have a secondary field called "Estimated cost based on $5/minute." The managers get their cost estimate, but it's clear that the actual report is based on the uptime, and cost is only an estimate, and how the estimate works.
I've not seen any studies, but a reasonable heuristic would be something like :
( Time since last application save when crash occurred + Time to restart application ) * Average hourly rate of application operator.
The estimation gets more complex if the crashes have some impact on external customers such, or might delay other things (i.e. create a bottle neck such that another person winds up sitting around waiting because some else's application crashed).
That said, your 'powers that be' may well be happy with a very rough estimate so long as it's applied consistently and they can see how it is changing over time.
There is a missing factor here .. most applications have a 'buckling' factor where crashes suddenly start "costing" a lot more because people loose confidence in the service your app is providing. Once that happens then it can be very costly to get users back to trusting and using the system.
In terms of cost, the only thing that matters is the business impact of the crash, so it rather depends on the type of application.
For may applications, it may not be possible to determine business impact. For others, there may be meaninful measures.
Demand-based measures may be meaningful - if sales are steady then down-time for a sales app may be useful. If sales fluctuate unpredictable, then such measures are less useful.
发布评论
评论（4）
我想乘坐热气球飞往火星，但这并不意味着这样的事情是可能的。
说真的，我认为你有责任告诉他们，没有办法准确衡量这一点。 告诉他们您可以对崩溃进行排名，或者您实际上可以对数据执行的任何操作，但这就是您所拥有的全部。
诸如“我们实际上无法计算出它的成本是多少。我们确实有关于运行时间的数据，等等，但附加成本的唯一方法是假设 X 分钟等于 X 美元，即使这在现实中没有根据”
如果你只是制定一些废话成本计算算法并且根本不反击，那么当管理层转身并使用这个任意编造的数字来做一些愚蠢的事情（例如消防人员）时，你只能怪自己决定不修复任何崩溃，而是专注于利用它们与 sharepoint 门户互联网网络共享爱情服务器 2013 的协同作用
更新：澄清一下，我并不是说您应该只依赖 100% 准确度的统计数据，然后放弃其他一切。
我认为重要的是你知道你在测量什么。 您实际上不是在衡量成本，而是在衡量正常运行时间。 因此，您应该坦率地说明这一点。 如果您想估计成本，那没问题，但我相信您需要明确这一点。
如果我要生成这样的报告，我会将其称为“崩溃正常运行时间报告”，并且可能有一个名为“估计”的辅助字段费用按 5 美元/分钟计算。” 经理们得到了成本估算，但很明显，实际报告是基于正常运行时间的，而成本只是一个估算，以及估算的工作原理。
I want to fly in my hot air balloon to Mars, but it doesn't mean that such a thing is possible.
Seriously, I think you have a duty to tell them that there is no way to accurately measure this. Tell them you can rank the crashes, or whatever it is that you can actually do with your data, but that's all you've got.
Something like "We can't actually work out how much it costs. We DO have this data about how long things are running for, and so on, but the only way to attach costs is to pretend that X minutes equals X dollars even though this has no basis in reality"
If you just make some bullcrap costing algorithm and DON'T push back at all, you only have yourself to blame when management turns around and uses this arbitrary made up number to do something stupid like fire staff, or decide not to fix any crashes and instead focus on leveraging their synergy with sharepoint portal internet web sharing love server 2013
Update: To clarify, I'm not saying you should only rely on stats with 100% accuracy, and just give up on everything else.
What I think is important is that you know what it is you're measuring. You're not actually measuring cost, you're measuring uptime. As such, you should be upfront about it. If you want to estimate the cost that's fine, but I believe you need to make this clear..
If I were to produce such a report, I'd call it the 'crash uptime report' and maybe have a secondary field called "Estimated cost based on $5/minute." The managers get their cost estimate, but it's clear that the actual report is based on the uptime, and cost is only an estimate, and how the estimate works.
我还没有看到任何研究，但合理的启发式应该是这样的：（
发生崩溃时上次应用程序保存以来的时间+重新启动应用程序的时间）*应用程序操作员的平均小时费率。
如果崩溃对外部客户产生一些影响，或者可能会延迟其他事情（即创建一个瓶颈，导致另一个人因为其他人的应用程序崩溃而只能坐在那里等待），那么估计就会变得更加复杂。
也就是说，你的“当权者”很可能会对一个非常粗略的估计感到满意，只要它始终如一地应用，并且他们可以看到它随着时间的推移如何变化。
I've not seen any studies, but a reasonable heuristic would be something like :
( Time since last application save when crash occurred + Time to restart application ) * Average hourly rate of application operator.
The estimation gets more complex if the crashes have some impact on external customers such, or might delay other things (i.e. create a bottle neck such that another person winds up sitting around waiting because some else's application crashed).
That said, your 'powers that be' may well be happy with a very rough estimate so long as it's applied consistently and they can see how it is changing over time.
这里缺少一个因素......大多数应用程序都有一个“弯曲”因素，崩溃突然开始“成本”更高，因为人们对您的应用程序提供的服务失去了信心。 一旦发生这种情况，让用户重新信任和使用该系统的成本可能会非常。
There is a missing factor here .. most applications have a 'buckling' factor where crashes suddenly start "costing" a lot more because people loose confidence in the service your app is providing. Once that happens then it can be very costly to get users back to trusting and using the system.
这取决于...
就成本而言，唯一重要的是崩溃的业务影响，因此它取决于应用程序的类型。
对于许多应用程序，可能无法确定业务影响。 对于其他人来说，可能有一些有意义的措施。
基于需求的衡量标准可能很有意义 - 如果销售稳定，那么销售应用程序的停机时间可能会有用。 如果销售波动不可预测，那么这些措施的用处就不那么大了。
维修费用也可能有用。
It depends...
In terms of cost, the only thing that matters is the business impact of the crash, so it rather depends on the type of application.
For may applications, it may not be possible to determine business impact. For others, there may be meaninful measures.
Demand-based measures may be meaningful - if sales are steady then down-time for a sales app may be useful. If sales fluctuate unpredictable, then such measures are less useful.
Cost of repair may also be useful.