AWS S3误操作,官方故障回顾及专家深度思考

继Gitlab的误删除数据事件没几天,“不沉航母” AWS S3(Simple Storage Service)几天前也“沉”了4个小时,墙外的半个互联网也跟着挂了。如约,按AWS惯例,AWS给出了一个简单的故障报告《Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region》。这个故障简单来说和Gitlab一样,也是人员误操作。先简单说一下这份报中说了什么。

 

故障原因 
 

简单来说,这天,有一个AWS工程师在调查Northern Virginia (US-EAST-1) Region上S3的一个和账务系统相关的问题,这个问题是S3的账务系统变慢了(我估计这个故障在Amazon里可能是Sev2级,Sev2级的故障在Amazon算是比较大的故障,需要很快解决),Oncall的开发工程师(注:Amazon的运维都是由开发工程师来干的,所以Amazon内部嬉称SDE-Software Developer Engineer为Someone Do Everything)想移除一个账务系统里的一个子系统下的一些少量的服务器(估计这些服务器上有问题,所以想移掉后重新部署),结果呢,有一条命令搞错了,导致了移除了大量的S3的控制系统。包括两个很重要的子系统:

 

  1. 一个是S3的对象索引服务(Index),其中存储了S3对象的metadata和位置信息。这个服务也提供了所有的GET,LIST,PUT和DELETE请求。
  2. 一个是S3的位置服务系统(Placement),这个服务提供对象的存储位置和索引服务的系统。这个系统主要是用于处理PUT新对象请求。

 

这就是为什么S3不可访问的原因。

 

在后面,AWS也说明了一下故障恢复的过程,其中重点提到了这点——

 

虽然整个S3的是做过充分的故障设计的(注:AWS的七大Design Principle之一Design for Failure)—— 就算是最核心的组件或服务出问题了,系统也能恢复。但是,可能是在过去的日子里S3太稳定了,所以,AWS在很长很长一段时间内都没有重启过S3的核心服务,而过去这几年,S3的数据对象存储级数级的成长(S3存了什么样数量级的对象,因为在Amazon工作过,所以大概知道是个什么数量级,这里不能说,不过,老实说,很惊人的),所以,这两个核心服务在启动时要重建并校验对象索引元数据的完整性,这个过程没想到花了这么长的时候。而Placement服务系统依赖于Index服务,所以花了更长的时间。

了解过系统底层的技术人员应该都知道这两个服务有多重要,简而言之,这两个系统就像是Unix/Linux文件系统中的inode,或是像HDFS里的node name,如果这些元数据丢失,那么,用户的所有数据基本上来说就等于全丢了。

 

而要恢复索引系统,就像你的操作系统从异常关机后启动,文件系统要做系统自检那样,硬盘越大,文件越多,这个过程就越慢。

 

另外,这次,AWS没有使用像以前那样Outage的故障名称,用的是“Increased Error Rate”这样的东西。我估计是没有把所有这两个服务删除完,有些用户是可以用的,有的用户则不行了。

 

后续改进 
 

在这篇故障简报中,AWS也提到了下面的这些改进措施——

 

1)改进运维操作工具。对于此次故障的运维工具,有下面改进:

 

  • 让删除服务这个操作变慢一些(笔者注:这样错了也可以有时间反悔,相对于一个大规模的分布式系统,这招还是很不错的,至少在系统报警时也可以挽救);
  • 加上一个最小资源数限制的SafeGuard(笔者注:就是说,任何服务在运行时都应该有一个最小资源数,分布式集群控制系统会强行维护服务正常运行的最小的一个资源数);
  • 举一反三,Review所有和其它的运维工具,保证他们也相关的检查。

 

2)改进恢复过程。对于恢复时间过长的问题,有如下改进:

 

  • 分解现有厚重的重要服务成更小的单元(在AWS,Service是大服务,小服务被称之为Cell),AWS会把这几个重要的服务重构成 Cell服务。(笔者注:这应该就是所谓的“微服务”了吧)。这样,服务粒度变小,重启也会快一些,而且还可以减少故障面(原文:blast radius – 爆炸半径);
  • 今年内完成对Index索引服务的分区计划。

 

