说一下这一次阿里云新加坡 C 区火灾

这次阿里云新加坡 C 区的火灾影响了很多依赖其服务的公司，我们的小公司也深受波及。

10 号早上：

我们发现服务不可用，SSH 无法连接。紧急登录阿里云后，看到服务器被莫名其妙地关机了。我们立即点击重启，并提交了工单。然而工单的回复却让我们提供服务器崩溃日志——事实上，真正的原因是火灾。

10 号中午：

午饭时，我们看到了新闻，阿里云新加坡 C 区发生火灾。这时，我们还没有意识到应该立即进行服务器备份和迁移。

10 号下午：

虽然服务恢复了，但由于上下游服务依然依赖阿里云，也不同程度受到了影响。比如 Lazada 无法获取面单，Flash 仓库无法推送仓库指令。整个下午都在安抚客户，并尽量提供情绪支持。

10 号晚上 8 点：

晚上 8 点，服务再次中断，尽管机器没有显示停机，但监控数据表明 CPU 和内存占用降到了 0 。我们意识到磁盘可能已经挂掉了。由于没有备份，我们开始购买新机器，并重新部署、修改 Nginx 和 DNS 等配置。刚刚迁移完最重要的两个服务，原本的机器又恢复了。这时我们立即给机器做了镜像，认为火灾已经得到控制，剩下的服务便没有迁移。

11 号早上：

一大早在群里得知服务再次中断，所幸我们有了镜像，迅速恢复到新机器，并修改了 DNS 解析，终于结束了这次危机。

这次事件的教训：

不要过度依赖大厂的效率：关键时刻，大厂的响应速度和可靠性未必能够保证。
能用钱解决的问题尽早解决：发现问题后，应该尽快换区并将所有服务迁移，避免更大的损失。
不要怕麻烦：提前做好备份和迁移工作可以在突发事件中减少很多麻烦。

这次的火灾为我们上了一课，数据和服务的安全性永远不能轻视。

odirus

68 天前

我们遇到的：
1. 对于有多可用区的产品一定要用多可用区的，不要省小钱误大事；出问题时自动就切换了；
2. 对于不支持自动切换多可用区的产品（ ECS 、NAS 、云盘等），要主动做多可用区部署，或者设计之初就做好快速切换方案，并定期演练；

其实只要数据存储（数据库、对象存储）是具备可用区自动切换的就还好，其他问题就是老板舍不舍得花钱的问题，既想省钱又想省心，没这种好事。

建议云上针对中大型客户只售卖多可用区产品（ OSS 本地冗余这种就别卖了，万一出问题还被骂），不具备自动切换的产品显式标记出来有单点风险，要做好架构设计。

opengps

68 天前

虽然多可用区这事有的聊，但是大家对于云来说，还是会考虑成本考虑软件逻辑简单回归到最终买单个可用区下的服务。
看到几个人再提两地三中心之类的，这次事故事故覆盖一个可用区，算是非常大型的事故了。其实容灾还有很多不可控的因素甚至会覆盖整个地域机房，说远点比如地震，说近点也可以是火灾这种，可以参考当年腾讯天津机房的案例，外界无感知迁移本身就是个巨大的工程。要做到这种级别的跨地域高可用，显然成本极高：需要高速通道，复杂的软件切换结构等等很多问题，很多人的系统完全做不到跨地域容灾，特别是载如今这种降本增效式的大行情下。所以最后结论还得回归到，什么样的成本具备什么样的能力上。