|
| |
| Sun Java System Communications Services 6 2004Q2 企業向け配備計画ガイド | |
第 2 章
企業の要件の分析Communications Services 配備の計画においては、まず企業のビジネスと技術的な要件を分析する必要があります。この章は、Communications Services 設計を決定するために使用する要件を収集し、評価するのに役立ちます。
この章には、以下の節があります。
配備目標の明確化Communications Services ハードウェアまたはソフトウェアを購入または配備する前に、配備目標を明確にする必要があります。配備要件は企業内のあらゆるソースが関係しています。多くの場合、要件はあいまいな用語で表現されるため、特定の目標を確定できるようにそれらの用語を明確化する必要があります。
要件分析の結果は、配備が成功したかどうかを評価できるように明確かつ簡潔で、測定可能な目標でなければなりません。プロジェクトの利害関係者に受け入れられるような明確な目標を持たずに推進するのでは根拠の乏しい計画になってしまいます。
配備計画を立てる前に確認する必要のある要件の一部は以下のとおりです。
ビジネス要件
ビジネスの目的が配備の決定に影響を与えます。特に、ユーザーの動作、サイトの分散、および配備に影響を与える企業内の潜在的な政治的問題について理解する必要があります。これらのビジネス要件を理解していないと、容易に間違った推定に基づく決定をしてしまい、配備設計の正確性に悪影響を与える可能性があります。
運用要件
簡単でわかりやすい目標として、運用要件を一連の機能要件として表現します。通常、以下のような非公式の仕様があります。
たとえば、「適切なエンドユーザーの応答時間」を、「適切な」とは何か、応答時間の測定方法などすべての利害関係者が理解できる測定可能な用語に変換します。
企業文化と政治
配備にあたっては企業文化と政治を考慮する必要があります。ビジネス要件を代表する部門からさまざまな要求が提出される場合があります。
例:
技術要件
技術要件 (または機能要件) とは、組織のシステムニーズの詳細です。
既存の使用パターンのサポート
既存の使用パターンを、配備が実現する明確で測定可能な目標として表現します。以下の質問が、このような目標を特定するのに役立ちます。
サービスにアクセスするユーザーについて調べます。ユーザーが既存のサービスをいつ使用するかなどの要素は、配備要件すなわち目標を特定するための手がかりとなります。組織の経験からこのようなパターンが得られない場合は、別の組織の経験を調べて予測します。
利用率の高い組織の領域には、専用のサーバーが必要になる場合があります。通常、実際のサーバーから離れた場所のユーザーの場合、応答時間が遅くなります。容認可能な応答時間を検討します。
サイトの分散
以下の質問を使用して、サイトの分散が配備目標にどのように影響を与えるかについて理解します。
ネットワーク
以下の質問がネットワークの要件を理解するのに役立ちます。
既存のインフラストラクチャ
信頼性が高く、可用性の高い帯域幅がある場合は、サーバーを集中化することができます。
サポート要員
一日 24 時間、一週 7 日間のサポートは、特定のサイトでのみ利用可能です。簡単なアーキテクチャで、サーバーの数が少ないほどサポートが簡単になります。
財務要件
財務要件は配備を構築する方法に影響を与えます。財務要件は、総合的な観点を通して明確に定義されるため、配備の制限または配備対象が絞られる傾向にあります。
明白なハードウェア、ソフトウェア、および保守費用のほかに、以下のような多くのコストがプロジェクトの全体的コストに影響を与えます。
プロジェクトの要件に関連する多くの要素に対して十分な注意を払い、分析を行うことによって、プロジェクトに関連する財務問題を回避することができます。
サービス品質保証契約 (SLA)
作動時間、応答時間、メッセージ配信時間、障害回復などの配備に関連する SLA を開発する必要があります。SLA 自体で、システムの概要、サポート組織の役割と責任、応答時間、サービス水準の測定方法、変更の要求などの項目を明らかにする必要があります。
システムの可用性に関する組織の要求を確認することは、SLA の範囲を決定するためのかぎです。通常、システムの可用性は、システムの作動時間のパーセンテージで表されます。システムの可用性を算出する基本的な計算式は次のとおりです。
可用性 = 作動時間 / (作動時間 + 不稼動時間) * 100
たとえば、サービス品質保証契約でフォーナイン (99.99 %) の作動時間は、1 ヶ月で約 4 分間システムが利用できないことを意味します。
さらに、システムの不稼動時間とは、システムを利用できない合計時間を示します。この合計時間には、ハードウェアの故障やネットワークの停止などの予測できないダウンタイムだけではなく、計画されたダウンタイム、予防保守、ソフトウェアのアップグレード、パッチなどが含まれます。システムが一週 7 日間、一日 24 時間利用可能でなければならない場合は、計画されたダウンタイムや予測できないダウンタイムを回避して高可用性を確保するために、アーキテクチャに冗長性を備える必要があります。
プロジェクトの目標の特定調査と分析によってプロジェクトの要件を明確にします。次に、はっきりと測定できる目標を特定することが必要になります。プロジェクトに直接関与しないスタッフが、目標と目標に対するプロジェクトの実績を測定する方法を理解できるようにこれらの目標を特定します。
利害関係者がプロジェクトの目標を受け入れる必要があります。実装後の審査でプロジェクトの目標を測定し、プロジェクトが成功したかどうかを確認する必要があります。
拡大のための計画
現在必要な容量を確定するだけではなく、計画できる期間内で将来必要になる容量を予測します。通常、拡大の時系列は 6 ヶ月から 12 ヶ月の範囲です。拡大に対応するために考慮しなければならない要素は、拡大の予測と利用特性の変化です。
ユーザーやメッセージ数の増加に応じて、容量計画の適切な指針の輪郭を描く必要があります。さまざまなサーバーのメッセージトラフィックの増大、全体のユーザー数の増加、メールボックスサイズの拡大、カレンダーのアポイントメントの増加などを計画に含める必要があります。ユーザー人口が増加すると、時間の経過に伴って利用特性が変化します。配備目標 (すなわち配備設計) は、将来の成長に基づいていなければなりません。
理想的に言えば、将来の拡大に容易に対応できるようにアーキテクチャを設計する必要があります。たとえば、Communications Services 自体に論理名を使用します。詳細については、「論理サービス名の使用」を参照してください。また、配備が本稼動段階に入ると、配備を拡大する時期と大きさを理解するために、配備の監視が非常に重要になります。
総所有コスト (TCO) の理解
総所有コスト (TCO) は、容量計画に影響を与えるもう一つの要素です。総所有コストには、Communications Services を配備するハードウェアの選択が含まれます。表 2-1 に、小規模なハードウェアシステムを数多く配備するか、または大規模なハードウェアシステムを数少なく配備するかを検討する要素の一部を示します。