本文是《中智观察》“企业数字服务供需市场”数智服务之发展趋势篇，盘点2021那些令云服务商痛心疾首的宕机，AWS、IBM多次上榜，验证了那句老话，人红（云服务商市占率高）容易是非多（宕机），读者可能产生另外一个猜想，没有是非就正常吗，本文可能给你一个明明白白！
——海比研究院
2021年12月30日
初期成本低、弹性扩展、安全、稳定可靠，这是十余年以来，云服务越来越受欢迎的主要原因。
其中，对讲究实时在线、实时响应的ToB服务而言，云服务的可靠性是对企业最迷人的吸引力。能提供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等大量热门网站和应用都发生严重的网络中断。同时，亚马逊自身的AlexaAI助理、Kindle电子书、亚马逊音乐、Ring安全摄像头等业务也受到影响。
12月10日，AWS公布了本次宕机的原因：用于扩展主AWS网络中托管的某个AWS服务的容量的自动活动触发了来自内部网络内大量客户端的意外行为导致连接活动激增，使内部网络和主AWS网络之间的联网设备不堪重负，从而导致这些网络之间的通信延迟。这些延迟增加了在网络之间通信的服务延迟和错误，从而导致更多的连接尝试和重试，最终引发持续的堵塞和性能问题。
12月第二次宕机发生在16日太平洋标准时间上午7点43分左右，本次宕机波及US-WEST-1和US-WEST-2两个区域，包括Twitch、Zoom、PSN、XboxLive、Doordash、QuickbooksOnline和Hulu等在线服务均受到影响。
AWS随后公布了故障原因：由于主网络中某自动化软件原因，错误得将一些流量转移到主干网，结果影响了一些互联网应用的连接。
12月第三次宕机发生在23日美国东部时间7点30分左右，位于弗吉尼亚州北部的US-East-Region1中断影响了许多服务，包括Slack、EpicGames、加密货币交易所CoinbaseGlobal、游戏公司Fortnite、约会应用程序Grindr和交付公司Instacart。对于此次中断，AWS初步调查称是数据中心供电的问题。
二、Azure：Windows虚拟机全球性故障
今年10月23日，AzureVirtualMachines发生了一起长达6小时的中断，使得包括美洲、欧洲、中东及非洲到亚太地区在内全球用户无法启动基于Windows的新系统。
据悉，故障发生了05:12UTC（世界标准时间）到11:45UTC 之间，使用Windows虚拟机的Azure客户子集在执行服务管理操作时面临问题，包括启动、创建、更新、删除，新虚拟机的部署和更新也失败了。
基于Linux的虚拟机和现有运行的Windows虚拟机没有受到该问题影响。此外，在创建资源时，对Windows虚拟机有依赖的服务也可能遇到类似故障。
事后，微软公布的中断原因为：在服务管理操作期间的调用故障，原因是所需的工件版本在查询期间未按预期返回。
此外，在今年3月16日，Azure也发生了一次中断。其ActiveDirectory出现故障，用户无法登录到Microsoft365、MicrosoftTeams、ExchangeOnline、Forms、XboxLive和Yammer。同时，这起中断也影响了微软旗下多个网站，如用户无法登陆其技术社区。
后续微软证实，本次故障是由于AzureActive Directory配置问题所致，使得用户们无法完成身份验证以登录到Microsoft365、Exchange、Online、MicrosoftTeams或其他依赖AAD的服务。
三、‖IBMCloud：5天2次宕机
今年5月22到26日，蓝色巨人在短短5天里接连发生两次严重中断事件，其中5月25日的中断为一级严重问题（SeverityOne），这是IBM来描述关键业务系统无法正常运行的评级。
据悉，该中断发生了5月25日UTC14点54分，华盛顿特区、大阪、伦敦、达拉斯、悉尼、东京和法兰克福等地云服务统统受到影响。
具体到受影响的服务，包括CloudantNoSQL DB、CodeEngine、ContinuousDelivery-Toolchain、DNSServices、EventStreams、HyperProtect Crypto Services、HyperProtect Virtual Server、HyperProtect DBaaS、IBMCloud Shell、IBMWatson Machine Learning、MobileFoundation以及IBMMQ。从UTC20点10分开始，服务陆续恢复。
除此之外，在今年6月10日，IBMCloud也发生了一起全球性的中断。此次中断涉及IBMAoC托管存储服务，进而影响了IBM位于阿姆斯特丹、金奈、达拉斯、法兰克福、香港、伦敦、墨尔本、墨西哥、米兰、蒙特利尔、奥斯陆、圣何塞、圣保罗、首尔、悉尼、东京、多伦多、华盛顿特区、巴黎和新加坡等多地的用户。
四、GoogleCloud：新区域上线便瘫痪
GoogleCloud今年也发生了两次宕机，其中一次为今年11月16日：谷歌云表示，网络配置中的潜在错误影响了GoogleCloud Networking、GoogleCloud Functions、GoogleCloud Run、GoogleApp Engine、GoogleApp Engine Flex、Apigee和Firebase，进而引起中断，Spotify、Discord、Etsy、PokémonGo等客户受到影响。
具体而言：GoogleCloud Networking ：用户无法更改网站上的负载平衡，导致出现404错误页面；GoogleCloud Functions ：使用GoogleCloud Load Balancing (GCLB) 的用户站点显示404错误；GoogleCloud Run ：美国中部的流量下降了25%，使用GCLB的用户站点显示404错误。GoogleApp Engine ：美国中部和西欧的流量下降80%，使用GCLB的客户网站出现404错误；GoogleApp Engine Flex ：使用GCLB的客户站点上出现404错误以及部署该工具的问题；Apigee：使用GCLB向用户发出请求时出现404错误；GoogleFirebase ：使用GCLB的用户站点上出现404错误。
今年8月24日，GoogleCloud在澳大利亚墨尔本上线一个月的新区域发生了中断，该区域用户无法正常使用虚拟机、负载均衡系统、存储等服务。
五、国内：一片祥和
或许是国内云服务商的技术太好，也或许是公关能力更强，国内的云服务商在2021年并未出现过于严重的宕机事件，一方面表现在宕机次数少，另一方面表现在宕机引起的后果并未太多严重。分别来看：
阿里云在12月7日早上部分CDN域名解析发生了异常。同时当天，由阿里云支撑的淘宝也发生了短暂崩溃事件。而在今年3月，淘宝同样也崩溃过一次。
腾讯云12月24日北京二区发生了部分云服务故障，后续，腾讯云表示是因为电力系统问题；除此之外，由腾讯云支撑的QQ、王者荣耀、微信在10月、11月均出现了短暂崩溃事件；8月31日，由于运营商网络原因，腾讯云故障7分钟。
华为云自2020年4月10日出现大规模崩溃后，在2021年对宕机相当谨慎，并未传出其宕机的事，在7月份B站的一次崩溃被传出是因为华为云的服务原因，后续华为云迅速辟谣与自己无关。
京东云2021年对外服务并未出现宕机事件，但由于支撑自家京东商城，所以还是会短暂出现中断事件。
国内其他云服务商暂未发现其在2021年发生宕机事件，如有遗漏，欢迎评论区留言~
科技媒体·企业演化科学·战略托管综合体
本文作者系海比研究院·木易