我们先来回顾一下3月2日事件
3月2日AWS声称,输错命令导致了亚马逊网络服务(AWS)出现持续数小时的故障事件。
故障原因:
亚马逊简单存储服务(S3)团队当时在调试一个问题,该问题导致S3计费系统的处理速度比预期来得慢。太平洋标准时(PST)上午9:37,一名获得授权的S3团队成员使用事先编写的playbook,执行一条命令,该命令旨在为S3计费流程使用的其中一个S3子系统删除少量服务器。遗憾的是,输入命令时输错了一个字母,结果删除了一大批本不该删除的服务器。
重新启动时,S3无法处理服务请求。该区域依赖S3进行存储的其他AWS服务也受到了影响,包括S3控制台、亚马逊弹性计算云(EC2)新实例的启动、亚马逊弹性块存储(EBS)卷(需要从S3快照获取数据时)以及AWSLambda。
处理结果:
下午1:54分恢复正常。
官方博客解释:“虽然删除容量是一个重要的操作做法,但在这种情况下,使用的那款工具允许非常快地删除大量的容量。我们已修改了此工具,以便更慢地删除容量,并增加了防范措施,防止任何子系统低于最少所需容量级别时被删除容量。”
比如:
程序员是否应该在线上环境直接敲命令?
有人说,可以,但是干这样的事情时,得一个人干,另一个人在旁边看着。是否应该做好多重备份?
有人说,当然!但也有人质疑,多重备份就安全了吗?就算所有的备份都可用,也不可避免地会有数据的丢失,或是也会有很多问题。
淘公仔 x 3
王坚新著《在线》 x 1
定制笔记本 x 1
西秦说云
已获得王坚新著《在线》
复制链接去分享
想要避免误操作。首先应该确保工作人员的休息时间。国内互联网崇尚加班,容易让开发人员疲劳工作。对于开车,我们知道不能疲劳驾驶,操作服务器也是一样的。此外,我们需要一些手段,来提醒相关的人员,我们的服务器很重要,比如生产环境的shell使用红色,开发环境使用黄色,测试环境使用绿色等等,不同的颜色可以让我们的维护人员提高警惕。也要注意,对于一些操作,尽可能的选择由机器完成,而不是人工完成,降低人员出错的可能。
似水的流年
已获得淘公仔
复制链接去分享
程序员在线上环境直接敲命令,当在执行时需要另外一个人授权确认后才能运行,或者机器识别出来是危险的指令时会有警告,这样的话可以减少这类事故的发生。多重备份虽然好,但是它也只是一段时间执行备份,2次备份中间会有一定的时间间隔,如果恢复到最近的一个备份点,那么备份点到事故发生的数据没有了,也会造成一定的损失。
bearyes
已获得淘公仔
复制链接去分享
一直以来,我都觉得直接到生产线上敲命令是一种非常不好的习惯。我认为,一个公司的运维能力的强弱和你上线上环境敲命令是有关的,你越是喜欢上线敲命令你的运维能力就越弱,越是通过自动化来处理问题,你的运维能力就越强。
理由如下:
其一,如果说对代码的改动都是一次发布的话,那么,对生产环境的任何改动(包括硬件、操作系统、网络、软件配置……),也都算是一次发布。那么这样的发布就应该走发布系统和发布流程,要被很好的测试、上线和回滚计划。
关键是,走发布过程是可以被记录、追踪和回溯的,而在线上敲命令是完全无法追踪的。没人知道你敲了什么命令。
其二,真正良性的运维能力是——人管代码,代码管机器,而不是人管机器。你敲了什么命令没人知道,但是你写个工具做变更线上系统,这个工具干了什么事,看看工具的源码就知道了。
keller.zhou
已获得淘公仔
复制链接去分享
改进我们的灾备机制,并在主机上凸显出数据恢复的作用。所以,我们并不会从“阻止工程师在生产主机上运行某个命令“这种角度来实现安全。因为,即使我们把禁用rm命令,也只能是阻止工程师不要犯运行 rm -rf /important-data 命令的错误,但是这种方式并不能阻止诸如磁盘损坏,或者其他可能导致数据丢失的情况发生。
我们认为理想的环境,应该是那种即使你犯了错误删了数据,也能轻易恢复,并保证对系统影响最小的环境。这就要求你要日常执行一些流程,并且要容易测试,容易回滚。
绝世傲立
已获得定制笔记本
复制链接去分享
采用raid磁盘阵列存储系统来进行相应的存储工作。采用raid磁盘阵列存储可以减少相关问题产生,加强服务器的磁盘容错功能。即便处于服务器瘫痪、自然灾害等极为恶劣的情况下,只要硬盘依然健在,那么,就可以第一时间恢复其正常操作。
要避免错误操作所造成的数据丢失和服务器故障,首先加强权限的管理,要想避免数据丢失所造成的损失,每天都要对重要的数据进行必要的数据备份。防止数据库故障引起的数据丢失。将数据库存储在单独的服务器中,防止应用服务器故障引起的数据丢失。
减少非必要错误的操作。减少操作出错的可能性,管理好服务器用户的权限,防止操作失误引起数据丢失
传说中的打错一个字母瘫痪半个互联网!
这个倒霉的程序员会被开除吗?
那么,这名程序猿打错命令有没有责任?肯定有。但是,在处理高度可靠的云服务时,每一次操作都应该按照严格的程序,每一个命令都要经过足够的审核。除非这名程序员在操作过程中因为偷懒省略了一些必要的步骤,否则,这次事故更多是系统的责任,因为系统没有足够的机制来防止错误的发生。人,都是会犯错的,只有机器不会。
为嘛这些大公司 不做 多重备份以及实时备份,可能有难度?
1.思路类似大楼备用发电机,整栋停电的时候备用发电机接管来提供必要的电力,不致于造成恐慌,在这个case场景下,即使线上命令删除一大批核心服务器,也应有响应的备份服务器接管,并且这批资源正常运维权限下不可被删除,以确保出现误操作的时候服务不至于彻底挂掉。
2.线上运维操作的时候设计影响系统黑名单。系统难以知道运维人员是不是真的要进行相应操作,还是打错字母误操作,但是针对某些系统的更改在日常运维权限下一定是不可接受的,如本次故障中被影响的核心系统Index和Placement,系统检查到命令会影响相应黑名单中系统应拒绝当前命令执行。
始终觉得操作出现了差错之后就使流程复杂化、投入更多人力这种行为是比较蠢的,比如找一个人在旁边看着,两个人double check
国外不加班的不也出现这个问题,怎么理解?
这个就是第二点,要根据环境来做提醒。没有任何提醒,很容易在多个窗口中迷失
国外出现一次就算新闻,国内出现这种情况已经算家常便饭了。咬文嚼字的理解问题,怎么理解都解不出来,只会便秘
家常便饭么?哈哈,我怎么没发觉?看来我是孤陋寡闻了!