云平台宕机引发的系列思考，企业如何自救？

近日，一则阿里云平台发生宕机的新闻引发众网友关注。细数这两年，国际主流云厂商在安全性和可靠性层面做了不少努力，但所有服务都不可能百分百稳定，企业应该思考的是在问题出现时如何自救，而不是坐以待毙。

近两年，因为云平台宕机造成的事故数不胜数，比如 Gitlab 曾因误删除引起服务中断 18 小时，并且无法完全恢复；亚马逊 AWS 因一条错误指令引起宕机，随后大部分互联网，包括 Slack、Quora 和 Trello 在内的企业平台停机 4 个小时；微软 Azure 公有云出现超过 8 小时的存储可用性问题；亚马逊 AWS 访问存储块出现问题，影响 S3 存储服务；谷歌自动化失效引起停运 93 分钟；亚马逊 AWS 北弗吉尼亚地区数据中心出现硬件问题等。

尽管云平台会发生故障，但企业对云的信赖度依然很高。Gartner 研究主管 Sid Nag 曾表示，云服务市场的增长速度比几乎所有 IT 市场都要快，其中大部分增长是以传统非云服务为代价，尤其是基于云计算的 IaaS 需求在继续增长，预计将在未来 5 年呈现最快增长趋势。

在云计算出现之前，企业内部自建数据中心依旧会出现很多问题，不少问题甚至是致命的。上云之后，公有云厂商至少可以帮助技术能力有限的企业进行合理范围内的监控、预警和备份。不可否认，云的出现确实解决了现阶段企业在计算、存储等方面的很多问题，但完全依靠云计算厂商提供安全性的做法是不可取的。

企业应该具备容灾意识，并在故障发生的第一时间采取措施弥补损失。因为云而产生的故障风险一般分为两类：一是因为误操作导致的问题（其实用不用云服务都有这个问题）；二是云平台故障导致的问题。

误操作导致的问题

在这种情况下，企业首先应该反问自己，如果不用云平台，解决方案是什么？常规的解决方案，比如定期备份归档策略，包括服务器、数据库、存储等方面。

在云计算环境下，平台基本都提供类似功能，例如服务器有快照，数据库和日志有备份等。这些功能都“实用性”地提供了解决方案，并且比自己构建类似服务要简单好用，但很多企业为了节省成本可能并未接受云厂商的服务，此时就需要依靠企业自身的技术能力。

其次是权限问题，云平台的账户权限管理严格避免无意或者恶意的误操作，就像传统环境下，如果 root 口令全公司都知道，那么出了事情也不奇怪。

最后，通过堡垒机或者云平台自带的审计功能，至少知道发生故障时干了什么，怎么干的，这样恢复环境比较容易。

云平台故障问题

无论是传统环境还是云环境，都不能做到绝对的“持续可用”。大部分情况下，云环境的可用性和可靠性都比传统环境要高，这主要是因为云平台的运维更加专业。既然任何环境都有出现故障的可能，那么需要重视的问题就是“发生故障时，应该怎么办”。

接受风险，这一点很重要。对于现阶段国内的云计算发展进程来看，上云是不可避免的，在这种情况下，企业应该保持正确的心理，毕竟只要是系统，都会发生故障。国内主流云计算厂商已经投入了大量精力和成本在可用性和可靠性层面，这肯定要优于不少技术能力不足、成本有限的企业自建服务器。如果出现这种情况，那么走应急预案，用非系统的方式尽量降低风险。例如，某个服务宕机了，及时在官网做出声明。

其次，分散风险。云环境的同城双活、异地灾备等方案基本就绪，尽量在经济和人员条件可行的情况下使用这些分散风险的方法。如果故障只出在一个服务器集群，采用异地灾备方案可以在最快时间切换到另一个集群，从而保持系统可用。虽然还是会有中断，但是可以最快时间恢复。

按照此模式，云下系统做云上灾备也是防范传统环境出现可用性问题的一种重要手段。作为企业的 IT 人员，日常做到以下四点可以尽可能避免云故障带来的损失。

1、备份、备份，还是备份，要异机异地；

2、数据容灾；

3、业务双活；

4、定期对灾备和双活进行演练。

未来，云服务很可能像水电煤一样成为基础设施，即便是这些基础设施，我们也无法保证百分百可用。因此，如果自身服务非常重要，可以考虑租用多个云服务互为主备，甚至自建机房，只是这样成本和技术复杂度会成倍增加。

从统计上看，中小企业的运维水平远低于主流云平台，故障概率要高得多，损失更不可控。因此，不必对云服务故障抱有恐惧，只需要保持正常的认知和高度灾备意识即可。