我刚刚遇到服务器机房里有东西着火了;我该如何快速识别它是什么?。我在评论中发现了以下引言:
you don't let a developer anywhere near your root passwords
作为一名开发人员,同时也是一名对系统管理员非常感兴趣的人,我想知道这句话除了是每个人的标准(即不要泄露密码)之外,是否还有其他含义?评论者说这在系统管理员社区中是相当普遍的知识。是吗?
答案1
我并不是说系统管理员是完美的,但是有很多开发人员示例甚至不应该是开发人员。更不用说被允许拥有对包含关键任务数据的系统的 root 访问权限。
但无论如何,这主要是对所做的更改负责。对于许多系统管理员来说,开发人员似乎会在服务器上做事,然后他们不对自己所做的事情负责。开发人员通常只专注于让他们正在开发的单个程序/任务顺利进行,而不会花时间考虑他们正在接触的系统的整体情况或长期状态。他们还没有学会如何安全地进行更改的习惯。
这些并不适用于所有开发人员,当然也有一些优秀的开发人员可以很好地维护系统。但通常看来,95% 的时间这些都是正确的。
习惯如下:
- 在没有先在开发系统上进行测试的情况下,不要对系统进行更改
- 不要做出你不理解的改变(盲目地谷歌搜索,做你不理解的事情)
- 在您确认备份系统正常运行并且知道如何回滚任何操作之前,请勿进行任何更改。
- 不要做出使系统长期维护更加困难的改变。(即不要增加任何技术债务)
- 不要损害系统的安全性
- 不要以增加潜在监管风险的方式改变系统(参见 PCI-DSS、HIPPA、FERPA 等)
答案2
由于生产系统的运营责任通常属于系统管理员,因此只有系统管理员才应该拥有对系统的完全管理访问权限 - 就这么简单。
现在你可能会说“嗯,有时我们更改代码时需要重新配置系统,难道我们不应该有权限重新配置系统吗?”
不
如果您的代码更改需要系统重新配置,您应该能够向系统管理员解释您的要求。这样,系统管理员就可以审查您的更改要求,如果更改可能产生您(作为开发人员)未预见到的运营影响,则应停止更改。
回复 @NathanLong,我意识到在小型企业中有时会出现这种情况。在这些情况下,管理员和开发人员是同一个用户,另一种方法是将系统所有权分配给多个人,并确保没有人(我的意思是没有人)推动自己的配置更改。让另一个开发人员审查您的更改,让第三个开发人员执行重新配置。
每当有疑问时,就重新开始变更规划和审查——其他任何事情都可能构成糟糕的变革管理
答案3
我将尝试用一个比喻来解释(我是一名开发人员,偶尔也会做一些系统管理的工作。)
画家和室内设计师
假设开发人员是一名画家,创作了许多出色的画作。好吧,也许这些画作并不出色,但他完成了雇主要求他完成的工作。他在这方面很擅长,所以所有的画作都很好。
现在需要将画作放置在相应的建筑物内。画家对绘画了如指掌,但却不知道如何正确地将画作安装在墙上。如果画家决定尝试一下(因为他可以),室内设计师(系统管理员)可能会在几周后回来并做出这样的回应:“这里到底发生了什么?”“一切都歪了,这……这必须挂在天花板上!这到底是怎么粘在墙上的……那是胶水吗?!”
不用说,室内设计师本可以做得更好。他知道把什么东西放在哪里,以及如何安装。他始终如一地使用相同的螺丝和偶尔的电线。他以前做过一千次,几乎闭着眼睛就能做到。
长话短说:系统管理员比开发人员更懂得如何操作自己的设备(至少他应该如此)。他会保持系统整洁有序,并了解整个系统的工作原理。此外,许多开发人员习惯于做系统管理员的工作(例如在家),并且如果可以的话他们会尝试自己做,因为这样可以节省时间。
当然也有一个人同时做两件事的情况,但这种情况很可能发生在相对简单的环境中,或者经理没有意识到他实际上需要两个人的地方。
答案4
这个建议感觉有点过时了;它来自于一个拥有 root 密码的顽皮开发人员会进入并在实时系统上进行更改的时代。
这些日子没有人不应该对实时系统进行更改,无论是开发人员也不系统管理员。在服务器上进行更改是 Chef 或 Puppet 等系统的工作。我们的行业已经超越了单一服务器几年前可以手动配置。现在我们要么需要能够许多相同配置的服务器一次部署,或者至少能够随时可靠地重建任何单个服务器。这排除了拥有 root 密码的人对服务器进行更改的可能性,无论他们身在何处。
那么,回到问题:开发人员应该有 root 密码吗?是的!系统管理员应该有 root 密码吗?是的!为什么?因为如果没有能够全面了解复杂系统的聪明通才,就无法对复杂系统进行有效诊断- 或者至少由开发人员和系统管理员组成的团队。如果不登录服务器并有权检查正在发生的事情,部分诊断就无法完成(例如,开发人员可能需要运行 strace 或 dtrace 来了解 Web 服务器实际上一直在做什么。)请记住 - 只看不碰!