我刚刚发现服务器机房里有东西在燃烧；我怎样才能快速识别它是什么？. 在评论中，我发现了以下引用：
you don't let a developer anywhere near your root passwords
作为一名开发人员，同时也是对系统管理员的东西非常感兴趣的人，我想知道除了每个人的标准之外，这句话是否还有其他意义——也就是说，不要泄露密码？评论员这样说，就好像这是系统管理员社区中的常识一样。是吗？
AskOverflow.Dev
我刚刚发现服务器机房里有东西在燃烧；我怎样才能快速识别它是什么？. 在评论中，我发现了以下引用：
you don't let a developer anywhere near your root passwords
作为一名开发人员，同时也是对系统管理员的东西非常感兴趣的人，我想知道除了每个人的标准之外，这句话是否还有其他意义——也就是说，不要泄露密码？评论员这样说，就好像这是系统管理员社区中的常识一样。是吗？
由于生产系统的操作责任通常属于系统管理员，因此只有系统管理员应该拥有对系统的完全管理访问权限——就这么简单。
现在，您可能会说“好吧，有时我们更改代码需要重新配置系统，难道我们不应该相应地重新配置系统吗？”
不
如果您的代码更改需要重新配置系统，您应该能够向系统管理员解释您的要求。这样，系统管理员可以审查您的更改要求并在更改可能具有您（作为开发人员）可能没有预见到的操作影响时停止更改。
作为对@NathanLong 的回应，我意识到在小型企业中有时会出现这种情况。在这些情况下，管理员和开发人员是同一用户，另一种方法是将系统所有权分配给多个人，并确保没有人——我的意思是没有人——推动他们自己的配置更改。让另一个开发人员检查您的更改，让第三个开发人员执行重新配置。
每当出现疑问时，从变更计划和审查开始 - 其他任何事情都会构成可怕的变更管理
我并不是说系统管理员是完美的，但是有大量的开发人员甚至不应该成为开发人员的例子。更不用说被允许对具有关键任务数据的系统进行根访问了。
但无论如何，这主要是关于对所做的更改负责。对于许多系统管理员来说，开发人员似乎会去服务器上做事，然后他们不对他们所做的事情负责。开发人员通常只专注于让他们正在进行的单个程序/任务继续进行，而不会花时间思考他们正在接触的系统的全局或长期状态。他们还没有学会如何安全地进行更改的习惯。
并非所有开发人员都如此，当然有一些优秀的开发人员可以很好地维护系统。看起来这些在 95% 的时间里都是正确的。
习惯如：
我将尝试用一个比喻来解释（我是一名开发人员，顺便说一句，偶尔会做一些系统管理员的事情。）
画家和室内装饰师
假设开发者是一位画家，创作了很多奇妙的画作。好吧，也许他们不是太棒了，但他做了他的雇主要求他做的。他很擅长，所以所有的画都很好。
现在需要将这些画放置在相应的建筑物内。画家知道关于油漆的一切，但不知道如何正确地将东西安装在墙上。如果油漆工决定无论如何都要尝试（因为他可以），那么室内装饰师（系统管理员）可能会在几周后进来并这样回答：“这里发生了什么……？” “一切都歪了，这..这必须放在天花板上！这到底是怎么粘在水上的..那是胶水！？”
不用说，室内设计师本可以做得更好。他知道在哪里放什么，以及如何安装它。他始终如一地使用相同的螺钉和偶尔使用的电线。他以前已经做过一千次了，几乎闭着眼睛也能做到。
长话短说：系统管理员知道如何比开发人员更好地处理他的装备（至少他应该）。他将保持他的系统干净和有条理，并且知道整个事情是如何运作的。此外，许多开发人员习惯于做系统管理员的事情（例如在家里），如果可以的话，他们会尝试自己做，因为这样可以节省他们的时间。
当然也有一个人同时做这两件事的情况，但他们很可能在相对简单的环境或经理没有看到他实际上需要两个人的地方。
我建议反过来，把自己放在对方的位置上。
因此，本着这种精神：
总而言之，对我来说，开发人员不应该拥有 root 访问权限，因为他们不一定从系统管理的角度知道他们在做什么，并且不需要（或不应该）需要它，因此授予 root 权限实质上是增加了导致问题的风险，没有任何好处。管理系统是别人的工作。
出于同样的原因，系统管理员不应该更改代码。
这个建议感觉有点过时了；它来自一个时代，在这个时代，拥有 root 密码的顽皮开发人员会进入并在实时系统上进行更改。
现在没有人应该对实时系统进行更改，无论是开发人员还是系统管理员。在服务器上进行更改是 Chef 或 Puppet 等系统的工作。我们的行业超越了多年前可以手动配置的单一服务器的概念。现在我们要么需要能够同时部署许多配置相同的服务器，要么至少能够在任何时候可靠地重建任何单一服务器。这排除了拥有 root 密码的人对服务器所做的更改，无论他们戴着什么帽子。
那么，回到问题：开发人员应该拥有 root 密码吗？是的！系统管理员应该有 root 密码吗？是的！为什么？因为如果没有端到端理解复杂系统的聪明通才——或者至少是一个由开发人员和系统管理员组成的团队，就无法有效地诊断复杂系统。如果不登录服务器并有权检查正在发生的事情，就无法完成部分诊断（例如，开发人员可能需要运行 strace 或 dtrace 来了解网络服务器实际上一直在做什么。）请记住 - 看，不要碰！
我和很多开发人员一起工作过，他们（理所当然地）对成为系统管理员没有兴趣——他们只想让他们的软件工作。他们将采取最快的路线到达那个目的，这通常需要例如修复权限错误
chmod 777 -R .不用说，这是一件坏事。
我不能代表系统管理员社区发言，但我可以从经验中发言。
虽然他们似乎知道他们的东西，但他们似乎没有注意所需的细节，并且随机安装/更改了一些东西，例如前一个月我发现我们的一个生产 Web 服务器安装了 KVM/QEMU！
另一件让我恼火的事情是他们倾向于混合服务器角色，所以 Hypervisor 主机会突然变成监控服务器和 Web 服务器。似乎也缺乏一致性，例如，执行相同角色的 3 台服务器应该以相同的方式设置，但会以 3 种完全不同的方式设置。
当然，评论者可能只是意味着他们应该使用 SSH 密钥而不是密码 :)
通常它是为了关注点分离。出于安全目的，在某些环境中需要施加这样的限制。它可以通过显示有关应用程序的信息来提供商业价值，否则这些信息将无法获得。
职责分离和变更控制。
职责分离意味着您永远不会让一个人负责一项任务。实现它的最佳方法是确保没有一个人可以单独执行一项任务。
至于变更控制，要正确实施它，您必须确保对生产系统的所有变更都得到完整记录。实现它的最佳方法是让开发人员向系统管理员进行讲义，向他们提供代码和文档并让他们执行部署。
这是对 IT 行业常见问题的过度简化。任何一个人都无法知道所有事情，所以人们将他们的知识专门化。理想情况下，只有那些具有完成任务的专业知识的人才应该这样做。
在现实世界中，我们经常被管理结构要求“身兼多职”，他们仍然不知道 IT 工作的所有复杂性，并且正在处理他们所知道的公司运营和财务的复杂性（而且通常是IT 人员没有）。
当这些 IT 领域中的两个重叠时，这通常会导致 OP 询问的态度。就像那种态度一样，作为网络人员，我知道对系统管理员有类似的想法是多么容易，因为系统管理员也经常被要求管理网络。
在相对较少的情况下，他们做得很好，而在另一些相对较少的情况下，他们做得很糟糕。大多数时候，他们的工作介于两者之间。然而，人们记住的不是伟大的工作，而是可怕的工作，在较小程度上是体面的工作。
当一名网络人员加入其中时（无论是出于特定原因/项目的顾问，还是因为 IT 人员已经扩大并且现在包括一名顾问），他们通常会发现被忽视的推荐最佳实践、错误配置、安全漏洞等。他们花费了他们花了大量时间试图弄清楚空白的东西是如何按照他们的方式出现的，解决不应该发生的问题，并修复错误配置和问题。
但这是双向的，包括许多重叠的学科。具体到我的示例，作为网络人员，我知道我无法像知识渊博的系统管理员那样快速设置服务器和/或可能会有很多事情我会忽略或做错（或者至少不是最好的方法）。给我足够的时间，我至少可以做一份相当体面的工作，但工作/工作通常不会给我时间。如果我有选择，我很容易倾向于将它交给一个好的系统管理员。