「残念ながら、テクノロジ業界において、障害などのサービス インシデントは避けられません。マイクロソフトが Microsoft Azure クラウド プラットフォームの信頼性を向上させ続けているのは言うまでもありません。また、大半のお客様とのサービス レベル アグリーメント (SLA) において、SLA 以上のサービス レベルを実現し、進化するツールやトレーニングに投資し続けることで、お客様がミッション クリティカルなシステムを自信を持って容易に設計および運用できるようにしています。

しかし、これらの取り組みを実施していても、マイクロソフトの運用規模や変化のペースを踏まえると、残念ながら障害を完全に回避するのは不可能であるという事実を認めざるを得ません。昨今、マイクロソフトは、影響を受けるすべてのお客様とパートナー様が何が起きているのかを確実に把握できるように、可能な限りオープンで透明性が保たれるよう努めています。「Advancing Reliability」ブログ シリーズの一部である本稿の執筆にあたり、障害時の通知プロセスを監督するプリンシパル プログラム マネージャーである Sami Kubba に、マイクロソフトが障害時のエクスペリエンスを向上させ続けるために行っている投資について大まかに解説してもらいました」 - Azure 担当 CTO、Mark Russinovich

---

 

マイクロソフトは、クラウド業界において、お客様と自社プラットフォームのセキュリティを維持し、お客様のエクスペリエンスを常に最適化しながら、お客様に最新テクノロジを大規模に提供するという方針を掲げています。それを実現するために、Azure には数多くの変更が行われる可能性があり、ごくまれにですが、その変更がお客様に予期しない影響を及ぼすことがあります。本シリーズのブログ記事で既にお話したように、マイクロソフトは変更を重視しており、体系的かつ段階的なアプローチでできる限り慎重に変更を実施するよう徹底しています。

マイクロソフトは、アーキテクチャの設計、運用プロセス、ハードウェアの問題、ソフトウェアの欠陥、および人的要因が合わさってサービス インシデント (障害) を引き起こすおそれのある複雑な方法に内在する不備を特定し続けています (特定しづらい不備もあります)。私たちの業界の現実として、変更による影響は、変更に必然的に伴う問題であると言えるでしょう。マイクロソフトは、障害時の通知について考える際、競うべき相手は他のクラウド プロバイダーではなく、むしろオンプレミス環境であると考えています。オンプレミスでは、変更の時間帯が管理者によって制御されており、管理者は、変更を実施するのに最適な時間を選択し、リスクを管理および監視して、障害が確認された場合は変更を元に戻しています。

同様に、オンプレミス環境で障害が起きた場合、お客様やユーザーは、状況について詳しく把握できていると感じています。リーダーは、問題の把握後、すぐさま障害について十分に把握し、トラブルシューティングのためにサポートにアクセスします。そして、チームやパートナー企業が、問題を理解すると、完全なインシデントの事後レポート (PIR) (旧称: 根本原因分析 (RCA)) を提供できる態勢にあると期待しています。マイクロソフトのデータ分析により、オンプレミスよりもクラウドの方がインシデント軽減までの時間が短いという仮説が裏付けられていますが、問題やそれに関して行える対処方法の把握に関しては、クラウドの障害の方がお客様のストレスが強くなる可能性があります。

マイクロソフトの通知に関する原則の紹介

クラウドの障害時、一部のお客様から、速やかに通知されていないように感じたり、彼らが必要な最新情報を見逃したりしたために、何が起きたのか、そして今後の問題発生を防ぐためにどんな対策が行われているのか十分に把握できていないと感じたというご意見を頂いてきました。これらのご意見に基づき、マイクロソフトは、現在、コミュニケーション戦略の指針となる以下の 5 つの柱に基づいて運用を行っています。これらの 5 つの柱は、Azure portal の Azure Service Health のエクスペリエンスにも影響を及ぼしています。

1. 速度
2. 細分性
3. 検出可能性
4. 等価性
5. 透明性

速度

