硬盘出故障、机房被雷劈,云服务能不能靠点儿谱?

7 月 20 日,腾讯云北京三区部分云硬盘 IO 异常。类似的故障在各大云厂商提供的云服务里,可谓是司空见怪,但这次因为一家名叫“前沿数控” 的创业公司,这个事...


7 月 20 日,腾讯云北京三区部分云硬盘 IO 异常。类似的故障在各大云厂商提供的云服务里,可谓是司空见怪,但这次因为一家名叫“前沿数控” 的创业公司,这个事件重新发酵,引起了热议。

“前沿数控”是一家以微信公众号起家的创业公司,因为这次硬盘故障,该公司线上生产数据完全丢失,在与厂商客服沟通后,得知数据无法恢复,该公司发言人称其网络产品已全部停运。

事件发生后,腾讯云做出回应:

事件到此远未完结,我们也将持续关注事件进展。现在,让我们来聊点别的。

云厂商故障宕机这些年来一直不是什么新闻:

2018 年 6 月 27 日,阿里云故障,起因:运维操作失误触发未知 bug;

2017 年 2 月 28 日,云计算巨头 AWS S3 故障,起因:调试时输入错误指令,意外移除大量服务器导致 S3 不能正常工作;

2017 年 3 月 22 日,微软云服务一个月内出现又一次宕机(上一次是 3 月 7 日);

2015 年 6 月 6 日,QingCloud 广东 1 区全部硬件设备因遭遇雷暴天气引发电力故障,造成 QingCloud 官网及控制台短时无法访问、部署于 GD1 的用户业务暂时不可用。

运维失误、硬盘出故障、机房被雷劈、调试输入错误指令,不同的失误会引起不同的 bug,最后同样导致云服务故障,造成大额损失。AWS 的费良宏老师回顾云计算的发展时曾说:“我眼里的云计算,就是十年生聚,十年教训”。故障,一直是云服务命运的双生子,每一次故障的阵痛,都是在倒逼云服务厂商和用户加速成长,只是这一次对于“前沿数控”这家创业公司而言过于疼痛了。

InfoQ 认为,在这类云服务故障的事件里,云厂商和用户都上了宝贵的一课。

注意 Error Handling

厂商工程师在写代码的时候都应该捕捉异常,然后做合适的错误处理。

尽可能地把动态内容缓存起来,甚至静态化

Redis cache、Nginx cache、HAProxy、CDN 都是把内容缓存甚至静态化的一些手段。尽管多级缓存维护起来是个麻烦,但当底层服务出现问题时,它们就是难得的战略缓冲区。cache 为你争取到的半个小时到几个小时几乎是续命的灵芝,它能帮你撑过最艰难的时刻(,相对从容地寻找解决方案,紧急发布新的页面,或者迁移服务,把损失降到最低。

故障演习很重要

一个系统的高可用的因素很多,不仅仅只是系统架构,更重要的是——高可用运维。对于高可用的运维,平时的故障演习是很重要的。Facebook 每个季度扔个骰子,随机关掉一个 IDC 一天。Netflix 有 Chaos Monkey,路透每年也会做一次大规模的故障演练——灾难演习。为的就是提升因对突发故障的应变能力。

充分告知用户云计算服务并不是 100% 可靠的

云厂商在提供云服务的时候,应该告知用户云存储有极小概率出现损坏或数据丢失,建议用户自己备份或者购买云备份。如果不告知或者不充分强调,很多用户都会以为云厂商造成数据丢失就要负责赔偿其所有损失。

敬畏用户,妥善处理危机

如果你是一个技术公司,你就会更多的相信技术而不是管理。相信技术会用技术来解决问题,相信管理,那就只会有制度、流程和价值观来解决问题。没有人愿意看到问题的发生;但是问题出现后,最重要的解决反思并从中汲取教训。——陈皓

检查核心依赖关系,提升关键性服务的冗余水平

很多云服务,比如 AWS 自身的系统在构建当中就具备冗余特性,但要充分使用就会增加大量管理复杂性与成本支出,因为跨环境间的数据同步工作需要由云用户负责打理。大多数企业并没有选择上述选项,可是单纯的数据备份在数小时的短周期内并不能发挥作用。但这却是一个值得去做的事。

主动做好备份

根据美国标准 TIA-942《数据中心的通信基础设施标准》,从可用性、稳定性和安全性分为四个等级:T1,可用性为 99.67%;T2,可用性 99.749%;T3,可用性 99.982%;T4,可用性 99.995%。年平均故障时间也从 0.4 小时到 28.8 小时不等,这意味着每年都可能存在各种原因的不可用。不管云服务是几个“9”,其靠谱程度始终不是 100%。用户需要自己做好备份,在云服务出现故障时,有可以恢复数据的渠道,而不是像“前沿数控”一样最终两眼一抹黑。

此次事件发展至今,众说纷纭,事件双方都给出了各自的说法和解释,怎么样去判断事件的真相和对错,InfoQ 在此不做价值判断,留给大家自己去思考、评价。我们希望大家可以基于事件本身去讨论问题,兼听则明,偏信则暗。