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

如何在恐慌中专注于寻找解决方案。
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 下删除了。

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

我当承包商已经很多年了。 我犯了很多错误,但最终形成了金丝雀模式(首先将更改应用于一个抛弃型服务器,然后进行健康检查)。

我曾经删除了 MySQL 数据目录,因为我感到疲倦,并且一个论坛告诉我这会让 MySQL 更快。 顺便说一句,感谢巨魔,让我有理由以更合理的时间工作。

我见过的另一个承包商最糟糕的情况是来自一位前雅虎员工,我仍然偶尔与他合作。 我只知道他们曾经在雅虎工作,因为他们告诉我“别担心,我为你修复了你的代码”,然后当我要求他们不要修改我的代码时,他们告诉我“自从我们上次说话以来,我忘记的都比你懂得多”或者其他傲慢的话。 我不是很开心。

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

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

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

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

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

回复 作者 Sami Laihonen

我曾经是 2003 年左右的一些 Novell NetWare 6.0 和 6.5 系统的系统管理员。 我们使用 Tivoli Storage Manager 来备份我们的用户文件。 因为我们刚开始使用 TSM - 而且我们还没有接受过培训 - 我们不知道如何正确设置日志轮换,所以我们过去只是在日志变得太大时删除日志。 还有其他服务用日志填充 HD,但 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 大师也不总是有最好的答案,并且永远、永远,在进行故障排除时首先查看日志。

© . All rights reserved.