今度は西日本でしたね。。日本時間だと3月28日3時～6時の間で西日本リージョンで障害がありました。（こちらから履歴が見れます）

以下とりあえず引用。

3/27

Multiple Azure Services – Japan West – Mitigated

Summary of impact: Between 18:04 and 21:16 UTC on 27 Mar 2017, a subset of customers in Japan West may have experienced degraded performance, network drops or time outs when accessing their Azure resources hosted in this region.

Preliminary root cause: A storage scale unit being added to the Japan West region announced routes that blocked some network connectivity between two datacenters in the region. VMs and services dependent on that connectivity would have experienced restarts or failed connections. Unfortunately, automated recovery did not mitigate the issue. The manual health checks that are conducted around all new cluster additions were performed, but did not detect a problem. This led to a delay in correct root cause analysis and mitigation. 

Mitigation: Engineers isolated the newly deployed scale unit, which mitigated the issue. 

Next steps: Investigations are currently in progress to determine exactly how incorrect routing information was configured into the storage scale unit being added and how that incorrect information escaped the many layers of validations designed to prevent such issues. A full detailed Root Cause Analysis will be published approximately in 72 hours.

3/27

Multiple Azure Services Impacted by Underlying Network Infrastructure Issue – Japan West – Mitigated

Summary of impact: Between 18:04 and 21:16 UTC on 27 Mar 2017, a subset of customers in Japan West may have experienced degraded performance, network drops or time outs when accessing their Azure resources hosted in this region.

Preliminary root cause: A storage scale unit being added to the Japan West region announced routes that blocked some network connectivity between two datacenters in the region. VMs and services dependent on that connectivity would have experienced restarts or failed connections. Unfortunately, automated recovery did not mitigate the issue. The manual health checks that are conducted around all new cluster additions were performed, but did not detect a problem. This led to a delay in correct root cause analysis and mitigation. 

Mitigation: Engineers isolated the newly deployed scale unit, which mitigated the issue. 

Next steps: Investigations are currently in progress to determine exactly how incorrect routing information was configured into the storage scale unit being added and how that incorrect information escaped the many layers of validations designed to prevent such issues. A full detailed Root Cause Analysis will be published approximately in 72 hours.

原因はストレージのスケールユニットを西日本に追加したが、西日本リージョンのデータセンター間のネットワークのルーティングが間違ってブロックされたため依存しているVMなどのサービスが再起動・接続の失敗状態になったということのようです。なお自動復旧では問題が解決しなかった模様。
追加時の手動ヘルスチェックでは問題が検出できなかったともあります。（なので正確な根本分析と対応に時間がかかり遅れたとのこと）

対応として新しく追加したスケールユニットを隔離したことで復旧させたようです。
今後のステップとしては、ストレージのスケールユニット追加時に間違ったルーティング情報がどう設定されてしまったのか、今回のような問題を防ぐための調査などを行っているところということです。

2017.04.01 追記

RCA（根本原因分析）がでてました。

3/27

RCA – Multiple Azure Services – Japan West

Summary of impact: Between 18:04 and 21:16 UTC on 27 Mar 2017, a subset of customers in Japan West experienced Virtual Machine reboots, degraded performance, or connection failures when accessing their Azure resources hosted in Japan West region. During the addition of a storage scale unit to the Japan West region, the scale unit announced routes that blocked some network connectivity between two data centers in the region. Unfortunately, automated recovery did not mitigate the issue, and the manual health checks that were conducted around all new node additions were not performed correctly. Automated alerting detected the drop in availability and engineering teams correlated the issue with the scale unit addition. The new scale unit was re-isolated and which fixed the route advertisement and restored the connectivity between two data centers. A limited subset of customers may have experienced residual impact.

