質の高い企業ソリューションを提供するには、ビジネスプロセスを実装するソリューションを作成するだけでは不十分です。 顧客はそれ自体が単なるソリューション以上のものを必要としています。 顧客は、この決定を運用、保守、監視する必要があることを理解しています。 既存のものと統合したり、新しいインストールを展開したり、落ちたものを回復したり、クラッシュやパフォーマンスの低下などを分析したり、サポートや操作のタスクを実行したりすることさえ可能です。 多数のコンポーネントで構成される決定のもう1つの特性は、自分自身に関する情報を提供し、自己記述できることです。 ソリューションが、多数のサーバーで実行される相互に接続された多数のコンポーネントで構成されている場合、そのようなソリューションが、どこでどのコンポーネントが実行されているかを自動的に検出できるインターフェースを提供すると非常に便利です。 コンポーネントがサーバーからサーバーに転送された場合でも、そのような変更に関する情報は自動的に提供される必要があります。 社内に既製のITILベースのシステムがある場合、そのような情報自体が外部からの干渉なしにシステムに入力される必要があります。 これにより、ソリューションの統合、監視、サポートの人件費が削減され、プロセスが簡素化され、アプリケーションカタログデータの混乱や手動更新がなくなります。
次に、Windowsプラットフォームは、将来のサポート、運用、およびインベントリの必要性を考慮して、ソリューションを作成するように設計されたテクノロジーを提供します。
管理容易性戦略
ソフトウェアソリューションが、多数のサーバーで実行される相互接続された多数のコンポーネントで構成されている場合、ソリューションを管理するには特定のコマンドラインインターフェイスが必要です。 これらのコンポーネントは、必ずしも相互にデータを交換するわけではありませんが、一般に既製のソフトウェアソリューションを表します。 そのため、このコマンドインターフェイスはスクリプト機能を提供する必要があります。 これは、発生する可能性のあるソリューションをサポートする日常的なタスクを促進および自動化するために必要です。 さらに、このようなインターフェースにより、既存の海のコンポーネントとサーバーで適切なサーバーと適切なコンポーネントを検索および検索できるようになります。 実際、彼が解決するのに役立つ基本的なタスクセットは次のとおりです。
- サーバー名で、このサーバーで実行されているすべてのソリューションコンポーネントとそのステータスを返します。 これにより、アプリケーションカタログのデータベースを自動的に更新できるようになり、サポートが容易になります。 本質的に、これは複雑なシステムのコンポーネント間の相互作用のグラフを自動的に取得することを可能にするかもしれません
- 停止/開始/再起動などのコンポーネントの基本操作を実行し、コンポーネントの状態を取得して構成します
これはすべて、Windows環境でWMIインターフェイスに基づいて実装できます。 ソリューションとそのコンポーネントが同様の機能を提供するWMIクラスによってバインドされている場合、PowerShellベースのコマンドラインスクリプトインターフェイスを取得するのは非常に簡単です。 これらのクラスに基づいてPowerShellコマンド（コマンドレット）を生成することは難しくありません。これにより、まさにこのようなコマンドラインインターフェイスが提供されます。 IISで構築されたソリューションの場合、IIS自体が必要な機能をすべて提供するため、WMIも必要ありません。 特定のソリューションに固有のラッパーのみを実装する必要があります。 その結果、コマンドラインからフル機能のソリューション管理インターフェイスを取得できます。これは、既存のCMDB実装と簡単に統合できます。
ここで重要な要素は、企業のITILインフラストラクチャとの統合です。 この要件を念頭に置いて、ソリューションを最初から設計する必要があります。 アプリケーションは、自身をインベントリし、CMDBの情報を自動的に更新する機能を提供する必要があります。 この場合、ソリューションとインフラストラクチャの両方をサポートするすべてのチームは、環境の状態とコンポーネント間の関係に関する完全かつ最新の情報を入手できます。
一方、CMDB環境では、これらの依存関係を受信できるインターフェイスを提供する必要があります。 これにより、既存のインフラストラクチャの知識に基づいて、アプリケーションの自動展開メカニズムを開発する機会が提供されます。
したがって、製品の管理性に関する開発者および設計者向けの推奨事項は次のとおりです。
- ソフトウェアソリューションにPowerShellベースのコマンドラインインターフェイスを提供します。
- オプションで、WMIインターフェイスを提供します。 実際、それを提供すると、最初のアイテムを自動的に取得できます。
- ソリューションの高レベルアーキテクチャを説明する技術文書、コンポーネント間の相互作用のマップ、およびコンポーネントの内部構造に関する詳細な文書を提供します。
- ITILに注目してソリューションを設計します。
モニタリング戦略
ご存知のように、ソフトウェアソリューションは会社が提供するサービスと考えることができます。 したがって、このサービスの品質を高くするには、ソリューションを簡単に監視し、新たなインシデントに対応できることが必要です。 さらに、最良の場合、ソリューションは既存のエンタープライズ監視インフラストラクチャと簡単に統合する必要があります。 これを達成する方法は？ 最も単純なものから最も複雑なものへの3つの主要なパスがあります。イベントログ、パフォーマンスカウンター、およびWindowsエンジンのイベントトレースです。
イベントログは、コンポーネントの状態に関する情報を提供する最も簡単な方法です。 アプリケーションまたはソフトウェアソリューションがそのステータスをログに報告する場合、すぐに既存の監視システムのいずれかに簡単に統合できます。
一方、開発チーム自身だけでなくサポートチームも、戦闘環境とテスト環境の両方で、システム全体またはその個々のコンポーネントの状態に関する追加情報を必要とする場合があります。 ここでは、パフォーマンスカウンターが役に立ちます。 ソリューションがパフォーマンスカウンターを提供すると、パフォーマンスの問題の調査と対処がはるかに簡単になります。 さらに、既存のすべての監視システムは、メーターデータを消費し、それらに基づいてアラートを生成できます。 次に、制御ソフトウェアインターフェイスとCMDBデータを含むこれらすべてを使用して、これらのアラートに自動的に応答できます。
これでは十分ではありません。 場合によっては、戦闘システムで何が起こっているかをより深く掘り下げて確認し、さまざまなソースから、さまざまな角度からシステムで発生するイベントを相関させる必要があります。 このような目的のために、Windowsのイベントトレース（ETW）メカニズムがあります。 ソリューションがETWインフラストラクチャを通じてそのパフォーマンスと状態に関するデータを提供する場合、詳細なパフォーマンス分析を実施することが可能になります。
そのため、結果として、アプリケーションを設計する際に、その監視とサポートの単純さを確保するために、以下が必要です。
- システムでステータスイベントを記録する方法を検討して選択します。
- カウンターを使用して、主要なメトリック別にパフォーマンスメトリックを提供します。
- オプションで、ETWプロバイダーを介して情報を提供します
展開戦略
Windowsは展開の基盤です。 ソリューションを簡単に展開するだけでなく、失敗したインストールをロールバックしたり、必要に応じて既存のインストールを修正したりする機会を提供します。 さらに、SCCMなどの集中型ツールを使用して、またはActive Directory自体を使用して、MSIを展開できます。 パッケージはWixツールセットを使用してビルドできます。これにより、ソリューションのビルド手順の一部としてパッケージをビルドできます。
現時点では、展開用に設計された最新のテクノロジーがいくつかあります：Desired State Configuration（DSC）とOneGet。
DSCテクノロジは、宣言型言語を使用して複雑な展開シナリオを構築する方法です。 目的は、目的のサーバー構成を単純な宣言型言語、またはPowerShell言語のサブセットで記述し、この構成をサーバー自体に適用するようにサーバーに指示することです。 主な使用例は、サーバーが中央ポイントにアクセスし、それらが変更された場合に構成を取得する場合です。バージョンが大きくなりました。 サーバー構成を適用する過程で、追加のファイル、配布などをダウンロードできます。 ソリューションを展開するために、追加のコンポーネントを実装する必要がある場合があります-コンポーネントを正確に展開および構成する方法、設定する必要があるパラメーター、および場所を知っているDSCリソース。 このリソースは、非常に中心的な構成リポジトリである構成リポジトリに保存されるため、サーバーへの配信について心配する必要はありません。 すべてが自然に起こります。
現在実験中のもう1つのテクノロジーはOneGetです。 Windows環境のパッケージマネージャーと見なすことができます。 イデオロギー的に、これは任意の外部パッケージリポジトリを使用できるフレームワークです。デフォルトでは、NuGetに基づくChocolateyパブリックリポジトリが使用されます。 ただし、会社が使用する任意のリポジトリのプロバイダーを実装できます。 このアプローチは大きな前進です。 リポジトリを使用すると、ファイル配布に基づくほとんどすべての展開が非常に簡単なタスクになります。 実際、ソリューションを収集するシステムは、完成したパッケージをリポジトリに配置する必要があります。 展開で必要になった時点で、SCCMなどの集中管理ツールによって開始できます。
その結果、アプリケーションを設計する際に、展開を容易にするために、次のことを考慮する必要があります。
- パッケージに基づいています。 車輪を再発明する必要はありません。
- 会社に既存の制御/リポジトリ/展開インフラストラクチャがあるかどうかを確認し、車輪を再発明しないように展開環境と見なします。 ほとんどの場合、会社のすべてのニュアンスとセキュリティポリシーが考慮されます。これにより、一方で複雑になり、他方で将来の生活を簡素化します。
- ある場合は、展開に使用します。
参照資料
Wmi
Msi
ウィックス
オネゲット