Go-live を計画する
Go-Live の前には、次に示すさまざまな活動を行う必要があります。
- パフォーマンス テスト
- デプロイ計画
- リスク評価
パフォーマンス テスト
パフォーマンス テストでは、アプリケーションが仕様どおりに実行されており、日常の過酷な使用に対応できることを確認します。 強力なパフォーマンスは、ユーザーの導入を推進する上で重要です。 ユーザーは、ページの読み込みに時間がかかりすぎるアプリケーションを使用したり、ビジネス プロセスを習得することに消極的になります。 パフォーマンス テストは、顧客が特定のカスタマイズを再確認したり、調整活動を実行したりする必要があるかどうかを特定するのに役立ちます。
多くの顧客は、コストと労力を節約するためにパフォーマンス テストを組み込んでおらず、 その結果、アプリケーションの Go-live の直後にユーザーが問題に直面することがあります。 ソリューション アーキテクトは、パフォーマンス テストを行わない場合のリスクを顧客に認識させる必要があります。
このテストの結果により、ソリューション アーキテクトには修復手順の計画や、サポート リクエストの送信の支援が必要になる場合があります。 パフォーマンス テストは、アプリケーションが Go-live になる前にこのテストにおいて発生した問題を解決するのに十分な余裕がある時期に実行する必要があります。
パフォーマンス テストでは、主に次のような質問に対して答えを出す必要があります。
- パフォーマンス テスト専用の環境はあるか。
- パフォーマンス テストに必要なマスター データまたは参照データを特定しているか。
- 重要なビジネス シナリオと、そのシナリオのためのベースラインを特定しているか。
- パフォーマンス テストのための同時負荷を特定しているか。
- 場所ごとに待機時間テストを実行する場所を特定しているか。
- パフォーマンス テストの実施前に必要なデータを入力するための計画を作成したか。
ソリューション アーキテクトは以下を行う必要があります。
- アプリ内でパフォーマンス テストの実施が必要になる潜在的なホットスポットを特定する。
- ピーク時に予測される量を理解し、常にそれよりも少し高く計画する。
- コンプライアンスに準拠するために、パフォーマンスについて契約を交わしたサービス レベル アグリーメント (SLA) のテストを行う。
ソリューション アーキテクトは、オフィスの複数の場所でネットワーク トラフィックを監視する必要があります。 特に、ネットワークの問題によってアプリのパフォーマンスが低下しないことを確認するために、待機時間と帯域幅を調べる必要があります。 Microsoft Azure Monitor と Azure App Insights を使用すると、アプリのパフォーマンスを監視できます。
デプロイ計画
事前に何らかの計画を立てることにより、ソリューションの展開がよりスムーズになります。 ソリューションの展開を成功させるために、多くの活動を含めてデプロイ計画を立てる必要があります。 デプロイ計画は場合によって異なりますが、主に次のものが含まれます。
- 環境のセットアップ
- 数種類のテスト
- ユーザー トレーニング
- データ移行
- ロールアウト戦略
- デプロイ中のサポート
プロジェクトの規模にもよりますが、ソリューション アーキテクトはデプロイ計画を指揮することや、専任のデプロイ計画チームにアドバイスを与える任務に就くことがあります。 通常、ソリューション アーキテクトはデプロイ計画を作成しませんが、アドバイスを与えたりレビューを行ったりします。
顧客がデプロイの進行に不満がある場合、最初に呼び出されるのは、多くの場合ソリューション アーキテクトです。
ソリューション アーキテクトは以下を行う必要があります。
- Go-live に向けた一連のイベントが行われているか確認する。
- リスクを矛盾なく調べて、代替計画を作成する。
- デプロイをサポートするチームが存在することを確認する。
リスク評価
システムを誰よりも理解しているのはソリューション アーキテクトであるため、Go-live に向けたリスク評価を自身で行う必要があります。 システムを上から下に調べて、次の点について検討する必要があります。
- 問題を起こし得るものはないか。
- 仕様どおりに機能しない可能性のあるものはないか。
- 他のシステムがダウンした場合どうなるか。
- デプロイの順序は適切か。
常に最悪の事態を予想して計画を作成しましょう。問題が起きなければそれが一番です。