1. 聚能聊>
  2. 话题详情

前有Gitlab删库,后有AWS误删服务器,乌龙频发我们该如何防范?

otwhmlis_jpeg

前有Gitlab程序猿误删除数据库,后有AWS程序猿输错代码,删除了服务器,这些个乌龙事件看似由于各种低级错误引发,实则却暴露出了很多值得令人思考的问题。

我们先来回顾一下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

520个回答

6

西秦说云 已获得王坚新著《在线》 复制链接去分享

想要避免误操作。首先应该确保工作人员的休息时间。国内互联网崇尚加班,容易让开发人员疲劳工作。对于开车,我们知道不能疲劳驾驶,操作服务器也是一样的。此外,我们需要一些手段,来提醒相关的人员,我们的服务器很重要,比如生产环境的shell使用红色,开发环境使用黄色,测试环境使用绿色等等,不同的颜色可以让我们的维护人员提高警惕。也要注意,对于一些操作,尽可能的选择由机器完成,而不是人工完成,降低人员出错的可能。

元芳 回复

国外不加班的不也出现这个问题,怎么理解?

西秦说云 回复
回复@元芳:

这个就是第二点,要根据环境来做提醒。没有任何提醒,很容易在多个窗口中迷失

拼命三郎ol 回复
回复@元芳:

国外出现一次就算新闻,国内出现这种情况已经算家常便饭了。咬文嚼字的理解问题,怎么理解都解不出来,只会便秘

元芳 回复

家常便饭么?哈哈,我怎么没发觉?看来我是孤陋寡闻了!

评论
1

似水的流年 已获得淘公仔 复制链接去分享

程序员在线上环境直接敲命令,当在执行时需要另外一个人授权确认后才能运行,或者机器识别出来是危险的指令时会有警告,这样的话可以减少这类事故的发生。多重备份虽然好,但是它也只是一段时间执行备份,2次备份中间会有一定的时间间隔,如果恢复到最近的一个备份点,那么备份点到事故发生的数据没有了,也会造成一定的损失。

易房租售 回复

同意

muni 回复

授权也不够,因为授权了代表我同意这次操作,但是我无法监管到这次操作的正确性,所以对于这种一个命令改变未来的指令或者少进行,或者增加这个操作的流程,同时再执行命令中要得到更深层次的审核

元芳 回复
回复@muni:

有没有什么更靠谱的做法呢?

刘秋明 回复

同意

小野13579 回复

同意

能不能不能 回复

同情

好事多 回复

同意

又欠的猪 回复

同意

评论
3

bearyes 已获得淘公仔 复制链接去分享

一直以来,我都觉得直接到生产线上敲命令是一种非常不好的习惯。我认为,一个公司的运维能力的强弱和你上线上环境敲命令是有关的,你越是喜欢上线敲命令你的运维能力就越弱,越是通过自动化来处理问题,你的运维能力就越强。

理由如下:

其一,如果说对代码的改动都是一次发布的话,那么,对生产环境的任何改动(包括硬件、操作系统、网络、软件配置……),也都算是一次发布。那么这样的发布就应该走发布系统和发布流程,要被很好的测试、上线和回滚计划。
关键是,走发布过程是可以被记录、追踪和回溯的,而在线上敲命令是完全无法追踪的。没人知道你敲了什么命令。
其二,真正良性的运维能力是——人管代码,代码管机器,而不是人管机器。你敲了什么命令没人知道,但是你写个工具做变更线上系统,这个工具干了什么事,看看工具的源码就知道了。

元芳 回复

感谢分享,不过这样会不会过于繁琐呢?

vox 回复

这种流程化只是让整个过程更清晰,并不能避免犯错,就算是自动化,界面化,点鼠标的还是人,还是有点错的几率,本质上和输命令没太大区别

dev-qbb6 回复
回复@vox:

流程化,界面化,工具化就存在提升的空间,可以不断积累改进,靠人的改进的就不大靠谱了

评论
2

keller.zhou 已获得淘公仔 复制链接去分享

改进我们的灾备机制,并在主机上凸显出数据恢复的作用。所以,我们并不会从“阻止工程师在生产主机上运行某个命令“这种角度来实现安全。因为,即使我们把禁用rm命令,也只能是阻止工程师不要犯运行 rm -rf /important-data 命令的错误,但是这种方式并不能阻止诸如磁盘损坏,或者其他可能导致数据丢失的情况发生。

我们认为理想的环境,应该是那种即使你犯了错误删了数据,也能轻易恢复,并保证对系统影响最小的环境。这就要求你要日常执行一些流程,并且要容易测试,容易回滚。

元芳 回复

有道理!

vox 回复

在设计架构的时候要把故障做为一种常态来处理,设计机制如何去把故障的影响尽量降低到最小。而不是如何去防止操作人员犯错。只要是人就有可能犯错,即使有审核,审核的人也有可能犯错。

我家二王子 回复

是的,我也这么认为。

评论
1

绝世傲立 已获得定制笔记本 复制链接去分享

采用raid磁盘阵列存储系统来进行相应的存储工作。采用raid磁盘阵列存储可以减少相关问题产生,加强服务器的磁盘容错功能。即便处于服务器瘫痪、自然灾害等极为恶劣的情况下,只要硬盘依然健在,那么,就可以第一时间恢复其正常操作。

要避免错误操作所造成的数据丢失和服务器故障,首先加强权限的管理,要想避免数据丢失所造成的损失,每天都要对重要的数据进行必要的数据备份。防止数据库故障引起的数据丢失。将数据库存储在单独的服务器中,防止应用服务器故障引起的数据丢失。