影響を受けるお客様には、できる限り速やかに通知する必要があります。これは、障害時の通知に関するマイクロソフトの重要な目標でもあります。マイクロソフトは、障害が発生してから 15 分以内に、影響を受けるすべての Azure サブスクリプションに通知することを目標に掲げています。人の力だけではこれを実現できないことは理解しています。(サードパーティの依存関係を含む複雑な相互接続などの問題を適切なエンジニアが軽減する作業に従事するのは言うまでもなく) エンジニアが監視アラートを調査して影響を確認する作業に従事するまでに、既に膨大な時間が過ぎてしまいます。通知が遅れると、お客様は自社側の問題なのか、Azure 側の問題なのかわからないまま、自社環境のトラブルシューティングに無駄な時間を費やしてしまうおそれがあります。反対に、慎重になり過ぎて、お客様への潜在的な影響が疑われるたびに通知すると、お客様が誤通知を数多く受け取ってしまうことにもなりかねません。何より、お客様の環境で問題が起きている場合に、そのような無関係の問題の原因をプラットフォームによって送信された誤通知の内容に由来すると安易に考えてしまうおそれもあります。したがって、通知を迅速かつ正確に行えるようにするための投資が重要になります。

先月、「人工知能による Azure サービス品質の向上: AIOps」の記事でマイクロソフトの継続的な投資について大まかに解説しました。これには、クラウドの障害の自動的な検出、関与、および軽減を強化する取り組みが含まれています。より幅広いこの AIOps プログラムのさまざまな要素が既に運用環境で使用され、お客様のリソースに影響を及ぼしているおそれのある障害についてお客様に通知されています。前四半期の障害時における通知の半数以上がこれらの自動通知を使用して行われました。数多くの Azure サービスにおいて、問題が起きた場合、Service Health を通じて、影響を受けるお客様に 10 分未満の時間で自動通知が送信されます。Service Health は、Azure portal でアクセスするか、構成済みの Service Health アラートを起動させて確認できます。これについては、後ほど詳しく説明します。

この領域への投資によって既にカスタマー エクスペリエンスは向上していますが、マイクロソフトは、人が介入してお客様への影響を確認することなく、影響が出始めてから 15 分未満の間にお客様に通知できるシナリオを引き続き強化していきます。現在はまだ初期段階にありますが、マイクロソフトは、AI ベースの運用によって、影響を受ける関連サービスを自動的に識別し、(サポートされるシナリオにおいて) 軽減後、できる限り速やかに解決の通知を送信するプロセスも強化しています。

細分性

マイクロソフトは、障害によって影響が起きる場合、影響を受けるリソースについてお客様が正確に把握する必要があることを理解しています。特定のリソースの正常性について把握する際に重要となる構成要素の 1 つとして Resource Health シグナルが挙げられます。Resource Health シグナルは、仮想マシン (VM)、SQL Database、ストレージ アカウントなどのリソースが正常な状態であるかどうか確認します。お客様が Resource Health アラートを作成することも可能です。このアラートは、Azure Monitor を活用して、プラットフォーム全体の問題であるか否かを問わず、特定のリソースに問題がある場合に適切なユーザーに通知します。重要な注意点として、Resource Health アラートは、リソースが正常でなくなった場合 (例: ゲスト内から VM が再起動された場合) に起動する場合があり、必ずしも障害などプラットフォームのイベントに関連しているわけではないことが挙げられます。また、お客様はリソースの種類別にまとめられた、関連する Resource Health チェックを確認できます。

マイクロソフトは、Service Health 内で、プラットフォームの障害によって正常な状態でなくなったそれぞれのお客様のリソースを増強および相関付けるために、このテクノロジに基づいて構築を行っています。また、お客様が影響を受けるリソースについて把握するために、必ずしも Service Health にサインインしなくても済むように、そしてもちろん、誰でもプログラムで利用できるように、影響を受けるリソースを通知ペイロードに含める方法も精査しています。

これらすべての取り組みにより、多数のリソースを保有するお客様は、自ら調査を実施することなく、障害によって影響を受けるサービスについてより正確に把握できるようになります。何より、お客様は Logic Apps や Azure Functions とのネイティブ統合機能を使用して、アラートを構築し、これらの Resource Health アラートへの対応をトリガーできます。

検出可能性

