準備条件の定義
デプロイの計画と管理には、各アクティビティに最適なさまざまなアクティビティとロールが含まれます。 この記事では、重要なロールを識別し、アプリを分類する方法を理解する方法について説明します。
ロールと担当者を把握する
計画を立てるにつれて、デプロイを実行する必要があるロールと、その役割を満たす必要があるユーザーを把握する価値があります。 デプロイのさまざまなフェーズで、異なるロールがアクティブになります。 organizationのサイズと複雑さに応じて、一部のロールが同じユーザーによって満たされる場合があります。 ただし、デプロイのすべてのタスクを監督するプロセス マネージャーを確立することをお勧めします。
プロセス マネージャー
プロセス マネージャーは更新プログラムの展開プロセスをリードし、必要に応じてプロセスを転送または停止する権限を持ちます。 また、これらの活動を組織する責任もあります。
| 互換性ワークストリーム | 展開 | 機能と最新化 |
|---|---|---|
| アプリケーションの優先順位の割り当て | インフラストラクチャ要件の確認 | インフラストラクチャの変更の決定 |
| アプリケーション評価 | 要件に対するインフラストラクチャの検証 | 構成の変更の決定 |
| デバイス評価 | インフラストラクチャ更新計画の作成 | 機能提案の作成 |
プロセス マネージャーの役割は、修復作業に関するレポートを収集し、エラーをエスカレートし、環境がパイロットデプロイの準備ができているかどうかを判断してから、広範なデプロイを行う準備ができているかどうかを判断することです。
次の表では、他のロールの 1 つのビューを、責任、関連するスキル、必要なデプロイ フェーズで示します。
| ロール | 責任 | スキル | アクティブなフェーズ |
|---|---|---|---|
| プロセス マネージャー | プロセスをエンドツーエンドで管理します。入力と出力がキャプチャされることを保証します。アクティビティの進行状況を確認します。 | IT サービス管理 | 計画、準備、パイロット展開、広範なデプロイ |
| アプリケーション所有者 | アプリケーション テスト 計画を定義する。ユーザー受け入れテスト担当者を割り当てる。アプリケーションを認定する | 重要で重要なアプリケーションに関する知識 | 計画、準備、パイロット展開 |
| アプリケーション開発者 | 現在の Windows バージョンとの互換性を維持するためにアプリが開発されていることを確認する | アプリケーション開発。アプリケーションの修復 | 計画、準備 |
| エンド ユーザー コンピューティング | 通常、アップグレード ツールが Windows と互換性があることを確認するインフラストラクチャ エンジニアや展開エンジニアを含むグループ | ベアメタル展開。インフラストラクチャ管理。アプリケーションの配信。更新管理 | 計画、準備、パイロット展開、広範なデプロイ |
| 運用 | 現在の Windows バージョンでサポートが利用可能であることを確認します。 ユーザー通信やロールバックなど、デプロイ後のサポートを提供します。 | プラットフォームのセキュリティ | 準備、パイロットデプロイ、広範なデプロイ |
| セキュリティ | セキュリティ ベースラインとツールを確認して承認する | プラットフォームのセキュリティ | 準備、パイロット展開 |
| ステーク ホルダー | 財務責任者、エンドユーザー サービス、変更管理など、更新の影響を受けるグループを表します | 部署または部署の主要な意思決定者 | 計画、パイロットデプロイ、広範なデプロイ |
評価アプリの条件を設定する
環境内の一部のアプリは、主要なビジネス アクティビティの基礎となります。 他のアプリは、ワーカーがロールを実行するのに役立ちますが、ビジネス運用にとって重要ではありません。 環境内のアプリのインベントリと評価を開始する前に、アプリを分類するための基準をいくつか設定し、それぞれの優先順位を決定する必要があります。 このプロセスは、更新プログラムを最適に展開する方法と、発生する可能性がある問題を解決する方法を理解するのに役立ちます。
準備フェーズでは、ここで定義した条件を、organization内のすべてのアプリに適用します。
推奨される分類スキームを次に示します。
| 分類 | 定義 |
|---|---|
| 重大 | 主要なビジネス アクティビティとプロセスを処理する最も重要なアプリケーション。 これらのアプリケーションが利用できなかった場合、ビジネスユニットまたは部署はまったく機能できませんでした。 |
| 重要 | 個々のスタッフ メンバーが生産性をサポートするために必要なアプリケーション。 ここでのダウンタイムは個々のユーザーに影響しますが、ビジネスへの影響は最小限に抑えられます。 |
| 重要ではない | これらのアプリがしばらく利用できない場合、ビジネスに影響はありません。 |
アプリケーションを分類したら、優先順位と重大度の観点から、各分類の意味をorganizationに同意する必要があります。 このアクティビティは、問題を適切な緊急度でトリアージするのに役立ちます。 各アプリに時間ベースの優先順位を割り当てる必要があります。
優先度評価システムの例を次に示します。詳細は、organizationによって異なる場合があります。
| Priority | 定義 |
|---|---|
| 1 | 特定された問題またはリスクは、できるだけ早く調査して解決する必要があります。 |
| 2 | 2 営業日以内にリスクと問題の調査を開始し、現在のデプロイ サイクル 中にそれらを 修正します。 |
| 3 | 10 営業日以内にリスクと問題の調査を開始します。 現在のデプロイ サイクル内でそれらをすべて修正する必要はありません。 ただし、すべての問題は、次のデプロイ サイクルの終わりまでに修正する必要があります。 |
| 4 | 20 営業日以内にリスクと問題の調査を開始します。 現在または将来の開発サイクルで修正できます。 |
優先度に関連しますが、個別のは重大度の概念です。 アプリの問題がデプロイ サイクルに与える影響に基づいて、重大度のランク付けも定義する必要があります。
以下に例を示します。
| 重大度 | 効果 |
|---|---|
| 1 | 仕事の停止または収益の損失 |
| 2 | ビジネス ユニットの生産性の低下 |
| 3 | 個々のユーザーの生産性の低下 |
| 4 | ユーザーへの影響を最小限に抑える |
例: 大手金融会社
推奨されるスキームを使用して、金融会社は次のようにアプリを分類する場合があります。
| アプリ | 分類 |
|---|---|
| クレジット処理アプリ | 重大 |
| 現場顧客サービス アプリ | 重大 |
| PDF ビューアー | 重要 |
| 画像処理アプリ | 重要ではない |
さらに、この分類を次のような重大度と優先順位のランク付けと組み合わせる場合があります。
| 分類 | 重大度 | Priority | 応答 |
|---|---|---|---|
| 重大 | 1 または 2 | 1 または 2 | 1 の場合は、解決されるまでデプロイを停止します。2 の場合は、影響を受けるデバイスまたはユーザーのみの展開を停止します。 |
| 重要 | 3 または 4 | 3 または 4 | 3 については、回避策のガイダンスがある限り、影響を受けるデバイスに対してもデプロイを続行します。 |
| 重要ではない | 4 | 4 | すべてのデバイスのデプロイを続行します。 |