任何公共云提供商，在漫长的发展历史中，都会遇到一种宕机和故障。
或因为人为因素，或因为太猛的闪电，或因为机房停电，或因为光缆被挖，或因为编码错误...
这些问题的出现和解决，恰恰是公有云服务不断优化升级的过程。
但作为全球公有云的兄弟，停机等可查询可记录的事件几乎每年都会出现。
在此，阿明前来回顾并特别编辑:
这套
从2010年到2019年的今天，
全球公有云一哥十年宕机故障大全。
[2010]
AWS云服务因UPS和人为错误中断，持续时间未知。
2010年5月4日，亚马逊云计算服务两次出现故障，原因是一个UPS单元故障和人为失误。
由于数据中心电路中断，AWS云服务持续7小时。
2010年5月8日，亚马逊云计算服务失败。由于数据中心的配电板电气接地和短路，部分用户失去服务7小时，极少数用户丢失数据。
亚马逊数据中心停电AWS云服务中断，持续1小时。
2010年5月11日，亚马逊的云计算服务因停电而出现故障，导致美国东部少数用户失去服务一小时。
事故原因是一辆汽车撞倒了亚马逊数据中心附近的高压电线杆，数据中心的配电开关未能从公共电网切换到内部备用发电机。
值得注意的是，这是亚马逊云计算服务一周内第四次因停电而出现故障。
亚马逊在欧洲的网站宕机超过一个半小时。
2010年12月13日，亚马逊在英国、法国、德国和西班牙的网站在周日晚上宕机超过一个半小时，但没有迹象表明这与网络攻击有关。自维基解密开始公布美国机密外交信息以来，亚马逊是首批宣布切断与维基解密业务的公司之一。然后一群支持维基解密的黑客对Amazon.com发动了网络攻击..
亚马逊在英国、德国、法国和西班牙的网站都出现了超过30分钟的宕机，并于格林威治时间周日21点45分逐渐恢复正常。Amazon.com这次没有受到影响。
[2011]
AWS云数据中心服务器长时间大面积宕机。
2011年4月22日，亚马逊AWS云数据中心服务器大面积宕机。此次事件被认为是亚马逊历史上最严重的云计算安全事件。
由于亚马逊位于弗吉尼亚州北部的云计算中心停机，包括Quora、Reddit、Hootsuite和位置跟踪服务FourSquare在内的一些网站受到影响。
亚马逊的官方报告声称，这一事件是由于其EC2系统设计中的漏洞和设计缺陷，这些已知的漏洞和缺陷正在不断被修复，以提高亚马逊ElasticComputeCloud服务EC2的竞争力。
AWS被闪电切断，故障持续了两天左右。
2011年8月，亚马逊在北弗吉尼亚州的EC2服务被断开，这暂时中断了许多使用亚马逊网络服务云计算基础设施的网站和服务。这个数据中心是亚马逊在欧洲唯一的数据存储场所。也就是说，EC2云计算平台的客户在事故发生时没有其他数据中心可供临时使用。
亚马逊表示，北爱尔兰都柏林的闪电导致亚马逊在那里的数据中心停电，导致那里的云服务中断。亚马逊是否确认了美国东一区与互联网的连接问题，但连接很快就完全恢复了。同时，在北弗吉尼亚的关系数据库服务中发现了另一个连接问题。这个故障11分钟就修好了。然而，宕机导致使用亚马逊EC2云服务平台的多个网站长时间中断两天。
[2012]
亚马逊AWS的EC2服务故障超过29小时。
2012年6月14日，亚马逊位于美国东部的数据中心发生故障，影响了众多AWS云服务以及Heroku、Quora等知名网站。16日，Amaozn公布了事故分析。事故是由公共电网故障引起的，并引发了一系列连锁故障。
雷暴导致亚马逊在该地区的设施断电，发电机无法正常运行，应急电源的不间断供电系统被消耗，导致亚马逊RDS上运行的约数千个MySQL数据库宕机。
同时，EBS相关的EC2 API损失集中在20:57-22:40。具体来说，这段时间变量系统调用失败，直接影响客户发布新的EBS支持的EC2实例。EC2和EBS APIs在多个可用的复制数据存储中实现。EBS数据存储用于存储元数据等资源的卷快照。
一般来说，为了保护数据存储，系统会自动转为只读模式，直到电源恢复可以启动可用区，然后尽快恢复到一致状态，回到数据存储读写模式，使得变量EBS调用成功。但在这种情况下，这种保护方案没有起作用。
AWS网络服务被中断，持续时间未知。
2012年10月22日，亚马逊在北弗吉尼亚的网络服务AWS中断。
事故影响了包括Reddit和Pinterest在内的知名网站。弹性魔豆服务中断，接下来是弹性魔豆服务的控制台、关系数据库服务、弹性缓存、弹性计算云EC2、云搜索。这起事故让很多人认为亚马逊应该升级其北弗吉尼亚数据中心的基础设施。
亚马逊的AWS弹性负载平衡服务关闭了一段未知的时间。
2012年12月24日，刚刚过去的平安夜，亚马逊没有让他们的客户过得太平静。亚马逊AWS在美国东部1区的数据中心出现故障，其弹性负载均衡服务中断，影响了网飞和Heroku等网站。
其中Heroku也受到了之前美国东部AWS服务故障的影响。
然而，有些巧合的是网飞的竞争对手，亚马逊自己的业务亚马逊Prime即时视频并没有受到此次故障的影响。
[2013]
亚马逊负载均衡失败，持续2小时。
2013年9月13日黑色星期五的故障是因为负载均衡问题，部分地区的部分客户受到影响。
Amaozn解决了复杂均衡的接入问题，增加了配置时间，防止后续出现此类问题。
虽然这次中断只持续了大约2个小时，并且只影响了弗吉尼亚州的一个可用区域，但它是亚马逊制定备份计划的一个重要提醒。
[2014]
AWS CloudFront DNS服务中断近2小时。
2014年11月26日，亚马逊Web服务的CloudFront DNS服务器从美国东部时间晚上7:15开始持续了近2个小时。晚上9: 00后，DNS服务器开始恢复备份。
部分网站和云服务断开连接，在此期间内容交付网络无法完成DNS请求。没有发生什么大的事情，但它值得被列入这个名单，因为它涉及到世界上最大、运行时间最长的云。
[2015]
AWS大规模宕机，宕机时间超过40秒。
2015年7月1日，亚马逊网络服务出现大规模宕机，持续时间超过40秒。许多应用程序，如Slack、Asana、网飞、Pinterest和许多使用AWS服务的网站都没有响应。
不少网友笑称“都是闰秒的错！”。也有网友怀疑是“苹果音乐服务”导致的。此外，有用户在黑客新闻上写道，是亚马逊的一个EC2服务器导致的。
亚马逊AWS平台DynamoDB超时导致宕机，持续了5个小时。
2015年9月，亚马逊自动化基础设施的进程中断，导致AWS平台宕机。从简单的网络中断级联反应到大规模的服务中断，亚马逊经历了传统内部数据中心才会经历的那种网络中断——尽管它拥有非常先进和集成的云平台。
亚马逊的网络中断影响了其DynamoDB云数据库的存储服务器。发生这种情况时，一些存储服务器仍在请求它们的成员数据。结果断网造成检索和传输超时，这些服务器无法获取自己的会员数据，自动退出服务。
当那些得不到请求的服务器开始重试请求时，DynamoDB的超时问题导致更大的断网。于是，恶性循环产生了，亚马逊客户5个小时都用不了AWS。
数据中心AWS服务因停电而中断，持续时间超过5小时。
2015年9月20日，亚马逊AWS的一个数据中心遭遇停电，影响了网飞、Tinder、Airbnb等应用的在线服务，以及Reddit和IMDB的服务中断。
服务中断归咎于其位于弗吉尼亚州北部的us-east-1数据中心的软件问题，受影响的客户大多是本地客户。20日凌晨3点停电后不久，共有24个应用和服务报告问题，其中10个处于完全“服务中断”模式。
[2016]
亚马逊AWS宕机20分钟。
2016年3月11日，美国当地时间2点20分左右，电商巨头亚马逊官网宕机20分钟。这一事故不仅导致亚马逊主要电子商务网站无法访问，还影响了亚马逊的其他服务，包括全球最强的亚马逊云计算服务和一些数字内容服务。
这对亚马逊来说是一个巨大的事故，这个事故会造成巨大的经济损失。作为实力和用户数全球第一的亚马逊，云服务事故不仅仅是经济损失这么简单，更带来了追赶者的希望。
澳大利亚的AWS因停电中断服务近10个小时。
2016年6月，悉尼遭遇风暴袭击，该地区AWS设施断电，为一些知名公司托管临界负载的多个EC2实例和EBS卷相继出现故障。
在那个周末，澳大利亚AWS可用区域的网站和在线服务中断了近10个小时，造成了从银行服务到披萨外卖的问题。
[2017]
亚马逊S3宕机，宕机时间为4小时。
2017年2月28日，亚马逊AWS最稳定的云存储服务S3出现“超高错误率”宕机。
最终AWS给出了确切的解释:一个程序员在调试系统时，运行了一个原本打算删除少量服务器的脚本。结果他打错了一个字母，导致大量服务器被删除。被错误删除的服务运行两套S3子系统，导致S3不能正常工作，S3 API不可用。
S3负责存储文件，它是AWS系统的核心组件，导致其他AWS的S3控制台、亚马逊弹性计算云新实例的启动、亚马逊弹性块存储卷拆分以及依赖S3存储服务的AWS Lambda在北弗吉尼亚州日服务区受到影响。
为了修复这个错误，亚马逊不得不重启之前几年都没有重启过的整个系统，最终导致了震惊全世界的亚马逊S3 4小时宕机。
[2018]
AWS网络故障，持续时间未知。
2018年3月，亚马逊Alexa智能家居出现区域性故障。当用户唤醒家中的亚马逊Echo产品时，Alexa会要求用户重试，并报告找不到服务器。
Alexa的失败源于亚马逊AWS的网络服务的问题。不仅是Alexa，其他依赖AWS作为主干网络的应用也在同一天受到影响，包括软件开发公司Atlassian和云通信公司Twilio。
亚马逊发言人表示，这可能与弗吉尼亚州AWS的一个冗余互联网连接点停电有关。在随后的故障确认中，AWS表示是它导致了梅冬1区多个数据中心的故障。与此同时，数据包丢失已经影响到美国东部的一些AWS Direct Connect客户服务。它还会影响来自弗吉尼亚州阿什伯恩的Equinix DC1-DC6和DC10-DC12与来自弗吉尼亚州莱斯顿的CoreSite VA1和VA2的直接连接。
AWS数据中心硬件故障造成云服务影响，持续30分钟。
2018年5月31日，由于北弗吉尼亚数据中心硬件故障，AWS再次出现连接问题。在这次事故中，AWS的核心EC2服务、Workspaces虚拟桌面服务和Redshift数据仓库服务都受到了影响。
AWS管理控制台出现故障，故障持续了近6个小时。
2018年7月18日，亚马逊盛大购物促销Prime Day遭遇史上最大尴尬。亚马逊的网站和应用程序出现了重大技术故障，威胁到了其36小时的销售盛宴。
与此同时，亚马逊的核心产品AWS云服务也已经中断。当客户登录AWS管理控制台时，他会收到一条带有一只狗的图片的错误消息。消费者权益日在Amazon.com看到了一张类似的照片，上面有一只狗。
AWS在声明中表示:“客户在用账户登录时遇到间歇性错误，无法访问AWS管理控制台。”管理控制台是客户控制如何从Web使用AWS资源的网关。如果此功能失败，客户将无法分配AWS资源。
故障持续了近6个小时，AWS发言人表示，间歇性的AWS管理控制台问题并没有对亚马逊的消费者业务产生任何有意义的影响。AWS和Prime Day问题是不相关的。
韩国AWS服务器中断，故障时间长达一个多小时。
2018年11月23日，亚马逊网络服务核心服务器在韩国全境中断，导致两大加密货币在线交易平台停止运营。AWS是世界上广泛使用的云服务之一。受内部核心服务器故障影响，导致各大数字资产交易平台Upbit和Coinone戛然而止。据外媒报道，几大电商中心一个小时左右都逛不完。
AWS表示，“太平洋标准时间下午3点19分至4点43分之间，亚太地区服务器出错率上升，但问题已经解决，服务器工作正常。”亚马逊的声明细节也证实，首尔的网络受中断影响最大。Upbit平台在停电后发布了多份声明，对未能提前通知用户突然关机表示歉意。Coinone平台也宣布进入维护模式。
[2019]
北京地区AWS因光纤断裂中断，故障时间不详。
2019年6月1日晚，AWS北京地区CN-NORTH-1区域在连夜道路施工过程中，多条光缆被切断，导致可用区域无法连接互联网，进而导致所有可用区域新实例无法启动的故障，包括EC2 API激活失败。所以EC2 API在整个CN-North-1地区都不可用。目前，维护团队已经找到具体断点，正在全力恢复。
业内人士指出，这是北京可用区域，市政施工切断了光纤，而且不止一处被切断。2 ECAPI接口部分正好在被挖掉的可用区域，所以不能启动新的实例。遇到这样的事情也说明市政施工队总是措手不及。
以上资料整理自新浪、搜狐、腾讯新闻等相关网站、信息平台及公开新闻报道。
如果编辑统计有遗漏，希望大家补充。
不过，我们为你骄傲，宫云逸哥哥！
所谓:
十年的停工期。
不假思索。自难忘。
用户，无处可说。
就算不认识，脸上也是满满的震惊，心里也是凉的。
谁敢想到一夜失败。
喝不好。味道不好。
没什么好谈的，就是农忙。
预计每年都会云开雾散，在月夜睡在机房。
来源:阿明《江城子十年停工忙》
编辑:阿明
对此你怎么看？
欢迎在文末留言评论。
来源:阿明独立自媒体。