相关思考 
 

下面是我对这一故障的相关思考——

 

0)太喜欢像Gitlab和AWS这样的故障公开了,哪怕是一个自己人为的低级错误。不掩盖,不文过饰非,透明且诚恳。Cool!

 

1)这次事件,还好没有丢失这么重要的数据,不然的话,将是灾难性的。

 

2)另外,面对在US-EASE-1这个老牌Region上的海量的对象,而且能在几个小时内恢复,很不容易了。

 

3)这个事件,再次印证了我在《关于高可用的系统》中提到的观点:一个系统的高可用的因素很多,不仅仅只是系统架构,更重要的是——高可用运维。

 

4)对于高可用的运维,平时的故障演习是很重要的。AWS平时应该没有相应的故障演习,所以导致要么长期不出故障,一出就出个大的让你措手不及。这点,Facebook就好一些,他们每个季度扔个骰子,随机关掉一个IDC一天。Netflix也有相关的Chaos Monkey,我以前在的路透每年也会做一次大规模的故障演练——灾难演习。

 

5)AWS对于后续的改进可以看出他的技术范儿。可以看到其改进方案是用技术让自己的系统更为的高可用。然后,对比国内的公司对于这样的故障,基本上会是下面这样的画风:

 

  1. 加上更多更为严格的变更和审批流程;
  2. 使用限制更多的权限系统和审批系统;
  3. 使用更多的人来干活(一个人干事,另一个人在旁边看);
  4. 使用更为厚重的测试和发布过程;
  5. 惩罚故障人,用价值观教育工程师。

 

这还是我老生长谈的那句话——如果你是一个技术公司,你就会更多的相信技术而不是管理。相信技术会用技术来解决问题,相信管理,那就只会有制度、流程和价值观来解决问题(注意:这里我并没有隔离技术和管理,只是更为倾向于用技术解决问题)。

 

最后,你是要建一个“高可用的技术系统”,还是一个“高可用的管理系统”?欢迎留言和我们一起探讨。

原文发布时间为:2017-03-05

时间: 2024-08-03 10:21:49

AWS S3误操作,官方故障回顾及专家深度思考的相关文章

aws实例误操作 吧网卡禁掉了,该怎么链接上呢?

问题描述 aws实例误操作吧网卡禁掉了,该怎么链接上呢? 解决方案 解决方案二:控制面板里面找找,再不行找技术支持.解决方案三:EC2控制台->NETWORK&SECURITY->NetworkInterfaces把网卡再绑上去就好了

炉石传说罕见数据库事故!丢失30%数据,疑似误操作?

引言   看到我这标题,千万别以为我是故意为了吸引你的眼球,而是官方这么说的哦:     这里用到个词-"回档",今天第一次听说,最开始不理解啥意思,接着恍然大悟,不就是Oracle 9i开始提供的新特性Flashback么!   你的朋友圈是不是也被刷屏了   昨天大概6点左右开始,我的朋友圈被刷屏了.     结合贴吧的一些留言,简单回顾下大体过程:   1月14日15:20开始,数据库由于供电异常中断,数据损坏. 接着数据库带病工作2天. 1月16日凌晨开始进行修复维护. 1月1

ApexSQL Log-SQL误操作恢复工具(支持sql2008,sql2012)

今天不小心对数据库执行了一次误操作,心想有没有什么工具能恢复这次误操作呢?于是找到 了Log Explorer 4.2,可惜它最多只支持SQL 2005,在SQL 2008上无法使用,然后又找到了ApexSQL Log,最新版本最高支持SQL 2008以及SQL 2012,试用版可以提供功能无限制14天的免费试用期,功能倒真是强大   直接下载安装,官方下载地址:http://www.apexsql.com/sql_tools_log.aspx 安装完成,打开主界面:   点击"New"

Windows7操作系统启动故障解决方法

