2025-03-02 数码 0
编辑 小智
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 在此不做价值判断，留给大家自己去思考、评价。我们希望大家可以基于事件本身去讨论问题，兼听则明，偏信则暗。
