我的第一次系统管理员失误

如何在恐慌中专注于寻找解决方案。
287 位读者喜欢这篇文章。
red pen editing mistakes

Opensource.com

如果你在 IT 行业工作,你就知道事情永远不会完全按照你想象的那样发展。在某些时候,你会遇到错误或出现问题,最终你不得不修复这些问题。这就是系统管理员的工作。

作为人类,我们都会犯错。有时,我们是过程中的错误,或者我们是出错的原因。结果,我们最终不得不修复自己的错误。这种情况会发生。我们都会犯错、打错字或出错。

作为一名年轻的系统管理员,我付出了惨痛的代价才吸取了这个教训。我犯了一个巨大的错误。但多亏了我的主管的一些指导,我学会了不要沉溺于自己的错误,而是制定一个“错误策略”来纠正错误。从错误中学习。克服它,继续前进。

我的第一份工作是在一家小公司担任 Unix 系统管理员。实际上,我是一名初级系统管理员,但我大部分时间都是独自工作。我们是一个小型 IT 团队,只有我们三个人。我是 20 或 30 台 Unix 工作站和服务器的唯一系统管理员。另外两人支持 Windows 服务器和桌面。

任何阅读本文的系统管理员可能都不会惊讶地知道,作为一名经验不足的初级系统管理员,我最终在错误的目录中运行了 rm 命令。以 root 身份。我以为我正在删除我们某个程序的一些陈旧的缓存文件。结果,我错误地清除了 /etc 目录中的所有文件。哎哟。

我意识到自己做错事是因为 rm 无法删除某些子目录的错误消息。但是缓存目录应该只包含文件!我立即停止了 rm 命令,并查看了我所做的事情。然后我慌了。一瞬间,无数的想法涌上我的脑海。我是否刚刚摧毁了一台重要的服务器?系统会发生什么?我会不会被解雇?

幸运的是,我运行的是 rm * 而不是 rm -rf *,所以我只删除了文件。子目录仍然存在。但这并没有让我感觉好一点。

我立即去找我的主管,告诉她我所做的事情。她看到我为自己的错误感到非常愚蠢,但我承认了错误。尽管情况紧急,她还是花了几分钟时间对我进行指导。“你不是第一个这样做的人,”她说。“别人在这种情况下会怎么做?” 这帮助我冷静下来并集中注意力。我开始减少思考我刚刚做的蠢事,更多地思考我接下来要做什么。

我制定了一个简单的策略:不要重启服务器。使用相同的系统作为模板,并重新创建 /etc 目录。

一旦我有了行动计划,剩下的就容易了。这只是运行正确的命令从另一台服务器复制 /etc 文件并编辑配置以使其与系统匹配的问题。感谢我记录一切的习惯,我使用了我现有的文档来进行任何最终调整。我避免了必须完全恢复服务器,否则这将意味着巨大的中断。

可以肯定的是,我从那个错误中吸取了教训。在我作为系统管理员的余生中,我总是在运行任何命令之前确认我所在的目录。

我还了解了制定“错误策略”的价值。当事情出错时,恐慌并思考接下来可能发生的所有坏事是很自然的。这是人之常情。但是,制定“错误策略”可以帮助我停止担心刚刚出错的事情,而专注于让事情变得更好。我可能仍然会考虑它,但知道我的下一步行动让我能够“克服它”。

photo of Jim Hall
Jim Hall 是一位开源软件倡导者和开发者,最著名的是他在 GNOME 中的可用性测试以及作为 FreeDOS 的创始人兼项目协调员。

12 条评论

我认为我们都删除过不应该删除的东西。我最糟糕的一次是在一个实时的销售点系统上删除了产品文件。大多数客户在其系统的多个位置都有产品文件的多个副本,我被要求拨号连接并删除这些副本,因为他们的磁盘空间不足了。所以我删除了一些副本,又做了一个 cd / rm / pwd(看看我哪里做错了吗?)。我立即看到了我的错误,并打电话给客户,他们正在给我们打电话,说他们知道他们有很多库存的产品在他们的系统中丢失了。

我很幸运 - 我在 16:45 删除了文件,业务在 17:15 结束,所以他们只需要手写 30 分钟的订单。如果我在早上这样做,他们会非常不高兴,因为从磁带恢复需要 2 个小时。我不得不加班来收拾残局。

故事的寓意:始终进行备份。?

- 并且备份一切,不仅仅是你的数据目录。如果我有 /etc 的备份,我的情况下的恢复会容易得多(是的,我吸取了教训,之后备份了一切)。

另外:定期测试备份以确保它们有效!:-)

回复 作者 Shawn H Corey

感谢分享。我刚开始的时候也曾在 /vars 下面删除过。

我的第一次“哦不,本杰明,你做了什么?!” 是当我移动数据以升级存储阵列上的磁盘时。我做了一个 `rsync --delete`....方向错了。幸运的是,它是在我们最新的阵列上,所以它只影响了十几个左右的用户(包括我,这有助于道歉)。所有恢复完成花费了几乎一天的时间。

我已经做了多年的承包商。我犯了不少错误,但最终还是形成了诸如金丝雀发布(首先将更改应用于一次性服务器,然后进行健康检查)之类的模式。

我曾经删除过 MySQL 数据目录,因为我太累了,而且一个论坛告诉我这样做会使 MySQL 更快。顺便说一句,感谢巨魔,给了我一个在更合理的时间工作的原因。