マイクロソフトは、障害時の通知に関して、「プッシュ」アプローチと「プル」アプローチの両方をサポートしていますが、適切な情報が適切なユーザーやシステムに自動的にプッシュ送信されるようにお客様が関連アラートを構成することをお勧めします。また、お客様とパートナー様は、障害によって大切なリソースが影響を受けるかどうか確認するために自ら調査を実施する必要はありませんが、マイクロソフトから (お客様が選択した媒体で) 送信する通知を利用して、適宜対応できるようにする必要があります。それでも、お客様は、Azure のサービスの正常性を確認するために、Azure の状態ページに頻繁にアクセスしています。

認証済みのポータル内 Service Health のエクスペリエンスを導入する前は、状態ページが既知のプラットフォームの問題について知る唯一の手段でした。最近では、この公開されている状態ページは、広範な障害 (例: 複数のリージョンおよび/または複数のサービスに影響を及ぼす障害) を通知する目的でしか使用されていないため、お客様が自社に影響を及ぼす潜在的問題に関する情報を求めている場合、こちらでその全情報を確認することはできません。マイクロソフトは、できる限り安全にプラットフォームの変更を展開しているため、障害などの問題の大半は、お客様のサブスクリプションのごく一部にしか影響を及ぼしません。このようなインシデントは、マイクロソフトのインシデントの 95% 以上を占め、こうしたインシデントが起きた場合でも、Service Health を介して、ポータル内で影響を受けるお客様に直接通知されます。

先日、Service Health に「Emerging Issues (新しい問題)」機能も組み込まれました。これにより、公開されている状態ページにインシデントが投稿されていて、影響を受けるお客様の特定とそのようなお客様への通知がまだ行われていない場合でも、ユーザーは Service Health を介して、ポータル内で同じ情報を確認できるため、状態ページにアクセスしなくても、すべての関連情報を入手できるようになります。マイクロソフトは、すべての Azure ユーザーに対して、サービス インシデントに関する情報を入手するための "ワンストップ ショップ" として Service Health を利用することをお勧めしています。これにより、影響を及ぼす問題を確認し、影響を受けるサブスクリプションやリソースについて把握して、インシデントが状態ページに投稿されているが影響を及ぼさないといった場合に誤った関連付けを行うリスクを回避できます。

検出可能性の原理からさらに重要なこととして、お客様は Service Health 内から、Azure Monitor との統合を活用したプッシュ通知機能である Service Health アラートを作成できます。この手段により、お客様とパートナー様は、通知を受け取る必要があるユーザー、および最適な通知方法 (例: 電子メール、SMS、LogicApp、および/または ServiceNow、PagerDuty、Ops Genie などのサービス管理ツールに統合できる Webhook) に基づいて、関連する通知を構成できます。

シンプルなアラートの利用を開始するには、すべての通知を、単一の配布リストに電子メールで送信することを検討します。これを次のレベルに引き上げるには、ユース ケースごとに異なる Service Health アラートを構成することを検討します。たとえば、運用環境の問題についてはすべて ServiceNow に通知し、開発およびテスト環境や運用前環境の問題については関連する開発者チームに電子メールで通知するだけにして、特定のサブスクリプションのすべての問題については主要ユーザーにテキスト メッセージを送信するといった方法が考えられます。これらはすべて完全にカスタマイズ可能であるため、適切なユーザーに適切な方法で確実に通知できます。

等価性

すべての Azure ユーザーが知っておくべきことがあります。それは、Service Health にアクセスすれば、サービスに影響を及ぼすイベントに関する情報をすべて入手できるということです。まず、このエクスペリエンスがすべてのさまざまな Azure サービス間で一貫しており、どのサービスについても、Service Health を使用してすべての問題が通知されます。単純そうに聞こえますが、マイクロソフトは、これを複雑にするいくつかの固有のシナリオに対応すべく今もなお取り組んでいます。たとえば、Azure DevOps を使用している大半のユーザーは、Azure portal を利用していません。DevOps は独自の認証済みの Service Health のエクスペリエンスを備えていないため、公開されている状態ページに掲載するほどではない小規模な DevOps の障害については、影響を受けるお客様に直接最新情報を通知できません。このようなシナリオに対応するために、小規模な DevOps の障害についても DevOps コミュニティに直接通知できる Azure DevOps の状態 (英語) ページを立ち上げました。

