［ストレージ・アーキテクトへの道］第10回ベンダー技術者との上手な付き合い方

　ストレージ基盤を構築・運用するには，ベンダー技術者の協力が欠かせません。その協力は，要件定義から設計，導入，運用，保守のすべてのフェーズにかかわってきます。ストレージ基盤を有効に活用するにはベンダーと上手に付き合っていくことが求められますが，現実にはベンダー技術者とのやり取りで何かしらの苦労を経験したことがある人がほとんどだと思います。

　システムを長く運用していれば，必ずといっていいほど問題に遭遇します。そうした問題に対する解決策を探るなかで学習し，同じ徹を踏まないように工夫します。そうした積み重ねがあると，効率のよいITシステムの運用が可能になります。そこで今回は，ストレージ基盤の構築・運用にまつわるベンダーとの間の問題のうち，よく見かける問題を紹介します。

問題１　ストレージ要件を決められない

　新しいシステムを構築する際，ディスク入出力の特性や，求められる処理性能を判断できず，ストレージ要件を決められない場合があります。

　たいていのストレージ・ベンダーは，一般的なサーバーやミドルウエア，主要なERPパッケージ・ソフトに関する実績やナレッジを持っています。予定しているシステム構成，設計，規模をストレージ・ベンダーに伝えれば，ある程度のストレージ要件を決めることができます。

　一方で，自社開発のアプリケーションなど，稼働させてみないと要件をまとめられないシステムもあります。そのときは，短期間であればストレージ・ベンダーの検証環境を利用して動作検証したり，選定対象の機器を一定期間貸し出してもらって動作検証したりすることを検討しましょう。

　新システムのストレージ要件を伝える場合には，そのシステムにとって重要な項目は何かを伝えることが重要です。ストレージ基盤では，容量，性能，可用性，バックアップ要件などが代表的な項目です。何を重視するシステムかによって選定する対象の機器や構成が大きく異なります。

問題２　作業内容と契約が合っていない

　ストレージ・ベンダーに作業を発注する場合，その作業によって適切な契約形態が違ってきます。作業に合わない契約形態はトラブルのもとです。

　例えば，システム構成が固定せず，何度もトライ＆エラーを繰り返す可能性のあるプロジェクトの場合，請負契約だとプロジェクト期間中のスコープの変更が制限されてしまう場合があります。このような場合，可能であれば準委任契約などでの契約の方がスムーズに進めることができます。

　そのほか準委任契約に適しているのは，パフォーマンス・チューニングです。この作業は，設計，導入，テスト，評価というサイクルを，基本的には求められる性能に達するまで繰り返します。また，新しいシステムの場合，ディスク入出力特性が変化する可能性があり，ストレージの構成も決まらないことがあります。このような場合も，一般的には準委任契約の方が向いています。

　請負契約が適しているのは，共用ストレージに対する単純な新規サーバーの接続や，容量の増設の場合などです。

問題３　伝達ミス

　守秘義務やセキュリティ・ポリシー，変更リリース管理などは，それぞれの企業でルールがあるものです。それらをストレージ・ベンダーの技術者に口頭で説明しようとすると，担当者が変わるたびに毎回同じ説明をしなければなりません。口頭で説明すると伝え忘れによって問題を起こすこともあります。

　例えば，障害発生時にデータセンターへの入館申請が提出されずベンダーの保守エンジニアの作業開始が遅れたり，変更管理プロセスを通さずに作業したために別のシステムの業務に影響を与えたり，ということが散見されます。こうした伝達ミスをなくすには，当たり前のことですが，文書として資料を作っておくことです。

　伝達ミスをなくすためにほかに作成する主な資料は，システム導入時に担当者などにヒアリングしたものをまとめた「ヒアリング・シート」や，ストレージの各種設定に関する資料があります。導入時に使用するヒアリング・シートは，必要な情報を漏れなく伝えるために効果的です。

　ストレージ基盤の各種設定情報を文書に残しておけば，設定内容が正しいことを後から確認できますし，将来，「前のストレージ筐体と同じ設定でお願いします」という依頼を受けても確実に設定できます。

　実際に運用が始まってから設定の違いが判明すると，変更管理やリリース管理でさらに余計な工数がかかってしまいます。本来の設定に戻すためにデータ移行が発生し，サービス停止やデータ移行の確認が発生するなどサービスへの影響も発生する可能性があります。ストレージの設定に関する資料は記録としてきちんと保存しましょう。

問題４　障害に対する認識に違い

　障害の種類ごとに，重要度についてコンセンサスを取っておくことが重要です。そうしておかないと，緊急対応をしてほしいのにそうではない対応をされたり，またはその逆のケースも考えられます。

　例えば，バックアップ・サーバーが停止した場合の重要度は組織によって全く異なります。バックアップをサービスとして行っている場合は重要障害になりますが，データへのアクセスに影響がなければすぐに復旧させなくてもよいというケースもあります。

　業務システムへの影響度合いやSLAに基づいて重要度や緊急度を定め，障害が発生したときの目標復旧時間を共有します。こうしておけば，ITサービス部門とベンダーが，障害に対して同じ視点で対応できるようになります。

問題５　知識不足でプロジェクトが手戻りに

　ストレージ・ベンダーと上手に付き合うには，発注する側も一定のスキルを持つ必要があります。ベースとなる知識がない場合，プロジェクトが進んでから要件などの不備に気付き，手戻りが発生してしまうこともあります。

　ストレージ製品の特徴や仕様などをしっかりと把握することで，ストレージ基盤をより活用し，無駄の少ないプロジェクト運営が可能になります。また，ストレージ基盤を最適に利用するチューニングでは，データベースやミドルウエアといった上位層の知識はもちろん，ファイバ・チャネルやSCSIの動作仕様を理解しておいた方が良い場合もあります。