官方服务微信:dat818 购买与出租对接

阿里云香港地域故障超12小时,众多服务受影响情况全解析

2万

主题

2

回帖

6万

积分

管理员

积分
66589
发表于 昨天 07:40 | 显示全部楼层 |阅读模式
    物联网智库 原创

    导读

    昨日,阿里云在香港地域出现了长时间且持续性的故障情况。服务出现了中断,中断的时间一度超过了 12 小时。

    昨日上午 10 点 47 分,阿里云发布了一则公告。阿里云监控到香港地域某机房的设备出现异常情况。此异常影响了香港地域可用区 C 的云服务器 ECS 以及云数据库等云产品的使用。目前工程师正在进行紧急处理。阿里云表示,这一故障还对香港地域的控制台访问和 API 调用操作造成了影响。阿里云的工程师昨日一直在与 PCCW 机房工程师配合,以加快处理的速度。截至目前,与该故障相关的官方网站和APP均可正常访问。

    受此故障的影响,昨日澳门司法警察局的官微发布了消息。消息称,因为阿里云的香港机房节点出现了故障,所以澳门金融管理局、澳门银河、莲花卫视、澳门水泥厂等这些关键基础设施的营运者的网站,以及澳觅和 MFood 等外卖平台,还有澳门日报等本地的传媒应用程式,从今天(18 日)中午开始,就暂时无法进行访问和使用了。不仅如此,Linux 中国的官网也遭遇了无法访问的情况。很多个人站长也表示,阿里云的长时间故障对他们网站的运营产生了影响。

    此次故障对“币圈”的影响较为严重。知名交易平台“Gate.io”发布公告称,由于受运营商部分网络节点维护的影响,充提服务将会出现延缓的情况。知名加密货币交易所 OKX(欧易)在 18 日上午 11:00 到 19 日上午 02:50 这段时间内,交易服务中断了几个小时。它关停了所有用户的交易,还限制了提币。这一举措使得部分 OKX 用户的加密资产显示为 0,曾引发该平台用户的担忧。可想而知,此次故障会对交易所上的投资者信心造成不可估量的打击。

    历史上云服务商已发生过多次故障

    零壹智库不完全统计,2010 年以来,混合云上市公司青云有过约 4 次故障宕机事件。阿里云有过约 5 次故障宕机事件。腾讯云有过约 8 次故障宕机事件。其中,阿里云的故障大多在 2018 - 2019 年间发生,腾讯云的故障也大多在 2018 - 2019 年间发生。这表明尽管云服务已进入技术较成熟阶段,但仍有较大概率发生宕机事件。从全球范围来讲,自 2010 年往后。亚马逊云科技 AWS 出现过大概 22 次故障宕机情况。谷歌云计算平台出现过大概 12 次故障宕机情况。微软 Azure 出现过大概 8 次故障宕机情况。

    已知发生的云服务故障修复中,修复时间有的短至 40 秒,有的长至 24 小时。阿里云作为一家具备雄厚技术实力的云服务商,却出现了如此长时间的持续性服务故障,这在业界是相当罕见的事件。其创始人徐明星甚至将此次故障称作“阿里云发展史上重大丑闻”。

    当前,使用云服务的大多是提供各种服务的 APP 客户以及网站客户。试想一下,如果用户在点外卖时出现无法下单的情况,或者在刷短视频时无法播放,这都将对用户体验造成严重影响。测试结果显示,多数用户对于打开网页等待时间的忍耐限度在 2 秒钟以内,最长不会超过 8 秒。倘若故障出现的时间持续较久,用户就会关闭网页和 APP,从而给企业造成不同程度的用户流失。

    对此,要衡量云服务商提供的服务质量和系统的稳定性,就需要设定一个统一标准。而 SLA 正是因为这个需求而产生的。

    SLA为云服务用户提供保障

    其中,SLA 是服务等级协议 -Level 的缩写。它指的是服务提供商与客户之间就服务质量所达成的双方共同认可的协议。此协议表明了公有云提供服务的等级以及质量,同时也是云服务商对产品服务能力的保障。云服务商及其产品团队一个很重要的目标就是围绕这些 SLA 来进行产品设计和运维保障。

    举例而言,假如是月度 99.95%的 SLA,以每月 30 天来计算的话,那么每个月云服务出现故障的时间仅能占据总时间的 0.05%。也就是说,每月最多会有 30 天乘以 24 小时乘以 60 分钟再乘以(100%减去 99.95%)等于 21.6 分钟的不可用时间。如果提升到 99.995%,那么每个月服务的不可用时间为 2.16 分钟。不可用时间缩短了很多,这也就意味着云服务器的稳定性有了大幅提升。

    近期,阿里云公布了新的云服务器 ECS 服务等级协议 SLA。单实例的可用性得到提升,从 99.95%提升到了 99.975%。多可用区多实例的可用性也有所提升,从 99.99%提升到了 99.995%。并且这些可用性均达到了全球最高水准。这一简单的数字变化背后,展现的是过去十年阿里云在云计算稳定性方面所做出的努力。阿里云不仅升级了 SLA,还提供了企业级云灾备解决方案,能够为制造、金融、医疗等企业提供一键容灾的能力,包括业务恢复、数据保护和网络自愈等方面。通过这些举措,最大程度地保护了本地和云上业务的稳定运行。然而,此次香港地区超过 12 小时的服务故障,却让阿里云真切地感受到了打脸的滋味。

    阿里云官方公告称,对于受本次故障影响的产品,阿里云会依据相关产品的 SLA 协议进行赔付。阿里云服务器 ECS 服务等级协议文档中有关赔偿标准的部分如下:

    如今,有越来越多的企业在采用云服务来替代本地的数据中心。主要的原因在于传统的数据中心很难达到云服务商所保证的超高 SLA。一般来讲,云厂商的 SLA 要比线下数据中心的 SLA 高出 5 倍以上,并且云的成本只是线下数据中心成本的几分之一。相关的赔付承诺使得各大云服务提供商在提升 SLA 时都非常谨慎,因为过度承诺往往会导致公司损失的概率提升。

    当然,要完全避免云服务出现故障是难以做到的。不过,提前制定事前预案,并且及时通知客户做好准备,或许能够进一步减少故障所带来的影响。欧易交易平台表示,云服务用户不应过度依赖单个云服务厂商,能够快速推进多云战略,以确保核心服务部署在多个云服务商处。当单个云服务商平台出现故障时,可迅速切换至其他平台,从而保障服务的稳定性。

    虽有“丑闻”,但云服务前景依旧良好

    阿里云从成立的第一天起就开始在稳定性方面投入大量技术并进行建设。经过十多年的技术探索,它推出了基于自研的飞天大规模操作系统,以及自研的服务器、网络、存储、智能调度等技术。这些技术不仅大幅提升了系统的稳定性,还能够预测感知系统异常,运用热迁移等技术保障客户业务不受影响,最终实现了超高的 SLA 标准。

    目前,阿里云在国内公有云行业处于领先地位。在中国公有云服务市场里,天翼云、浪潮云、金山云、京东云等云厂商的名字为人们所知晓。阿里云、腾讯云、华为云和百度智能云是知名的国产“四朵云”,它们共同占据了国内云服务的很大部分。从全球市场的角度来看,阿里云在全球市场中处于第三位。它在全球 28 个地域开展了运营,并且在这些地域中设置了 86 个可用区。同时,阿里云还是亚太市场基础设施规模最大的云计算平台,其规模超过了亚马逊云科技和微软。在过去的三年时间里,阿里云在海外市场的营收增长幅度超过了 10 倍。

    今年阿里云首次实现了年度盈利。阿里巴巴在今年 5 月发布的 2022 年财报表明,云业务同比增长 23%。全年收入在抵销跨分部交易前为 1001.8 亿元,抵销后为 745.68 亿元,并且实现了 11.46 亿元的盈利。阿里云成立 13 年,这是首次实现年度盈利。阿里云成为国内首家实现持续盈利的云计算公司。

    不过,阿里云在盈利的同时,也遭遇着云计算市场增速放缓的难题。公布的数据显示,今年第三季度,国内云基础设施服务支出同比增长 8%,达到 78 亿美元,占全球云支出的 12%。从 2022 年第一季度起,年增长率已连续三个季度放缓,并且首次跌破 10%。原因大概是互联网行业大中型客户对云服务的需求更高,且他们已基本完成布局。现在的云计算不仅要深入到各行各业,还要解决市场教育和前沿技术研发的难题。

    写在最后

    云服务出现故障的情况时有发生。然而,与传统的本地服务相比,云服务发生故障的概率已经显著降低。并且,随着技术持续地完善,云服务还会在更多的场景里发挥出独特的作用。

    云服务发生故障,原因不只是技术方面,还可能被技术处理能力、自然天气以及故障原因等多方面因素所影响。阿里云在过去几年有了很大进步,然而此次持续超过 12 小时的故障,能够给云服务厂商敲响警钟。作为云服务平台,确保平台安全且稳定运行,一直是其最为关键的工作之一。

    参考资料:

    阿里云出现了严重事故,故障持续时间超过了 12 小时。张建锋刚刚带领公司达成了年度盈利的目标。

    阿里云在香港出现故障,这成为了其发展史上新的一个“极为艰难的时刻”。阿里云在香港的业务遭遇了故障,这对于阿里云的发展来说,是一个新的具有挑战性的阶段。阿里云在香港的运行出现了问题,这标志着其发展历程中出现了新的“黑暗时期”。

    《梳理 17 次云巨头故障事件,云服务是否可靠?》,零壹财经

    扫码即可下载报告全文
您需要登录后才可以回帖 登录 | 立即注册

Archiver|手机版|小黑屋|关于我们

Copyright © 2001-2025, Tencent Cloud.    Powered by Discuz! X3.5    京ICP备20013102号-30

违法和不良信息举报电话:86-13718795856 举报邮箱:hwtx2020@163.com

GMT+8, 2025-4-5 02:21 , Processed in 0.080007 second(s), 17 queries .