バージョン管理、テスト、継続的統合/展開などの開発プラクティスをシステム管理にどのように適用しますか？

多数の人々が使用するさまざまなサービスを備えた多数のサーバーを管理するとします。次に、これらのサーバーのいずれかでソフトウェアを再構成または交換したいとします。明らかに、実稼働中のサーバーで作業する必要はありません。

これがコード変更である場合、開発者として、ローカル開発マシンで変更を行い、ローカルでテストして、バージョン管理システムに変更をコミットします。その後、変更をステージング環境に展開し、さらにテストして、最終的に本番環境に展開できます。また、必要に応じて簡単にロールバックできます。

一般的に、または具体的に、システム管理でこれをどのように達成しますか？

（最初に頭に浮かぶのは、仮想マシンを使用してバージョン管理に仮想マシンイメージを配置することですが、私が現在知らない多くの文献と賢い解決策があると確信しています。）

簡単な答えは、「OS展開管​​理」、「構成管理」、および「ソフトウェアパッケージ」です。長い答えが続きます。

Daniel Pittmanの回答に、システム管理における「システム」を形成するものの内訳を付け加えたいと思います。

システムまたは環境は、次のもので構成されます。

• サーバー
• オペレーティング・システム
• 構成
• ベンダーパッケージ。そして
• ローカルパッケージ

これらを包むのは、次のようなプロセスです。

• OSの展開またはイメージング
• 構成管理
• ソフトウェアパッケージ管理
• 監査/ロギング
• モニタリング
• バックアップ

そして、これらを組み合わせて、次のような非機能的な目標の達成を支援します。

• 再現性
• 保守性
• 測定可能性
• 性能
• 追跡可能性
• テスタビリティ
• 変更可能性

これは簡単なブレインダンプです。すべてのリストにさらに追加できると確信しています。

あなたの質問は、特定の言葉を使わずにこれらの多くに触れています。たとえば、簡単に展開して元に戻せるようにしたい、つまり保守性が必要な場合。テスト環境でそれを行い、合格するまでテストしたい、すなわち、再現性、テスト可能性、および測定可能性。OSと構成の展開の再現性が必要なため、バージョン管理にvmイメージを配置することを考えています。

これを支援するツールはたくさんありますが、ダニエルが言及したものもあります。他のいくつかは：

• 既知のOS環境を展開するためのキックスタート（RedHatベース）、Preseed（Debianベース）、WDS（MS Windows）
• Spacewalk / Satellite（RedHatベース）、構成およびパッケージ管理用のグループポリシー（MS Windows）
• パッケージ（ソフトウェアの一部を構成するバイナリ、データ、および構成のセット）を生成、展開、アップグレード、および削除するためのYUMおよびAPTパッケージングシステム
• 監視用のNagios、OpenNMS、およびSCOM
• バックアップ用のAmanda、BaculaおよびWindows Backup Server
• パフォーマンスモニタリング用のMunin、PCP、Hyperic
• バージョン管理用のCVS、SVN、GITまたはBazaar
• ビルド管理のためのハドソンとジェンキンス
• テスト用のセレンとロボット
• Bugzilla、Request Tracker、およびJiraによる記録、通信、追跡

繰り返しますが、これは包括的なリストではありませんが、私をガイドするために頭に置いておくものであり、うまくいけばあなたにも役立つでしょう。

免責事項：私はPuppetの開発者の一人です。

明白な方法は、概念を適用することです。開発/テスト/生産のサイクルを定義し、それらを通して変更をプッシュします。バージョン管理を使用してシステムを追跡します。

簡単に言えば、そのパスを開始すると、これらのことを自動化するツールが本当に必要であることがわかります-基本的に、システム管理を自動化したいので、マシンでこれらの技術を使用せず、システムでそれらを使用しますマシンを管理します。

などのツールシェフ、人形、塩、およびcfengineのは、第二の必要性、そのアドレスへのすべての一般的なツールです。これらは、システム管理をバージョン管理とテストが可能な中央ソリューションに変えるという一般的な方向で機能します。

DevOpsチームの動きは、これを行う方法の良い情報の別のソースです。この原則は、開発者と運用スタッフの間のより良い協力ですが、この同じ方向に向かう傾向もあります。

Windowsの世界では、アプリケーションライフサイクル管理に関するこれらの問題はSystem Center 2012で対処されています。

System Center Virtual Machine Manager（SCVMM）では、サービスは「サービステンプレート」（従来の3層サービスなど）を使用して定義され、実行環境は「クラウド」（開発、ステージング、本番など）として定義されます。サービステンプレートは、バージョン管理され、異なるクラウドに（自動化された方法で）ロールアウトできます。SCVMMは、仮想化されたハードウェア（VMなど）とソフトウェア（OS、アプリコンポーネントなど）のプロビジョニング、展開、構成を行います。

System Center Service Managerは、プロセスの観点からこれを結び付ける部分です。たとえば、問題の管理と変更の制御。