次に、Service Health のエクスペリエンスは、Azure 全体にわたって影響を及ぼすイベントをすべて通知するよう設計されています。これには、メンテナンス イベントやサービスまたは機能の提供終了が含まれ、広範な障害と 1 つのサブスクリプションにしか影響を及ぼさない局地的な問題の両方が含まれます。どのような影響でも (潜在的な影響、実際の影響、近い将来の影響を問わず)、お客様が Azure の全サービスで同じエクスペリエンスを期待でき、予測可能なアクション計画を準備できるようにすることが不可欠です。

最後に、マイクロソフトは、この柱の原則を強化し、他のマイクロソフトのクラウド製品へと拡大すべく取り組んでいます。マイクロソフトは、Azure、Microsoft 365、および Power Platform など、異なるクラウド製品のナビゲーションがあたかも 3 つの異なる企業のテクノロジのナビゲーションのようになっている場合があることを認識しています。マイクロソフトは、未来を見据えながら、これらの製品を調和させ、より一貫性の高い、クラス最高のエクスペリエンスを実現する取り組みに力を入れています。

透明性

「Advancing Reliability」ブログ シリーズで何度もお話しているように、マイクロソフトは、信頼は勝ち取るものであり、維持する必要があることを理解しています。また、障害が起きた際に、何が起きているか、何がわかっているか、そして何がわかっていないかについて透明性があることが非常に重要である点も理解しています。クラウドは、ブラックボックスのようなものであってはなりません。サービスの問題発生中は、マイクロソフトは、影響を受けるすべてのお客様とパートナー様に定期的に通知します。多くの場合、問題の調査の初期段階において、マイクロソフトが詳しい状況を把握するまで、更新される情報が詳細でないこともあります。マイクロソフトは具体的な最新情報を共有できるよう努めていますが、お客様が障害時にこれらの最新情報に基づいてビジネスの意思決定を行うことを理解しているため、通常、憶測は共有しないよう心掛けています。

また、お客様への影響が軽減されても、障害が終わるわけではありません。問題の原因の複雑さに関してまだ新たに何かわかる可能性もあるため、軽減時または軽減後に送信される通知については、何が起きたのかかなり簡潔に要約されているだけの場合もあります。重大なインシデントの場合、問題の原因について詳しく把握した後、通常 3 日以内に PIR でフォローアップします。

少数のサブスクリプションにしか影響を与えていないと思われるインシデントの場合、お客様とパートナー様は、インシデントの PIR を要求することで、Service Health 内で詳細情報を要求できます。過去にお客様から PIR の透明性をさらに向上させてほしいというフィードバックを頂きました。そこで、マイクロソフトは、問題の影響や、将来のリスクを軽減させるマイクロソフトの次のステップなど、できる限り詳細な情報を提供するようインシデント管理者と通知管理者に継続的に促しています。今後、こうした問題が起こる可能性や問題の影響を小さくすることができれば理想的です。

私たちの業界はサービスの障害による影響を完全には免れることはできませんが、マイクロソフトはあらゆる機会を活用して、何が起きたのか包括的に把握し、わかったことを共有しています。マイクロソフトが特に注目している将来の投資領域の 1 つとして、PIR の次のステップで大まかに示されている取り組みの進捗状況に関する最新情報を最適な方法で常にお客様に提供し続ける手段が挙げられます。次のステップで内部の修復項目と外部の取り組みを結び付けることで、お客様とパートナー様は、修正措置を確実に講じるためにエンジニアリング チームが行っている取り組みの進捗状況を追跡することが可能になります。

マイクロソフトがより多くのことを学び、これらの 5 つの柱を支えるプログラムに投資し続ける中、あらゆるシナリオ (障害、メンテナンス、サービスの提供終了、正常性に関するアドバイス) を網羅するマイクロソフトの通知は今後も進化し続けます。

信頼性 = 責任の共有

