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

如何在恐慌中专注于寻找解决方案。
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 系统中的可执行二进制文件。我立即取消了删除,并思考我应该做什么。然后我意识到我可以使用“挽救”选项。“挽救”的工作方式类似于 Windows 回收站,但更好,因为它保留了同一文件的多个版本,并跟踪了时间、日期和删除用户。我只需要筛选出最近由我删除的文件,以便我可以恢复它们,而系统不会停机。

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

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

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

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

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

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

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

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

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

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 4.0 International License 获得许可。
© . All rights reserved.