神話 vs 現実：7月19日の障害から学ぶ信頼性の教訓

2024.09.24更新

ニューアーク・リバティー国際空港で午前3時のことでした。眠気に襲われながら搭乗券を受け取るために列に並んでいたところ、チェックイン機のブルースクリーンに遭遇しました。コーヒーが必要だと思い、売店に行くと現金のみの対応でした。

明らかに大規模な障害が発生していたので、すぐにPagerDutyのシステムを確認しました。世界中で、このような大規模な障害は年に何度も発生するため、社内には「『インターネットが壊れた』ダッシュボード」と呼ばれるものがあります。案の定、そのチャートは私だけでなく多くの人が悪い顧客体験をしていることを示していました。しかし、スマートフォンのPagerDutyアプリを確認すると、すべてのシステムは正常でした。安心して、コーヒーを飲みながら読書に戻りました。

そして運命のいたずらか、隣に座っている人が、障害通知を受け取ったようです。しかし、パニックに陥るのではなく、その聞き慣れたPagerDutyの通知音に安心しました。私たちのプラットフォームは、他のすべてが崩壊している状況下で、重要なサービスを稼働し続けるという本来の役割を確実に果たしていることを確信しました。

この瞬間、重要なリーダーシップの教訓が浮き彫りになりました。リーダーとして、自分が連絡不能な状況 – コーヒーもない空港で足止めされているような状況 – でも確実に機能するシステムが必要です。これは顧客に信頼性の高い体験を提供するためです。重要な局面では、単にシステムを持っているだけでなく、システムのシステム – つまり、潜在的な障害に直面しても回復力を確保する技術、プロセス、プロトコルの統合フレームワーク – を持つことが真に重要なのです。

信頼性に関しては一般的な誤解があり、これはしばしば顧客や同業者との会話で表面化します。この考えは、信頼性が単一の特性であるか、単純な冗長性によって達成できるものだと想定しています。バックアップサーバーや冗長クラウドを持つだけで信頼性が確保されると考える人もいますが、現実ははるかに複雑です。

神話#1：冗長性イコール信頼性

信頼性に関する最も根強い神話の1つは、すべてのものを2つ持っていれば安全だというものです。この単純化された見方では、2つのクラウドプロバイダー、2つのサーバー、または2つのデータベースを持つことで、システムが無敵になるはずです。しかし、この考え方は、協調して動作しなければならない複数のシステムを導入する際に生じる複雑さを無視しています。

コンポーネントを増やすことが必ずしもシステムの信頼性を高めるわけではありません。実際、新たな障害ポイントを導入する可能性があります。2つのシステム間に依存関係がある場合、障害の確率は半分に減るのではなく、増加します。現代の相互接続されたシステムの複雑さを加えると、システムの複雑さ自体が最大の信頼性リスクになる可能性があります。

神話#2：障害の防止が唯一の目標

もう1つの一般的な誤解は、信頼性の鍵は障害を完全に防ぐことだというものです。障害を防ぐことができれば、ダウンタイムを心配する必要はないはずです。そう考えがちですが、実際はそうではありません。

残念ながら、どんなに設計が優れていても、障害から完全に免れるシステムはありません。障害が決して発生しないという非現実的な期待でシステムを設計するのではなく、私たちは「障害を想定する」原則の下でシステムを設計し、障害を適切に処理します。このアプローチには、障害マスキング（障害が発生したコンポーネントを分離し、全体のシステムに影響を与えないようにする）や、影響範囲の限定（障害の影響をインフラストラクチャの小さな管理可能な領域に限定する）などの安全策の実装が含まれます。

このアプローチの良い例が、私たちの「Failure Friday」の取り組みです。私たちは、ステージング環境だけでなく、本番環境でも定期的に障害モードをテストしています。サーバーのクラッシュからネットワーク障害まで、さまざまな障害シナリオをシミュレートして、実際の条件下でシステムが回復力を持つことを確認しています。この取り組みにより、7月19日のトラフィック増加を大きな障害なく自信を持って処理することができました。

神話#3：対応者が多いほど解決が早い

危機の際、多くの組織は、インシデント対応プロセスに多くの人を投入すれば、それだけ早く解決できると考えています。より多くの頭脳がより速い問題解決につながるはずだという論理的な仮定です。

