《中智观察》第1571篇推送
作者：木易
编辑：苏苏
头图来源：host.ie
初期成本低、弹性扩展、安全、稳定可靠，这是十余年以来，云服务越来越受欢迎的主要原因。
其中，对讲究实时在线、实时响应的To B服务而言，云服务的可靠性是对企业最迷人的吸引力。能提供99.99%甚至99.999%可靠性的云服务，帮助企业每年减少了太多宕机时间，间接赚取了更多收益。
以99.999%可靠性为例，其代表着企业每年只有5分钟的停机时间，而99.99%可靠性意味着企业每年停机时间为1小时。相关数据显示，企业IT系统停机1小时的平均成本为26万美元，而停机5分钟，平均成本仅为2600美元。
尽管云服务商已经尽力将云服务的可靠性做到99.99%甚至99.999%，但仍然有宕机的可能性。而承载全球各地企业海量业务的云服务商一旦宕机，其导致的后果不堪想象。
云服务商的宕机，既是企业所担心的，毕竟自身的业务受到影响；更是云服务商们自己痛心疾首的事。因为宕机，云服务商们提供服务的可靠性将遭到质疑，影响新客户的签约，也影响老客户的续约。
回顾即将划上句号的2021年，在全球范围内，令云服务商们痛心疾首的宕机事件，也在多家云服务商身上发生了多次。
‖AWS：不太平的12月3次宕机
一组有趣的数据显示：2010年至2019年间，AWS平均每年宕机次数达2.4次。而仅仅在2021年的最后一个月，AWS便发生了3次宕机。
12月第一次宕机发生美国东部时间7日，位于弗吉尼亚州北部 （US-EAST-1）区域，本次宕机从上午10点45分持续到下午2点22分，包括迪斯尼+、奈飞、Robinhood、Roku等大量热门网站和应用都发生严重的网络中断。同时，亚马逊自身的Alexa AI助理、Kindle电子书、亚马逊音乐、Ring安全摄像头等业务也受到影响。
12月10日，AWS公布了本次宕机的原因：用于扩展主 AWS 网络中托管的某个 AWS 服务的容量的自动活动触发了来自内部网络内大量客户端的意外行为导致连接活动激增，使内部网络和主 AWS 网络之间的联网设备不堪重负，从而导致这些网络之间的通信延迟。这些延迟增加了在网络之间通信的服务延迟和错误，从而导致更多的连接尝试和重试，最终引发持续的堵塞和性能问题。
12月第二次宕机发生在16日太平洋标准时间上午7点43分左右，本次宕机波及US-WEST-1和US-WEST-2两个区域，包括Twitch、Zoom、PSN、Xbox Live、Doordash、Quickbooks Online和Hulu等在线服务均受到影响。
AWS随后公布了故障原因：由于主网络中某自动化软件原因，错误得将一些流量转移到主干网，结果影响了一些互联网应用的连接。
12月第三次宕机发生在23日美国东部时间7点30分左右，位于弗吉尼亚州北部的US-East-Region 1中断影响了许多服务，包括Slack、Epic Games、加密货币交易所Coinbase Global、游戏公司Fortnite 、约会应用程序Grindr和交付公司Instacart。对于此次中断，AWS初步调查称是数据中心供电的问题。
‖Azure：Windows虚拟机全球性故障
今年10月23日，Azure Virtual Machines发生了一起长达6小时的中断，使得包括美洲、欧洲、中东及非洲到亚太地区在内全球用户无法启动基于Windows的新系统。
据悉，故障发生了05:12 UTC（世界标准时间）到 11:45 UTC 之间，使用 Windows 虚拟机的 Azure 客户子集在执行服务管理操作时面临问题，包括启动、创建、更新、删除，新虚拟机的部署和更新也失败了。
基于Linux的虚拟机和现有运行的 Windows 虚拟机没有受到该问题影响。此外，在创建资源时，对Windows 虚拟机有依赖的服务也可能遇到类似故障。
事后，微软公布的中断原因为：在服务管理操作期间的调用故障，原因是所需的工件版本在查询期间未按预期返回。
此外，在今年3月16日，Azure也发生了一次中断。其Active Directory出现故障，用户无法登录到Microsoft 365、Microsoft Teams、Exchange Online、Forms、Xbox Live和Yammer。同时，这起中断也影响了微软旗下多个网站，如用户无法登陆其技术社区。
后续微软证实，本次故障是由于Azure Active Directory配置问题所致，使得用户们无法完成身份验证以登录到Microsoft 365、Exchange、Online、Microsoft Teams或其他依赖AAD的服务。
‖IBM Cloud：5天2次宕机
今年5月22到26日，蓝色巨人在短短5天里接连发生两次严重中断事件，其中5月25日的中断为一级严重问题（Severity One），这是IBM来描述关键业务系统无法正常运行的评级。
据悉，该中断发生了5月25日UTC 14点54分 ，华盛顿特区、大阪、伦敦、达拉斯、悉尼、东京和法兰克福等地云服务统统受到影响。
具体到受影响的服务，包括Cloudant NoSQL DB、Code Engine、Continuous Delivery-Toolchain、 DNS Services、Event Streams、 Hyper Protect Crypto Services、Hyper Protect Virtual Server、Hyper Protect DBaaS、 IBM Cloud Shell、 IBM Watson Machine Learning、Mobile Foundation以及 IBM MQ。从UTC 20点10分开始，服务陆续恢复。
除此之外，在今年6月10日，IBM Cloud也发生了一起全球性的中断。此次中断涉及IBM AoC 托管存储服务，进而影响了IBM位于阿姆斯特丹、金奈、达拉斯、法兰克福、香港、伦敦、墨尔本、墨西哥、米兰、蒙特利尔、奥斯陆、圣何塞、圣保罗、首尔、悉尼、东京、多伦多、华盛顿特区、巴黎和新加坡等多地的用户。
‖Google Cloud：新区域上线便瘫痪
Google Cloud今年也发生了两次宕机，其中一次为今年11月16日：谷歌云表示，网络配置中的潜在错误影响了Google Cloud Networking、Google Cloud Functions、Google Cloud Run、Google App Engine、Google App Engine Flex、Apigee 和 Firebase，进而引起中断，Spotify、Discord、Etsy、Pokémon Go等客户受到影响。
具体而言：Google Cloud Networking ：用户无法更改网站上的负载平衡，导致出现 404 错误页面；Google Cloud Functions ：使用 Google Cloud Load Balancing (GCLB) 的用户站点显示 404 错误；Google Cloud Run ：美国中部的流量下降了 25%，使用 GCLB 的用户站点显示 404 错误。Google App Engine ：美国中部和西欧的流量下降 80%，使用 GCLB 的客户网站出现 404 错误；Google App Engine Flex ：使用 GCLB 的客户站点上出现 404 错误以及部署该工具的问题；Apigee ：使用 GCLB 向用户发出请求时出现 404 错误；Google Firebase ：使用 GCLB 的用户站点上出现 404 错误。
今年8月24日，Google Cloud在澳大利亚墨尔本上线一个月的新区域发生了中断，该区域用户无法正常使用虚拟机、负载均衡系统、存储等服务。
‖国内：一片祥和
或许是国内云服务商的技术太好，也或许是公关能力更强，国内的云服务商在2021年并未出现过于严重的宕机事件，一方面表现在宕机次数少，另一方面表现在宕机引起的后果并未太多严重。分别来看：
阿里云在12月7日早上部分cdn域名解析发生了异常。同时当天，由阿里云支撑的淘宝也发生了短暂崩溃事件。而在今年3月，淘宝同样也崩溃过一次。
腾讯云12月24日北京二区发生了部分云服务故障，后续，腾讯云表示是因为电力系统问题；除此之外，由腾讯云支撑的QQ、王者荣耀、微信在10月、11月均出现了短暂崩溃事件；8月31日，由于运营商网络原因，腾讯云故障7分钟。
华为云自2020年4月10日出现大规模崩溃后，在2021年对宕机相当谨慎，并未传出其宕机的事，在7月份B站的一次崩溃被传出是因为华为云的服务原因，后续华为云迅速辟谣与自己无关。
京东云2021年对外服务并未出现宕机事件，但由于支撑自家京东商城，所以还是会短暂出现中断事件。
国内其他云服务商暂未发现其在2021年发生宕机事件，如有遗漏，欢迎评论区留言~
原文链接：https://blog.csdn.net/Z1Y492Vn3ZYD9et3B06/article/details/122247726?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522165918469516781683936040%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=165918469516781683936040&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~times_rank-19-122247726-null-null.nonecase&utm_term=%E9%A6%99%E6%B8%AFcdn
原创文章，作者：优速盾-小U，如若转载，请注明出处：https://www.cdnb.net/bbs/archives/2448
