导致系统不可用的原因有哪些？保障系统稳定高可用的方案有哪些？请分别列举并简述。

不可用的原因

导致系统不可用的原因可以分为内部原因和外部原因，内部原因可以分为，软件问题和硬件问题。外部原因一般是自然灾害或者人为灾害。

内部原因：

1、软件问题，软件的 bug 导致内存溢出，数据库连接被占用，不合适的加锁响应慢。还有一些缓存的设计没有起作用，存储设计不合理等等。

2、硬件问题，硬件是软件的载体。如果载体有问题，那运行上面的软件更容易出问题。硬件问题，最常见的硬盘问题，内存问题，电源，网络，操作系统等问题。

外部原因：

1、自然灾害：洪水，挖断电缆，断电等等

2、人为灾害：对系统维护时，修改文件数据库等等。还有一次当不同厂商的软件放到同一台服务器的时候，别的厂商维护自己软件的时候，杀掉所有的 java 进程，启动自己厂商的软件，你的软件程序刚好是 java 的程序，于是莫名其妙的遭殃

保障系统稳定高可用的方案

架构方案：

解耦：

解耦是最好的方案也是没有标准的方案。因为很难有标准，但是很有效。解耦可以降低程序之间的复杂性，降低复杂性，有软件引起的锁，数据库连接等这种隐形资源问题就可以轻松解决。也能更聚焦业务，写出的代码更容易维护。不同的模块之前可以消息队列，也能提高吞吐量。

分流：

解耦是程序内部模块化，在程序内部可以做一些并流处理，也可以做一些串流处理。现在分流是指当外部人员，app 等其他应用接口访问程序做分流操作。可以利用硬件，域名，DNS，负载均衡到不通的机房，不同的服务器去处理用户请求。在同一个机房，不通服务器之间按照能够处理的上限也可以做一些限流措施，也可以做一些降级，熔断等等。

配置中心：

有很多问题都是出现在配置上，配置中心的修改，下发要统一维护，统一下发。保证相同软件的机器的配置都一样，这样可以减少很多奇怪的问题。

异地多活：

当某一个机房因为自然灾害或者人为原因导致服务不可到达，就要有异地多活的架构。异地多活的架构主要要考虑网络延迟，一般来说机房离的越近，网络的速度影响越小。但是离的越近，受影响的关联程度越大。比如洪水，地震等灾害。比如北京，天津的机房。相反，机房离得越远，自然灾害的关联性就比较少。比如北京，深圳等。当时北京的用户要访问深圳的机房，这样网路问题就要考虑，由网络问题引发的数据不一致，超时等等问题都要进行考虑。

运维方案：

部署发布：

统一流程，规范发布。要敬畏生产环境，对于要发布的内容。要经过相关 leader，架构师，测试工程师，产品经理，安全部门确定过功能才能进行发布部署。不同随随便便发布应用，导致线上功能不能用。也不能随便修改配置，修改数据库，很容易引起大的问题。

监控告警：

对于程序要有健康检查，比如提供一个 api，检查程序是否提供服务。数据库监控，操作系统 cpu，io，网络等等监控。当 cpu 等其他硬件出现问题，可以使用看门狗来判断是否重启操作系统。当操作系统起来的时候，程序要自动能够起来，比如 supervisor 软件。