我从另一位承包商那里看到的最糟糕的事情是来自一位前雅虎员工,我偶尔还会和他一起工作。我只知道他们曾经为雅虎工作,因为他们告诉我“别担心,我已经为你修复了代码”,然后当我要求他们不要修改我的代码时,他们告诉我“自从我们上次谈话以来,我忘记的比你了解的还要多”或其他傲慢的话。我非常不高兴。

我知道这是不对的,但我很高兴得知他们浪费了 48 小时的服务器时间,并且我被要求修复,因为他们比我聪明。教训是,我们都会犯错,大公司的成功并不意味着你永远不会犯错,而且最好不要爬得太高。

在灾难发生之前制定一个流程,例如备份 mysql 数据文件夹或将代码提交到存储库。然后肌肉记忆就能发挥作用,你也可以在正常时间工作!

如何不做事。这很有价值。特别是当一个人深入分析出错的原因,概述它并提出更好的做事方式时。希望这些能被其他人采纳。

我认为这篇文章最好的部分是主管的反应,这就是你如何创造一种氛围,让员工在犯错时不会害怕举手,并通过这样做大大提高从这些错误中恢复的速度,更不用说主管进行了指导,而不是将问题转移给更有经验的人。

我同意!她可能是我有过的最好的老板。总是很有耐心,而且是一位伟大的教练。我从她那里学到了很多东西,这些教训我至今仍在运用。

回复 作者 Sami Laihonen

在 2003 年,我是一名 Novell NetWare 6.0 和 6.5 系统的系统管理员。我们使用 Tivoli Storage Manager 来备份我们的用户文件。因为我们才刚刚开始使用 TSM - 而且我们还没有接受培训 - 我们不知道如何正确设置日志轮换,所以我们过去常常在日志太大时删除它们。还有其他服务会用日志填满硬盘,但 TSM 是迄今为止最积极的。

事实是,那是一个星期五晚上,我只需要清理一些日志才能去和我的朋友喝啤酒,所以我使用了一个工具来总结服务器上 NetWare 卷上的已用空间,以测量 SYS 卷(类似于 Windows 系统的 C:\Windows)上剩余的可用空间。

在我按下键盘上的“删除”键之前,我按了“F5”来刷新屏幕内容,但是当我刷新屏幕时,它也重置了选择,选择了 SYS 卷的根目录。

我只是在等待它完成删除,这时我看到一些 NLM 文件正在被删除。NLM 文件是 NetWare 系统中的可执行二进制文件。我立即取消了删除,并思考我应该做什么。然后我意识到我可以使用“salvage”选项。“Salvage”的工作方式类似于 Windows 回收站,但更好,因为它保留了同一文件的多个版本,并跟踪了删除的时间、日期和用户。我只需要过滤掉最近由我删除的文件,这样我就可以将它们恢复回来,而系统不会停机。

当然,我很幸运,因为 salvage 已启用(他们为什么要选择禁用它?)并且因为服务器没有停止,所以它不会在启动时崩溃。

那是一段糟糕的时光,但最终它变成了在酒吧里告诉我的朋友们的有趣故事,我们都笑了...

对于配置文件,我保留了一个 /root/archive 文件夹,并有一个小脚本将文件复制到那里,并附加一个日期时间戳。在实施任何更改之前,我会在脑海中演练回滚计划。我还会问自己,如果我成功地进行了更改,会产生什么影响,以及如果我破坏了它,会产生什么影响。

对于 rm,尤其是 rm -rf,我使用绝对路径,并且我目视确认路径 - 我使用默认的 RHEL .bash_profile,其中包括当前主机和目录名称作为提示符的一部分。如果提示符不够具体,或者如果我觉得我迷失了方向,我会使用 pwd。

我最糟糕的破坏是实施了一个损坏的 SELinux 模块。我使用自动化工具来生成一个新的模块。它是空的,当它被执行时,它添加了一个新的上下文,该上下文与 "/.*" 匹配。然后我重新标记,并且不出所料,东西开始崩溃。在我们的组织中,我是一名系统管理员,我们有工程师构建新东西。我问了其中几个比我做这个时间更长的人,他们会怎么做,他们的回答是从备份恢复,或者从头开始重建。

好吧,这台服务器是一台管理服务器。它托管一个 yum 仓库,一个用于我作为管理员为我的小网络需要的随机文件的文件共享,并充当我的 Ansible 主机。因此,我没有完整的备份,实际上,我没有任何备份,因为如果服务器死机,对用户零影响。我当时是这么想的。

在我破坏它后,我立即收到一个用户的请求,要求安装一个最近被批准用于网络的软件。很简单,把它放在一个自定义仓库中,然后用 Ansible 推送它。但是,哎呀,管理服务器宕机了。重建需要一段时间,因为我需要将 yum 仓库(四个完整的 RHEL 仓库,并且网络离线)从服务器上移走,然后再重建。所以我估计需要等待一天半的时间,再加上几个小时的启动和重新配置。

所以,我深吸一口气,做了我一开始就应该做的事情。我在日志中查找并找到了问题根源。我在 SELinux 上下文文件中找到了一行。实际上是第一行。我尝试使用实用程序删除该行,但它格式错误,它们不会触及它。所以我备份了该文件(哈哈),然后删除了该行。然后启动了一个重新标记,一切都修复了。

故事的寓意是,即使是更有经验的 Linux 大师也不总是拥有最佳答案,并且始终、始终、首先查看日志进行故障排除。

知识共享许可协议本作品根据知识共享署名-相同方式共享 4.0 国际许可协议获得许可。
© . All rights reserved.