V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
neptuno
V2EX  ›  程序员

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

  •  1
     
  •   neptuno · 109 天前 · 3856 次点击
    这是一个创建于 109 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    10 号早上:

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

    10 号中午:

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

    10 号下午:

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

    10 号晚上 8 点:

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

    11 号早上:

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

    这次事件的教训:

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

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

    19 条回复    2024-09-13 08:41:09 +08:00
    yyttrr
        1
    yyttrr  
       109 天前
    这次很离谱
    首先是锂电池爆炸起火,机房周围的锂电池应该是 UPS 在用的,本来为了提高稳定性的装置反而引起的了事故
    之后是新加坡消防灭不了锂电池起火,从上午 10 点烧到至少晚上 20 点
    最离谱的是第二天凌晨还发生了断电,不仅仅是阿里云新加坡 C 区,A 区 B 区也有影响,我们就丢失了一些数据
    odirus
        2
    odirus  
       109 天前
    我们遇到的:
    1. 对于有多可用区的产品一定要用多可用区的,不要省小钱误大事;出问题时自动就切换了;
    2. 对于不支持自动切换多可用区的产品( ECS 、NAS 、云盘等),要主动做多可用区部署,或者设计之初就做好快速切换方案,并定期演练;

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

    建议云上针对中大型客户只售卖多可用区产品( OSS 本地冗余这种就别卖了,万一出问题还被骂),不具备自动切换的产品显式标记出来有单点风险,要做好架构设计。
    neptuno
        3
    neptuno  
    OP
       109 天前
    @yyttrr 是的,UPS 着火影响了机房,太搞笑了。我们 oss 、rds 倒是没受影响(万幸),不过好多公司 oss 丢数据了,我们数据传输给下游仓库,客户说仓库那边显示不了面单,仓库技术说文件丢失了。
    PureWhiteWu
        4
    PureWhiteWu  
       109 天前
    应该这么说,如果是自建机房出了火灾,大概率一天时间恢复不了服务。

    上了云,不管咋说,起码能够换个可用区起一套服务就能跑。
    neptuno
        5
    neptuno  
    OP
       109 天前
    @odirus 哎,小公司没那么多钱,而且竟然没有给系统盘做定时快照,不然这次至少修复的快一点。这次庆幸的是 oss 、数据库没有受到影响。
    neptuno
        6
    neptuno  
    OP
       109 天前
    @PureWhiteWu 确实,当时中午恢复了,应该第一时间先换区重新部署的
    opengps
        7
    opengps  
       109 天前
    虽然多可用区这事有的聊,但是大家对于云来说,还是会考虑成本考虑软件逻辑简单回归到最终买单个可用区下的服务。
    看到几个人再提两地三中心之类的,这次事故事故覆盖一个可用区,算是非常大型的事故了。其实容灾还有很多不可控的因素甚至会覆盖整个地域机房,说远点比如地震,说近点也可以是火灾这种,可以参考当年腾讯天津机房的案例,外界无感知迁移本身就是个巨大的工程。要做到这种级别的跨地域高可用,显然成本极高:需要高速通道,复杂的软件切换结构等等很多问题,很多人的系统完全做不到跨地域容灾,特别是载如今这种降本增效式的大行情下。所以最后结论还得回归到,什么样的成本具备什么样的能力上。
    zouqiang
        8
    zouqiang  
       109 天前
    可以考虑多云化了
    neptuno
        9
    neptuno  
    OP
       109 天前
    @opengps 是的,谁不知道多地多机房甚至多云呢,但归根结底,这个都是钱,咱没钱,只是希望出了事情,阿里云可以承担责任,给出解决方案,协助迁移。
    neptuno
        10
    neptuno  
    OP
       109 天前
    @zouqiang 多云我们暂时没这个预算,而且对架构也有要求。暂时就不考虑了。
    Jhma
        11
    Jhma  
       109 天前
    这需要自己做云上业务高可用,或者不同云之间的多活,不能单纯靠大厂,不过需要技术过硬的运维人员或者团队
    neptuno
        12
    neptuno  
    OP
       109 天前
    @Jhma 经过这一次,感慨运维是多么的重要,高可用背后是强大的运维、开发团队和资金量支持。
    povsister
        13
    povsister  
       109 天前
    这些年是真的见了太多草台班子。连谷歌都干过一键清空大客户全部云资产的事情。
    云服务不是保险箱,异地/备份/多活都是生意,重要数据一定要异地备份。
    https://cloud.google.com/blog/products/infrastructure/details-of-google-cloud-gcve-incident
    PureWhiteWu
        14
    PureWhiteWu  
       109 天前
    @neptuno 是的,其实说白了就是钱一定要够。
    高可用靠的就是冗余,不管是机器还是人。
    echo1937
        15
    echo1937  
       109 天前
    @zouqiang 很明显 op 还没有上多可用区,多云就更远了。
    geekvcn
        16
    geekvcn  
       109 天前
    怪不得有些机房坚持用铅酸电池,我之前还纳闷,后面老哥说锂电着火很麻烦我还不以为然当时认为是铅酸电池耐浮充电源管理方案简单,现在相信是消防问题了
    Cassius
        17
    Cassius  
       109 天前
    铅酸如果换气不好...也有爆炸的风险...
    bbsingao
        18
    bbsingao  
       109 天前
    能有镜像已经是万幸了
    ExplodingFKL
        19
    ExplodingFKL  
       108 天前
    > 铅酸如果换气不好...也有爆炸的风险...
    @Cassius 比锂电要好,至少起火可以快速扑灭
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1111 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 18:43 · PVG 02:43 · LAX 10:43 · JFK 13:43
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.