据报道，近日，由于中国联通整治违规互联网接入及大带宽业务，某CDN/IDC服务商业务中断，华为云故障一整天，导致生意帮一整天当机，脉脉服务器挂了，失联15个小时……

接着整个经历就非常崩溃了：用户不间断的咨询投诉，很多用户几百万的生意，重要的战略合作受影响，重要数据和资料的无法调用，CDN直播叫停……都因为网络故障而停摆，影响甚大。

意外在所难免。用户和客户是无辜的。如何保障自己的技术和服务的高可用性，做到即使在出现0.0001%的故障发生率的情况下，仍然可以给用户和客户提供高可用性，保证灾难情况下网络服务的及时恢复，是云技术服务商、提供商必须面对，又亟待解决的重要问题。

什么是高可用性？

要了解高可用性对于服务提供商的必要性和重要性，首先我们要了解什么是高可用性。一般来讲，一个靠谱的云服务一定是可用性非常高的，24*7随时可以用。第二点，可控性一定要好，非云服务你可以上个锁，云服务没法上锁，如何能做到可控性很好是一个难点。第三点是灾难恢复，是软件就会有问题。怎么样积极地面对这个问题，多长时间恢复，如何恢复，是否有成熟的预案这是任何一个云厂商都要诚实面对的问题。

业界的高可用性标准

首先，我们来看一下可用性的评判标准，就是SLA，Service Level Agreement。一个东西是不是高可用，那么就问他几个九，敢不敢拿出来说一下。

3个9基本上是国内云服务的基础线。也就是说云服务至少要做到3个9才称为基本上可用，是合格性产品。如果做不到这个，你的产品就连忽悠客户都做不到了。回去重新开发，重新装备，刷到至少3个9再回来。

从3个9迈向4个9，也就是99.99%的可用性，每年只有52.6分钟的时间是不可用的。以前谷歌搜索可用度大概是全球5个9到6个9之间，每一个小节点都是5个9不到6个9之间。其实这个是很可怕的一个概念，也就意味着即使有不可抗力，发生了台风，洪水，地震等重大灾害性事件，也只需要5分钟内恢复服务。

相较而言，大部分国内的IDC机房都是按照99%设计的，一年至少3天是不可用的。这一标准，给了厂商一定的机动时间，也提供了一定的灵活性。

所以说，从3个9往上，每一次提升都是一次技术的挑战。SLA直接反映一个云服务的靠谱程度：

从99%到3个9，是基本可以靠人力和运气解决的;

从3个9到4个9，考验的是运维自动化的能力，灾备的能力;

从4个9往上基本考验的是服务基础架构、业务设计的能力。

分布式核心机房保障声网Agora.io的高可用性

声网Agora.io一直在4个9到5个9之间努力,这个目前还是很有难度的。为了保证高可用性，声网Agora.io特意将核心机房分布在全球各地，以减少地区性的网络故障对于通信的影响，同时，核心机房用了十几家不同的IDC，即使某家的网络故障了，也能最大限度上保障服务的稳定性。

声网在全球部署了覆盖四个大洲的虚拟实时通信网，100多个数据中心，近千台服务器，每年为用户提供数千亿分钟的网络通话服务，这一系列的举动都是为了充分确保接入SDK的客户随时随地获得高质量的通话服务。

声网认为，要提升高可用性，需要从方方面面整体布局。

从架构上，声网的所有服务都有多点备份，并且所有备份节点都能够独立服务，不依赖其他节点。任何机房故障，甚至几个机房同时故障都不会影响到整体服务，除非所有节点同时发生故障。

声网的SDK也能够快速切换，一旦检测到某个服务节点不可用，可以快速切换到其他备份节点。

当然，武功再高，也怕菜刀。为了防范一些万一的故障导致服务不可用，声网还有一系列措施应对故障。

首先声网部署了实时故障检测系统。在服务用户的同时，该系统收集整个系统服务状态，并实时分析。如果遇到服务数据异常立即报警。

接下来，声网的数据分析系统可以对服务数据进行多个维度和层面的分析汇总。在故障发生时，可以快速判断是哪个模块或者机房出现问题。有了这个系统，声网就可以快速定位故障。比如常见的数据库故障，进程崩溃，遇到性能瓶颈，还有此次事件的主角——机房故障。

在定位了问题之后，声网还有一套工具能够实时调整线上系统，进行故障隔离。比如遇到某些数据库瓶颈时，能够暂时关闭某些数据库的写服务，不影响读数据。能够暂停某个机房的服务，避免用户受到影响。或者某些后台服务故障，暂时禁用，不让用户的音视频通信受到影响。

在进行故障隔离后，或者遇到难以隔离的故障，就需要快速恢复了。对于常见的进程崩溃，声网有自动化的包管理工具可以一键重启，回滚到前一个稳定版本。对于数据库故障，有数据库工具可以快速重建数据库，并恢复数据。即使遇到这次事件中的机房故障，除了架构设计能够保证服务基本不受影响外，也有机房上架工具能够快速上架，并使用部署工具重新部署一个新的机房。一般而言，声网上架一个新机房仅需几十分钟。

故障隔离处理后，声网会尽快对故障的根本原因做一个彻底的调查。首先从系统中收集各种数据和日志，进行分析，并尝试建立测试环境以确认故障的根本原因。

最后，需要进行服务改进。改进主要从几个方面着手：第一，修复问题。直接修复bug，改进算法性能等。第二，架构改进。下一次这个模块再出问题，怎么样设计系统才能够让服务不受影响？如何设计多点备份？第三，工具改进。下次再出现这些问题，需要哪些工具可以帮助更快速的定位，对故障进行隔离，更快速的恢复故障？

开发者该如何甄别和选择高可用性服务

面对市场上鱼龙混杂的云服务提供商，开发者应该如何正确地甄别和选择高可用度的服务呢？三个层面：一，观察该服务商的架构是否符合高可用度，SLA一定要达到4个9，二，是否具备完整的、实时的灾难预案。从问题发生的预警，到问题定位分析，到问题解决和服务恢复，是否能在最快的时间内完成，将用户的损失降到最低，三，是否把服务可用性当成生命线的信仰。