最近在制定故障等级，陷入了细节矛盾中，想听听大家的公司都是如何去定义的？

我的思路是这样，故障等级的影响因素包括功能的重要性，影响用户数，时长；
功能的重要性我们可以根据业务去给每个功能定义一个功能分，比如非常非常核心的我们可以定义为 1，稍次之 0.9、0.8 依次；
影响用户数，这个指标不太好去衡量，不能用绝对值，需要有个用户比的概念，比如端上某个版本的 bug，是用出问题的用户数/这个版本的用户数，还是用出问题的用户数/日活？
前者的话容易出现比较极端，比如新版本一共 20 个用户，如果 20 个用户都有问题，那这个指标就变成了 100%，能说这个问题很严重么，似乎也不能这么定义；后者是容易造成这个指标非常小，同时影响这个指标的权重变得很小；同样的，如果是服务器的错误，怎么去定义这个用户比？
最后时长这个因素，关于时长想到了两点，一个是影响时长一个是处理时长，影响时长因为差别很大，可能会是这个指标的权重变大，比如一个非常不重要的功能如果影响时长很久可能会比一个很重要的功能但影响时长很短计算出来的故障等级分更重，所以有考虑是否把这个指标去掉？然后关于处理时长，可以当故障超时处理时用于升级故障等级，比如一个 P2 的故障是不是超过多少时间未处理时就升级成 P1，但 P2 这个定义可能是故障解决时才能给出，这个时候才能去计算影响了多少用户，此时超时的影响已经体现在了影响用户变多了，已经对故障等级分计算上产生了影响，是否还需要再去升级故障等级？

希望各位有经验的同学帮忙解决疑惑！
感激不尽！