云服务厂商案件案件备案查询

北京时间6月27日下午，阿里云挂了。市场占有率47.6%的阿里云宕机，影响的是中国互联网的半壁江山。对此，坊间传闻伴着吐槽声起伏不断，甚至有人声称此次事故是由两个实习生造成：

“对于这次故障，没有借口，我们不能也不该出现这样的失误！我们将认真复盘改进自动化运维技术和发布验证流程，敬畏每一行代码，敬畏每一份托付。”

年2月28日，云计算巨头AWSS3故障，事件的起因是AWSS3（云存储）团队在进行调试时输入了一条错误指令，本应该将少部分的S3计费流程服务器移除，可是最终意外移除了大量服务器。被错误移除的服务其中运行着两套S3的子系统，从而导致S3不能正常工作，S3API处于不可用状态。

由于S3负责存储文件，为AWS体系中的核心组成部分，这导致北弗吉尼亚日（美国东一）服务区中，依赖于S3存储服务的其他AWS的S3控制台、Amazon弹性计算云（简称EC2）新实例启动、Amazon弹性块存储（简称EBS）分卷（限于需要读取S3快照的数据）以及AWSLambda均受到影响。

年3月22日，微软云服务又一次宕机了。Outlook、Hotmail、OneDrive、Skype和XboxLive都出现了网络故障，全球用户都无法登陆。英国海岸和美国海岸城市的Outlook邮箱系统的用户受到的影响特别严重，同样悲惨的还有西欧与美国海岸线的美国OneDrive用户，西欧和巴西的Skype用户，及Xbox的英国、美国、西欧用户。Azure用户的一天也不好过，一大批工程师无法登陆系统。这不是微软最近第一次出现这种问题，上次是3月7日。

年6月6日，QingCloud广东1区全部硬件设备因遭遇雷暴天气引发电力故障，造成QingCloud官网及控制台短时无法访问、部署于GD1的用户业务暂时不可用。在业务恢复后，青云方面披露了合作运营商针对事故的调查原因：

年11月2日，腾讯云服务器出现了六分钟的访问故障。腾讯云平台部方面表示，此次访问故障主要是上海和广州机房的服务器出现故障，机房网络出口抖动造成的，而网络抖动是源于运营商网络信道阻塞，导致用户连接服务器出现丢包等现象。“这是网络上游的问题，并非机房本身硬件故障，所以无法避免该情况的发生。”云平台部方面负责人如是说。

纵观以上云厂商宕机案例，有的是天灾（机房被雷劈了），有的是人祸（误删除操作），但可以肯定的是：宕机这事儿，预计在很长的一段时间里都无法避免。那么对于吃瓜群众们来说，看完热闹了，要看会什么门道呢？

以AWSS3故障为例。InfoQ整合了三位技术专家陈皓、陈天、NickKephart给出的思考整理如下：

从errorhandling的角度，陈天认为在写代码的时候都应该捕捉这个异常，然后做合适的错误处理。很遗憾的是，S3这样的服务是如此基础，就像互联网的水和电一样，大家默认为它永远不会出错。因此，好多工程师干脆不做错误处理。

除了代码编写层面的处理，当云服务商的宕机发生时，尽量控制它影响面。像Trello连landingpage都一并挂掉实在不可取，因为起码S3影响不到的页面，如landingpage，用户注册/登录页面，应该还保持正常服务；而像Quora的服务，其实是可以准备一个静态化的镜像，一旦出问题，起码让读者可以无障碍地阅读。

Rediscache、Nginxcache、HAProxy、CDN都是把内容缓存甚至静态化的一些手段。陈天认为：尽管多级缓存维护起来是个麻烦，但当底层服务出现问题时，它们就是难得的战略缓冲区。cache为你争取到的半个小时到几个小时几乎是续命的灵芝，它能帮你撑过最艰难的时刻（这次S3宕机前后大概4小时，最严重的时候是11点到1点），相对从容地寻找解决方案，紧急发布新的页面，或者迁移服务，把损失降到最低。否则，只能像这次事件中的诸多公司一样，听天由命，双手合十祈祷AWS的工程师给力些解决问题。

