サーバーのドキュメントが実際の設定と同期しなくなるのをどのように回避しますか？

私たちの環境に適したドキュメント（AsciiDoc形式）があり、最近、他の人がセットアップ全体を30分未満で最初から再作成できるようになりました。
ただし、最初のセットアップ後、システムに小さな変更が加えられたことが簡単に発生することに気付きました（たとえば、inetdが無効になり、IMAPサーバーがManageSieve接続の追加ポートでリッスンし、exim構成に新しいルーターが追加されます）。 （もしあれば）すぐにドキュメントに記載されることはありません。

これを実装する1つの方法は、配置するかもしれ-私の考えでは、その中にコンフィギュレーションファイルおよびコメントの外にドキュメントを生成する（？部分的に）することで、この問題を回避するためだった/etcと/usr/local/etcいくつかのソースコード管理システムに（と言う- gitの）、その後、Aを実行しますコミットごとにドキュメントを再生成するスクリプト。しかし、それがやりすぎであるか、正しく理解するのが難しすぎるかはわかりません（結局のところ、ドキュメントのソースファイルの完全なコピーではなく、diffだけが必要です）。

他の人々はサーバーのドキュメントが古くなるのをどのように避けますか？それらを自動的に同期を保つための良い方法はありますか、それともシステムを変更すると同時にドキュメントを更新する規律がありますか？

一部のドキュメントから離れることはありませんが、多くのことをカバーするために変更プロセスに統合できるシステムがあります。

• 設定管理ツール（puppetやchefなど）を使用します。
• 変更管理された方法で構成を保存します。（gitやSVNなど）
• 設定が人間によって読み取り可能/アクセス可能であることを確認してください（つまり、プレーンテキスト、検索可能なデータベース）

このように、通常は見落とす（または気にしない）下位レベルのドキュメントは、変更を行うシステムの一部として構成アイテムまたはコードにその展開情報を格納することによって適用されます。これには、プロセスが将来さらに再現可能になるという追加のボーナスもあります。

外部ドキュメントは引き続き更新する必要がありますが、長いコマンド/ファイルリストではなく、「Deploy X」または「Deploy Y」へのポインタで非常に高レベルになります。これにより、ドキュメントの変更頻度が少なくなり、変更も簡単になります。つまり、作業が完了する可能性が高くなります。

また、あなたが家に帰る前に、人形で誰かがおそらくあなたが望むものを管理するために何かをすでに書いています。

1つまたは2つの小さなシステムのみを管理する場合、puppetやchefなどの大規模な構成管理システムをセットアップするのはやり過ぎのようです。（ただし、将来さらに多くのシステムを計画している場合は、今すぐ実行してください！）

このような小さなセットアップetckeeperでは/etc、gitリポジトリに入れてパッケージをインストール、アップグレード、または削除するたびに自動コミットを実行するなど、いくつかの便利な機能を提供するプログラムのようなものを使用することをお勧めします。

システムに変更を加えるたびに、ドキュメントを更新する必要があります。別名Change Management。

ほとんどの企業が変更管理をとんでもない方法で実装し、何も悪化させないという事実は、基本概念の有用性を損なったり、正しく実行したりすることを妨げるべきではありません。

私は以前、htmlまたは何らかのwiki を使用してすべての構成を追跡していました。今、私は（震える）SharePointを使用してWindowsショップで働いているので、私が作成したWordドキュメントの「テンプレート」を使用して、自分が持っているすべてのシステムと行ったすべての構成変更を追跡します。システムは、他のシステムのcookie-cutterコピーであり、すべて同じ文書にまとめることができます。（そして、私のすべてのドキュメントのローカルコピーをハードドライブに保存します。実際には賢明な方法で整理されているだけでなく、誰かのSharePointサイトである整理されていないヒープにそれらをスローします。）

最大の課題は、実際に文書化する時間を作ることです。これは、変更を加える時間の一部として文書化時間を追加することで行います。ですから、それほど難しいことではありません。特に、お尻が少しあり、現時点で問題が多すぎて忙しいので、人々をだまして列に並ぶように言ってもかまわない場合は。