#aws事故

Micro 小熊猫

2周前

经历了这几次AWS/Windows/Cloudflare的事故，想必外星人已经很清楚地球文明最脆弱的地方在哪了。

#aws事故 #Windows事故 #Cloudflare事故 #地球文明脆弱性 #外星人威胁

1个月前

AWS 这次事故的原因报告出来了：简单看了一下，让 AI 总结一下： 1 DNS 记录由 DNS Planner 定期生成一份完整的区域计划，列出应该指向哪些load balancer。 2 DNS Enactor 负责把计划写进 Route 53（Amazon 的 DNS 系统），每个可用区运行一个独立实例。所以有多个。 3 Enactor 开工前只核对一次：确保手里的计划是最新版本。 4 其中一个 Enactor 在更新 DNS 记录时，速度卡了，每改一个endpoint 都要试好几次才成功。 5 在它卡顿的过程中，Planner 生成了多个更新的计划，其他 Enactor 已经快速把最新计划写进了 Route 53。 6 慢的 Enactor 最初检查时认为自己的计划是最新，但由于延迟太久，实际上已经过时。它没有再次检查，直接用的旧计划。 7 快的 Enactor 写完后会清理旧计划，把所有比自己刚应用的版本更旧的计划全部删除。 8 结果：慢 Enactor 正在应用的旧计划被快的 Enactor 删除，导致区域端点的 DNS 记录被清空。 9 区域端点无法解析，连接全部失败，引发区域级服务中断。感觉设计真的挺复杂的，但是几十万条 DNS 记录只能自动化实现，并发 + 延迟就造成了竞态条件的问题。

#aws事故 #DNS故障 #区域服务中断 #竞态条件 #自动化运维

1个月前

说起 aws 的事故来，我是觉得自建机房挺好玩的，从选点拉网线和采购开始，一点点把自己的服务搭建起来，很有成就感，现在大家都爱用云了，云适合快速迭代快速部署，但有几个问题： 1）规模上去了成本会变高； 2）你用户集中的地方并不一定是云的重点覆盖区域，不一定能提供最好的接入质量； 3）你不是大客户时常被忽视； 4）容易被云的稳定性迷惑，散失了基本的生存能力是的云大部分时候很少出事情，但一旦出事情，经常看到某某某成长还不错的公司，一夜之间数据全没了，然后自己完全没备份，从此一蹶不振，跟腾讯云扯皮几年无果，或者某某公司因单个云挂掉整体停止服务，感觉这些公司用云用多了被宠坏了，自己的运维能力真的已经退化的跟婴儿差不多的水平，完全散失了再丛林中生存的基本技能。我不说让大家一夜之间都下云，但要确保有下云的能力，不要被哪家云厂商绑架，过分独有的服务，如果不具备替代性或者没法切换，做的再好也不要用，同时做好数据备份，最好至少保持两家以上的云提供商，能随时切换那种。

#aws事故 #自建机房 #云计算问题 #数据备份 #多云策略

1个月前

aws 这次事故感觉很严重啊

#aws事故 #AWS故障 #云服务 #IT事故 #负面