Customer impact: Virtual Machines may have experienced reboots / connectivity issues. App Service \ Web Apps customers may have received HTTP 503 errors or experienced higher latency when accessing App Service deployments hosted in this region. Approximately 5% App Service \ Web Apps customers may have experienced issues until 03:30 UTC on 28 Mar 2017. Azure Search resources may have been unavailable. Attempts to provision new Azure Search services in the region may fail. Redis Cache customers may have been unable to connect to their resources. Azure Monitor customers may have been unable to auto scale and alerting functionality may have failed. Azure Stream Analytics jobs may have experienced failures when attempting to start. All existing Stream Analytics jobs that were in a running state would have been unaffected. VPN Gateway customers may have experienced disconnections during this incident.

Workaround: During this incident, the Japan East region remained fully available, customers’ applications with geo-redundancy (for example, using Traffic Manager to direct requests to a healthy region) would have allowed the application to continue without impact or would have been able to minimize the impact. For further information, please visit http://aka.ms/mspnp for Best Practices for Cloud Applications and Design Patterns, and https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-overview for Traffic Manager.

Root cause and mitigation: A newly built storage scale unit in one data center in the Japan West region was assigned IP addresses that should have only been used in a second data center in the Japan West region. The announcement of these IP addresses activated an aggregate statement on the border routers of the first data center, which then interrupted communication between all VMs in the first data center and VMs with IP addresses belonging to the aggregate in the second data center. The IP addresses were not duplicated, but were sub-prefixes of the same aggregate. The validation code designed to prevent issuance of overlapping IP addresses did not properly check that the IP addresses were not sub-prefixes of the same aggregate and so did not block assignment of these IP addresses to the new storage scale unit. The addition of new capacity to a region has been the cause of outages in the past, so both automated systems and manual checks are used to verify that there is no impact. The tool used in this turn up did not gate its activity based on the presence of a continued healthy signal from the region and so continued the turn up and failed to rollback even after the availability signal fell. The manual checks for health were performed incorrectly after the turn up, as a result the rollback was not initiated. There was a concurrent maintenance to in the Japan West region as part of a network reliability improvement project to remove the aggregates involved in this incident. We have a change advisory board in place to avoid introducing concurrent maintenance in the environment. In this case, there was a process error that resulted in a failure to identify conflicting changes. Had that maintenance completed ahead of the storage scale unit turn up, this incident would not have occurred. Unfortunately, the proximity in time between the incident start and the maintenance to remove the aggregates misled the engineers responding to availability alerts to rollback the aggregate maintenance. This increased the time taken to correctly root cause the incident and rollback the scale unit turn up, delaying the time to mitigate issues.

Next steps: We sincerely apologize for the impact to the affected customers. We are continuously taking steps to improve the Microsoft Azure Platform and our processes to help ensure such incidents do not occur in the future, and in this case it includes (but is not limited to):
1) Remove the aggregate statements from the Japan West region that led to this incident
2) [Complete] Remove all similar aggregate statements from all regions.
3) [In progress] Improve validation checks for IP address assignment to enforce correct behavior even in the presence of aggregate statements.
4) Improve tooling that are used to turn up new scale unit to gate progress on a continuous healthy signal from the region.
5) Azure will continue to automate processes, as well as ensuring that manual health checks are performed correctly.

影響の概要: 西日本の顧客の一部は西日本リージョンでホストされているVMの再起動やパフォーマンス低下、または接続の失敗を経験しました。西日本リージョンにストレージスケールユニットを追加している間、スケールユニットはそのリージョンの2つのデータセンター間のネットワーク接続を遮断したルートをアナウンスしました。残念ながら自動復旧では問題が緩和されず、新しいノードの追加関連で行われた手動ヘルスチェックも正しく実行されませんでした。自動アラートでは可用性の低下が検出され、エンジニアリングチームはこの問題をスケールユニットの追加と関連付けました。新しいスケールユニットは再度分離され、ルートの通知を修正し2つのデータセンター間の接続を復元しました。

