1. 故障分类

将故障分类可以帮助运维人员和开发人员，根据不同的故障类型选择不同的处理方案，也可以根据不同的类型来制定更有针对性的告警阈值。一般来说，故障可以分为错误、延迟、流量和资源这 4 个类别。

• 错误类：某个组件、服务或者接口出现执行错误。这类错误比较直观，一般日志中都会有对应的错误详情。但需要注意的是，错误类的故障有时只能代表表象，并不能代表真正发生的原因。比如接口执行超时，此时就需要更细致地观察这个执行链路里下游的延迟原因。
• 延迟类：服务之间的通信耗时，或者是服务本身的耗时。这类错误一般需要结合具体的内容来看，比如 MySQL 出现了慢 SQL，此时就需要定位具体的 SQL 再进行优化。如果突然出现类似的告警，通常是系统出现问题的前兆，要多加注意。
• 流量类：服务本身所承担的访问压力。一般这一类型的故障更多的说明的是目前产生的现象，通过这些我们可以看到当前服务的请求情况，比如 QPS 突然的大幅下跌上涨，服务调用量突然掉到 0。
• 资源类：组件或者基础服务中的资源使用情况。通过这部分数据，我们可以看出是哪些资源出现了问题，再然后寻找问题的原因，比如机器中的 CPU 使用率突然升高，我们可以去 CPU 中寻找；Dubbo 中的执行线程数突然增多，我们可以去查看是否有请求堆积。

就是这 4 类故障通常不会单独出现，很多时候会彼此之间组合发生。比如表象上是某个接口出现了高延迟的现象，但底层的原因可能是某个系统的资源数使用不足导致的。

2. 故障分级

在互联网企业中为了管理好系统的可用性，界定好系统故障以后的责任，通常会用故障分进行管理。一般过程是，根据系统可用性指标换算成故障分，是整个系统的故障分，比如 10万 分，再根据各自团队各个产品各个职能角色承担的责任的不同，会把故障分下发给每个团队，直到每个人，也就是说每个工程师在年初的时候就会收到一个预计的故障分。然后每一次系统出现可用性故障的时候，都会进行故障考核，划定到具体的团队和责任人以后，会扣除他的故障分。如果到了年底的时候，一个工程师，他的故障分被扣为负分，那么就可能会影响他的绩效考核。

故障分的计算方式是用故障时间乘以故障权重来计算得到的。而故障的权重通常是在故障产生以后，根据影响程度，由运营方确定的一个故障权重值。下图是故障权重的示例。

3. 故障处理流程和故障时间

再看一般互联网应用的故障处理流程和故障时间的确定，如下图。

首先是故障的开始，故障的开始时间是客服报告故障的时间点，或者是监控系统发现故障的时间点，如果客服收到了投诉，说系统不可用，这个时候就开始计算故障时间。或者监控系统发现，用户访问量或者是订单量因系统故障而出现了大幅的下跌，那么监控系统监控到的故障时间点就是故障的开始时间。

确定了故障以后，就把故障提交给相关部门的接口人，接口人再把故障现象发送给相关的责任人，责任人接手故障后，进行故障排查和处理。处理完毕以后系统重新启动，或者是代码重新发布上线以后，重新确认系统指标正常或者是功能恢复正常，确认故障处理完毕，这个时间就是故障的结束时间。

我们刚才用来计算故障分的故障时间，就是用这个故障结束时间减去开始时间，就是故障时间。这个时间通常以秒为单位，故障处理整个过程是争分夺秒的。故障结束以后，通常要开一个故障复盘会，检讨故障产生的原因，亡羊补牢，避免下次出现类似的故障，同时也要对引起故障的原因进行责任划分，扣除相关责任者的故障分计入绩效考核。

4. 参考资料

《架构师的 36 项修炼》

《分布式链路追踪实战 》