故障管理的第一步是对故障的理解，只有正确地面对故障，我们才能够找到更合理的处理方式。

这便需要做两个工作：一是跟踪线上故障处理和组织故障复盘，二是制定故障定级定责标准，同时有权对故障做出定级和定责。

所以，这里的一个关键就是我们要有明确的故障定级标准。这个标准主要为了判定故障影响程度，且各相关利益方能够基于统一的标准判断和评估。

现实情况中，因为各方受到故障的影响不同，对故障影响的理解也不同，所以复盘过程中，经常会出现下面这两种争执场景。

1、技术支持判定故障很严重，但是责任方认为没什么大不了的，不应该把故障等级判定到如此之高；

2、技术支持认为故障影响较小，但是受影响方却认为十分严重，不应该将故障等级判定得这么低。

那么久需要故障等级设置为 P0~P4 这么 5 个级别，P0 为最高，P4 为最低。对于电商，主要以交易下跌、支付下跌、广告收入资损这些跟钱相关的指标为衡量标准。对于其他业务如用户 IM 等，主要区分业务类型，制定符合业务特点的定级标准。两个示例如下。

交易链路故障定级标准示例：

用户 IM 故障定级标准示例：

故障定级的标准，会由技术支持与各个业务研发团队进行点对点的细节沟通讨论，从业务影响角度把影响面、影响时长这些因素串联起来。这样即使在后续出现争执，也会有对应的标准参考。这个标准可能覆盖不到有些故障影响或特例，但是技术支持可以根据自己的经验进行“自由裁量”。同时，每个季度或半年对标准进行一次修订和完善。

不同的故障定级，在故障应对时采取的策略也就不同。一般来说，P2 及以上故障就需要所有相关责任人马上上线处理，并及时恢复业务。对于 P3 或 P4 的问题，要求会适当放宽。整个过程，技术支持会给出一个基本判断，然后会组织召集临时故障应急小组处理。

故障定级标准，主要是用来判定故障等级，使得故障相关方不至于过分纠结在等级标准上。而故障定责的主要目的是判定责任方。这就需要有明确的故障定责标准。

1、避免扯皮推诿。比如我认为是你的责任，你认为是我的责任，大家争执不清，甚至出现诋毁攻击的情况。

2、正视问题，严肃对待。不是为了处罚，但是作为责任方或责任团队一定要正视问题，找出自身不足，作为改进的主要责任者，来落地或推进改进措施。

关于定责，有下面几个维度供参考。

1、变更执行

比如变更方没有及时通知到受影响方，或者事先没有进行充分的评估，出现问题，责任在变更方；如果通知到位，受影响方没有做好准备措施导致出现问题，责任在受影响方；变更操作的实际影响程度大大超出预期，导致受影响方准备不足出现故障，责任在变更方。

2、服务依赖

比如私自调用接口，或者调用方式不符合约定规则，责任在调用方；如果是服务方没有明确示例或说明，导致调用方出现问题，责任在服务方等等。

3、第三方责任

比如机房 IDC 电力故障、服务器故障、运营商网络故障等等，如果确实是不可抗力导致，责任在第三方；但是因自身的冗余或故障预案问题导致故障，责任在应用 Owner。

有了这样的原则，在故障复盘时，就可以有效减少不和谐氛围的出现。因为每个公司的业务形态和特点不一样，里面的具体内容可能也不一样，上述的定责标准可能不完全适用，所以仅供示例参考。如果你在日常深受故障定责的困扰，建议尽快把规则明确起来，并能够与各方达成一致，这样就会最大程度地减少扯皮推诿的情况出现。

此文章为4月Day12 学习笔记，内容来源于 极客时间 《赵成的运维体系管理课》，推荐该课程。

1、影响功能正常使用的现象（服务中断、服务质量下降），服务不能执行规定功能的状态 2、用户反馈的大面积线上体验问题上述定义是理论层面的，实际工作中，会根据 故障 评分 定级 模型对线上问题进行分值 定级 考量，从五大维度进行评估：受影响业务功能、影响范围、影响量级、影响时长和受影响业务个数，根据维度对应的权重比例进行评分加权求和，分值大于40分的线上问题则定义为 故障 ，线上问题一般通过以下方式获取：各类监控系统、全国运营POC反馈渠道、SSC对接群。 连锁 故障 ：由于正反馈循环（positive feedb