自社運用（オンプレミス）のメールシステムからクラウド型メールへ移行する場合、企業のシステム管理者であれば、「システムに問題が生じていないか」「障害が発生しているならどのように対処が進んでいるか」といった情報の提供体制を把握しておきたい。システム運用を外部に委ねるクラウドだけに、システム管理者が自らメールシステムの障害対応に当たることはないが、従業員からのクレームの対処などを考えると、システム稼働状況は常に分かるようにしておきたいものだ。
グーグルの「GoogleApps（Gmail機能を含む複合アプリケーション）」では、システム全体の稼働状況を「Status Dashboard」というWebページで、ほぼリアルタイムに公開している（写真1）。得られる情報は限られるが、不具合が生じた場合に、Google Apps側に障害が発生していることが原因なのか、自社側に問題があるのかを知る目安として使える。
インテグレータによっては、こうした情報を自動的に配信するサポートも行っている。例えば電算システムは、Google Appsの障害情報などを伝える無償のメール配信サービスを2010年10月に開始した。公式情報に限らず、自社で調査した障害の状況や解決情報も案内している。
同じ「99.9％」でも、内容は各社で違う
クラウド型メールのサービス品質を事前に知っておくための情報としてはもう一つ、サービス提供者が公表しているSLAの数値がある。おおむね「稼働率99.9％」が標準的な保証品質だが、詳細に見ていくと、その内容には各社で違いがある。
典型例が「ダウンタイム」の定義だ。保証稼働率を99.9％とするGoogle Apps for Businessの場合、「10分以上Webインタフェースにサーバーから応答できないエラーが起こる割合が、全ユーザーの5％を上回る状態」だ（表1）。裏を返せば、10分未満であれば、応答できない状態が断続的に長時間継続しても、ダウンタイムに計上されないということになる。グーグルは企業ユーザーからこうした指摘を受け、SLA測定方法の変更を予定している。
これに対し、マイクロソフトのクラウド型メール「Exchange Online」も保証稼働率は99.9％だが、こちらは全ユーザーの月間利用時間に対して、ダウンタイムの影響を受けたユーザーの総時間を毎月0.1％以内に抑える、という意味である。仮に10人が1カ月（4万3200分）利用するなら、ダウンタイムは計43.2分以内（単純計算では1人当たり4.32分以内）であることを保証する。
また、Google Apps for Businessにしろ、Exchange Onlineにしろ、システムのメンテナンスなどのための計画的なダウンタイムを年間10時間程度ずつ予定する。両社とも5日前までに顧客に通知。この時間は、SLAで規定する不測のダウンタイムには含まない。
導入済み企業は「障害対応の早さ」を重視
実際には、SLAよりも、障害が起こった際のサポートのほうが重要と考える企業ユーザーは少なくない。Google Appsを採用したユーザーの多くは、「グーグル本体からのサポートがそれほど期待できないことを前提として、問い合わせ対応が素早い、導入実績のあるインテグレータを選んだ」と口をそろえる。
もっとも、インテグレータは障害時のアドバイスはできるが、グーグル内部の再発防止策までは関与できない。つまり、Google Appsのようにクラウド型メールを提供するサービス主体からの直接的なサポートを期待できない場合は、障害時のバックアップ方法まで考えておいたほうがよいだろう。
例えばイタリアンレストラン・チェーンなどの飲食店を運営するワイズテーブルコーポレーションでは、Google Appsへの全面移行後も、「従来使っていたメールホスティングのアカウントを少数残して、いざというときに備えている」（経営企画グループの成清寛隆アシスタントマネジャー、本連載の第4回を参照）。自社のDNSサーバーに登録した「MXレコード（メールサーバーの情報）」と呼ぶ項目を書き換えれば、多少時間はかかるが、送受信サーバーの切り替えは可能である。
