サーバーの変更を記録する方法は？

だから私たちはおそらくこの状況を抱えているでしょう：あなたはいくつかの問題をデバッグしますが、それは6ヶ月前に行った設定変更が原因であると理解するだけで、なぜそれをしたのか思い出せません。そのため、元に戻して問題を修正すると、他の問題が再発します。そうそう、今は覚えています！その後、適切に修正します。

あなたが適切なメモを取らなかったからです、あなたはばかです！しかし、これを行う良い方法は何ですか？

エンジニアリングには、変更を検出して追跡するためのソフトウェアがたくさんあります。ソース管理、コードレビューなど。すべての変更は追跡され、すべての変更はそれが何であるかについてのコメントを必要とします。そして、典型的なエンジニアリング部門は良いコメントを必要とするので、なぜそのように壊れたのかを理解している6ヶ月で、歴史的な「非難」機能またはバイナリ検索ビルドを使用して問題を特定できます。これらのツールは、非常に効果的なコミュニケーションツールであり、過去の記録です。

しかし、サーバーランドでは、500種類のサービスがあり、すべて異なる方法で構成されています。また、テキスト形式の場合もありますが、常にテキスト形式（フォルダーへのアクセス許可の設定やページファイルの場所の変更を検討）があるわけではありません。

私たちの環境では、Perconfigにできる設定ファイルをチェックインしますが、それらのファイルはほとんどありません。Active Directory DBを正確にチェックインすることはできません。

過去にwikiで手動の変更ログを保持しようとしましたが、これを行うための規律を維持することは非常に困難です（良い言い訳ではないことは知っていますが、それは本当に難しいです）。

私の質問：サーバーの構成変更を追跡するこの問題に対処するために、どの戦略とツールを使用しますか？

-更新-

注：サーバーの変更を追跡するのに特に役立つ自動化ツールほど、共有メモ作成ツール（OneNoteなどに精通している）は探していません。サーバー構成の変更を追跡するための包括的なツールはありませんが、GPOなどの特定のアプリケーション向けのツールはおそらくあります。

また、私はあなたが有用であるとわかった特定の戦略に非常に興味があります。「Sharepointでメモを共有する」はかなりあいまいです。規律をどのように維持しますか？変更を追跡するためにどのフォーマットを使用していますか？変更データをどのように整理しますか？アイデアだけでなく例も本当に欲しいです。

Linuxの世界では、人々はいくつかの異なる戦略を追求しています。

• cfengine、puppet、chefなどの構成制約システム。これらは、Windows GPOに似ています。ポイントは、すべてのサーバー構成が意図的に単一の場所に文書化され、ポリシーがどの粒度（サーバールーム、グループ、特定のサーバー）で実施されているかを知っていることです。これは、「6か月前に地獄は何が変わっていたのか」からあなたを救うことにはなりません。ただし、サーバー構成を破棄して、ゼロから再構築することはできます。質問に答えるために、cfengineおよびpuppetポリシーを改訂管理下に置くことができます。
• / etcを制御するリビジョン。一般に、Linuxプログラムは構成を1つの場所/ etcに保存します。大胆に、/ etcをリビジョン管理に入れるスクリプトを書き始めています。私が知っているそのようなプログラムの1つがetckeeperです。

説明：/ etcをgit、mercurial、bzr、またはdarcsに保存します
 etckeeperプログラムは、/ etcをgit、mercurial、
 bzrまたはdarcsリポジトリ。APTにフックして、変更を自動的にコミットします
 パッケージのアップグレード中に/ etcに対して行われます。そのバージョンのファイルメタデータを追跡します
 制御システムは通常はサポートしませんが、/ etcにとっては重要です。
 / etc / shadowの許可として。それは非常にモジュール式で構成可能ですが、
 また、バージョンの操作の基本を理解している場合は使いやすい
 コントロール。

この状況での問題の1つは、実際には、ビジネスプロセスと技術的な問題の組み合わせであることです。そして、管理者が行った変更を追跡するだけでなく、間違いなく大きくなります。また、予期しない変更、およびADコントローラーの変更が一部の部門サーバーのデータベースアクセス許可設定を壊さないように、管理者またはユニット間の適切な調整に注意する必要があります。すなわち、あなたの質問はワームの巨大な缶です:)

私の組織では、これに対処するためのプロセスとシステムの展開に約1年かかります。ビジネスプロセス側では、変更管理チームを編成しました。SOPによると、本番環境へのすべての変更はそれらを通じて調整されます。スコープ、影響を受けるシステム、影響を受けるサービスなどとともに、すべての変更をコンパイルします。変更、およびロールアウトとロールバックの両方の計画に関する適切な文書を強制します。毎週（オープン）ミーティングを開催して、今後の環境の変更を確認し、これらすべての変更の詳細を記載したメールを送信します。このプロセスの最終目標は、事実上、ITの全員が進行中の他のすべてを把握できるようにすることです。これにより、たとえばSysAdminがカーネルパッチをインストールし、タイムクロックデータベースを停止するシステムを再起動する問題を停止できます。

