作为开发人员，我该如何帮助系统pipe理员改进webfarm部署和Web应用程序的稳定性？

问题：

部署和pipe理这个网站已经成为一场噩梦。部署从开发到质量保证和预生产需要几天的时间。我们有很多错误，而且涉及到大量的手工劳动。我们经常有configuration文件已被更新或更改不正确，然后在该Web服务器上的整个网站失败。

环境：

大量的Web前端服务器（Windows 2003，IIS6）
大量的MemCached服务器（Linux）
多个数据库服务器（SQL 2005）
每月约500万独特

更多详情：

我是负责开发系统的开发人员之一。目前，零自动化，零自动化testing，部署过程涉及login到服务器，terminal服务器，手动更改IIS设置，更新configuration文件，以及类似的恐怖。灾难恢复文档有很多不足之处。

我想让处理服务器操作的团队成功部署和维护我正在使用的应用程序。所以，出于部分非常自私的原因，我希望他们成功。

我想要一些方向; 我可以问他们什么具体的问题，或者我可以提出的build议，以及开发者如何创造一些东西来帮助他们取得更大的成功。

目前有一些泥泞的事情发生，我认为唯一的解决办法就是忽视泥泞，把重点放在这个问题上。而目前的问题是，维护，排除故障和部署网站是非常费力的。

感谢日韩

编写代码来检查所给configuration的完整性，并直接向做configuration的人员和日志报告问题。
在开发，testing，验收，产品（DTAP）街道上明确区分特定于环境的configuration值和应该保持不变的configuration值。
使用版本pipe理软件（例如subversion）跟踪所有环境中的configuration更改。
像自杀狂妄一样pipe理DTAP环境的configuration。
在您发布发布之后，再次开始编码之前，请安排将生产环境复制到所有其他环境（包括开发）上。当你把这个信息传达给你的开发者时，看看他们中的哪一个变成了白色，然后问他们哪些资源是他们无法从源代码控制中取代的。
最重要的是！！！你可能正在读这个想法，这个白痴是谁？这不可能！我们无法做到这一切。死的权利 – 当然你不能 – 现在不行。（如果你还没有遇到麻烦，你不会问这个问题）。所以与实施分离的远景。与其他利益相关者分享这一愿景。共同决定你应该拥有哪些能力，并制定一个计划，让你在那里。每个周期或释放或任何其他事情，确保你又向前迈进了一步。设定现实的目标，并与他们见面。（当然，你可以根据经验改变你的愿景。）

我会说，除了保持服务器设置和configuration文件相同，你应该有testing环境部署到您的办公室。如果您的开发人员testing他们开发的代码在非常像现场环境的环境中工作，那么他们会感到更自信。更多的信心意味着他们必然会更快地发展（因为这是我们从SCRUM团队那里学到的），而且更less的泥泞和无法控制的感觉。

所以基本上我说的是，只要给开发人员大量的机器玩和testing，你会看到积极的结果。

最重要的一步就是尽可能简单地在整个基础架构中configuration所有服务器。标准操作环境（SOE），如果您愿意：

所有的IIS实例具有相同的configuration。
所有的Web服务器都有相同的网站副本。

一旦你有了这个，它应该变得更有可能实现自动化的发布，testing，等等。

如果所有服务器上的IISconfiguration相同，则可以更新IIS在一台主服务器上使用的configuration文件，然后运行脚本将其推送到所有Web服务器，对其进行testing并重新加载IIS。您可以为您的实际网站文件做同样的事情。

我的猜测是，如果您可以select将要部署的服务器标准化，那么您现在就应该这样做了，所以我将跳过这个build议。你需要做的是构build脚本/ MSI等，以自动化操作团队的部署过程。这需要一些时间来设置，但是从stream程中移除Ops团队的人工干预是使其顺利运行的唯一方法。现在我不侮辱他们的智慧，远非如此。问题是他们不知道代码如何工作。他们不知道具有错误值的configuration文件是什么样的。他们依靠你知道，帮助他们和自动化的原因是解决你的问题的关键。

我的build议是在本地设置模拟各种服务器的虚拟机，这样你就可以一遍又一遍地testing安装是如何工作的。如果你的IT部门和我的一样，那么获得新的服务器将会很困难，因为它涉及到预算和资源分配等等。虚拟机消除了很大一部分头痛，因为你不需要新的硬件，任何人的input都是最小的因为你只需要知道服务器是如何configuration的，然后你可以自己完成剩下的工作。虚拟机还可让您快速将机器重置为原始状态，然后再次尝试安装过程。

在我的基础架构中，我们有一个称为预览的临时环境，数据在达到生产之前就已经完成了。登台级别的应用程序代码与生产代码完全一样，所以任何数据问题都会在那里显示出来。

我们还为新代码提供了一个testing环境，该代码可以在旧的，已知的数据上运行（当需要testing代码失败时，我们可以对其进行修改）。

一般来说，这种隔离使我们有了一个非常稳定的生产环境，而且我们没有看到太多意想不到的事情出现。

我应该注意到，我没有太多处理，因为我不是程序员。我只是同步数据库，刷新文件时，他们问我;-)

首先是一致性。确保所有的服务器都完全一样。所有W2003 Web服务器应该看起来像其余的。所有数据库服务器，所有Linux服务器。我的意思是一样的 相同的OS版本，相同的补丁，相同的目录结构…一切！

第二次来了。您应该有一个单独的服务器，可以用来testing您的部署。这是你所有的configuration错误的地方。然后，您可以将系统从这些部署服务器复制到生产环境。

第三，“分离关注”概念应该适用于你的configuration文件。如果不同的模块有不同的configuration项，请将它们放在自己的configuration文件中。如果有特定于计算机的configuration，请将IT移至其自己的configuration文件。这样，您可以从部署服务器和组件本身部署受影响的configuration文件。