統合ストレージ調達のRFPをどう作るか

　3. 管理要件

　統合ストレージ基盤に対する管理レベルは、利用者により非常にさまざまです。前回まででもいくつか例を紹介していますが、第８回で予定している「運用管理の実際」でさらに詳細に述べたいと思っています。今回紹介する部分に関しては、この「運用管理の実際」とともに参照いただくとより理解を深められると思います。

■構成管理方法

　自社でどのレベルの構成管理を実施したいかをRFPに盛り込むことをお勧めします。具体的な管理方法が分かっている場合は、その内容を記載するのが良いと思いますが、以下のレベルでも十分です。

• 障害が発生した場合、障害発生の部位を利用しているサーバが特定できること
• 筐体内のバックアップにおいて、バックアップ先のボリュームが特定できること
• サーバが接続されている、FCスイッチとそのポート番号が特定できること
• サーバから確認できるデバイス名とストレージのデバイス番号の識別が可能なこと
• バックアップ・ジョブ名から、関連システム名を特定できること
• バックアップ・サーバと利用対象のストレージ基盤、テープ装置などの関連性が把握できること

　 ほとんどの場合、基盤構築サービスの納品物に構成図や構成管理表などが含まれます。
あらかじめサンプルを確認し、自社で想定している構成管理が可能になるかどうかの判断をすることも、有効な方法です。

■キャパシティ管理方法

　構成管理と同様、どのようなレベルでキャパシティ管理を実施したいかを明記します。前述の例にならい、記述すると以下のようになります。

• 追加導入なしで、あとどのくらい容量が利用できるかが判別できること
• プライマリ用のボリュームと、バックアップ用のボリュームの区別が可能なこと
• 追加導入なしで、接続可能な物理パス数、論理パスが判別できること
• 設置スペースの拡張なしで、どの程度の容量が追加できるかを確認できること
• 接続されている業務システムのストレージ利用容量が把握できること、かつそのデータをxx年間保存できること
• 業務システムのストレージ利用容量の時系列のグラフが自動的に作成できること
• バックアップ要件を満足できる状態で、後どのくらいの容量のバックアップが取得可能かを判別できること　（CPU/メモリの観点、テープメディアの観点、接続性の観点を含む）

　キャパシティ管理の一環として、拡張計画（増強計画）があります。あらかじめ、将来拡張する容量や、サーバ接続の予定が決まっていれば、その状況をRFPに盛り込み、将来の拡張計画までを念頭においた提案を受けてください。また、拡張時の要件に関しても、可能な限りこの時点で伝えることが有効です。例として以下のようなものが考えられます。

• 容量を追加した場合も、既存利用サーバの性能に影響を与えないこと
• 追加される容量分も既存接続分と同様の性能が提供できること
• 提案構成を元にした、最小拡張単位と推奨の拡張単位、その推奨理由を提示すること

■性能管理方法

　IT基盤サービス（IT基盤運用）を提供する場合は、性能監視までは必要ない場合でも、一定レベルの性能管理を検討すべきです。ただし、その管理レベルは、ストレージ基盤を利用する業務システムの管理要件により大きく変動します。RFPに盛り込む例を紹介します。

• 月例の運用レポートに盛り込める性能データを作成できること
• I/O応答時間のサービスレベルが達成できているかどうかを、日次で評価が可能なこと
• 業務システムで性能遅延が確認できた場合、ストレージ基盤として性能遅延が発生しているかどうかを確認できること、また、I/O性能の遅延が確認できた場合、原因が特定できること
• I/O性能データをｘｘ年間保存できること
• 最小計測間隔が、ｘｘ分以下であること

■変更管理要件

　変更管理に関しては、構築プロジェクトの実施要件の側面と、運用フェイズでの個別の案件実施の場合、および、障害時の修復作業、保守対応などの場合が対象となります。QMS, ITILなどが導入されており、すでに確立した変更管理プロセスが存在する場合は、ベンダ作業において、どの時点から、どの範囲でこの変更管理プロセスを遵守してもらうか、その内容はどのようなものかなどを可能な範囲で伝えてください。それにより、ベンダ側も適切なレベルの体制、文書管理等をあらかじめ想定することが可能となります。
　
■セキュリティ要件

　設備的な側面、自社ネットワーク・セキュリティ上の制限、構築プロジェクト推進中のデータの受け渡し等の制限、ISMSを取得している場合の制限や、機密保持契約の有無等、統合ストレージ基盤構築時、運用時に想定される、自社のセキュリティ要件も、可能な範囲で伝えてください。

　RFPのタイミングでは必要ないと思いますが、要員受け入れ時の制限、サーバ構築時等のネーミング・ルールなどの条件等も、基盤構築を進めていく際には、ベンダと合意しておく項目の1つです。

■リリース時のUAT要件、達成基準

　この項目は重要なポイントです。最初のRFPに盛り込むか、ある程度ベンダを絞った後の2次提案要求時に盛り込むかという検討は必要ですが、契約締結前にはベンダと合意を得ておく必要があります。

　対象となるストレージ基盤を利用する業務システムの重要度等にも大きく依存しますが、機能テスト、統合テスト、ユーザー受け入れテスト（UAT）、性能負荷テスト、障害切り替えテスト、運用機能テストおよび、それぞれの完了基準等の合意を得ておく必要があります。あらかじめ要件として提示するか、あるいは、ベンダに提示を求めて評価するかは、一考の余地はありますが、この要件を曖昧にしておくことは、避けるべきです。

■必要となる文書の定義
■想定される内部工数、外注費用

　管理要件に該当する上記項目群に関する、運用引き継ぎ用の文書類の定義、検討／構築を進めていく際の自社費用、および、この管理項目を運用する際の自社要員や、必要な外注費用などの検討は必要な項目の1つといえます。

3/4

Index
統合ストレージ調達のRFPをどう作るか
	Page1 統合ストレージの調達 1. 機能要件
	Page2 2. 運用要件
	Page3 3. 管理要件
	Page4 4. 保守要件 5. プロジェクト要件 6. 運用管理支援要件