故障生命周期
约 1882 字大约 6 分钟
2025-10-10
故障还是缺陷？
如何理解和区分，一个问题到底是故障还是缺陷？
故障：故障通常指的是设备、系统或组件在其运行过程中出现的异常或失效状态。这种状态可能导致设备或系统无法正常工作或达到预期的性能水平。故障是动态的，发生在设备或系统的使用或运行过程中。
缺陷：缺陷则是指设备、系统或组件在制造、设计或安装过程中存在的瑕疵或不足。这些瑕疵可能导致设备或系统在使用过程中出现故障。缺陷是静态的，是存在于设备或系统本身的一种状态或属性。
故障 突发性，即设备或系统在正常运行过程中突然出现的异常。 可能由多种因素引起，包括缺陷、操作不当、环境因素等。 通过维修、更换或调整来修复。 VS 缺陷 固有的，即设备或系统在制造、设计或安装时就已存在。 可能导致设备或系统在使用过程中出现故障，但并非必然。 通过改进设计、制造工艺或质量控制来消除。
一句话总结：缺陷是故障的可能原因，而故障是缺陷导致的可能结果。
故障发生
如何判断故障的最初发生时间？
存在明确日志、监控、告警的情况，以系统记录时间为准。 用户/客户反馈情况，先以具体反馈时间为准，故障处理完再追溯。如无法确认故障发生时间，缺省即可，后续计算时以故障发现时间为起始。 以下还会存在一些小概率事件： 累积性故障，以劣化点开始计算时间。如内存泄露，以实际影响到服务时开始计算。 概率性故障，以第一个请求日志为准，开始计算故障时间。如单点/单机、单人出现故障。 夜间等非活跃时间发生故障，按照实际情况记录即可。
故障发现
主要是人或机器两大维度。以人发现为主的系统，我们通常会认为可靠性较差，且被动；而以机器发现、故障自愈的系统，我们则会认为可靠性较好。
生产实务中，按照以下情况，记录实际时间即可，以最初发现时间为准。
人：用户发现（toC或toB的实际使用人员）/客户发现（toB甲方）
机器：监控告警、巡检拨测
故障定位
故障定位到什么样的程度，才能叫发现根因？
为了确保故障定位的客观性和准确性，避免主观臆断、片面，我们通常采用5W1H方法。比如： 为什么会出现故障？什么时候开始故障？谁的变更导致了故障？故障点在哪里？如何解决这个故障？ 避免毫无根据的猜测，在客户生产环境中反复尝试，进而导致故障影响升级。 同时，也应尽量避免定位扩大化，造成不必要的资源浪费。
故障修复
修复故障的方式，真的合适吗？
- 优先尝试恢复，包括回滚、重启等；
- 无法恢复时，及时止损，避免故障影响进一步扩大，包括降级、熔断等；
- 最后再考虑如何彻底解决。
故障恢复
谁来确认？如何确认？
确保至少2人以上确认，避免故障恢复后出现遗漏。建议运维+客户双确认。
健康检查？服务状态检查？监控曲线？告警信息？
故障影响
如何定义故障影响？如何根据故障影响定级？
损失度量维度：时长、流量、资损、口碑
时长 主要故障发生，我们肯定希望影响时长越短越好。缩短故障时长的关键在于，早发现、早修复。
流量 对于流量依赖很强的互联网公司而言，流量意味着公司的营收和生命线。因此，在无法及时恢复时，采用降级、限流、熔断等手段，放弃一部分业务或用户体验，以追求更高的可靠性来保障核心业务的健康，也是非常常见的情况。
资损 服务不可用最终影响到交易量，引发资损。或触发了SLA导致赔偿，也会引起资损。
口碑 引发舆情、冲上热搜、引起甲方/项目方/管理层的不满等，都是常见的口碑影响。
回到正题，如何根据故障影响定级？ 首先确定上述维度中我们的关注方向，然后结合实际情况，确定故障定级的指标，最后按照不同程度划分等级，并在实操中结合可靠性建设的完整度和团队能力的成长，不断调整指标和定级。
故障复盘
最后，当故障处理完毕，我们还需要做好故障复盘。
并且，完成根据故障复盘整理出的待办项，做好故障闭环。
故障背景、故障影响、故障定级、时间线梳理、改进措施和预防策略、待办项指定到人并及时追踪。
对于故障，系统性、数字化的记录和持续改进。
故障管理
这块偏管理手段
故障应急小组、应急机制（值班机制、接口人列表、摇人机制、...）
指标拆解
当故障发生后，存在两种情况：
- 故障触发了告警，并且我们迅速感知到了告警；（故障发生--->故障发现 的时间是T0）
- 故障未触发告警，或告警无法及时感知，依赖客户反馈；（故障发生--->客户发现--->客户反馈，如果能回溯故障发生时间最好，如不能则只有将客户发现到反馈的时间作为T0，即Tx未知、T0'当作T0）
感知到故障后则进入定位，同样分为两种情况：
- 有告警，能直接根据告警去定位，此时影响故障定位时间的关键因素在于日志、监控等手段的完善程度，以及告警有效率；
- 若是客户电话或其他途径反馈，还存在问题沟通时间，这里统一抽象成问题沟通环节，此环节的耗时大概率由沟通双方、问题本身等决定，记为T2.1；
正式进入故障定位后，大概率还需一段时间查日志、监控确认，记为T2.2；若告警有效率为100%，则T2这段时间就是完整的故障定位时间。
实际情况下，大概率是 问题确认/问题沟通+问题定位 最终组成故障定位时长。
后续就比较明确了，故障定位完成 到 故障修复 时长为T3，修复完到 故障恢复 时长为T4。
当然，也存在一些特殊情况，比如客户异地，需要出差前往，则不同场景下故障定位时长会存在明显差异。在具体统计时，可排除 接收到反馈 至 到达客户现场 的区间，也可将此类时间单独记录。