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个回答

1

1268233929058008 复制链接去分享

1.做好备份
2.在测试系统中验证

1

1082117777128544 复制链接去分享

做多了就会凭经验先得出要进行的操作的危险性,比如要进行ls这种操作就可以毫无顾虑,如果是cp命令,就要注意会不会覆盖掉有用的文件,或者在cp之前先备份,在做危险操作时必须要先用小样本进行测试!!很难想象AWS在没有测试的情况下直接去执行有可能危险的操作!就算再自信,也必须要先单元测试!

1

1870413004863677 复制链接去分享

要制定操作规范,让所有要执行的程序都是可逆的,程序稳定后再做后续操作。

1

eavergg 复制链接去分享

服务器上要做的事情是有限的,针对每个事情都要编写成脚本并测试通过,以后就只要针对这些事情,选择执行与不执行,也方便以后由统一的运维系统一管理调用。 突发大事件,才允许在服务器上临时执行灵活的命令

1

1417680139106246 复制链接去分享

应该进行;实时备份异常记录,加全程循环数据库。防止不可能完美的程序bug,能给修复更新完善带来帮助

0

lyrewu 复制链接去分享

误操作不可避免的,还是选择备份吧…本地、云上、异地均来个备份,尤其是金融业,多灾备少忧患。

0

无雨 复制链接去分享

设试点服,设转正式点权限

0

sadadsada 复制链接去分享

回滚回滚。。

0

1918249368820238 复制链接去分享

尽量少人介入才是正途。

0

mec 复制链接去分享

但是你不得不佩服别人防删除备份机制不是吗?很多数据都恢复了。

0

yukmiwu 复制链接去分享

首先,从工具设计来讲,对于删除等危险操作,可以设计成两次确认之后再执行,即在第一次执行之后会显示操作后果等相关信息,第二次确认之后才能执行;其次,从流程上来讲,所有危险操作需要在测试环境验证,同时需要增加团队评审;最后,工作习惯或是责任心,毕竟最后都需要人来操作,否则前面的任何措施都没有意义。

0

军武你最棒 复制链接去分享

再认真点

0

skylens116 复制链接去分享

只要能补救就行了,谁不会犯错

0

ops-q 复制链接去分享

先制定操作预案,审核
双人操作,一动手一审核
整理风险操作清单,动手前查一查

0

拼命三郎ol 复制链接去分享

一直以来我们都在研究持续集成,自动测试,自动部署。用这样的方式来保证产品项目质量和可靠性。同时也减少程序员的工作量和压力。容器容量在用户选择释放时,在后台保留一个月,超过时限就自动释放,把资源留给其他容器。这样来保证产品的高可用性!

0

灰狼0813 复制链接去分享

做好相应的备份就可以了。

0

1591083427594466 复制链接去分享

????

0

lio_2017 复制链接去分享

海量模式下的运维,暂时无法做到精准的运维,多少会存在一些风险,所以,必须通过严格的流程,专业的人员,稳定的技术结合。

0

点滴!!! 复制链接去分享

一不阻止错误,因为阻止不了,二错了一定能完全还原,如果错了无法还原,那就不要做,不能做,用系统空间,运行时间换安全

0

点滴!!! 复制链接去分享

这样的乌龙事件在长期运行的过程中根本不可能避免,治标的办法就是危险指令分级,危险的命令根本不容许任何人输入,遇到需求,使用不危险的命令折中操作,如rm换用mv折中实现。

26