いつ構成マネージャー（Puppet / Chef / Ansibleなど）を使用するのが適切ですか？
現在の職場では、2台のVMwareホストマシン、OpenBSD物理マシン、3台のDebian VM、6台のWindows Server VM（2008/2012）の世話をしています。
PuppetやChefなどの構成管理ツールの実装を検討しています。これは合理的ですか、それともツールを学習するオーバーヘッドがメリットを上回りますか？管理性と実装コストの転換点はどこですか？
私見それはあなたが単一のサーバーを管理している場合でも学ぶ価値があります、
はい、学習曲線があります。はい、あなたはイライラします。ただし、これらのコストについては、信頼性が高く、一貫性のあるワンクリックの導入、バージョン管理されたサーバー構成、テスト/開発環境のセットアップの容易さなどにより、倍数で返済されます。
現在の仕事の利点に加えて、履歴書にCMシステムを追加できることは大きな勝利です。現代のシステム管理者は、熟練していない場合でも、少なくともexposureを構成管理システムに持っていることが期待されています。
（補足：Ansibleも検討してください。これは私の好みのCMであり、veryで簡単に起動して実行できます。PuppetやChefよりもはるかに簡単です。さらに、AnsibleでのWindowsサポートも順調に進んでいます。 ）
PuppetやChefなどの構成管理ツールの実装を検討しています。これは合理的ですか、それともツールを学習するオーバーヘッドがメリットを上回りますか？
どれだけの時間とお金を費やさなければならないか、そしてあなたが自分のお金であるかどうかによって、それは合理的です。
構成管理ツール（それらのいずれか）は、今日の市場で価値あるスキルになりつつあります。
CMツールの学習と実装に時間を費やすことは、ビジネスまたは環境の観点から行うのが最も効率的なことではないかもしれませんが、スキルセットからは価値があるかもしれません。
管理性と実装コストの転換点はどこですか？
ほとんどの構成管理ツールは無料で使用できますが、インストールして使い始めるのが難しいという警告があります。
この質問は、これらのサーバーを管理するために日常的に何をしているのかによりますので、答えるのは少し難しいです。それほど多くのことをする必要がない場合は、構成管理ツールは完全に行き過ぎかもしれません。
インフラストラクチャを予測可能で基本的な状態に強制する必要があるだけの場合、SaltStackやAnsibleなどの基本的なものを取得してもそれほど害はありません。
私の個人的な経験では、Saltは非常に簡単に実行でき、サーバーにbootstrapし、非常に基本的なリモート実行およびレポートに使用できます。これがない場合に便利です。環境にすでに実装されています。
心に留めておいてください、私は偏見があります。各CMツールを自分で評価する必要があります。
@EEAAが言ったように-サーバーの数は無関係です。単一のマシンで構成管理を使用する利点を享受できます。
- 文書化された設定（CMスクリプトを介して文書化）
- 信頼性の高い展開（セットアップを何度も[再]展開できます
- セットアップの回復力（現在のサーバーの鳴き声-新しいものを起動）
- 再利用（2番目のサーバーを使用するようになったとき-最初のサーバーからリサイクルできるCMスクリプトが既にある）
- アップグレード（新しいセットアップのようなもので、異なるプラットフォームの上にあるだけです）
私は頻繁にそこでは仕事をせず、細部のすべてを忘れているため、すべての個人サーバーにCMを実装する必要があったと言えます。 CMスクリプトを作成するのは時間がかかるように見えるかもしれませんが（実際はそうです）、その見返りは価値があります。長期的には、設定に費やす時間を大幅に節約できます。
私は人形とアンシブルでの経験があります。 Ansibleは手続き型であるためIMOの方が単純ですが、Puppetは宣言型です。どちらにも長所と短所がありますが、Puppetの不可解なエラーのために十分な量の髪を引き出しました。
クリーンで再利用可能な構成を作成する場合は、どちらも多くの作業が必要です。非常に類似したサーバーが少なくとも2つある場合、コストは実際に見返りを始めます。雲またはクラスター。
ただし、スタンドアロンサーバーでも使用できます。管理ユーザー、標準（ローカルバリエーションを使用）のsshd、postfix、またはsnmpdの構成をセットアップし、ポリシーの遵守やShellshockの脆弱性のテストなどの単純な情報収集にも使用できます。
また、EEAAで言及されているように、サーバーが実際に基本状態から実行状態に移行することを確認した場合、設定を文書化するための値があります。これをバージョン管理システム（git）と組み合わせて、行った変更がバージョン管理され、文書化されるようにすることをお勧めします。管理者のチームがある場合、これは非常に価値があります。
Puppetまたはその他の管理システムは、ここで他の回答によってすべて強調されている大きな利点をもたらしますが、管理に関しては特効薬はありません。
たとえば、複雑なシステムのパペットクラスを作成すると、多くの時間と労力がかかり、多くの落とし穴があり、エラーメッセージが必ずしも100％明確であるとは限らず、ソフトウェアのアップグレード時に時間をかけて新しい仕様に合わせてパペットクラスを調整する必要があります。または手順と、どのアプローチがこれに最も適しているかを判断します（たとえば、宣言型の人形とアップグレードは通常、手続き型です）。
また、クラスに加えられた変更を管理された方法で展開する計画、およびマニフェストのさまざまなバージョンを維持する方法を理解する必要もあります。
また、その時が来たら、管理ソリューションのアップグレード方法を検討する必要があります。
たとえばパペットクラスの作成にかなりの時間を費やしている場合、実際のメリットを享受するには、ワンクリックで多数のインストールを実行する必要があります。
私はまだ、適切な場所を探索することをお勧めします。つまり、構成ファイルの配布を開始して、そこから始めるのが良いでしょう。