故障处理与自动驾驶（63/100）

有天在设计故障处理机制时，突然想到故障处理的三种方式（手动处理，半自动处理，全自动处理）和汽车驾驶的三种方式（人工驾驶，辅助驾驶，全自动驾驶）有点类似。

现阶段团队技术能力不允许，架构不成熟，初期对故障的原因不够了解，这时候故障发生时，先进行告警，然后选择人工介入进行故障处理； 就好比，在当前阶段， 在复杂的路况下，选择人工驾驶是最靠谱的方案。

对故障原因有了了解之后，能够进行总结分析，罗列出可能的故障原因，这时候针对能够自动处理的故障就做自动处理，依旧无法处理的就提供处理建议，也就是所谓的半自动处理； 就好比，上了高速，可以开启领航辅助，让车子自动接管，遇到一些突发情况，比如堵车，有事故，高精地图没有覆盖等情况时，就要人工接管。

技术可靠了，架构稳定了，业务成熟了，对故障的原因也足够了解了，可以开启全自动处理了； 就好比智能汽车的全自动驾驶阶段。

我们目前故障处理还处于“辅助驾驶”阶段。 以供应链管理为例，我们背后也接入了一些数字权益的供应商， 我们的会员用户在充值数字权益时，由于各种原因会出现充值故障，通过几个月的观察，我们基本排查出了基本大部分的故障情况和原因，针对每一类故障进行分类和列出故障处理方式，形成了一套用户充值故障处理的 SOP 和技术框架。 我们在初期先进行告警提示，人工介入处理； 然后逐步过渡到 90%以上的情况自动处理，然后有些情况依然采用人工判断介入来完成。 一来保证了处理效率和确保了用户的使用体验 ，二来针对一些特殊情况，要留了冗余度，避免自动处理带来公司的损失。

总结一下故障处理的经验如下：

1. 分业务模块业务场景进行分析，针对业务逻辑进行埋点，将故障进行完全暴露告警，并打印所有相关的故障参数，出入参，方便后续的分析；

2. 对故障原因进行详细的分类，并形成不同故障分类的故障处理方式

3. 根据故障的情况先人工介入处理，然后进行交叉验证，确保人工处理后不会触发其他的问题

4. 经过一段时间，能够稳定处理的故障，开启自动处理，但是处理过程要进行飞书通知

5. 形成一套故障处理的技术框架，后面针对不同的业务场景可以复用