しかし、現実はしばしばその逆です。インシデントに対応者を多く追加しすぎると、混乱、重複作業、コミュニケーションのボトルネックにつながる可能性があります。PagerDutyでは、単に人間の対応者を増やすよりも、自動化がしばしば解決時間を改善するより効果的な方法であることを学びました。

7月の障害の際、ある顧客が私たちにこのアプローチを完璧に示すエピソードを共有してくれました。彼らのチームは障害が発生したときにちょうどAIOpsの実装を始めたところでした。AIOps導入前は、管理可能な量のシステムノイズに対処していましたが、障害時にはそのノイズが圧倒的な量のアラートに膨れ上がりました。しかし、アラート管理を自動化していたため、ノイズをすばやく切り分け、問題の根本原因を特定することができました。これにより、人間の対応者は優先度の高いインシデントに集中し、重要なシステムの復旧を確実に行うことができました。

回復力は多くの要素の総和

結局のところ、信頼性は一度達成して終わりというものではなく、継続的なプロセスです。そのため、私たちは自動化、AI駆動のインサイト、継続的なテストに投資してきました。

私たちの取り組みは成果を上げました。障害のピーク時には、プラットフォームは1分間に60,000以上の通知を配信し、それでも平均通知時間は15秒以内に収まりました。内部のSLOを維持し、インシデント量が192%増加したにもかかわらず、顧客は通常の日と比べてわずか29%の遅れでインシデントを解決しました。また、モバイルとSlackに設定された対応者の場合、通知は500ミリ秒未満、文字通り一瞬で行われました。

システム設計の選択において、他に何ができるでしょうか？私たちは、システム設計において信頼性の詳細なフレームワークに従うよう努めています。つまり、プロセスとシステム設計の両方で障害を避けるために多くのことを行ったとしても、物事は依然として失敗します。ある程度の障害が避けられないと仮定すれば、回復力を生み出すための他の戦略を取ることができます。例えば、障害をマスクすることができます。この戦略の実例には、クラスタオーケストレーション、自動フェイルオーバー、状態レプリケーション、リーダー選出などがあります。PagerDutyでは、多くのシステムがこれらの戦略を採用しており、さらに定期的な障害テストを本番環境で実施して、設計通りに機能することを確認しています。

時には、障害のマスキングが常に可能というわけではなく、すべてのユースケースをカバーできないこともあります。次にできることは、障害の影響範囲を限定することです。これを行う最良かつ最も簡単な方法は、カナリアリリースと段階的なロールアウト(phased rollouts)です。私たちは、インフラストラクチャの変更であれ機能リリースであれ、すべての変更に対して段階的なロールアウトを行い、トラフィックを徐々に増やしています。

障害を回避、マスク、または限定できない場合、次の目標は迅速に修正することです。ここで明らかに、優れた対応力のあるインシデント対応プロセスが重要になります。システムを素早く回復させることができれば、それだけ早く顧客とミッションのためのサービスを復旧できます。

ここでのもう1つのユースケースは、インシデント中に変更を素早くロールバックできる高速ロールバックです。これはカナリアリリースの素晴らしい補完タスクです。具体例として：PagerDutyの全チームは、5分以内に実行できるロールバックメカニズムを持つことが要求されています。このような種類の自動化は、インシデントへの対応を迅速化し、顧客の重要なシステムを稼働し続けるのに役立ちます。また、私はこれを、自動化ツールを使用して信頼性と対応性を向上させるために、どの組織でも取れる測定可能で実行しやすい最初のステップとしてよく共有しています – すべてのチームに変更イベント、カナリアリリース、高速ロールバックを実装させ、インシデント対応プロセス中に、インシデントコマンダーが最近の変更（変更イベントを通じて相関付けられた）によってインシデントが引き起こされたと思われる場合にチームのロールバックスクリプトを実行する権限を与えます。社内では、これらのツールを利用できることで、少なくとも年に6回ほど、大きなインシデントになる前に問題を捉え、影響を限定し、ロールバックして復旧することができています。

7月19日の障害から学んだ教訓は、真の信頼性が単一のコンポーネントや即席の解決策ではないことを再確認させてくれます。それは、障害を想定し、迅速に回復するように設計された、回復力のあるシステムのシステムを構築することです。私たちは、顧客がこのレベルの回復力を達成するのを支援することに尽力しており、適切な戦略、ツール、考え方があれば、どの組織でも真の運用信頼性を達成できると信じています – 将来どのような課題が待ち受けていても。

原文: Myth vs. Reality: Lessons in Reliability from the July 19 Outage