我们先来回顾一下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磁盘阵列存储可以减少相关问题产生，加强服务器的磁盘容错功能。即便处于服务器瘫痪、自然灾害等极为恶劣的情况下，只要硬盘依然健在，那么，就可以第一时间恢复其正常操作。
要避免错误操作所造成的数据丢失和服务器故障，首先加强权限的管理，要想避免数据丢失所造成的损失，每天都要对重要的数据进行必要的数据备份。防止数据库故障引起的数据丢失。将数据库存储在单独的服务器中，防止应用服务器故障引起的数据丢失。
减少非必要错误的操作。减少操作出错的可能性，管理好服务器用户的权限，防止操作失误引起数据丢失
小柒2012
复制链接去分享
传说中的打错一个字母瘫痪半个互联网！
这个倒霉的程序员会被开除吗？
那么，这名程序猿打错命令有没有责任？肯定有。但是，在处理高度可靠的云服务时，每一次操作都应该按照严格的程序，每一个命令都要经过足够的审核。除非这名程序员在操作过程中因为偷懒省略了一些必要的步骤，否则，这次事故更多是系统的责任，因为系统没有足够的机制来防止错误的发生。人，都是会犯错的，只有机器不会。
为嘛这些大公司 不做 多重备份以及实时备份，可能有难度？
cnssr4bb1t
复制链接去分享
1.思路类似大楼备用发电机，整栋停电的时候备用发电机接管来提供必要的电力，不致于造成恐慌，在这个case场景下，即使线上命令删除一大批核心服务器，也应有响应的备份服务器接管，并且这批资源正常运维权限下不可被删除，以确保出现误操作的时候服务不至于彻底挂掉。
2.线上运维操作的时候设计影响系统黑名单。系统难以知道运维人员是不是真的要进行相应操作，还是打错字母误操作，但是针对某些系统的更改在日常运维权限下一定是不可接受的，如本次故障中被影响的核心系统Index和Placement，系统检查到命令会影响相应黑名单中系统应拒绝当前命令执行。
始终觉得操作出现了差错之后就使流程复杂化、投入更多人力这种行为是比较蠢的，比如找一个人在旁边看着，两个人double check
1012988794233826
复制链接去分享
任何事情都没有十全十美的 鱼和熊掌不可兼得 实时更新bug当然需要线上操作 主要还是应该分情况而定吧
vling
复制链接去分享
全是马后炮，装叉犯，删了就删了嘛，多大点事情，谁不会犯点错。还煞有介事地在这里说些不着调的方法。
瓜跑跑丶
复制链接去分享
从来不赞同线上模式敲代码，这完全就是不负责任。记得学git的时候看见过一句话，没有提交的代码，都是白敲的。随时备份，以及代码审核是真的好习惯！
杨周
复制链接去分享
应该需要审核机制，当执行命令输入复审下。
1892988267967496
复制链接去分享
建立第二机制，所有操作只能对第一序列有效。第二序列与第一序列共用控制机制，但只具有次时效的记忆。第一序列失败，控制机制解除对第一序列的控制，控制第二序列，
秋水鸣蛙
复制链接去分享
把需要删除的数据移动到某个特定文件夹下，计划任务定时清理这个文件夹
1953688799298128
复制链接去分享
授权也不够，因为授权了代表我同意这次操作，但是我无法监管到这次操作的正确性，所以对于这种一个命令改变未来的指令或者少进行，或者增加这个操作的流程，同时再执行命令中要得到更深层次的审核
国外不加班的不也出现这个问题，怎么理解？
这个就是第二点，要根据环境来做提醒。没有任何提醒，很容易在多个窗口中迷失
国外出现一次就算新闻，国内出现这种情况已经算家常便饭了。咬文嚼字的理解问题，怎么理解都解不出来，只会便秘
家常便饭么？哈哈，我怎么没发觉？看来我是孤陋寡闻了！