这场景也发布在 SO，针对不同的受众提出不同的问题——我很高兴我这么做了，因为我收到了一些非常好的回应。
我们正在尝试使用虚拟化技术为企业组织内由 4 名开发人员组成的小团队实施开发环境。这将使我们能够设置单独的开发、测试和准备环境，并允许访问我们正在评估的系统或工具所需的新操作系统。
我们重新利用了现有的工作站级机器，投入了 24GB RAM 和 RAID-10，并且一切运行良好，直到我们尝试将机器添加到域中。
现在，我们开始了一场自古以来所有企业开发人员都必须打的战争——争夺开发和测试环境的本地控制权。网络和 IT 管理员提出了许多担忧，从“ESX Server 是企业标准”到“服务器不允许在客户端 VLAN 上使用”，再到“[填空] 不是本地或企业 IT 组织目前拥有的技能”。
我们或许可以证明生产级硬件和正式的 IT 支持的合理性（阅读：如果有必要，我们可以证明这种需要的合理性，但这需要时间并且会带来很多麻烦） - 但通过将其视为生产系统，可能需要数月才能正式分配 IT 资源 - 即使我们这样做了，我们也可能会失去我们想要的本地控制权。
我想你们中的许多人都曾与企业内的开发人员在非生产环境的控制方面遇到过类似的困难，所以我的问题如下：
- 您的开发人员提出了哪些论点让您同意允许这些类型的孤岛存在于具有标准网络和安全策略的企业中，而这些策略通常（可以理解地）会排除这种非（集中）管理的基础设施？
- 这仅仅是开发人员进行技术或商业论证并确保补丁管理和 AV 会发生的问题，还是更多的是争夺控制权和所有权的政治斗争？
- 如果可以选择，您是否愿意拥有并支持硬件/操作系统，同时赋予开发人员本地管理权限，还是让他们完全管理，同时确保他们建立补丁管理/AV，并在他们造成问题时追究他们的责任？
- 如果您成功阻止开发人员对您基础设施上的“恶意服务器”进行本地控制，那么开发人员是否就此罢休，还是他们（或您）将开发环境移至断开连接的 VLAN/完全独立的网络？
一些假设限制了这个问题的范围：
- 重申一下，这是发展环境 - 无需生产负荷或可支持性。没有任何外部可访问的内容。
- 这不是 Hyper-V 与 ESX 的圣战（我们对其中任何一种都没意见 - 但选择 Hyper-V 是因为它在 MSDN 上对于这些目的而言是“免费的”[是的，VMWare 也有免费工具 - 但好的管理工具通常不是]，并且更容易由“Microsoft Shop”中的本地开发人员管理） - 因此支持或反对其中任何一种的争论超出了这个问题的范围。
- 开发团队已经保证要么管理补丁管理和防病毒，要么与现有企业系统集成（如果 IT 支持） - 但无论您是否愿意接受，这肯定都在范围内。
答案1
首先，我确实看到了几个为什么你的管理员有理由反击的原因：
IT 部门还负责报告补丁管理、防病毒软件、pci 合规性、年度（或更频繁）安全审计等。这不仅是为了确保这些事情得到妥善处理，而且还能证明给我看对外人来说。
举个例子，我在一所小型学院运行网络，我们有一个物理实验室，里面有几台数据收集机，供学生做实验。它们唯一要做的就是从科学仪器收集数据，然后打印出结果（到直接连接的打印机上），供学生分析并交给老师。它们绝不在互联网上——甚至 AV 和 Windows 更新都是通过本地网络应用的。它们连接到网络并运行 AV 软件的唯一原因是明确地向我的监控软件报告它们仍然存在并且是最新的。这很愚蠢，因为它们实际上更多的安全地删除网络连接，但他们首先用教育补助金支付，所以这些是我的报告要求。
- 无论喜欢与否，你的开发服务器从开发人员的角度来看是一个生产系统。也许一个月后，如果服务器出现故障，开发人员将很难完成工作，因为您设置的流程假设服务器可用。避免/限制员工因技术故障而闲置的情况是企业仍然使用集中式 IT 部门的一个重要原因。
- 如果“ESX Server 是企业标准”，那么您需要遵循这一点。目前，hyper-v、vmware、xen 和其他产品在操作方式上存在显著差异，不能简单地假设为其中一种产品构建的机器在另一种产品上运行良好。如果您要这样做，IT 部门将需要在某些时候帮助管理它，他们不希望在机器上出现一堆可能导致问题的垃圾后将其转换为 vmware。
- 有一天这台机器会变旧，要么需要更定期的维护，要么设置一个标准的更换周期。即使是新服务器有时也会有坏零件。这种情况几乎总是落在 IT 的头上后某些东西出了问题，导致人们无法正常开展工作。通过尽早承担服务器的责任，IT 可以更好地确保避免将来发生意外停机。
- 这是个人问题，但我可以告诉你，最后的我希望我的网络周围有另一台伪装成服务器的桌面。过去几年里，我已经处理了足够多的此类问题，足以让我终生难忘。
话虽如此，IT 部门需要能够支持这一举措。仅仅说“不”是不够的。挑战他们提出一个满足您（非常实际）需求的替代方案。这里唯一的政治情况应该是他们的替代方案可能会有更高的标价（因为他们正在计划您目前无法看到的成本），所以问题是谁必须为此买单。IT 部门不会愿意，因为他们没有为此做预算，但您会犹豫，因为这是您为一个您满意的解决方案所花费的 6 倍（目前）。
此外，听起来你可能还没学会走路就想跑。你想改进你的开发流程。作为一名前开发人员，我认为这很好。但不要只是扔掉一堆虚拟机和“环境”（即：开发、阶段、质量保证等）。规划新流程是什么样子——开发人员将如何完成工作。你会使用持续集成吗？自动构建？使用什么软件来支持它们？开发人员是否可以将代码移动到生产或暂存，还是只有 QA 才有这种能力？你需要一个单独的暂存吗？两个开发分支怎么样（一个用于 vNext，一个用于 vCurrent 的错误）？
您可能需要一台服务器，以便开发主管或经理可以解决所有这些问题，但如果是这样，那么这需要是第一步，并且需要完成设置和初始流程设计前开发人员可以将其用于实际用途。
答案2
1）您的开发人员提出了哪些论点让您同意允许这些类型的孤岛存在于具有标准网络和安全策略的企业中，而这些策略通常（可以理解地）会排除这种非（集中）管理的基础设施？
没有——主要是因为我在组织中不担任管理职务，所以这些“政治事务”实际上与我无关。唯一能真正说服我的论点是，允许明确违反网络政策并免于系统运营团队控制和可见性的事情是气隙和我老板的老板的 CYA 信。
并不是我真的想成为一个说“不”的行业，只是从运营团队的角度来看，这没有什么好办法可以结束。
- 我们最终会发现，服务器由那些主要技能不是管理网络上的服务器的人管理，他们无法了解整个网络及其相关的问题空间。这不仅仅是“保护”地盘的政治担忧；举个老套的例子，想象一下当开发人员出于某种原因打开 DHCP 时会发生什么。
- 我们最终替他们管理开发团队的服务器。但结果却恰恰相反，这很麻烦。开发人员经常对我们修补问题（破坏他们知道但我们不知道的东西）感到恼火，或者他们争取让我们启用我们出于各种原因不想启用的功能。这很快就会陷入僵局，运营团队感到负担沉重、备受折磨，而开发团队感到沮丧和被忽视。
- 这会产生政治后果——因为你必须向另一个部门解释为什么开发人员是“特殊的”以及为什么他们可以免受网络政策的约束。
2) 这仅仅是开发人员进行技术或商业论证并确保补丁管理和 AV 会发生的问题 - 还是更多的是争夺控制权和所有权的政治斗争？
我认为开发人员不需要提出商业案例——很明显，开发人员必须进行开发，而为了做到这一点，他们需要某种开发环境。至于补丁管理和 AV——那是运营团队的工作，我们将确保完成。我们并不是认为开发人员做不到。只是我们不相信你能做好——系统管理员仍然是系统管理员，因为他们不要相信任何事情可以做正确的事情所以这不是个人问题。当然，这显然是一个政治问题，让人感觉好像别人在“做你的工作”，但这并不是一个技术问题，因此不在 SF 的范围内。
3) 如果可以选择，您是愿意拥有并支持硬件/操作系统，同时赋予开发人员本地管理权限，还是让他们完全管理，同时确保他们实施补丁管理/AV，并在他们造成问题时追究他们的责任？
上述原因均不是。
4) 如果您成功阻止开发人员对您基础设施上的“恶意服务器”进行本地控制，那么开发人员是否就此采取了行动，还是他们（或您）将开发环境移至了断开连接的 VLAN/完全独立的网络？
隔离。处理这种情况的最佳方法是将环境（以及对环境的控制）交给开发人员，然后隔离或使用其他一些可靠的方法将其与网络隔离。这基本上就是我们处理公共 wifi 的方式。您想要 wifi 服务吗？当然。您需要支付网络连接费用，我们会管理 WAP，但它永远不会影响我们的网络。抱歉。您的需求只是数百个需求中的一个。我们还需要考虑其他问题。
你不想说“不”，因为开发人员（他们在技术上特别聪明）无论如何都会找到得到他们想要的东西的方法。所以为他们提供一个适合他们需求的环境，让他们开心，然后找到一些方法来防止任何事物他们在开发环境中进行的操作不会影响您业务网络的其余部分。
总结：我会为您提供一台服务器，该服务器带有您想要的任何虚拟化平台，位于单独的物理网络或 VLAN 上。访问您的开发环境将通过单个堡垒主机进行，运营团队将控制和监控该堡垒主机。您用它做什么取决于您的业务 - 我们不提供支持，但我们会尽可能在服务器管理方面提供建议和帮助。
答案3
如果您向我展示一台配备了消费级 RAM、消费级 HDD、消费级 PSU 和消费级 RAID 的工作站级机器，我也会拒绝将其放在服务器网络上。
您需要了解很多关于在服务器 VLAN 上放置类似的东西的知识。
服务器 VLAN 很可能是 DMZ。在 DMZ 中，您不能放置任何事物未经加固和保护。这只是一台你交给他们的机器，他们不知道你用它做了什么。这也意味着定期修补和更新，这意味着集中管理。我绝对不会登录到每个不受管理的服务器并手动应用补丁。
我保证，那台机器的组件会出故障。6 个月、12 个月或 24 个月内，它就会崩溃。然后，备份在哪里？哦，你没有设置它们？但是，我以为那是一台服务器？哦，那是别人配置的服务器？……然后又开始互相指责
当系统崩溃并出现问题时，谁来承担责任？在大多数组织中，“我把它交给开发人员来照看”不是要飞了。
他们要把它放在哪里？如今的服务器都是机架式安装的，将塔式服务器放在机架中会浪费空间，而且机架可能不是为此设计的。
因此，IT 部门完全有理由不将这台随机计算机纳入他们的服务器网络。
然而IT 部门的工作是确保您能够正确完成您的工作。他们需要确保您在需要时获得所需的东西。如果您拥有一款业务部门需要的软件需求为了继续奔跑，他们有为它提供一个运行平台。这是他们的职责。但你需要确保他们拥有完成工作所需的信息。
如果您来我公司告诉我您正在启动一个新项目，我会给您三台虚拟机：Dev、Live 和 Staging。您将拥有 Dev 的完全管理权限，我们会讨论您需要为其他两个虚拟机执行哪些工作。如果您需要它们的完整管理权限，并且可以证明这一点，那么您就会得到它。我们已经熟练掌握了虚拟机部署。VMWare 使这变得非常简单 - 每个虚拟机只需大约 5 分钟即可部署完成。
听起来，您的 IT 部门遭受的困扰与大公司几乎所有 IT 部门都一样。建造小城堡，用生命捍卫它们，不让别人进入，专横跋扈，等等。作为每天与他人的 IT 部门打交道的人，我经常看到这种情况。这令人沮丧。
但基本事实是，变革需要从 IT 部门内部开始，而且必须从上层开始。如果你能让 IT 部门意识到他们不是一支独立的力量（因为他们中的大多数人不会为他们的业务创造收入，这可能是一个相当大的打击），他们在那里是为了支持现有员工和提高那么你会发现你的问题变得无关紧要，因为每个人都会扮演幸福的家庭。
答案4
你会在这里得到很多答案，支持和反对开发人员拥有环境任何部分的管理员访问权限（可能大部分是反对），但底线是：
系统管理员组的任务是维持生产系统的运行、稳定和安全，并负责确保这些系统按照公司期望的水平提供他们所支付的服务（因为他们正在为这些服务付费）。
同样，开发团队也被赋予了为公司提供服务（网络、应用程序等）的任务，尽管是在不同的领域。争夺对开发环境的控制权是适得其反的，对双方都没有任何好处。
我在一家小型 ISV/ASP 公司工作。我们有一个开发人员和一个系统管理员（我）。我们的关系建立在相互尊重和信任的基础上。我们需要作为一个团队工作，以帮助实现公司的总体目标。我授予开发人员对其开发环境（包括工作站和服务器）的完全、不受限制的访问权限。我管理开发系统的安全性、更新、AV 和硬件，开发人员负责其余工作。当他的代码准备好投入生产时，他会将其交给我，协助我进行任何必要的配置，然后退后一步。我们互相帮助。
开发人员应该是开发环境的主人，而系统管理员应该是生产环境的主人，在合理的界限内，通过合理的制衡和控制。当任何一方需要“跨越”时，都应该与受其管辖和指导的“执政”方合作和协调。