Microsoft 365障害はなぜ長引いたのか？ 原因・タイムラインと「SLAクレジット」請求方法まとめ：Windowsフロントライン（3/3 ページ）

[鈴木淳也（Junya Suzuki），ITmedia]

SLAにおけるサービスクレジットの請求について

　今回の障害は法人向けとコンシューマー向けの両サービスで発生したが、法人向けではライセンス規約にSLAがあり、約束された稼働率を実際のサービスが下回ると、ユーザーには「サービスクレジット」を請求する権利が生まれる。

　サービスクレジットとは次回以降の支払いに充当できる“クレジット”であり、サブスクリプションの支払いを通じて実質的な返金を受ける措置だ。

　例えば、Outage.comのデータを参考にすれば、現在のMicrosoft 365の“過去1カ月”の稼働率は98.9％だ。少なくともMicrosoftが規定する「99.9％未満」のサービスクレジット「25％」に相当し、場合によっては「99％未満」の「50％」に相当する可能性もある。

Outage.comが示すMicrosoft 365の“過去31日間”の稼働率は98.9％

今回の障害の発端になったExchange Onlineにおける、稼働率とサービスクレジットの対応

　このサービスクレジットの請求で問題となるのは2点だ。1つは実際に請求の対象になるのかという点、もう1つは請求方法となる。

　まず対象になるかについて、Tech InsiderはOutage.comが出しているダウンタイムの数字から、実際のダウンタイムを最大で460分間と推定している。

　11月は30日あり、同月全体を分に換算すると4万3200分なので、ダウンタイムが460分なら稼働率は約98.94％となる。Exchange Onlineの稼働率の計算式では、ダウンタイムに影響を受けたユーザー数を掛け合わせるが、今回は組織内のほぼ全ユーザーが影響を受けた可能性が高い。

　全ユーザーが対象だったとして計算すると、サービスクレジットは「25％はかなりの確率で対象」となり、「50％はボーダーラインで、Microsoft側の判断も入る」と考えられる。

　どちらかといえば、問題となるのは2つ目の請求方法だ。サービスクレジットの請求は「自己申告制」で、自動的には適用されない。また、障害発生月の翌月末までの申請が求められる（Azureの場合は2カ月）。

　加えて、公式ページの説明にあるように、CSP（Cloud Solution Provider）プログラム経由の契約では、請求は直接プロバイダーまたは間接プロバイダーからしか受け付けていない。そのため、システムをCSPなどのSIer経由で導入している企業は、それらの業者を通じて請求することになる。

　一方、Microsoft 365 BusinessなどのSMB向けサービスをクレジットカードなどで直接契約している場合は、契約者本人が申請する。

　既に今回の障害に対するサービスクレジットの請求について、公式サイトで質問が投稿されているケースも見受けられる。

　自身で直接請求する場合は、Microsoft 365の管理センターを通じてインシデント番号「EX1550543」と「MO1550821」を提示しつつ、障害の影響を受けた開始時刻と終了時刻、対象のサービス、具体的な影響内容、証拠となるスクリーンショットやログ、エラーメッセージなどを添えてリクエストする。

　請求対象になるかは、基本的に影響を受けたサービスごとに判定される。そのため、今回のケースではExchange Onlineの「EX1550543」と、それ以外のMicrosoft 365関連サービスの「MO1550821」の両方のインシデント番号が必要となる。

　通常、「MO1550821」のようなアドバイザリのカテゴリーは請求対象とならないが、今回は関連インシデントが全てこの中に含まれるため、対象に含めておいた方がいいだろう。