日本国内でも多くの企業が利用しているマイクロソフト社が提供するOffice365。先月は大規模なサービス障害が発生し、テレビでも放送される事態となった。免許制の事業である通信キャリアのサービス障害がテレビ報道されるのは当然だが、一企業が提供するクラウドサービスのサービス障害をNHK等が報道する事態になるというのは非常にレアなケースである。このことから、Office365の障害がどれだけ国内企業へ影響をもたらすか、影響の大きさをうかがい知ることが出来る。

■Office365等のサービス障害の確認方法

　Office365のサービス障害が発生した時に、以外と知られていなかったのが、Office365のサービス障害のステータスを確認する方法だ。通常であれば、Office365の管理コンソールから確認可能だが、サービス障害時にOffice365自体にログイン出来なくなることも多々ある。そのため、マイクロソフトはOffice365の管理コンソールにアクセス出来なくなった時でも、Office365のステータスを確認する方法を提供している。

• ウェブサイト:Microsoft 365 Service health status
• Twitterアカウント:@MSFT365Status

ウェブサイト版は現時点で発生しているトラブルを表示する、過去のトラブルは確認出来ない。Twitterアカウントはトラブル発生の度に投稿されるため、過去に遡ってどういったトラブルが起きていたか遡ることが出来る。

■@MSFT365Statusの投稿からサービス障害履歴を作成

　海外のニュースサイト等を見ているとOffice365関連のサービス障害を目にする機会が増えてきた。Office365は世界中でサービス提供を行っているため、日本でトラブルが発生していなくても、他の国でトラブルが発生しているということがある。全体としてOffice365を含むMS365がどの程度サービス障害を発生させているのか?が気になり、Twitterアカウント@MSFT365Statusの投稿を基に調べてみることにした。その結果がこのグラフだ。

　横軸は時間軸で、縦軸はSharePointやOneDriveといったサービス単位で各月毎のサービス障害合計となっている。なお、@MSFT365Statusの投稿が2019年3月5日からとなっているので、それより以前のデータは含んでいない。

　SharePointやOneDriveといった個々のサービスを示す障害はそのサービスに対するサービス影響だが、水色のMS365というものはOffice365を含むWindowsやモバイル・セキュリティ等のソリューションも含んだより広い範囲でのサービス障害であったことを示している。MS365のトラブルが発生している場合には、MS365に含まれる複数のサービスにトラブルが発生していることが多く、Office365の管理コンソール等にもアクセス出来なくなる可能性がある。

■単一プラットフォームへの依存度を高めるリスク

　日本で大きく報道されたのは11月だが、他国も含めれば毎月かなりの数のサービス障害が起きていることがわかる。そして、海外のニュースサイトを見ていると、日本で起きた障害と同程度の影響をもたらしていたケースも少なくない。特にMFAと呼ばれる2要素認証に関するトラブルの場合は、認証でのトラブルとなるので、ログインすら出来なくなるため影響範囲も大きく海外のニュースサイトでは多くののメディアが取り上げていた。(実は2018年にもMFAに関するトラブルが発生している)

　最近はOffice365からAzureへとクラウド利用を拡大、更にAzureの認証機能を利用したゼロトラスト・セキュリティへと、マイクロソフト製品への依存度をOfficeだけでなく、IaaSや認証基盤にまで拡大しようと検討する企業も増えてきていると感じる。筆者も「全部マイクロソフト製品で固めたら管理が楽だし、設定も楽」というような意見も耳にする。

　筆者がアプライアンス製品を使ってインフラを構築していた時代には、SPOF(Single Point of Failure)を作らない、ようは一つの機械やシステムが故障すれば全てが停止するような、単一障害箇所を作らないというのはインフラ設計の基礎として考えられていた。しかし、最近は盲目的に「クラウドは安全」「クラウドは止まらない」など過信されることが多いのか、マイクロソフトやアマゾンといった巨大プラットフォームに依存しようとしするシステム管理者が増えてきているように思う。それは非常にリスクを高める行為であると、筆者は考える。

■クラウドは責任共有モデル。常に代替案を

　クラウドは責任共有モデルであり、クラウドサービスプロパイダーが責任を持つ部分も有れば、利用者が責任を持たなければならない部分もあり、クラウドサービスプロパイダーに全ての責任を丸投げしてはなりませんよ、という考え方に基づいている。安易に単独のプラットフォームへの依存度を高める行為は、クラウドサービスプロパイダーがトラブルを起こした時の代替案を利用者が考えるという責任を放棄する考えに他ならない。

　実際、11月のOffice365の障害発生時には、メールもTeamsも利用できなくなり、多くのシステム管理者が単一プラットフォームへ依存することのリスクを痛感したのではないだろうか。勿論そうは言ってもOffice365に代わるクラウドサービスはそうそう無いのも実情であり、変えたくても変えれないというのも事実だろう。

　だが、だからといって全てをマイクロソフトに依存するというのは、サービス障害の発生頻度から見ても万全とは言えないし、依存度が高まれば契約更新時の値上げリスクも考慮しなければならない。メーカーに対して交渉力を維持するといった観点からも、代替案は常に考慮しておく必要があるだろう。

　例えばコストはかかるが、Office365 + Boxや、Office365 + Slack等で、Office365の主要な機能が利用不能になった場合も考慮し、代替案も検討しておくべきだろう。

　特にマイクロソフトサービス以外への認証機能をAzureADで実行するという考え方は、AzureADやMFA等の認証機能にトラブルが発生した場合には、認証機能を連携させているBoxやSlack等も利用不可となってしまうため、影響範囲、ビジネス継続リスクも考慮して検討する必要があるだろう。