澳门新葡亰平台官网为故障而设计:AWS S3云存储故障给我们的启示 运维派

by admin on 2020年4月17日

2月28号,号称「亚马逊AWS最稳定」的云存储服务S3出现“超高错误率”的宕机事件。

导读:AWS S3
故障已经过去一周多了,我们可以从中得到哪些启示?本文由魏佳翻译,转载请注明来自高可用架构
(ID: ArchNotes) 公众号。

遇到的问题:

接着,半个互联网都跟着瘫痪了。

如今 2017
年,云是重要业务技术选型的最好选择。使用云也为管理基础设施带来了很多益处,包括提升灵活性、可扩展性,同时降低了
IT 成本。但是上周我们目睹了 AWS S3 停机故障
[1],看来即使是最可靠的服务提供商也可能遇到倒霉的一天。
服务不可用直接导致了数百万的收入损失,以及难以估量的公司品牌负面影响。尽管如此,你依然可以采取一些预防措施来减少这种事件的负面影响。

  1. 过去一年事故频发
  2. 事故恢复时间过长
  3. 对事故现场没有很好的取证,不便于日后的分析
  4. 架构模块在使用的时候没有实质性对产生影响做分析,带有盲目性

一个字母造成的血案

事故报告

 

AWS在昨天给出了确切的解释:一名程序员在调试系统的时候,运行了一条原本打算删除少量服务器的脚本,结果输错了一个字母,导致大量服务器被删。为了修复这个错误,亚马逊不得不重启整个系统(在此之前已经几年都没有重启过了),最终导致了震惊全球的Amazon
S3宕机4个小时事件。

亚马逊 Web
服务(AWS)是当今被广泛使用的的云基础设施服务,占据全球40%以上的市场份额。一直以来
AWS 的服务质量都高于其服务质量协议(SLA)
,达到99.9%的正常运行时间。但是上周发生的 AWS
简单对象存储服务(S3)故障说明没有什么服务是完美无懈可击的。

解决方案的个人想法:

澳门新葡亰平台官网 1

在星期二上午 11:30 左右,AWS 美国东一区(US-EAST-1)的 S3
存储服务宕机,并且迅速产生了巨大的影响。 服务恢复后,AWS
发布了一个声明,有意思的是,我们从官方声明中发现,这次故障既不是人为破坏的,也是不是系统损坏的原因,而仅仅是由简单的错误输入命令导致。
难以置信吧?但确实是,一个完全无意的命令输入错误 [1],这导致像
Adobe,Slack,Expedia,甚至是美国证券交易委员会,都遭受了严重的性能影响,据悉还有小的在线电商网站因此被拖垮。

  1. 容灾:
    1. 关键参数
      1. NRO – 网络恢复目标(灾难后的网络恢复时间)
      2. RPO – 恢复点目标 (灾难前最后一次备份的时间,数据丢失)
      3. RTO – 时间恢复目标 (灾难后恢复物理系统环境的时间)
      4. RAP – 访问恢复目标(验证应用功能是否正常运行的时间)
  2. 保存现场
  3. 故障转移
  4. 事故恢复
  5. 逻辑优化

我想这名程序猿当时的表情应该是这样的

目前很难准确估量在这将近 5
个小时的宕机过程中造成的财产损失,但据不完全统计,已经造成了数千万的财产损失,数十万的用户受到影响。

重构,借用工具。上线必须保证:httpunit功能测试,LoadRunner负载测试通过。

曾经有人计算过,AWS每宕机一分钟,对亚马逊造成的损失是$66,240美元...而这还不包括那些依靠AWS来运行自家服务的公司们的损失。所以这次接近4小时的宕机造成多大的损失,只能请大家自行脑补了。

事故真相

  1. 性能优化
  2. 后期优化

澳门新葡亰平台官网 2

整个事故过程中,虽然许多依赖美国东一区 S3
服务的公司在宕机期间受到严重影响,但仍然有一些公司部分或全部业务毫不受影响。
这是为什么? 有几个因素发挥作用。

利用大数据分析,将业务问题转化为大数据问题。日志分析,监控异常,逻辑优化,响应时长分析,并发分析,数据恢复,保存现场数据,提供可持续改进的数据基础。

程序员的世界就是这样的不近人情,一丁点儿错误就足以酿成大错。在这次“一个字母造成的血案”之前,刚刚发生了Gitlab程序猿用错一条命令误删了整个数据库的悲剧。再久一点以前,欧洲宇航局的的火星探测器因为传感器失灵了仅仅一秒钟,就造成探测器在火星表面坠毁,历时数年的探测计划功亏一篑。

隐藏的依赖

提供数据的频率:

