是否有人使用发布管理原则来对基础设施进行系统管理，就像对软件开发一样？
我从事系统管理领域已有 10 多年，但我还没有接触过一家使用发布管理原则来管理服务器基础架构和应用程序配置的公司，就像软件开发一样。例如外部化配置、将配置签入和签出版本化存储库、将配置自动部署到系统、通过适当的非生产环境进行推广、自动对组件进行单元测试等。
我很好奇大家使用什么应用程序和流程来管理这些配置和部署。此外，是否有人会为配置部署创建发行说明？
附加评论- 我同意盲目地遵循方法框架并不能使你的组织变得更好，而这并不是我所要求的。我试图确定是否有某些概念可以应用于系统管理，就像它们应用于软件开发一样。例如，如果我想对生产系统中的系统进行配置更改，我怎么知道我在开发中测试的内容是否真的转移到了生产系统中？我想说，如果你有一个系统，该配置被签入存储库，进行版本控制，然后自动部署到生产系统中，这将在很大程度上确保一旦部署到生产中，一切就能正常工作。
答案1
我实际上花了不少时间思考这个问题。在我所在的大型互联网公司，我的工作是内部发布管理运行在我们众多服务器上的软件。我们实际上做了大量工作，尝试将发布管理原则应用于基础设施或系统管理。虽然我们的软件包系统可供外界使用，但一般原则应该是相同的。
举个例子：以前，在设置 Web 服务器时，管理员必须记住将 VIP 地址设置为环回地址的别名，以使机器轮换。我们一直在努力更换机器，却错过了这个重要的步骤。结果就是服务器就在那里，随时准备运行，但却无法提供流量，因为 VIP 已将其标记为关闭。
我们使用的解决方案是集成到常规版本中的软件包。我们有一个模板系统，可以为大约 600 个服务器场生成特定于服务器场的设置。然后，在安装匹配的软件包时，打包系统会应用这些设置。
因此，我们创建的这个相对简单的程序包只是采用了每个服务器场的设置并将其设置在系统环回上。这完全消除了系统被 VIP 意外标记为关闭的问题。
我们还将这种方法应用于系统的其他部分。结果是，我们已逐渐将大部分系统配置转移到我们的软件发布系统中。我们构建和分发包含所有必要软件包的软件版本。这些软件包依次选择每个服务器场的设置并应用它们来修复诸如环回地址之类的问题。
这仍然是一个相当高级的机制。还有其他系统可以确保在服务器上加载基本操作系统并安装系统管理员用户帐户。但是，一旦您超越该级别，我们会尽力将所有可能的系统配置移至设置中，然后由软件包读取。我们对这种方法非常满意，可以管理大约 10,000 台服务器。
答案2
这是一个引导性问题，原因有很多。
首先，开发软件的方法不止一种。一方面，您拥有传统的瀑布式模型，其中需求是预先收集的，软件遵循非常严格、不变的生命周期，直到完成主要版本。另一方面，您拥有敏捷模型，其中可能每周或每两周都会发布一个新版本。根据我的经验，前者往往反映在企业软件模型（ERP 系统等）中，而后者往往反映在较小、不太复杂的系统（LAMP 堆栈等）中。
其次，仅仅因为您可以订阅方法框架并不意味着您应该这样做——看看 ITIL 和 COBIT 等企业灾难（至少当公司天真地匆忙进行全面实施而不考虑他们实际上在做什么以及为什么这样做时）。解决 IT 问题的正确方法是弄清楚您对任何潜在流程改进的投资回报率实际上是多少，然后确定是否实施它。如果您对业务需求和帮助支持其技术的人员的工作流程视而不见，那么您将一事无成，只会浪费大量的时间和金钱，因为您在某人的博客上听说这是某个时间点的“最佳实践”。如果您正在为一家销售在大型相同配置的服务器网络场上运行的服务的公司管理服务器，那么与拥有 100 个异构部门服务器和可靠备份工作系统状态的商店相比，配置即代码的可重复性优势将大得多。
当然，有很多商店至少在某种程度上认同这种心态。这就是 Puppet、Chef 和 Cfengine 等项目存在的全部原因。至于它们是否能满足你询问的所有要求，这只是一个程度问题——理应如此。
答案3
我们用木偶管理我们所有的配置。除了 Puppet 的历史数据之外，我们还将配置检查到 SVN 中。
答案4
我使用 Git 进行软件开发，但我也将其用于所有配置以及几乎所有需要保留版本的文本。然后我使用 git push 或 rsync 来移动内容。我认为管理员很少使用这种东西，因为每个学科的人之间没有太多的交叉（以我的经验而言）。