技術面については、Windowsを扱っていないため、Unix / Linuxの人たちについてのみ話すことができます。これらのシステムすべての構成管理のために、Reductive LabsがPuppetを展開しています。単純に、サーバー/マシン構成を定義するクライアント/サーバーシステムであり、クライアントは頻繁にそれらのチャンスを引き出します（デフォルトでは30分）。さらに、ローカルで管理されたファイルに何らかの機会があれば、その時点でも元に戻されます。実行中のサービス、ファイアウォール設定、ユーザー認証などの管理に使用します。

TippingPointのようなものを調べることもお勧めします。これは、システム構成を監視し、変更に関するアラートを送信するクライアントサービスです。これにより、セキュリティ担当者は最も幸せになります。主に悪意のある変更または未公開の変更を追跡するために使用されます。

私は今ではあまり覚えていませんが、4、5社に行っています。

私たちは皆この問題を抱えていました。私たちの誰もがそれを100％解決したわけではありませんが、私は今のところ、これまでで最高の戦略だと思うものを持っています。

Sharepoint / Wiki / Evernote / PIN

• 共有ポイント
  • あなたが望むすべてをうめきます...それはいくつかの非常に素晴らしいリスト機能を備えています。
  • IPアドレスリスト
  • 在庫
  • サービスアカウントと使用
  • 通知ログを変更する
• Wiki
  • ハウツー
  • 長期タスクリスト
• Evernote
  • 私のパートナーと私はこれを使用して、ウィキに不要なものをすべて入れます
  • 技術的な性質のハウツーの詳細
  • 私たち二人が見なければならないスクラッチノート
  • 週のタスクアカウンティング
  • 請負業者のタスクリスト
  • evernoteクリッパーにより、AD /権利設定のスクリーンショットを簡単に作成できます
  • どこでも利用可能
• PIN
  • パスワードリポジトリ

これらのいくつかにはおそらくより良いツールがありますが、これは私たちが使用しているものです：

• プライベートwikiでサーバーごとに構成の変更とアップグレード/パッチを追跡する
• また、wikiにハウツーと問題/解決策の記録を保管します。
• SharepointまたはGoogleドキュメントを使用して、静的IPリストなどの信頼できるコピーを保持します
• Subversionを使用して構成ファイルへの変更を追跡する

Windowsの場合、Microsofts System Centerシリーズまたはそのプラットフォームの構成およびサービス管理における他の競合他社をご覧ください。

変更は、実際に行われる前にそれ自体を承認してログに記録する適切な変更管理ルーチンを介してルーティングする必要があります。これは、初心者向けに100％手動にすることができます。統合されたいくつかのツールを使用すると、ツールに実際の変更を行い、中央の構成データベースに「自動的に」ログアウトするように依頼できます。問題のカウボーイスタイルを試して修正してください。

特に、環境内のシステムレベルで変更を行う能力/アクセス権を持つ複数の人がいる場合は、変更管理プロセスを必ず用意する必要があります。これにより、管理者が潜在的な変更を承認する方法も提供されますが、その場で変更を行うことができない場合、変更プロセスの遅延が発生します。

変更を追跡するいくつかの方法には、SEMでのイベントの検証（セキュリティイベントマネージャーがある場合）またはNessusなどのツール（多くの作業を行うと、環境を監査して変更を見つけることができます）が含まれます。

これは、よりローカライズされた* nixベースの回答です。Windowsでエミュレートするための優れたツールは見つかりませんでした。

これを実装するにはいくつかの方法があり、忘れたときにキャッチする方法があります。

Subversion、Git、CVS、RCSなどのリビジョン管理システムは、構成ファイルの履歴を追跡するための良い方法です。実稼働サーバーにリビジョン管理システムをインストールしたくない場合、rsnapshotのようなものを使用して構成ファイルディレクトリをローカルまたはリモートに保存すると、RCSの利点のほとんどが得られますが、監査またはコミットを残す可能性がなくなりますログ（ただし、ファイル自体にコメントを付けて回避することもできます）。

変更をログに記録することを忘れないように、cronで作成されたtripwireの実行を介した構成変更の自動レポートは良い出発点です。ファイルの現在の状態に関するtripwireのデータベースを構築した後、ファイルに変更を加えると、次回の実行時に電子メールが送信されます。データベースが更新されるまでこのメールを受信し続けるため、トリップワイヤが「リセット」されます。

