随着时间的推移，IIS/Web 应用程序在我工作过的商店中一直是一个棘手的问题。
一方面，IIS 是一种内置于服务器中的服务（总的来说），通常由服务器管理员负责维护和配置。当出现问题时，他们知道需要发生什么，或者至少可以诊断到他们说“Web 应用程序有问题”并让开发人员调试他们的代码。
但是，服务器上的每个 Web 应用程序都是独一无二的，并且有很多细微差别，这些细微差别可能会根据手头的问题变得复杂。
另一方面，每个 Web 应用程序在许多方面都是独一无二的，并且有需要处理的特定问题，开发人员是最了解应用程序的人。如果需要修改 web.config 文件以进行调试，或者 IIS 开始给 Web 应用程序带来麻烦，开发人员应该知道问题出在哪里并相应地修复它，无论是由于 IIS 还是应用程序本身。
然而，允许开发人员自行调整 IIS 成为一个严重的问题，因为某些设置/优化会严重影响服务器性能和稳定性。
那么平衡点在哪里呢？服务器管理员应该是 IIS 专家并处理所有这些问题，而我只是通过部署发送站点文件，还是应该由开发人员承担服务器和 IIS 问题的责任并相应地处理它们？
听起来你真正需要的是在围栏两边都有专业知识的人。
根据我的经验（与小型公司），IT/系统管理员人员没有时间、兴趣或特定于 webapp 的知识来正确维护 IIS 设置。他们将把事情带到操作系统，并将 IIS 交给我，开发人员。
显然，我需要“不仅仅是一名编码员”才能使其正常工作；我必须注意系统级问题（安全性和诸如此类）。多年来我一直在做低级系统管理，所以我对这类任务很有信心（事实上，这些年来我教过专业的系统管理员一些东西）。然而，并不是每个开发者都具备这种能力。
尽管如此，据我所知，拥有系统管理员技能的开发人员比拥有（webapp）开发技能的系统管理员多。
一如既往，YMMV。
我个人不希望开发人员弄乱 IIS，尤其是如果这意味着它可能会导致另一个应用程序出现问题，而另一个开发人员必须不断地进行故障排除。
如果存在 IIS 问题，请让系统管理员进行调查，如果特定应用程序存在问题，请将其发送回开发人员。如果开发人员有问题，请将其提交给系统管理员，系统管理员可以尝试就是否进行任何更改做出明智的决定，并弄清楚它将如何影响每个人。
我们（系统管理员）像对待第三方供应商一样对待我们的开发人员 - 当他们希望我们部署应用程序时，如果他们希望得到支持，就必须提供文档。这包括常见的故障排除例程和支持升级路径（正常运行时间要求与记录在案的开发人员责任相结合，以防不可接受的中断）。
它显然不是非黑即白，但它为缓解开发人员和管理员之间的紧张关系做了很多工作。开发人员现在意识到，他们必须提供与他们在下班后被寻呼的意愿成反比的质量软件，并且开发人员现在可以使用工具和文档，而不必担心他们没有创建的工具。
因此，在您的场景中，这意味着开发人员在他们自己的 IIS 服务器上创建他们的应用程序，然后为管理员提供软件和文档以安装在生产服务器上。
答：找一个人，给他们涂上“WSA”（Web Server Administrator）。他们可以是管理员或开发人员；真的没关系。但他们需要沉浸在工作的两个方面，团队的其他成员（双方）需要尊重他们的专业知识。
这与 DBA 如何跨越 IT/dev 之间的界线没有什么不同。鉴于 Web 服务器在拥有基于 Web 的产品的组织中的重要性，我认为这是一个至关重要的角色，而且经常被忽视。
由于网络还很年轻（与数据库相比），因此很难招募到这个人。您很可能需要培养/培养某人担任该职位。
有了像Web 部署工具这样的新实用程序（这将成为从 Visual Studio 2010 开始发布 Web 应用程序的标准内置方式），微软似乎正朝着让开发人员或至少安装工程师选择诸如 IIS 设置（证书、应用程序池设置等）。它们内置在 msdeploy 安装包中，并在将包部署到服务器时自动应用于 IIS 服务器。
似乎是一个合理的妥协。开发人员不必手动修改实时生产服务器上的设置，系统管理员也不必具备特定于 webapp 的知识。然而，想要了解在安装软件包之前会发生什么的系统管理员可以清楚地看到所需的 IIS 设置。