相信绝大多数朋友都用上了Win7系统了吧,Win7系统虽然比以前其他版本的Windows系统都稳定得多,但是由于安装某些特殊软件或误操作,系统还是会出现各种启动故障.接下来,笔者就来给大家分析一下Win7常见启动故障产生的原因以及如何解决相关启动故障. 故障1:MBR故障 故障表现:开机后出现类似"press F11 start to system restore"错误提示 原因分析:许多一键Ghost之类的软件,为了达到优先启动的目的,在安装时往往会修改硬盘MBR,这样在开机时就会出

关闭windows7旗舰版系统中的power键以防误操作直接关机

  1.在win7桌面空白处鼠标右击选择"个性化"选项,然后选择"屏幕保护程序"; 2.在弹出的屏幕保护程序对话框中,点击界面下方的"更改电源设置"项; 3.在弹出来的电源设置界面中,点击左侧的"选择电源按钮功能",然后选择按电源按钮时,选择"从不采取任何操作",完成设置之后重启计算机即可生效. 关于关闭windows7旗舰版系统中的power键以防误操作直接关机就跟大家分享到这边了,如果你也是有遇到这样的

Windows中哪些误操作会损害硬盘

  一般地,现在的硬盘都加入了S.M.A.R.T的自动侦测技术,以便让用户能在致命的故障出现前看到先兆,备份好数据--但这都是针对正常操作情况下设计的,如果用户的使用方法如下所列,故障的出现将可能是无先兆的,也就是突然死亡. 一.在开机和关机的时候突然强行切断电源 现在的电源及主板的ATX设计,普遍实现了软关机的功能.这种设计让人倍感方便.但是软关机要先完成一系列的关闭正在运行的程序的操作,加上各种操作系统及各主板厂家设计上的兼容性.BUG,Windows在进行关闭应用程序然后切断电源的时候经常

【MySQL】恢复误操作的方法

一 .前言 本周接二连三的出现开发人员在测试环境和生产误操作导致数据库误删除/更新,对DBA而言,回滚数据着实是一件头疼的事情,凡涉及到恢复线上数据必然对应用带来一定的影响.大多数情况是开发误操作delete数据,update多数行,根据之前的操作经验,本文介绍常用的恢复方法. 写本文的时候 Monogdb 也被曝出有被利用安全漏洞,数据被删除了,希望各位DBA/安全相关人员及时查看自己负责的业务数据库安全相关问题,保护好自己的数据. 二.常用的恢复方式 2.1 利用备份恢复 使用这种方式的前提

电脑操作大忌之硬盘毁灭性误操作_硬件维护

本文要叙述的是会造成硬盘毁灭性故障的错误及操作,不是一般的磁盘和系统错误,这些故障通常没有先兆,一旦出现,在BIOS里也不能认出硬盘,硬盘数据挽回的可能性极小,此所谓硬盘之大敌.  一般地,现在的硬盘都加入了S.M.A.R.T的自动侦测技术,以便让用户能在致命的故障出现前看到先兆,备份好数据--但这都是针对正常操作情况下设计的,如果用户的使用方法如下所列,故障的出现将可能是无先兆的,也就是突然死亡.  一.在开机和关机的时候突然强行切断电源  现在的电源及主板的ATX设计,普遍实现了软关机的功能

百神大战续:UC再发声明称百度仍在“误操作”

中介交易 SEO诊断 淘宝客 云主机 技术大厅 新浪科技讯 5月21日下午消息,继本月初UC发布声明指责百度利用垄断打击神马搜索之后,UC今日再度发布声明,称继第一波对神马搜索和UC浏览器展开了一系列封杀和屏蔽后,百度再次对UC旗下产品的"误操作". UC优视表示,近期在手机百度.百度手机助手.百度PC网页搜索以及百度手机网页搜索等产品搜索"UC浏览器",优先推荐的不是下载量最大的主流官方版本,而是UC浏览器(x86版),导致大量用户下载后无法正常安装使用. &qu