减少非必要错误的操作。减少操作出错的可能性,管理好服务器用户的权限,防止操作失误引起数据丢失

2

1461587759184916 复制链接去分享

是人总会犯错,只有机器不会。如此低级的失误导致如此严重后果充分暴露了大公司执行工作程序漏洞,这哥们惨了……

元芳 回复

估计不会太惨吧,你看这事件关注度多高~

vip琦 回复

机器就不会错吗?自动重启,自动关机,蓝屏,数据报错,重启后数据丢失,还可能会死机,这还正是机器的问题吗?

评论
2

小柒2012 复制链接去分享

传说中的打错一个字母瘫痪半个互联网!

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

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

为嘛这些大公司 不做 多重备份以及实时备份,可能有难度?

hooo 回复

审核有鸟用,走马观花,审核是最不靠谱的程序 +1

小柒2012 回复
回复@hooo:

只是 减少 出错

元芳 回复

我琢磨着,不开除也会被扣薪资吧?

评论
4

cnssr4bb1t 复制链接去分享

1.思路类似大楼备用发电机,整栋停电的时候备用发电机接管来提供必要的电力,不致于造成恐慌,在这个case场景下,即使线上命令删除一大批核心服务器,也应有响应的备份服务器接管,并且这批资源正常运维权限下不可被删除,以确保出现误操作的时候服务不至于彻底挂掉。

2.线上运维操作的时候设计影响系统黑名单。系统难以知道运维人员是不是真的要进行相应操作,还是打错字母误操作,但是针对某些系统的更改在日常运维权限下一定是不可接受的,如本次故障中被影响的核心系统Index和Placement,系统检查到命令会影响相应黑名单中系统应拒绝当前命令执行。

始终觉得操作出现了差错之后就使流程复杂化、投入更多人力这种行为是比较蠢的,比如找一个人在旁边看着,两个人double check

1

浮生递归 复制链接去分享

操作执行的严格度对应所产生行为的后果的重要度
把各种操作行为及命令分成不同的级别
1级行为或命令,负责人1人处理
2级行为或命令,处负责人外,再加一个监督员确认后再执行
3级,再增加团队主管
4级,部门主管
5级,更高级别
以此类推

聚小编 回复

加强管理流程与追则,是一种方向!

元芳 回复

流程管理是不错,但是这样逐级审批,执行效率会不会降低呢?

浮生递归 回复
回复@元芳:

如果是特别重大的操作,降低执行效率也是应该的。另外,既然很重要,各部门主管自然会积极配合,谁也不敢怠慢

评论
1

寒心 复制链接去分享

我把etc拖走了 livecd进去修了一下午

元芳 回复

别拦我,让我笑一会~

评论
1

shizeqing 复制链接去分享

线上运维操作的时候设计影响系统黑名单。系统难以知道运维人员是不是真的要进行相应操作,还是打错字母误操作,但是针对某些系统的更改在日常运维权限下一定是不可接受的,如本次故障中被影响的核心系统Index和Placement,系统检查到命令会影响相应黑名单中系统应拒绝当前命令执行。

ap1253j8y 回复

曾经在给总局某局长汇报前夕准备数据时,这样在线上系统误操作过,瞬间冷汗就下来了,幸好之前做过备份。

评论
1

fourmi 复制链接去分享

让机器去判断,但是机器怎么知道你是真的要去删这些服务器,还是打错字母了呢?

让另一个人去审核,看上去可以避免一些错误,但是个人总会犯错误的,而且让职位更高级别的人来审核,他不一定知道具体的技术细节,以至于审核到后面就只是走个过场罢了。

Windows的删除有个回收站功能,是个不错的方法,它不是立即删除,而且恢复又快,不知是否可以借鉴一下?

猴哥说的对 回复

有人的地方就可能犯错。

评论
1

ghost-ai 复制链接去分享

我干过类似的……shell脚本修改权限,传值没获取到,导致整个服务器所有文件都变成0777权限……

聚小编 回复

厉害了WORD哥!

评论
1

1012988794233826 复制链接去分享

任何事情都没有十全十美的 鱼和熊掌不可兼得 实时更新bug当然需要线上操作 主要还是应该分情况而定吧

1

vling 复制链接去分享

全是马后炮,装叉犯,删了就删了嘛,多大点事情,谁不会犯点错。还煞有介事地在这里说些不着调的方法。

1

瓜跑跑丶 复制链接去分享

从来不赞同线上模式敲代码,这完全就是不负责任。记得学git的时候看见过一句话,没有提交的代码,都是白敲的。随时备份,以及代码审核是真的好习惯!

1

杨周 复制链接去分享

应该需要审核机制,当执行命令输入复审下。

1

1892988267967496 复制链接去分享

建立第二机制,所有操作只能对第一序列有效。第二序列与第一序列共用控制机制,但只具有次时效的记忆。第一序列失败,控制机制解除对第一序列的控制,控制第二序列,

1

秋水鸣蛙 复制链接去分享

把需要删除的数据移动到某个特定文件夹下,计划任务定时清理这个文件夹

1

1953688799298128 复制链接去分享

授权也不够,因为授权了代表我同意这次操作,但是我无法监管到这次操作的正确性,所以对于这种一个命令改变未来的指令或者少进行,或者增加这个操作的流程,同时再执行命令中要得到更深层次的审核

26