AWS 重大故障！

[sailors]

大家一睡醒就会看到这个大新闻，等待大佬们分析原因。

https://health.aws.amazon.com/health/status

[94]

@stinkytofux #8 ，下不下云都一样。昨天才经历某一个自建机房停电。很多服务都没必要做多活或者容灾。对比上云，自建机房成本明显高太多了。

[bitmin]

好几年前去听一个中小公司的分享，他们老早就阿里云和 AWS 一起用了

[killva4624]

看上去是由一个系统的异常扩散到其他系统，内部的互相依赖...

[jjianwen68]

这种严重故障，协议上如何赔偿客户？

[ksmiracle923]

下云的事故率可能会更高

[coldle]

@Amex #10
这是真的补完东墙跨西墙 🤣

[Miary]

@realpg 学啥不好学米粉 :狗头:

[luodan]

所有服务都在 aws 上。这次故障主要使用的 ec2,eks,rds 都没全坏，只是响应慢点。

[sugars]

https://edition.cnn.com/business/live-news/amazon-tech-outage-10-20-25-intl
国外损失还蛮大的

[realpg]

@Miary #27
我就是米粉啊 不用学 真的米粉
另外就是 说实话 这踏马是本站常态 崇洋媚外

[freekindom]

盲猜 dns 配置错误，永远的单点，永远的痛

[s1461a]

昨天下午 15 点就崩了，拉不动 dockerhub 看到是 aws 的原因

[salmon5]

这个不是第一次，也不是最后一次。不得不说，世界就是个大草台班子，说好的多人 review 、说好的回滚、说好的层层审批

[Miary]

@realpg 那太抱歉了，这里的米粉没有贬义的意思
习惯就好，画风一向如此

[SSyang]

世界就是个大草台班子，这级别的故障估计在国内云的话讨论度得炸了吧。

[fds]

@salmon5 #33 我觉得还是个人能力有极限。自己维护一个小组件可以尽可能完善，需要调整时可以从底层重构。系统一旦大了，很多同事一起协作，如果没人统筹，很容易就各行其是，破坏一些隐性的规则，在一些特殊情况下造成崩溃。甚至有些就是固有缺陷，当初设计权衡时确定的，后期因为需求变动得修改，不从底层改很麻烦，改底层又很危险。这些复杂性很难完全通过制度去规避，审批也只是尽可能降低风险。

[NeoMatrix]

@Amex

某个 AU 的 bro 改了 us-east-1 的核心网络配置导致的，DDB 也是受影响的一方。大部分服务的核心控制面都在 us-east-1 ，所以影响很大。DDB 是通过手动恢复了 DNS recorde 来解决了。

[realpg]

@Miary #34
不用抱歉 我自己都知道米粉是贬义 毕竟我有投资一个公关传媒公司 很懂这行的不为人知的秘密

[yxzblue]

屎山终于爆了

[Amex]

@NeoMatrix
对我写的不太清楚 不是 ddb 的问题
话说回来这么核心的网络配置改变没有 review 就上 prod 么⋯不知道这些人得写几个 coe