鍋綿ブログ

C#・SharePoint・SharePoint Framework・Office365を中心に扱うブログです。

2019/11/20 AzureとOffice 365で大規模な障害が発生(11/21 復旧)

11/19(火)に大規模なメール障害から復旧したばかりのOffice 365ですが、翌11/20(水)に更に大規模な障害を起こしてしまいました。Azureの内部ネットワークの更新が良くなかったようで、ユーザーからのアクセスが正しくサービスに接続できなかったみたいです。同日昼頃にはサービスが復旧しました。

 

DownDetectorの障害発生マップ(11/20 朝時点)

f:id:micknabewata:20191120105645p:plain

https://downdetector.jp/shougai/windows-azure/mappu/

 

インシデント情報はSNSで得るほうが早かった

障害発生中は、AzureやOffice 365のサービスヘルス画面には現在繋がらない状態でした。Twitterなどで情報収集するほうが早かったですね。

Microsoft 365 Status (@MSFT365Status) | Twitter

 

11/21時点でサービスは復旧済み

2019/11/20 10:35 Microsoftが最初のインシデント情報を発信

2019/11/20 11:56 Microsoftから続報。障害の原因をネットワーク更新と推定し、これを元に戻すことで順次復旧の気配ありとのこと。

2019/11/20 13:38 更に続報。障害の原因をネットワークの更新と断定。変更を元に戻すことによりサービスが正常に復旧することも確認。但し一部ユーザーには依然として影響が残る可能性有とのこと。

 

復旧後の所感

  • SharePointやFlowで構築した社内の諸々もメールもTeamsも一切合切止まったけど業務は意外と回ってた。「システムが止まったらダメ絶対。200%止まらない構成が必要」という顧客要望のうち99%はやはり嘘だった。
  • 業務を何とか回している間にMicrosoft側で障害復旧をしてくれた。その間、ウチの情シスは何もしてない。確かに何も手出し出来ないもどかしさはあるだろうが、社内だけの少ない人員でシステム障害を復旧するよりよっぽど早かったし楽だった。
  • 今年はAWSもAzureも大きな障害に見舞われたが、それでも人は死んでいない。被害は業務の遅れや機会損失など金銭的なもので、これは障害を予防するための投資額と天秤にかけられるべきもの。クラウドのメリットを考えればAzureを卒業するとかAzureが止まっても大丈夫な構成とかは大概の場合は必要ない。
  • 「システムの停止と共に顧客も心肺停止」するくらい大事なシステム(医療機関など?)とか、「災害時の安否確認」などのそもそも基盤がイッちゃってそうな利用シーンを想定するシステムとかでは1つの基盤に依存する構成はダメだってことを再認識した。