如何制定业务的故障分级标准？

本文来自于架构实战营学员的求助，回答后觉得很典型，整理成文供大家参考学习。

相信很多同学都有这样的想法，找大公司比如说阿里腾讯的故障定级标准，然后拿过来套到自己的业务上，这样简单方便，毕竟 BAT 都是这么干的，我们跟着学肯定没错。

但这样做其实就很容易掉到坑里去了，为什么直接学习大公司的标准，结果还掉到坑里去了呢？有几个核心的原因：

1）业务领域不同，故障的定义和容忍度都会不同：比如说支付业务和社交业务，很显然支付业务的故障容忍度要低，毕竟和钱打交道；同样是电商，拼多多用户 6 亿，而一个小程序电商用户可能就 100 万；

2）大公司的基建和技术能力很强：比如说淘宝的单元化、异地多活；蚂蚁的底层数据库是 OceanBase，一般的公司没有这个技术能力或者还没有做相应的高可用方案；

3）大公司的高可用配套完善：比如说完善的监控运维平台、全链路跟踪、各种问题定位工具等，不是所有的公司都具备这样的配套设施。

基于以上三点，故障分级标准也一定要遵循架构实战营讲的三原则中的“合适原则”和“演进原则”，不能简单照搬网上或者其它公司的标准，而应该基于自己的业务、技术、团队来按需定制（合适原则），然后随着业务和技术发展逐步调整（演进原则）。

在具体制定故障分级标准的时候，有几个通用的原则，这个原则是和公司大小以及业务类型没有关系的。具体如下：

1）合适原则：这点最重要，并不是可用性要求越高越好，适合团队和业务最重要，因为要提升可用性是需要投入的，而且越到后面代价越大，比如说：从 99.9 提升到 99.95，代价可能是做同城双机房，而从 99.95 提升到 99.99，代价就是做异地多活了；而且可用性的提升是一个体系化的工程，并不是在纸上把标准写高了就自然达到了，而是要有各种措施来保障，包括自动化测试、全链路跟踪、自动化运维监控平台，强大的基础设施等；

2）风险共担原则：这点非常重要，否则就会出现头脑简单的产品经理或者业务老大，无限拔高可用性要求，如果产品不愿意承担风险，那么就不要制定这样的标准，因为必然是技术背锅，而且产品也跑不了，因为出了 P0/P1/P2 的故障是要汇报给高层级大佬的，汇报的时候“产研测维”一个都跑不了。

3）业务导向原则：从业务角度触发来分级：影响程度 = 业务重要性 * 影响范围 * 影响时长，比如说淘宝的领金币，就算 100%的用户全部不可以领，影响程度也没有 5%的用户不能下单那么大。

什么样的标准算是比较合理的呢？正常来说：3 年都不应该发生一次的是 P0，1 年最多发生 1 次的是 P1，1 个季度最多发生 1 次的是 P2，P3/P4 是可以发生的，完全杜绝 P3/P4 的故障是不可能的，当然也不能太多，总体趋势应该是逐渐减少。

关于风险共担原则，如果遇到头铁的产品人员，肯定会跳出来说“可用性是技术的事情”，但是这里要据理力争，那怎么争呢？

第 1 个技巧是：产品设计不合理的要求会导致技术方案变复杂和容易出错（当然，头铁的产品还是会说那也是你们能力的事情）；

第 2 个技巧：出了 P0/P1/P2 的故障是要汇报给高级别的，汇报的时候产品也要去，而且技术可以说是产品设计太复杂要求太高，在大佬的眼中，最后只会看到“某某产品很烂，经常出故障经常汇报”，大佬绝不会说“这个业务的产品人员很厉害，只是技术人员差了点” ：）

第 3 个技巧：墨菲定律，不可能做出一个没有任何问题的系统，提升可用性是需要巨大投入的，包括流程、人员、基础设施等，巧妇难为无米之炊，可以给老板讲讲阿里腾讯怎么做各种保障的，以及要实现这些东西代价是什么；

下面给出一个模板参考，大家可以根据自己的业务增加对应的列：

制定标准后，最好先按照架构实战营讲过的 FMEA 方法分析一下业务的现状技术能力，看看是否真的能够达到。如果明确达不到标准，要么调整标准，要么架构重构。