S3是多种Amazon服务的核心组成部分之
一。无论是利用其进行简单文件存储、对象存储抑或是用于存储网站或者应用程序中的内容，其间复杂的依赖性都必须会引发级联效应。S3能影响到的组件包括用户会话管理、媒体存储、内容存储、用户数据、第三方对象和自动化机制等。

在Thousandeyes公司的NickKephart看来，云用户应检查核心依赖关系，提升关键性服务的冗余水平。AWS的系统在构建当中具备冗余特性，能够实现跨数据中心自动复制存储对象与文件。而作为另一种冗余层，云用户需要利用额外AWS服务区或者其它云服务供应商以彻底避免此类事故；不过这会增加大量管理复杂性与成本支出，因为跨环境间的数据同步工作需要由云用户负责打理。大多数企业并没有选择上述选项，可是单纯的数据备份在数小时的短周期内并不能发挥作用。

虽然面向云环境的迁移确实能够在稳定性与弹性方面为企业带来巨大帮助，但是各种不易被发现的依赖性也因此增加，单一服务失败可能引发大规模服务瘫痪。Nick建议云用户的开发与运营团队审查与云服务供应商间的核心依赖关系，制定策略以监控各项服务可能受到的影响，同时调整现有架构以提升关键性用户的冗余水平。

对于这次事件，陈皓在其博客中表示美国东一区作为老牌的服务区拥有海量对象，能在数小时恢复已属不易，并且幸运的是没有丢失重要数据。

陈皓重申了其观点：一个系统的高可用的因素很多，不仅仅只是系统架构，更重要的是——高可用运维。并且，他认为对于高可用的运维，平时的故障演习是很重要的。AWS平时应该没有相应的故障演习，所以导致要么长期不出故障，一出就出个大的让你措手不及。比如，Facebook每个季度扔个骰子，随机关掉一个IDC一天。Netflix有ChaosMonkey，路透每年也会做一次大规模的故障演练——灾难演习。

在陈天看来，这种容错的操练适合大一些且工程团队有余力的公司。为什么Netflix重度使用AWS，却在历次AWS的宕机中毫发无损？其实Netflix之前也深深地被云的「不稳定性」刺痛过，而如今他们的ChaosMonkey（之后发展为simianarmy）服务，会随时随地模拟各种宕机情况，扰乱生产环境。比如说对于此次事件的演练，可以配置simianarmy去扰乱S3：simianarmy.chaos.fails3.enabled=true。

这样，这群讨厌的猴子就会在不知情的情况下随机把服务器的/etc/hosts改掉，让所有的S3API不可用。如此就可以体验平时很难遇到的S3不可访问的场景，进而找到相应的对策（注意：请在staging环境下谨慎尝试）。

陈皓表示非常喜欢GitLab、AWS这样向大众公开其故障及处理流程，哪怕起因是一个低级的人为错误，也不会掩盖、不会文过饰非。

如果你是一个技术公司，你就会更多的相信技术而不是管理。相信技术会用技术来解决问题，相信管理，那就只会有制度、流程和价值观来解决问题。没有人愿意看到问题的发生；但是问题出现后，最重要的解决反思并从中汲取教训：这难道不是技术人应有的傲骨吗？

如果你正在学习或考虑学习前端框架，我们向你推荐这个React专栏：《React实战进阶45讲》，课程采用React16.3版本教学，通过概念讲解加实战演练的方式，帮你快速掌握当下最热门的前端框架。限时特价最后一天倒计时，识别下图二维码即刻订阅！

知来者之可追JS:解决了吗，怎么弄的啊？这篇文章只有播放端，直播端怎么弄，他说不需要看小程序直播服务，但是小程序管理后台应该还是要开通直播功能吧

Serendipity-天天:三丰云提供免费的虚拟主机和云服务器。用户可以免费体验快速、可靠的托管服务。无论您是想托管个人博客还是小型企业网站，三丰云都可以提供免费、易用的服务。立即注册，体验我们免费的主机和云服务器！

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。

2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。