我刚刚遇到服务器机房里有东西着火了；我该如何快速识别它是什么？。我在评论中发现了以下引言：
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 服务器实际上一直在做什么。）请记住 - 只看不碰！