过去一段时间一直在处理公司一个IOT云平台集成测试的项目，对整个软件工程的可靠性进行全方位的思考与梳理，总结如下：
业务自身容错能力
业务本身的一个容错能力，不因上下游的错误而导致本端业务的崩溃或者进入不可用的状态，直白的讲就是个别的异常问题不应该影响到系统整体的可用性。对这个能力最直接的判断是达到几个9的可靠性。
辅助的旁路系统对业务功能出错时起到补位的作用。具体来讲，就是当业务本身由于在某一点上容错能力的缺失，导致业务进入不可用的状态时，怎样利用这个旁路让业务自身从不可用状态恢复过来。目的就是增加整个业务系统更高级别的可靠性，把原来的‘几个9’当中的9的数量进一步提升。当然提升的成本是很高的，另外有必要的话，这个旁路系统是可以多层、多维度的。
上面我们提及利用旁路系统增加软件可靠性的成本在通常情况下是很高的，一般情况下也没必要花很多精力、成本去将可靠性提升到概念上的‘及其可靠’，例如原来可靠性已经在3个9，即99.9%了，且业务允许这种级别的偶然性错误，那么再花精力去提升可靠性其实就没必要了，因为可能在你的系统出问题前地球都已经爆炸了。当然这个也是软件概念上的一般阐述，实际场景要怎样测量可靠性，怎样判断多大的可靠性能满足业务需求，都需要具体结合业务进行考量。
上述两个都失败的情况下，如何保证业务有足够的‘证据’可供追溯是系统可靠性救赎的最后一步。这个追溯可以是软件重启后，进行的自我修复，更可以是人工介入时可供分析的素材。这个证据就是我们一直在强调的log，根据这个log我们可以知道系统发生不可恢复的时候，经历了什么，外部系统对其施加了什么，内部发生了什么等等信息，根据这些信息判断出系统的缺陷。更重要的，我们还需要这些信息去恢复系统到一个稳定的状态。
上述就是我以为的软件可靠性的三重境界。
后面有机会结合实际业务谈谈我们应该怎样来践行上述三重境界。