顧客への影響: VMは再起動や接続に問題を経験した可能性があります。App Service、Web Appsは西日本リージョンでホストされているApp ServiceのデプロイにアクセスするとHTTP 503エラーを受信したか、遅延が長くなっている可能性があります。約5%のApp Service・Web Appsユーザーは3月28日3時30分（UTC）まで問題が継続した可能性があります。西日本リージョンで新しいAzure Searchサービスをプロビジョニングしようとすると失敗することがあります。Redis Cacheのリソースへ接続できなかった可能性があります。Azure Monitorのユーザーがオートスケールすることができず、アラート機能が失敗した可能性があります。Azure Stream Analyticsジョブは開始しようとすると失敗した可能性があります。実行中であった既存のすべてのStream Analyticsジョブは影響を受けませんでした。 VPN Gatewayのお客様はこの問題の発生時に切断された可能性があります。

回避策: このイベントでは東日本リージョンは完全に利用可能でしたが地理的冗長を備えた顧客のアプリケーション（たとえばTraffic Managerを使用して健全なリージョンにリクエストを送信する）により、アプリケーションは影響を受けずに続行でき、影響を最小限に抑えられました。詳細については https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-overview

根本的な原因と緩和: 西日本地域の1つのデータセンターに新たに追加されたストレージスケールユニットには、西日本リージョンの第2のデータセンターでのみ使用されるIPアドレスが割り当てられました。これらのIPアドレスのアナウンスにより、第1データセンターの境界にあるルーター上で集約され、第1データセンター内のすべてのVMと第2データセンター内の集約に属するIPアドレスとの通信が中断されました。IPアドレスは重複しませんでしたが、同じ集約のサブプレフィックスでした。重複するIPアドレスの発行を防止するために設計された検証コードはIPアドレスが同じ集約のサブプレフィックスではないことを適切にチェックしなかったため、これらのIPアドレスの新しいストレージスケールユニットへの割り当てを防止できませんでした。
リージョンに新しい容量を追加することは過去に停電の原因となっていたため、自動システムと手動によるチェックの方法を使用して影響がないことを確認しました。このターンアップで使用されたツールはリージョンからの継続的な健全なシグナルの存在に基づいて活動をゲートでコントロールしなかった領域でターンアップし続け、シグナルが低下した後でもロールバックに失敗しました。ターンアップ後に正常に手動でヘルスチェックが行われたため、ロールバックは開始されませんでした。
このインシデントに関連する集約を削除するネットワーク信頼性向上プロジェクトの一環として西日本リージョンで並行してメンテナンスが行われました。Microsoftは環境における並行保守の導入を避けるために、変更査問委員会を設定しています。この場合、競合する変更を特定できないプロセスエラーが発生しました。ストレージスケールユニットに先立ってメンテナンスが完了していれば、このインシデントは発生していなかったでしょう。残念ながら集約を取り除く付帯的な作業の開始とメンテナンスの間の時間の近接はロールバック集計のメンテナンスへの可用性アラートに対応しているエンジニアに誤りを起こさせました。これは問題の原因を正しく突き止めるのにかかる時間が増加し、スケールユニットがロールバックして問題を緩和するための時間に遅延が発生しました。

次のステップ: Azure Platformとそのプロセスを改善し、将来発生しないようにするために引き続き取り組みます。この場合以下が含まれます。（ただしこれに限定されません）

1) このインシデントに至った西日本リージョンから集約声明（aggregate statements）を取り除く
2) [対応済み] すべてのリージョンから同様の集計声明を取り除く
3) [進行中] IPアドレス割り当ての検証チェックを改善し、集約ステートメントが存在する場合でも正しい動作を強制する
4) リージョンからの継続的な健全な信号のために新しいスケールユニットを進行制御にあげるために使用するツールを改善する
5) Azureはプロセスの自動化を継続し、手動による健全性チェックが正しく行われるようにする。

所感: 「リージョンに新しい容量を追加することは過去に停電の原因となっていたため」って電源不足ってことですよねぇ…あらまぁ。限りあるファシリティでがんばるのは難しいですね。あとやっぱり手動に頼らざるを得ない部分をどうするかですかね。。