IT基盤サービスを提供する場合，品質を向上させると同時に，サービス提供側の効率性を最大限に高めなければなりません。これはストレージ基盤サービスに限った話ではありませんが，サービス提供側として，いつも考え，常に改善していかなければならないことです。

　その際にキーワードとなるのは「標準化」と「自動化」ですが，やり方を間違えてしまうと，望ましくない結果を生み出すこともあります。そこで今回は，「ストレージ基盤サービスの標準化における落とし穴」というテーマで，実際に発生した問題や，起こり得る課題を紹介します。標準化の推進は，例外をどのように扱うかということがポイントになります。

標準を決めれば「例外」が生まれる

　標準化の代表例としては，提供デバイスの属性やバックアップ属性があります。提供デバイスの属性とは，RAIDの種類やリモート保護の有無，ストレージ容量，入出力速度，など。バックアップ属性とは，筐体内バックアップ技術，論理/物理バックアップ方法，世代数，バックアップ開始手順，メディア，保管期限，などです。

　サービス・メニューを決める場合は，要求されるサービスレベル別に，いくつかのメニュー（属性の組み合わせ）を準備しておくのがよいでしょう。こうして決まったものが標準サービス・メニューとなります。問題は，標準サービス・メニューに適合しない要求があった場合です。あくまで標準サービス・メニューにこだわるか，多少の例外を受け入れるかを決定しなければなりません。

　例えば，標準サービス・メニューでは，すべてのディスクをRAID5構成で提供していたとしましょう。ところがある特定の業務システムは，高速性を重要視することからRAID5ではなくRAID1の方が向いていることが確認できたとします。そうなると，そのシステムの担当者は，当然RAID1での提供を求めてきます。

　こうした場合，ストレージ基盤サービスの担当者はどのように対応すべきでしょうか。その判断を行うには，RAID1で提供する際の問題点とリスクを十分につかんでおく必要があります。この例の場合は，キャパシティ管理業務にどのように影響するかを考えることが重要です。

　RAID1とRAID5では，サービスとして提供する容量が同じでも，必要な物理ディスク容量は異なります。ですので，残存するディスク容量（もしくは拡張した容量）で，どのくらいの容量を利用者に提供できるのか，それをRAID1の場合，RAID5の場合，混在の場合で分けて管理することが必要になってきます。

　異なるRAIDセットの混在を柔軟に許容するストレージであれば，まだ影響は限定的ですが，あるまとまったディスク・グループ単位でRAID1やRAID5を設定する必要がある場合，RAID5のグループに余裕があっても，RAID1グループ用にディスクを追加しなければならないといったことが起こります。

　バックアップ・サービスに関しても同様です。標準サービス・メニューとして3世代のバックアップしか提供していなかったとします。それでも，システムによっては7世代，あるいは31世代のバックアップを要求されることが考えられます。

　こうした例外要求は，必ずといっていいほど発生します。また現実問題として，こうした例外要求を断り続けるのは至難の業です。例外要求を受け入れざるを得ないのが実情です。

　例外要求を受け入れる際，あくまで例外として対応するか，標準サービス・メニューの改変（改善）として，新たな標準サービスのメニューの一つとして組み入れるかという判断が必要です。

　例外扱いとする場合，例外を常に特別扱いして管理運用していかなければなりません。例えば，定期的に要員の入れ替わりが発生する場合，一般に，例外サービスを確実に引き継いでいくのは困難です。一方，標準サービス・メニューとして追加する場合，追加したメニューの利用者が増えることを考えおかなければなりません。

　例外要求を標準サービス・メニューに加え，そのメニューの利用者が増えたとしても，性能管理，キャパシティ管理，構成管理などの観点での影響が容認できるのであれば，正式な標準サービス・メニューとして対応していくことをお勧めします。