在我目前的工作场所，我照顾两台VMware主机，一台OpenBSD物理机，三台Debian VM和六台Windows Server VM（2008/2012）。
我正在考虑实施一个像Puppet或Chef这样的configurationpipe理工具。 这是合理的，还是将学习工具的开销超过了好处？ 可pipe理性和实施成本之间的转折点在哪里？
恕我直言，这是值得学习，即使你只是pipe理一台服务器，
是的，会有一个学习曲线。 是的，你会感到沮丧。 但是，对于这些成本，您将通过可靠，一致的一键式部署，版本控制的服务器configuration，设置testing/开发环境的简易性等方式来获得多倍的回报。
除了你目前工作的好处之外，能够在你的简历中添加一个CM系统是一个很大的胜利。 如果现在的系统pipe理员不熟练的话，现在预计至less会暴露于configurationpipe理系统。
（旁注：也考虑Ansible，这是我最喜欢的CM，而且很容易起来跑步 – 比Puppet或Chef要容易得多，另外Ansible的windows支持也很好。
我正在考虑实施一个像Puppet或Chef这样的configurationpipe理工具。 这是合理的，还是将学习工具的开销超过了好处？
这是合理的，取决于你有多less时间和金钱燃烧，是否是你的钱，你燃烧。
configurationpipe理工具（其中任何一个）正在成为当今市场上的一项宝贵技能。
花时间学习和实施CM工具可能不是从您的业务或环境angular度来看最有效率的事情，但从您的技能组合来看，这可能是值得的。
可pipe理性和实施成本之间的转折点在哪里？
大多数configurationpipe理工具都是免费提供的，因此安装起来很困难。
这个问题有点难以回答，因为它实际上取决于你每天在做什么来pipe理这些服务器。 如果你不需要做太多的工作，那么一个configurationpipe理工具可能是完全不必要的。
如果你只是真的需要强制你的基础设施进入一个可预测的基本状态，那么拿起SaltStack或Ansible这样的基础知识可能没有什么坏处。
根据我的个人经验，Salt非常容易上手并引导到服务器上，并且可以用于非常基本的远程执行和报告，如果您尚未在您的环境中实施，可能会派上用场。
请记住，我有偏见。 您应该自己评估每个CM工具。
我有Puppet和Ansible的经验。 Ansible更简单，因为它是程序性的，而Puppet是声明性的。 两者都有优点和缺点，但是由于木偶的错误，我已经拉到了足够的头发。
如果要创build干净且可重用的configuration，则两者都需要很多工作。 如果您至less有两台非常相似的服务器，例如云或群集，则成本开始得到回报。
但是，即使对于独立服务器也有一些用处 – 您可以设置pipe理员用户，标准（使用本地变体）sshd，postfix或snmpdconfiguration，并将其用于简单信息收集，如遵守策略或testingshellshock漏洞。
另外，正如EEAA所提到的，如果您确认服务器是否真正从基本状态变为运行状态，那么它就具有logging设置的价值。 把它和版本控制系统（git）结合起来是很好的，所以你所做的修改是版本化和logging的。 如果你有一个pipe理团队，这是非常有价值的。
就像@EEAA所说 – 服务器的数量是无关紧要的。 您可以享受使用单台机器进行configurationpipe理的好处：
我可以说，我不得不为所有个人服务器实施CM，因为我在那里工作很less，忘记了所有的细节。 拥有CM脚本虽然看起来很费时（这是）回报是非常值得的。 长期来说，您将节省更多的时间，您将花费设置。
木偶或任何其他pipe理系统带来的好处已经在这里得到了其他答案的突出显示，但是在pipe理方面没有什么灵丹妙药。
例如，为复杂系统创build木偶类需要花费很多时间和精力，有时候会有很多的缺陷，而且错误信息并不总是100％清楚，而且当软件升级时，你必须投入时间来调整你的木偶类以匹配任何新的规范或程序，并找出哪种方法最适合于这种（傀儡例如声明和升级通常是程序性的）
此外，您还需要弄清楚如何计划以受控的方式推出对class级所做的更改，以及如何维护您的清单的不同版本。
在这个时候，你也应该考虑如何升级你的pipe理解决scheme。
如果你花费大量的时间写作例如puppet类，那么你将不得不执行大量的一键安装来获得任何真正的好处。
我build议仍然在适当的地方进行探索，也就是说，configuration文件的分发可能是一个很好的开始的地方，并从那里开始。