所以,当你身边的程序员为了一点点小事较真的时候,你一定要理解:魔鬼都藏在细节里啊!

S3
服务已经成为大多数基于云的分布式系统中至关重要的组件。正因为其被广泛使用,同时大量复杂的服务或系统构建在它之上,所以当
S3 服务不可用时加剧了事故影响范围和深度。对于那些直接或间接依赖(S3
服务) 的系统,S3 服务都会成为潜在的影响因素。

  1. 流量异常:必须实时或近实时的进行
  2. 战略性业务业务决策的趋势分析:分析可采用批量模式
  3. 数据采集(后续)

当S3宕机时,你才明白AWS多么强大

网络性能监控公司 Thousand Eyes 归纳了 3 种可能被所依赖的 S3
服务影响的表现形式:

反正我的blog除了乐视同事也没有别人看,不涉及信息安全。把接口架构图放在这里,以后好找:

几年前,Google.com曾有一次宕机了一个小时。在那一个小时的时间里,整个互联网的流量减少了40%。当时有人感慨:Google一家就是半个互联网。如今,“半壁江山”的江湖地位似乎要归属于亚马逊了。

如果一个公司的静态网页直接或单独托管在宕机的 S3
服务器上,那么将变得完全不可用。很不幸,Lululemon Athletica Inc
是这类公司之一。如果页面中的某些元素(脚本、资源)直接或间接依赖于 S3
服务,则会发生部分失效。比如Slack,事故造成它的文件上传功能变得不可用。应用程序的关键服务可能依赖于受影响的
S3 或其他 AWS 服务,这将导致应用部分或完全无法使用。8th Light
的创始人之一介绍了他对 AWS Lambda 功能的使用,通过它可以实现 rate limit
功能以限制用户恶意请求,但在宕机期间它变得无法使用,因为该功能依赖 S3
服务。最后他给出了一条建议:“清楚的认识你依赖的依赖。“

澳门新葡亰平台官网 3

AWS是云计算领域全球的领导者,而S3又是AWS历史最久的服务,可以说是AWS的基石。很多AWS提供的其他服务都依赖于S3云存储,比如EC2,Lambda
和 EBS
等,所以这次宕机影响巨大。据最近的统计显示,全球共有148213个网站和121761个独立域名在使用AWS
S3服务。

滑稽的是,事故刚开始发生时,AWS 无法将 S3
服务状态更新到仪表板上,因为它也依赖于 S3
来存储。这意味着出现故障的服务在宕机期间显示为正常?!这就是我们说的隐藏的依赖!

不是我画的图果然就看起来高端大气上档次[汗]。性能优化是我的日常工作,可以慢慢来。如果遇到什么闹心的线上事故,建议看看

澳门新葡亰平台官网 4

这里我们强调的是要知道风险在哪里,并做有针对性得规划。
将每个远程依赖关系都看作是潜在的故障点这会有所帮助,特别是以这次 AWS
事故为例,对远程依赖关系的分析首先将会帮你反思是否真的有依赖的必要。

《打错一个字母-瘫痪半个互联网  
 亚马逊AWS的云存储服务S3超高错误率宕机事件》

就拿这次事故来说,很多人一觉起来发现手机里的歌听不了,电影看不了,股票不能交易,App也没法下载,就连家里的智能电器都纷纷罢工(主页君家里的电子门锁都失灵了!)云计算听上去离生活很远,其实离我们很近

装满鸡蛋的篮子

《google.com宕机一小时》

这次S3宕机影响到无数家公司和服务

AWS 的数据中心(zone)遍布全球 16
个不同的国家地区。在美国,有四个地区:北弗吉尼亚州、俄亥俄州、俄勒冈州和北加利福尼亚州,剩下的则分布在欧洲、亚洲、南美洲和澳大利亚。

《gitlab程序猿用一条错误命令误删了整个数据库》

在这里罗列了几个著名的:

在 AWS
上部署/使用服务时,可以选择要部署到哪个独立区域。显而易见,通过跨地区、或者跨云服务提供商来创造冗余,将提供最健壮的业务连续性。在这次事故中,只有一个区(美国东一区)受到影响,但对那些资源/服务/依赖集中在这个区的公司来说,这便成他们的噩梦。

心情会好很多!

  • Apple App Store & icloud

  • Airbnb

  • Expedia

  • Netflix

  • Quora

  • Amazon Echo

  • Amazon.com

  • Nasdaq

为故障而设计

 

澳门新葡亰平台官网 5

前面提到,一些公司在这次事故中损失较小。这是因为他们部署服务时,带着某一天某些事会出错的预期,从而更有针对性得做准备。

今天开会确定的方案,这里备忘一下:

就连AWS自己用来公布服务状态的 AWS Dashboard
都受到了影响,在一段时间内只能通过Twitter账户来发布更新状态。这次S3宕机事件的影响范围之广,可见一斑。

虽然 AWS
正在处理此次事故的后续事宜,但是亚马逊的零售部门(amazon.com),尽管依赖
S3,但在事故期间并没有受多大影响。诚然,亚马逊在任何时候都会采取所有必要和建议的预防措施,以确保其旗舰产品的健壮。

1
从上面架构图中可以看出安外联通的cbase只是做了一个冷备,会面临网络抖动的问题;马驹桥电信一旦故障,需要手动切换。冷备的机器虽然是正常写入的,但是数据没有经过检验,切换后的数据一致性隐患问题;跨机房的性能问题。所以我们决定改成联通和电信做一个物理隔离。这样做需要解决的问题:swiftq给联通和电信发消息,两端接受和处理消息的时机不一样,但是只有两段都更新成功后才能给各端发通知消息的更新,涉及到策略的问题。一旦一边更新失败,需要有补偿机制,补偿的策略问题。部署的复杂性提高,合理部署的问题。

“打错一个字母瘫痪半个互联网”是怎样的感受?

如何为故障做规划和预防,我们可以参考
Netflix。他们内部使用一套被称为猴子军团(Simian
Army)的云测试工具,这些工具专门用于模拟系统上的破坏,以便捕获可能导致服务中断或性能问题的任何潜在故障点
。通过规划一系列可能遇到的小问题和大问题,Netflix
能够预测他们系统面对问题时反应,并依此建立各种保护措施,以确保系统在故障期间依然可以提供服务。

2
memcache的mget在数据量大时性能急剧下降的问题。性能急剧下降时占用连接导致阻塞的问题。测试时需要注意key的数量以及value大小的双重变化影响。

在今天亚马逊披露了这起事故背后的原因后,很多人心里都会有一个疑问:

应对故障的准备措施不应采取”一刀切“的方法。亚马逊和 Netflix
都拥有海量的数据、数亿用户,他们的预防措施和解决方案可能有很大不同。在决定如何防止第三方故障时,应考虑诸如数据容量,针对不同情况进行防护的性价比,以及计算损失风险等因素。

3 cbase读写分离的问题

这个倒霉的程序员会被开除吗?

对于较小的规模,解决方案可能不是完全预防,而是如何优雅的降级。这意味着需要对应用中各个功能进行不同优先级的容错。例如网络故障时,对于需要远程访问的资源降级成从本地文件/缓存中获取。

 

关于这一点,虽然主页君肯定没法做出准确的判断,但还是愿意给出我们的猜测:不会。

S3 事故也暴露了网络架构设计的缺陷,AWS
官方提出了未来防止这类事故的举措,也表态采取更多的预防措施来保护客户们的业务不受损失是十分重要且明智的。

另外,我们是基础服务部门,应该可以不使用http协议来调用

首先,这名程序猿打错命令有没有责任?肯定有。但是,在处理高度可靠的云服务时,每一次操作都应该按照严格的程序,每一个命令都要经过足够的审核。除非这名程序员在操作过程中因为偷懒省略了一些必要的步骤,否则,这次事故更多是系统的责任,因为系统没有足够的机制来防止错误的发生。人,都是会犯错的,只有机器不会。

好了,上星期我们学到了“一个错误输入可以使得一部分互联网不可用”,现在我们学到了更好更充分的准备和预防,可以最大程度减少故障再次发生时的损害和影响。

其次,oncall(值班)的程序员一边操作着影响巨大的的系统,一边还需要争分夺秒的解决问题,肩上的压力之大难以想象。虽然这次事故确实是由于一个打错的字母造成的,但如果事故发生后,作为云服务领航者的亚马逊不是勇敢的承担这笔学费,而是把锅甩给某一个程序员身上,那就太让人寒心了。

本文链接:

我甚至敢断言:如果亚马逊真的做出这样的决定,那么他们在日后的招聘过程中会遇到很大的困难——每个程序员都会三思:我会不会成为下一个背锅的人?

本文原文
-carpenter/2017/03/06/to-minimize-downtime-prepare-for-chaos.html

澳门新葡亰平台官网 6

当然,如果这哥们(也可能是姐们)

真的因此被解雇了,想想看——我打错了一个字母,就瘫痪了半个互联网 

这牛逼也够吹一辈子了!

最后,主页君想说:程序员这行真的不容易,做云服务的尤其如此,大家且行且珍惜。对受到这次事故影响而心惊胆战了好几几天的程序员们说一句:加油,你们挺住!

稿源:西雅图IT圈

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图