故障必然发生

2019年3月3号阿里云宕机持续3个多小时，华北地区很多公司的网站，APP， 内部系统纷纷瘫痪。消息立马上了社交的头条，大家都调侃“一年一挂，今年比往年早一些”。
阿里这样的大公司，技术实力是毋庸置疑的，也不可避免的出现大大小小的各种故障。我想在互联网行业的打工人都感同身受吧，生产环境的故障就没断过，总会在某些特殊的时刻出现，给你一个大大的“惊喜”。无论是传统的软件时代，还是现在的互联网，云时代，随着时间的推移，软件硬件的持续运行， 终究会在某个时间点被终结，走向失败。
那么，我们要做什么呢？面对不同的级别的故障或者问题，我们要用合理的成本，有效的方法保障业务的连续性，持续性。这个过程中，面向失败的设计特别的重要，业务的持续性，取决于我们对异常场景的投入了多少精力。

失败场景

这里例举我遇到的一些常见的失败场景

硬件问题

硬件有固有的生命周期，它随着时间推移一定会老化，而且会在某个不确定的时间点损坏。还有可能受到外力的因素导致损坏，譬如火灾，地震等等。
我自己每天巡检系统，有时候就会遇到某一个节点的异常（尽量排除了系统异常软件异常的情况下），采取换机器的方式来解决。

代码bug

这个就更常见了， 即使是非常优秀的程序员写出来的代码，经过严格的测试，上线后依然可能存在bug。我不优秀，所以我每天背着沉重的电脑来回跑，深怕突如其来的bug，哈哈。

配置变更错误

现在都流行分布式的统一配置中心进行灵活的配置系统的一些变量，方便是挺方便的。但人为的配置难免会出现疏忽大意，考虑不周（这个也是血淋淋的教训，线上出现过几次因为统一配置错误出现故障）。另外由于所有的项目都依赖于统一配置系统，如果统一配置系统出现故障，也会导致大量的系统异常。

洪峰流量

对于突发流量导致系统异常也是屡见不鲜，譬如某巨星发布了离婚的消息，如果不提前告诉新浪微博，那么微博随时可能会宕机啦。

依赖服务问题

依赖的服务肯定不会100%可用，它们随时会超时，会失败。当依赖的服务超时了，你没有很好的处理，那么可能会导致你自己的系统不可用。在分布式的情况下，可能会将异常辐射出去，最终导致大量的系统不可用。

依赖库问题

我们系统依赖的各种库，用到的各种组件，封装好的工具，使用的时候很爽，功能完成的很快。但它们对我们来说是黑盒，你不了解它们，会存在哪些风险，存在哪些漏洞 （譬如fastjson暴露出来的漏洞好几个），即使是公司内部的组件也一样可能存在bug，一句话，就是不能完全信任它们，尤其是非常重要的业务功能，更要当心。

系统的恶化

春节前，我还跟同事开玩笑，要在封网前把各个系统都重启一下，防止出纰漏。为啥呢？随着时间推移原本工作的很好的程序可能不能再正常工作。譬如：缓存的数据逐渐增大空间不足了，代码哪里写的有问题内存泄露了等等。

后续再介绍避免单点故障，异地多活架构，依赖调用的自我保护，精细化监控体系，故障与攻防演练等等。