私は、フライスプレーなどの問題追跡システムを使用します（何でもかまいませんが、プログラミング以外のものにはフライスプレーが好きです）。構成に触れる前に、改善/問題を記録する必要があります。修正/実装すると、変更はチケットに反映されます。

Wikiは現在の設定を文書化するのに便利ですが、時代遅れになるのは簡単です。また、IMOを更新するのにより多くの労力がかかるようです。

これを行うための自動化されたものを見つけることはできません-必要に応じて特定の構成ファイルへの変更が問題トラッカーに自動的に電子メールで送信されるようにセットアップすることもできます。

良い政策、障壁の低いツール、規律の問題だと思います。

環境で変更ログの追跡を行うために、独自に開発したものを作成しました。非常に複雑なものではなく、非常にうまく機能します。

• 自己ポリシングポリシーは、推定値の変更がすぐに使用可能な設定から逸脱するか、問題を引き起こす可能性がある場合、変更ログシステムに文書化する必要があるという設定です。
  • この「コイン」の反対側は、問題のトラブルシューティングを行う場合、最近のまたは関連する変更ログエントリを検索することです。
• システムにサインインし、変更するサーバー、サービス、またはハードウェアコンポーネントを選択します
  • コンポーネントは、以前に基本的な「人口統計」情報（場所、ベンダー、シリアル番号、担当部門）とともに同じシステムに入力されています
• 基本的なカテゴリのドロップダウンから選択します
  • 予定外のダウンタイム
  • パッチ適用
  • ハードウェア保守
  • ソフトウェアのインストール
• あなたがしたこと、見たこと、観察したことの詳細を記入してください
• コピーが責任者に送信され、検索アプライアンスによってインデックスが付けられたXMLファイルとして保存されます。
• 利益

私が言ったように、空想はありません。それはPERL CGI（10億年前に書かれた）とインデックス作成用のGoogle検索アプライアンスを使用します。

欠点：

• たとえば、ドメインコントローラーの25個すべてに同じパッチを追加したなど、サービスのグループを操作するのは困難です。「ドメインコントローラー」グループがないため、すべてを手動で選択する必要があります
• トラブルシューティングに役立つハードウェア、ソフトウェア、またはイベントログのエラー報告と統合されない
• 関連して、上記で述べたように、すべての「人口統計」データの手動データ入力

とにかく、もしあなたがコードに興味があるなら、私に知らせてください、そしておそらく私は共有するためにそれをつかむことができます。

前述のように、それはしばしば文化的な問題です-結局のところ、一部の開発店はコメントをもう気にしません（今日、自己文書化コードは流行の流行語です！）いくつかは歴史的記録の聖杯としてバージョン管理システムを使用します。明らかに、これらは完全ではありません。

したがって、それを修正する唯一の真の方法は、文化的な解決策にすることです。変更のすべての理由がバグトラッカー（またはナレッジベース、またはWiki）に記録されていることを確認し、すべての変更が変更管理システムに記録されていることを確認します。

緊急サービスのお客様がおり、システムに発生したすべての変更が記録され、システムにログインするたびに記録する必要があります。そのうちのいくつかについては、まず許可を得るために電話をかけなければなりません（そして、彼らもそれを記録していると思います！）。すべての変更はログに記録されます。ログを記録せずに顧客システムを変更することは懲戒処分となります。

面倒ですが、そうではありません。あなたはすぐにアクセスログと変更ログに自分を追加する習慣になります-コード変更をチェックインするときにコメントを書く必要があるよりも悪いことではありません。

通常は更新が簡単なので、変更管理の理由ログとしてバグトラッカーをお勧めします（私はMantisを使用しています）。

「エンタープライズソリューション」を探している場合（つまり、神よりもお金があり、本当にクールなツールが必要な場合）、私がサポートしてオンサイト作業を提供するために使用したツールは、多数の機能の1つとしてこれを行います。

基本価格が何であるかは分かりませんが、HPがOpswareを購入する前は、約$ 350,000でした（サポートなしで、私を信頼してください-Opswareを始めたときにサポートが必要でした）。

私がそこで働いていた数人の顧客は、Tripwireとともにアプリケーション構成とスナップショット機能を使用していました。

もちろん、予算がない場合-これはBad Choice™です:)

そして、fwiw、私がそれをリロードしたときに私のためにこのページの上部に表示された広告はspiceworks用でした。HPSAに非常に似ています:)

あなたがしたいすべてがある場合はトラックの変更ではなく（シェフや人形を経由してすなわち、）プロセス全体を管理し、ちょうどrsyncあなたのetc地元のgitリポジトリにディレクトリ（それはあるかもしれない場所）。

for HOST in alpha bravo charlie delta ...; do

    rsync -avz --exclude-from=exclusions -e ssh admin@$HOST:/opt/local/etc/ ./$HOST

done

もちろん、必要に応じて他のソースを追加できます。