適切な構成管理のために、どの構成項目を追跡しますか？
プロのシステム管理者として、適切な構成または変更管理を実行するために追跡することが不可欠だと思う構成項目は何ですか？
たとえば、Windowsでは、ハードウェアまたはソフトウェアに加えてレジストリの変更を追跡しますか？ Linuxでは、設定ファイルを比較しますか？
編集：明確にするために、私は具体的に追跡する（または追跡しない）ものを探しています-ツールを推奨したい場合さらに追跡する価値があると思うアイテムに、先に進んでください。
[主にUnix/Linuxバイアス、私はWindowsシステムでは動作しません:-)]
一度変更すると、実行中のシステムの状態を変更するものはすべて追跡する必要があります。構成は、GitやSubversionなど、完全な変更履歴をサポートするリポジトリに保存する必要があります。また、 Opscode's Chef などの自動化された方法でデプロイする必要があります。 ）または Reductive Labs'Puppet 。
システムの状態を変更するアイテムのいくつかの例：
- インストールされているパッケージ/パッチのバージョン。
- デプロイされたアプリケーション、アプリケーションライブラリ。
- 管理およびアプリケーションユーザー。
- ハードウェア構成とデバイスドライバー/モジュール。
- スケジュールされたメンテナンスジョブ（Unix/Linuxではcron）。
- 外部ツールによって監視されるサービスとコンポーネント。
このような追跡は、変更を監査するための十分なログを提供する自動化ツールを使用して実行する必要があります。ソフトウェアリポジトリの履歴には、そのリポジトリに保存されている構成ファイルの変更履歴が表示されます。 ChefやPuppetなどの宣言型構成ツールでは、各構成ファイルはユーザー、パッケージ、サービスなどのリソースのセットを表し、リポジトリ履歴はこれらの変更を示します。
アプリケーションの観点から、文書化することが重要です
- OSとパッチレベル
- どのレイヤード製品がインストールされ、どのパッチが適用されているか
- バージョンを含め、インストールされているカスタムおよび/またはサードパーティの製品とライブラリ
- 上記のカスタム/サードパーティアイテムのインストールソースをどこに置くか
- 上記すべてのプロダクトキー/ SN
- アプリケーションレベルのサーバー構成（つまり、Web、メールなど）
- アプリケーションレベルで担当する別の開発チームがある場合の連絡先リスト
- バックアップ構成
注-質問でのロマンダのコメントに応えて、それが正確に1つの項目ではないことはわかっていますが、この場合、ドキュメント全体を1つの項目と見なします
Windowsの場合、WMIを介していつでもクエリできるため、OSのパッチレベルを「追跡」する必要はありません。変更管理に従っている場合は、変更の前後にグローバルクエリを実行して、OSパッチの結果を確認できます。 （MSIプロバイダーがインストールされていることを確認してください）
ドライバーの更新を追跡する必要があります（wmiを使用してクエリを実行できますが、すべてをキャッチしようとする価値はありません）ソフトウェアアプリケーションの更新はCMDBに保持する必要がありますが、（最初を除いて）本当に必要な場合は変更管理から取得する必要がありますレジストリの変更を追跡するには、ファイルとオブジェクトへのアクセスを有効にするグループポリシーを設定し、監査するキーを選択します（ http://support.Microsoft.com/kb/324739 ）。これはCMDB用ではありませんが、誰が変更を加えているかを追跡できます。
だから、それは人々が通常CMDBで追跡したいものであり、なぜそれが時々良い考えではないので、CMDBに何を入れるべきかです。答えはそれが依存するということです。 ITILで定義されたCMDBは、特定のマシン構成がサービスに関係しない限り、マシン構成を気にする場合と気にしない場合があります。 ACMDBには、資産追跡ソリューション（ハードウェア構成の場所や保証情報など）も含まれている場合がありますが、特定の構成アイテムと他のCIとの関係に関するものです。関係には、「責任がある」、「接続されている」、「依存している」、（より困難ですが、多くの場合、より重要です）「SLA tier_」に必要」などが含まれます。つまり、サーバーではなく、サービスを再作成するために必要なものを記録します。
例えば。電子メールがサービスだった場合、次のようなものをリストします。
ハードウェア：64ビットCPU、3 GBのRAM（@todayのユーザー数に基づく）サーバーのインストール用に7 GBのスペース、交換データベースとリカバリ用に100 GBのストレージ（@todayの使用量に基づく）、dvdromドライブ。
ソフトウェア：Server 2003 R2、Exchange 2007 SP2、SAN用のMPIOドライバー
等...
CMDBは通常、サーバー管理者が使用するためのものではありません。管理者は、資産管理ソリューションにはるかに満足するでしょう。
ウィンドウズ：
- OSバージョン
- OSサービスパック
- セキュリティパッチ
- 監査ポリシー（GPOを介して実施する必要があります）
- 管理者、パワーユーザー、およびリモートデスクトップユーザーのメンバー
- インストールされているアプリケーションリスト
- ネットワーク共有
OSパッチレベル。それは多くのことを意味する可能性があります。理想的には、どのパッチがどのマシンにあるかをマトリックスで追跡します。これの貧乏人のバージョンは、各サーバーの「最終パッチ日」です（これは、毎回すべての更新をプルインすることを前提としています）。
UNIX/Linuxの場合、構成ファイルを2つのグループに分けます。OSによって提供されるものと、カスタムアプリケーションの一部であるものです。
すべてのアプリケーション構成ファイルは、ソースリポジトリに保持されます。インストールごとに異なる標準コピーがあります（開発、QA、本番、プリプロダクション、デモ...）。これらのいずれかに変更を加える必要があると判断した場合、変更は最初にソースリポジトリのコピーで行われ、次に必要なサーバーに展開されます。また、課題トラッカーで対応する変更リクエストを開きます。
OSタイプの構成ファイルの場合、ソースリポジトリにある場合とない場合があります。そうである場合は、上記のプロセスを使用します。そうでない場合は、変更の数が特定の任意のしきい値に達したときに、それらをリポジトリに配置します。それまでは、少なくとも課題トラッカーでチケットを開いて、その変更を追跡します。
また、課題追跡システムの優れた機能は、ソースリポジトリのコミットにインデックスを付ける機能です。それはあなたのチケットをあなたの設定変更に非常にうまく結び付けます。
Ciscoスイッチなどのネットワークデバイスの場合、バージョン管理システムで起動構成と実行構成を収集して追跡するのが好きです。可能であれば、編集を行ったユーザー名も保存します。
ログを自動的に監視し、ログデータから構成コレクションをトリガーするオプションがない限り、通常はPerlスクリプトを介してこれをプルします。
ネットワークデバイスの場合、RANCID（自動構成グラバー）が理想的です。
サーバーの場合、etckeeper（/ etc /をVCSに保持）とpuppet（構成をVCSに保持）などの組み合わせ。