Azure プラットフォーム自体の信頼性についてはマイクロソフトが責任を負いますが、クラウド アプリケーションの信頼性についてはお客様とパートナー様が責任を負います。その一例として、各ワークロードの要件に基づいたアーキテクチャのベスト プラクティスの使用が挙げられます。クラウドでの信頼性の高いアプリケーションの構築は、従来のアプリケーション開発とは異なります。従来、アプリケーション プラットフォーム全体の障害が発生するリスクを最小限に抑えるために、さまざまなレベルの、冗長な、よりハイエンドのハードウェアを購入されていたかもしれません。クラウドでは、障害はいずれ起きるという前提で考えます。既に何回かお話しているように、すべての障害を防ぐのは絶対に不可能です。マイクロソフトも障害を防ぐよう努めていますが、お客様も、クラウドで信頼性の高いアプリケーションを構築する際、あるコンポーネントで問題が発生した場合にその影響を最小限に抑えることを目標にする必要があります。

これを実現するために、マイクロソフトは、先日、ワークロードの品質向上に使用できる一連の基本原則となる Microsoft Azure Well-Architected Framework を立ち上げました。信頼性は、コストの最適化、オペレーショナル エクセレンス、パフォーマンス効率、およびセキュリティとともに、アーキテクチャの卓越性を支える 5 つの柱の 1 つです。既に Azure でワークロードを実行しており、これらの領域の 1 つまたは複数のベスト プラクティスにどの程度準拠しているか評価したい場合は、「Microsoft Azure Well-Architected Review (英語)」を参照してください。

特に、信頼性の柱では、信頼性の高い Azure アプリケーションを構築するための 6 つの手順が示されています。まず、分解したワークロードやビジネス ニーズに基づいて可用性と回復の要件を定義します。次に、アーキテクチャのベスト プラクティスを使用して、提案された/既存のアーキテクチャの想定される障害点を明らかにし、アプリケーションの障害への対応方法を決定します。次に、シミュレーションと強制フェールオーバーによるテストを実施して、さまざまな障害の検出と回復をテストします。次に、信頼性の高い反復可能なプロセスを使用して、一貫性のある方法でアプリケーションを展開します。次に、アプリケーションの正常性を監視して障害を検出し、潜在的障害の指標を監視して、アプリケーションの正常性を評価します。最後に、確立された戦略に基づいて最適な対処方法を決定し、障害と災害に対応します。

障害時の通知という中核トピックに話を戻します。マイクロソフトは、各サービス インシデント直後の PIR に、関連する Well-Architected ガイダンスを採り入れる取り組みを実施しています。重要なワークロードを実行しているお客様は、信頼性を向上させ、特定の障害による影響を回避したり、小さくしたりする具体的な手順について知ることが可能になります。たとえば、障害の影響を受けるのが 1 つの可用性ゾーン内のリソースだけである場合、マイクロソフトは、PIR の一部としてこれを通知し、影響を受けるお客様に重要なワークロードについてゾーン冗長を検討するよう促します。

今後

障害などのサービス インシデント時およびサービス インシデント後における Azure の通知アプローチについて大まかに解説しました。マイクロソフトは、5 つの通知の柱に関して透明性を保ち、現在までの進捗状況と継続的に投資している領域の両方について説明したいと考えています。マイクロソフトのエンジニアリング チームが各インシデントから学ぶことでプラットフォームの信頼性を向上できるよう努めるのと同様に、マイクロソフトの通知チームも各インシデントから学ぶことで透明性を向上させ、情報に基づいた意思決定を行えるように適切な詳細情報をお客様とパートナー様に提供し、こうした困難な状況においてもお客様とパートナー様をできる限りサポートできるよう努めています。

マイクロソフトは、この領域の継続的な改善のために適切な投資を行っていると自負していますが、マイクロソフトの通知がうまく機能しているかどうかについてフィードバックを頂ければ幸いです。マイクロソフトが公開している各 PIR の最後には、Azure のインシデントの事後アンケート (英語) が含まれています。マイクロソフトは、お客様とパートナー様から学び、適切な領域に焦点が置かれているかどうか検証し、エクスペリエンスを向上させ続けるために、すべての回答を確認するよう努めています。

マイクロソフトは、アーキテクチャの設計、運用プロセス、ハードウェアの問題、ソフトウェアの欠陥、および人的要因が合わさって障害を引き起こす複雑な状況に内在する (場合によっては難解な) 不備の特定を続けています。信頼は勝ち取るものであり、維持する必要があるため、マイクロソフトは、特に頻繁には起きないけれども避けられないこれらのサービスの問題時に、できる限り透明性を保つよう努めています。