Microsoft Azure の CTO である Mark Russinovich 氏は、「障害時のコミュニケーション」を監督する主席プログラム マネージャーの Sami Kubba 氏とともに、「障害時のエクスペリエンス」の向上について投稿しました。これは、クラウド障害で 1 日が台無しになったときに通常は思い浮かぶフレーズではありません。
ルシノビッチ氏は、サービス停止は「テクノロジー業界にとって残念ながら避けられないこと」だと語った。
Azure の信頼性記録は良好です。Russinovich 氏は 2019 年 7 月に「Azure は、グローバル クラウド インフラストラクチャ全体で、コア コンピューティング サービスを平均 99.995% の稼働率で運用しています」と報告しましたが、これらの世界的な数字だけでは全体像はわかりません。
たとえば、2018 年 11 月と 2019 年 10 月に大規模な障害が発生した Azure MFA (多要素認証) の問題は、不均衡な影響を及ぼし、多くのユーザーが電子メール、SharePoint、Teams などの Office 365 サービスを使用できなくなりました。
もう 1 つの例として、Azure DevOps Pipelines などの個別のサービスに障害が発生すると、アプリケーションの展開がブロックされ、一部の顧客に重大な混乱が生じる可能性がありますが、全体的な信頼性の数値にはほとんど反映されません。
障害を完全に回避できない場合、マイクロソフトが最低限できることは、顧客への情報提供を継続することです。ルシノビッチ氏によると、目標は自動化プロセスを通じて15分以内に顧客に通知することです。「AIOps」を用いて異常を検知し、エンジニアと顧客の両方に通知します。理論的には、このアラートプロセスにより、管理者はAzureとソーシャルメディアの両方で検索して、問題がAzure側の問題なのか顧客側の問題なのかを確認するなど、自ら対処する必要なく、問題のアラートを受け取ることができるはずです。
マイクロソフトは、Azureポータルのサービスヘルスが障害情報を確認する場所だと述べています。ただし、ポータル自体が壊れていないことが前提です。
クッバ氏の投稿は、まさにここで重要なヒントを明らかにしました。クッバ氏によると、確認すべき場所はAzureポータルの「サービス正常性」です。Azureの公開ステータスページは「広範囲にわたる障害の通知にのみ使用される」ため、問題の特定には役立たない可能性が高いとのことです。「それにもかかわらず、お客様がAzure上のサービスの正常性を確認するためにAzureステータスページにアクセスするケースが頻繁に発生しています」とクッバ氏は不満を漏らしました。ただし、障害によってポータルへのアクセスがブロックされている場合は、ステータスページを確認するのが適切だと推測されます。クッバ氏によると、それ以外のケースでは「インシデントの95%以上」がステータスページに表示されないため、ステータスページはあまり役に立ちません。
さらに複雑なのは、Azure DevOps（Pipelines が稼働している場所）が Azure ポータルに統合されていないことです。多くの Azure DevOps ユーザーは DevOps ポータルのみを利用しています。そのため、Azure DevOps ステータス ページが別途用意されており、障害追跡のためにブックマーク登録が必要な 3 番目のサイトとなっています。
もう一つの問題は、管理者からエンドユーザーへの情報の流れです。エンドユーザーは、Azure 上でサービスまたはサービスの一部が実行されていることさえ知らない可能性が高いです。影響を受けるのはエンドユーザーであるため、これは管理者が解決すべき課題です。適切なユーザーにメッセージが届くようにサービス正常性アラートを設定し、それをエンドユーザーとの効果的なコミュニケーションにつなげる必要があります。
クッバ氏はまた、「信頼性は共同責任である」と述べ、顧客は信頼性の高いアプリケーションを設計することで、サービス停止の影響を軽減、あるいは完全に排除できると指摘しました。これは微妙な問題です。顧客がビジネスクリティカルなアプリケーションを単一の仮想マシン（VM）上で実行し、それがダウンした場合、適切なアーキテクチャを使用していなかった顧客の責任となります。しかし、だからといって、マイクロソフトが信頼性の低いVMサービスをホストすることが正当化されるわけではありません。®
