Slack クラウド依存障害の説明責任分析

要約

Slack のエンジニアリングブログによると、VPC を接続する AWS Transit Gateway が休暇明けの急激なトラフィック増加に十分な速さでスケールしなかった。Slack によれば、AWS のエンジニアが手動で容量を追加した。[1]
ゲートウェイの問題によりパケットロスとレイテンシが発生したが、顧客への影響は Slack の環境内で連鎖的に生じた。依存関係の呼び出しが遅延し、ワーカーが飽和し、インスタンスが交換され、オートスケーリングは最初に CPU 需要の低下を読み取り、その後急成長を要求し、プロビジョニングはリソースとクォータの制限に直面した。[1]
Slack はすべての運用データを失ったわけではない。通常のダッシュボードとアラートは影響を受けたトランジットパスに依存していたため利用できなくなったが、生メトリクスのバックエンド、ログ、コンソール、ステータスページはアクセス可能なままであった。制御の失敗は解釈能力の低下であり、完全な盲目ではなかった。[1]
PST 午前 6 時 57 分、Slack は通常の 99.999% 以上の成功率に対し、99% のメッセージがまだ正常に送信されていると報告した。午前 7 時頃、定例のトラフィックのミニピークが既に劣化したネットワークに達し、サービスは広範囲に使用不能となった。[1][3]
Slack は午前 7 時 1 分から 7 時 15 分の間に 1,200 台の Web サーバーを追加しようとした。多くは完全にプロビジョニングできなかった。プロビジョニングされていないインスタンスはオートスケーリンググループの設定上限を占有し、復旧の試みが別の制約となった。[1]
復旧は段階的に行われた。プロビジョニングサービスは午前 8 時 15 分頃に機能を再開、ほとんどの顧客は午前 9 時 15 分頃にコアサービスを利用可能となり、ネットワークエラーとレイテンシは午前 10 時 40 分に正常に戻った。カレンダー、メール、関連する統合機能は別の復旧経路をたどった。[1][3]
公開記録は、正確な影響を受けたユーザー数、インシデント固有の経済的損失、顧客データの漏洩、法的判断、または表明されたすべての是正措置が完了したという証拠を支持しない。現代の報道は広範なグローバルな混乱とリモートワークへの依存を立証するが、防御可能な総人口は立証しない。[4]-[9][11]-[21]
アカウンタビリティの基準は、同等のトラフィック不連続性の下での制御の証拠である。独立した可観測性、テストされたプロビジョニング、境界のある自動化、可視化されたトランジット容量、リハーサルされた劣化モード、そして複数の制御が同時に失敗した場合に是正措置が機能するという証明。

公開記録が立証するもの

最も強力な技術的説明は Slack 自身のエンジニアリングポストモーテムである。これによると、1 月 4 日は多くのユーザーにとって年初の営業日であった。アジア太平洋地域と欧州・中東の朝のトラフィックは静かだった。状況はアメリカ大陸の朝が始まると変化した。外部監視サービスがエラー率上昇時に Slack にページングし、同社はインシデントプロセスを開始した。[1]

その後、Slack の通常のダッシュボードおよびアラートサービスが利用できなくなった。この詳細は誇張されやすい。メトリクスストレージシステムは直接クエリを受け付け続けており、対応担当者はログ、コンソール、ステータスページを保持していた。同社はすべてのテレメトリを奪われたわけではない。大規模システムの状態を有用な運用信号に圧縮する準備されたビューとアラートを失ったのである。対応担当者は依然として証拠を探すことはできたが、サービスが劣化する中でより多くの手作業を強いられた。[1]

インシデント記録は、PST 午前 6 時頃に散発的なエラーとレイテンシがあったとしている。午前 6 時 57 分、Slack はメッセージの 99% がまだ正常に送信されていると報告した。多くの状況で、99% は正常に近いように聞こえる。しかし、Slack のベースラインは 99.999% 以上であった。1 パーセントポイントの低下は、完全な使用不能になる前から、プラットフォーム規模での障害の大幅な増加を意味していた。午前 7 時頃、Slack の定例の 30 分間のトラフィックミニピークが到来した。パケットロスが悪化し、Web 層からバックエンドサービスへの呼び出しに時間がかかり、ワーカーリソースが飽和し、サービスは広範囲に使用不能となった。[1][3]

根本的なネットワークトリガーは、Slack によれば、過負荷の AWS Transit Gateway であった。Slack は複数の AWS アカウントと Virtual Private Cloud を使用しており、Transit Gateway がそれらの環境間のハブとして機能していた。休暇中のトラフィックは異常に低かった。ユーザーが戻ると、コールドクライアントキャッシュがデータ取得とネットワークトラフィックの急激な増加に寄与した。Slack のサービス提供システムはこのパターンに対応してスケールするように設計されていたが、管理されたトランジット層は十分な速さでスケールしなかった。[1]

Slack によると、AWS の内部監視が AWS エンジニアに警告を発した。AWS は手動でゲートウェイの容量を増加させ、その容量変更は PST 午前 10 時 40 分までにすべてのアベイラビリティーゾーンに到達した。ネットワークエラー率とレイテンシはその後正常に戻った。この説明に使用された記録には独立した AWS のポストモーテムはないため、AWS の監視と介入は、個別に確認された AWS の所見としてではなく、Slack に帰属するものとして提示されている。[1]

顧客向けステータス履歴と現代の報道は、大まかな流れと影響を支持している。これらは接続の問題、遅延または失敗したメッセージ、エラーの増加、広範な使用不能、段階的な復旧を記録している。北米、欧州、その他の地域からの報道は、パンデミック時代のリモートワークとリモートスクールの文脈で障害を説明している。これらの記述は、Slack が業務上重要になっていたことを立証する。しかし、影響を受けた個別ユーザー数や障害の金銭的コストは立証しない。[3]-[9][11]-[18][20][21]

これらの事実は、限定された因果関係の説明を生み出す。管理されたトランジット容量の問題がパケットロスを引き起こした。Slack の内部アーキテクチャと自動化が結果を増幅した。復旧は、AWS がトランジット容量を回復することと、Slack が自身のサービス提供システムとプロビジョニングシステムを十分に健全にすることの両方に依存していた。これは、制御の連鎖を追跡するため、単一の原因帰属よりも強力である。また、法的結論よりも狭い。

事実、推論、不確実性

アカウンタビリティ分析は、事象の事実、技術的解釈、ガバナンスの推奨が同じ証拠的重みを持つかのように書かれると信頼性を失う。このケースでは 3 つの明確なカテゴリが必要である。

確定事実は、インシデント記録によって直接支持される記述である。これには、Slack が説明した過負荷の Transit Gateway、パケットロスとバックエンドのレイテンシ、通常のダッシュボードの障害（直接メトリクスは利用可能であった）、1,200 台の Web サーバー追加の試み、プロビジョニングサービスのオープンファイル制限と AWS クォータ、オートスケーリンググループの上限、AWS による手動容量増加の報告、段階的な復旧時間、Slack が表明した是正措置の方向性が含まれる。[1][3]

分析的推論は、それらの事実を制御の所有権に結びつける。例えば、ダッシュボードとそのデータベースが異なる VPC に配置されたことは、VPC 分離が設計上の誤りであったことを証明しない。しかし、運用上の可観測性が、オペレーターの診断を支援するはずのトランジット依存関係から十分に独立していなかったという推論を支持する。同様に、プロビジョニングバーストの失敗は、オートスケーリングが安全でないことを証明しない。スケーリングロジックは、成功したスケーリングが依存するプロビジョニングパス、クォータ、グループ上限とともにテストされなければならないという、より狭い推論を支持する。

未解決の疑問は、記録が答えを提供しないため未解決のままである。情報源は、ゲートウェイの正確な容量しきい値、Slack の完全なトラフィック予測、Slack と AWS 間の内部サービスレベル契約、インシデント中に下されたすべての決定、または後日のすべての是正措置が実装および検証されたかどうかを示していない。正確な影響を受けた人数、定量化された損失、法的違反、執行結果を立証していない。

この分離は、議論を 2 つの点で制限する。第一に、合理的な制御は、それが障害を軽減できた可能性があるという理由だけで、証明された失敗として扱われるべきではない。第二に、事業者が発表した是正措置は、元のリスクが閉じられたことの証明として扱われるべきではない。この記事は、どの証拠がクロージャーを示すかを特定できるが、そのような証拠が存在すると主張することはできない。

区別は結果バイアスも防ぐ。予期しない条件の組み合わせで合理的なアーキテクチャが失敗することはあり得る。アカウンタビリティは、すべての深刻な結果が事前に明白であったふりをすることを要求しない。制御所有者が依存関係を理解し、信頼できる不連続性をテストし、警告サインに対応し、制限を伝え、同じ相互作用が再発しないという証拠を作成したかどうかを問うことを要求する。

リモートワークが可用性を運用上の依存関係に変えた

障害は、仕事の組織化において異常な時期に発生した。Reuters、Associated Press、Washington Post、Guardian、CBS、Fortune、TechCrunch、専門技術報道は、COVID-19 パンデミックの中で人々が休暇からリモートの仕事や授業に戻っていると説明した。Slack はそれらのユーザーにとって単なる便利な手段ではなかった。多くの組織で、調整、メッセージ、チャンネル、インシデント議論、日々のプレゼンスのための経路となっていた。[4]-[9][11]-[21]

それでも証拠は正確な影響人数を正当化しない。Downdetector に提出された報告数は、影響を受けた Slack ユーザー数ではない。Slack の有料顧客数またはデイリーユーザー数を示す数字は、プラットフォームの規模を示すものであり、インシデントの範囲ではない。世界的なニュース報道は地理的な広がりを確認するが、すべての顧客に対する均一な使用不能を確認するものではない。最も正確な記述は、混乱は広範囲に及び世界的に報告されたが、影響を受けた総人口は証明されていない、というものである。

その限界はガバナンスの問題を減少させない。依存関係は、公的な総数が得られない場合でも重大であり得る。プラットフォームは、その障害が組織の作業調整、問題のエスカレーション、スタッフへの連絡方法を変えるときに、運用上重要になる。尺度はベンダーのユーザー数だけではない。プラットフォームが存在しないときに、そのタイミングと品質が低下する内部プロセスの集合である。

したがって、エンタープライズ顧客にとっての推論は、障害ではなく継続性に関するものである。顧客は Transit Gateway を飽和させたり、Slack のプロビジョニングサービスの制限に達したりする原因を作ったわけではない。しかし、重要な指示、インシデントエスカレーション、カスタマーサポート、経営判断に独立した経路があるかどうかを顧客は管理していた。Slack を 1 つの有用なチャネルとして扱っていた組織は、それを緊急調整のための唯一の実用的なチャネルにすることを許した組織とは異なるエクスポージャーに直面していた。

継続性計画はその区別を維持すべきである。すべての小規模企業がグローバルなコラボレーションプラットフォームを複製することを要求するのは非現実的であろう。最低限の運用モードを特定することは合理的である。スタッフが重要な通知をどのように受け取るか、インシデントブリッジがどこに作成されるか、重要な文書にどのようにアクセスするか、どの顧客チャネルが利用可能か、誰が代替手段を呼び出すことができるか。目的は完全な機能パリティではない。1 つのベンダーの障害が組織の意思決定とコミュニケーション能力を消去するのを防ぐことである。

この顧客側の義務は、責任を Slack や AWS から転嫁するものではない。階層化されたシステムを認識するものである。プロバイダーはサービスを責任持って運用しなければならない。クラウド事業者は販売するサービスを管理しなければならない。顧客は両方に依存することの結果を理解しなければならない。各義務は異なる制御面に従う。

静穏期が不連続性を隠蔽した

トラフィックパターンが重要なのは、インシデントが単純で着実な上昇が明らかな限界を超えたものとして説明されていないからである。休暇中の使用量は異常に低かった。アジア太平洋期間と EMEA の朝は静かだった。その後、アメリカ大陸の朝が多くの人々の仕事復帰とともに急上昇をもたらした。コールドクライアントキャッシュがデータ取得を増加させ、トラフィックの変化に拍車をかけた。Slack のサービス提供システムは容量を追加するように設計されていたが、トランジットハブは十分な速さで応答しなかった。[1]

これは不連続性の問題であった。容量システムはしばしば、1 秒あたりのリクエスト数、帯域幅、CPU、インスタンス数、ストレージなどのボリュームに対して評価される。Slack の説明は、変化の速度と形状が最終的なレベルと同じくらい重要である理由を示している。管理されたコンポーネントは高い定常負荷をサポートしても、長期の trough の後にパケット量が急激に上昇する場合には適切に反応しない可能性がある。顧客システムは最終的な需要を処理できる可能性があるが、劣化したネットワークを介して新しい容量をプロビジョニングできないため、移行中に失敗する可能性がある。

この観察は、開示されたベンチマーク結果ではなく、報告されたシーケンスからの推論である。公開記録は、正確なパケット/秒の曲線やゲートウェイのスケーリングしきい値を提供しない。しかし、低トラフィック期間とそれに続く突然の復帰、コールドキャッシュ、データ取得、トランジット、プロビジョニング、モニタリングへの同時圧力をテストがカバーしていたかどうかを問うことを支持する。

レベルと移行の区別はリスク評価を変える。「サービスは月曜日のトラフィックを処理できるか」とだけ問う容量計画は合格するかもしれないが、より関連性の高い質問は未回答のままである。「すべての依存関係は、必要な速度で休暇トラフィックから月曜日のトラフィックに移行できるか？」前者は静的な目標である。後者は調整された制御テストである。

また、早期警告の解釈方法も変える。午前 6 時 57 分、Slack はまだ 99% のメッセージ成功を報告していた。通常の 99.999% 以上の率と比較して、これはすでに深刻な逸脱であった。表面上高いままの集計値は、急速に進行するテールリスクを隠す可能性がある。オペレーターは、文脈がなければ心強いように見える広範な可用性パーセンテージだけでなく、通常のパフォーマンスと劣化率に関連付けられたしきい値を必要とする。

午前 7 時の 30 分のミニピークは、その後促進剤として機能した。Slack はそれを定期的なものと説明した。ネットワークは定期的な状態ではなかった。通常の需要パルスが劣化した依存関係に遭遇すると、そのパルスは複数のしきい値を同時に超える可能性がある。リトライが増加し、呼び出しが長時間開いたままになり、ワーカープールが満たされ、ヘルスチェックが失敗し、自動化がフリートの変更を開始する。1 つのトラフィックイベントのように見えるものが、制御システムのイベントになる。

アカウンタビリティにとって、実務的な質問は、所有者が移行とその結合効果をテストしたかどうかである。キャッシュをウォームアップし、トランジット容量を事前割り当てし、通常のプロビジョニングをバイパスするテストは、ピークスループットを実証できるかもしれないが、実際の障害モードを見逃す可能性がある。同等負荷の証拠は、低い開始点、増加率、新しい容量を作成するために使用される依存関係を含むシーケンスを再現する必要がある。

パケットロスがサービスカスケードになった

Transit Gateway の飽和は最初のパケットロスを説明するが、その後のすべての失敗を説明するわけではない。Slack の Web 層は、影響を受けたネットワークを経由してバックエンドサービスを呼び出す必要があった。それらの呼び出しが遅くなるにつれて、ワーカーは長く待機し、利用可能なワーカーリソースが満たされた。依存関係に到達できなかったインスタンスは異常としてマークされた。自動化はその後、それらの一部を交換しようとした。[1]

各アクションは個別には理解可能である。ヘルスチェックはサービスを提供できないホストを削除すべきである。オートスケーラーはフリートを調整すべきである。プロビジョニングサービスは新しいインスタンスを構成すべきである。問題は相互作用であった。ホストは必ずしも不良ではなかった。共有ネットワーク状態によって依存関係から隔離されていた。それらを交換するには同じネットワークが必要であった。したがって、制御対応は、既に障害が発生している依存関係からより多くを要求した。

これは重要な分析上の境界を生み出す。記録は、自動化がインシデントを増幅したと言うことを支持する。自動化が元のパケットロスを引き起こしたと言うことは支持しない。トリガーと増幅は異なる。それらを分離しておくことで、責任は制御に従い、多段階の失敗を唯一の原因の探求に変えることなく進むことができる。

また、シーケンスはヘルスが文脈依存的である理由を示している。ホストはマシンとしては正常でも、サービス参加者としては異常であり得る。バックエンドは実行中でも到達不能であり得る。新しく起動されたインスタンスは AWS 上に存在しても、プロビジョニングが不完全なため使用不能であり得る。ダッシュボードがこれらの状態を単一の「正常/異常」ラベルにまとめると、自動化は有用な容量を破壊し、交換需要を生み出し、根本的なネットワーク状態を隠す可能性がある。

説明責任のある設計は、異常の理由を可視化する必要がある。プロセスが停止したのか？ローカルリソースが満たされたのか？依存関係がタイムアウトしたのか？パケットロスがチェックの完了を妨げたのか？症状は地域的か、ゾーン的か、フリート全体か、孤立しているか？異なる答えは異なるアクションを正当化する。ローカルクラッシュは交換を必要とするかもしれない。共有トランジット障害は、インスタンスの保持、チャーン削減、ルート変更、劣化モードへの移行を必要とするかもしれない。

公開記録は、Slack が 2021 年 1 月にそのような区別をすべて利用可能であったかどうかを開示していない。推論は、報告された交換チャーンと、調査中のインスタンスがプロビジョニング解除されたときの SSH セッション喪失に基づいている。その運用上の詳細は、自動化が容量を追加しただけでなく、証拠も削除し、診断を中断したことを示している。[1]

リスクは Slack に固有ではない。自動化されたヘルスチェックと交換を持つ大規模サービスは、ローカルな修復が逆効果になる相関障害に遭遇する可能性がある。教訓は自動化を無効にすることではない。自動化が減速し、状態を保持し、人間の確認を要求し、または一般的な依存関係問題のために設計された障害モードに切り替えるべき条件を定義することである。

その制御の証明には、ヘルスチェック失敗の文書化された分類、交換速度の制限、診断用ホストの保持ルール、共有ネットワーク依存関係が障害を起こしインスタンス自体は無傷のままであるテストが含まれる。これらは提案された証拠基準である。情報源は、Slack が後でそれらのどれを実装したかを立証していない。

オートスケーリングが矛盾するシグナルを生成した

Slack のオートスケーリング動作は、メトリクスが正しくても間違った行動を指示する方法を示している。ネットワークに縛られたワーカーがバックエンド呼び出しを待っている間、CPU 使用率は一時的に低下した。オートスケーラーは CPU 需要の低下を Web 層削減の理由と解釈した。状況が悪化するにつれて、ワーカースレッド使用率が反対のシグナルを生成し、急速な拡大を引き起こした。[1]

どちらのメトリクスも必ずしも偽ではなかった。作業が待機していたため CPU は低くなっていた。作業がブロックされていたためスレッド使用率は高くなっていた。矛盾は、各メトリクスが輻輳システムの異なる部分を表していたために生じた。通常の需要に最適化されたコントローラーは、「より少ない顧客作業」と「同じ作業がネットワークで停滞している」を区別できなかった。

分析上の推論は、使用率は有用なスループットと等価ではないということである。CPU、スレッド、キュー深度、リクエストレイテンシ、正常完了はそれぞれ部分的な状態を明らかにする。1 つの尺度に依存するスケーリングルールは、その尺度と完了した作業との関係が変化すると、間違った方向に反応する可能性がある。ネットワーク障害はその関係を壊す可能性のある 1 つの条件である。

午前 7 時 1 分から 7 時 15 分の間に Slack が 1,200 台の Web サーバーを追加しようとした試みは、問題の反対側を示している。積極的なスケールアウトコマンドは、システムがそれらのインスタンスを構成、登録、提供できる場合にのみ有用である。望ましいフリートサイズは、提供される容量ではない。インシデント中、これらの状態間のギャップが決定的になった。

したがって、オートスケーリングの説明責任はスケーリングポリシーで止まることはできない。それは作動経路全体に及ぶ。制御所有者は以下を知るべきである。

どのシグナルがスケールインとスケールアウトを引き起こすか
依存関係が欠落しているのではなく遅い場合、それらのシグナルがどのように振る舞うか
プロビジョニングサービスが使用可能なホストをどの程度迅速に提供できるか
プロビジョニングに必要なネットワークと API パス
バーストを制限するクォータとローカルリソース制限
プロビジョニングされていないインスタンスがグループ上限に対してどのようにカウントされるか
コントローラーがスケールインまたは交換をいつ中断すべきか
オペレーターが指示された、作成された、プロビジョニングされた、提供されている容量を個別にどのように見ることができるか

これらはインシデントから導き出された分析要件であり、すべての項目が欠落していたという所見ではない。記録は、チェーン内の特定の失敗を証明する。プロビジョニングサービスは劣化したネットワークを必要とし、オープンファイル制限と AWS クォータに遭遇し、多くのインスタンスがプロビジョニングされないままオートスケーリンググループの上限を占有した。[1] より広範な制御リストは、それらの既知の相互作用が対処されたことを示す証拠を定義する。

このイベントは、自動化をその速度だけで称賛することに対する警告でもある。システムは非常に迅速に応答しようとした。応答パスが障害を共有し、独自の制限があったため、速度は効果的な復旧を保証しなかった。環境が完了できないアクションを発行する高速コントローラーよりも、状態を認識する低速コントローラーの方が回復力に優れている可能性がある。

プロビジョニングはサービス提供システムの一部であった

プロビジョニングはしばしばバックグラウンド機能として扱われる。この障害では、それはライブ復旧パスの一部となった。Slack はより多くの Web サーバーを必要としたが、そのプロビジョニングサービスは影響を受けたネットワークを介して内部サービスと AWS API に到達しなければならなかった。複合的な需要の下で、Linux のオープンファイル制限と AWS クォータに達した。インスタンスは起動されても完全に構成されず、不完全なインスタンスがオートスケーリンググループの最大サイズを消費した。[1]

このシーケンスは、いくつかの一見管理上の設定を可用性制御に変換する。ファイルディスクリプタ上限、API クォータ、グループサイズ制限はそれぞれ、Slack が顧客容量を回復できるかどうかに影響を与えた。どれも最初のネットワークトリガーではなかった。それらが一緒になって対応を制限した。

事実の境界は具体的である。ポストモーテムはこれらの制約を特定する。設定された各値、各値が選択された理由、または別の設定だけで障害を防げたという証拠は提供しない。すべての制限を増やすことは弱い結論であろう。無制限の制限は他の障害を生み出す可能性があり、より大きなグループ上限だけでは劣化したプロビジョニングネットワークを信頼性のあるものにはしない。

より強い推論は、緊急容量にはエンドツーエンドのバジェットが必要であるということである。オペレーターが定義された間隔内で特定の数のホストを追加することを期待する場合、ファイルディスクリプタ、接続プール、API クォータ、ネットワークパス、構成サービス、登録システム、フリート上限はすべて、その目標を一緒にサポートしなければならない。バジェットは、個々の最大値のコレクションとして文書化されるだけでなく、移行レートでテストされなければならない。

インスタンスの存在とサービスの準備状態の区別は中心である。クラウドコンソールはマシンが作成されたことを示すかもしれない。顧客が利益を得るのは、それらのマシンが構成され、依存関係に接続され、ロードバランサーの背後に登録され、リクエストを完了できる場合のみである。監視は各状態を個別にカウントすべきである。そうでなければ、コントロールプレーンはグループがいっぱいであると報告する一方で、サービスプレーンは枯渇したままになる可能性がある。

障害のクリーンアップにも制限が必要である。プロビジョニングされていないインスタンスは、別の試行、診断のための隔離、または削除を必要とする可能性がある。あまりにも迅速に削除すると、証拠を消去し、同じ失敗行動を繰り返す可能性がある。無期限に保持すると上限を消費する可能性がある。回復力のある設計は、緊急事態の前にタイムアウト、リトライバジェット、診断サンプリング、エスカレーション条件を定義する。

Slack はプロビジョニングサービスを定期的にロードテストすると述べた。[1] それは方向性であり、検証されたクロージャーではない。意味のある証拠は、ネットワーク遅延、クォータ圧力、部分的な障害が導入されている状態で、サービスが指定された数の使用可能なホストを同等のトラフィック上昇下で提供することを示すものである。起動 API に到達するが、提供容量を検証しないテストは、測定ギャップを再現するであろう。

可観測性が運用上の依存関係として失敗した

Slack の通常のダッシュボードおよびアラートサービスは、障害の影響を受けた同じトランジットパスに依存していた。ダッシュボードインスタンスはデータベースとは異なる VPC にあったため、Transit Gateway の問題が準備された運用ビューを中断した。Slack は依然として直接メトリクスクエリ、ログ、コンソール、ステータスページを利用できた。[1]

これは完全な監視喪失の話ではない。データの可用性と意思決定の可用性の違いについての話である。生データは存在し続ける可能性があるが、それを高速で信頼できる解釈に整理するシステムが欠落している。複雑なインシデントの間、その違いは応答速度と自信を変える。

ダッシュボードはエンコードされた知識を運ぶ。シグナルを選択し、時間範囲を調整し、正常ベースラインを定義し、関連する尺度を一緒に配置する。アラートはしきい値と変化率を注意に変換する。それらのツールが消えると、対応担当者はクエリを記憶し、バックエンドを特定し、コンテキストを再構築し、手動で結果を調整しなければならない。データは技術的に到達可能かもしれないが、認知負荷と調整負荷は最悪の瞬間に増加する。

分析上の推論は、可観測性は複数の意味で独立しているべきであるということである。監視対象サービスの最も重要な障害ドメインを共有しないデータパスが必要である。また、対応担当者が劣化状態で使用できるアクセスおよびプレゼンテーションパスも必要である。独立性は、ダッシュボードをデータベースと同じ場所に配置する、別のパスを使用する、最小限の緊急ビューを維持する、またはテストされた直接クエリ手順を保持することから得られる可能性がある。正しい設計はアーキテクチャに依存する。

Slack はダッシュボードインスタンスをデータベースと同じ VPC に移動する計画を発表した。[1] その是正措置は、ポストモーテムで説明されたクロス VPC トランジット依存関係に直接対処した。すべての監視コンポーネントが常に 1 つの VPC を共有しなければならないというルールに一般化されるべきではない。同じ場所への配置は 1 つの依存関係を削除する一方で、別の共有境界を作成する可能性がある。証拠基準は、監視パスが説明することが期待される障害モードを生き残るかどうかである。

独立したパスには、使用可能な認証、権限、トレーニングも必要である。インシデント中に対応担当者がアクセスできないバックアップダッシュボードは、実際には独立していない。1 人だけが知っている直接クエリ手順は脆弱である。内部の不確実性を、確認された事実と推定を区別せずに繰り返すステータスページは、意思決定を支援せずに活動を伝える可能性がある。

Slack の記録は部分的な回復力を示している。外部監視が会社にページングし、メトリクスバックエンドはクエリ可能なままであり、他の証拠ソースが利用可能であった。また、通常のダッシュボードとアラートが利用できなかったため、てこ作用が低下したことも示している。両方の所見は可視化されたままでなければならない。対応担当者を「盲目」と表現することは、生き残った制御を消去するであろう。監視を利用可能と表現することは、運用上の障害を消去するであろう。

したがって、クロージャーの証拠は、メトリクス取り込みの成功以上のものを示すべきである。指定された対応担当者がトランジット障害を検出し、それをホスト障害と区別し、最小限のサービスビューにアクセスし、通常のダッシュボードパスが利用できない間にアクションを調整できることを示すべきである。これはイベントから導き出された提案されたテストであり、そのようなテストが行われたという主張ではない。

復旧は段階的であり、単一の復旧瞬間ではなかった

Slack の復旧は 1 つのタイムスタンプで発生しなかった。ステータスアーカイブは、プロビジョニング修復を PST 午前 8 時 13 分頃としている一方、Slack のポストモーテムはプロビジョニングサービスが午前 8 時 15 分頃に再び機能し始めたと説明している。初期の顧客改善は午前 8 時 45 分頃に現れた。午前 9 時 15 分頃までに、Web 層はほとんどの顧客が Slack を使用するのに十分な機能するホストを持っていたが、パケットロスとエラー率は依然として高かった。ネットワーク状態は、容量増加がすべてのアベイラビリティーゾーンに到達した後、午前 10 時 40 分に正常に戻った。[1][3]

Slack はまた、ロードバランサーの「パニックモード」、リトライ、サーキットブレーキングが、ヘルスチェックの失敗にもかかわらずトラフィックの処理に役立ったと報告した。[1] これらのメカニズムは根本的な障害を排除しなかった。劣化中の利用可能容量の活用に役立った。これは復旧制御と根本原因修復の間の有用な区別である。

カレンダー、メール、関連する統合機能は別の復旧トラックを持っていた。[1][3] したがって、「Slack は 9 時 15 分に復旧した」という記述は広すぎるであろう。ほとんどの顧客はその頃にコアサービスを使用できたが、ネットワークエラーは依然として高く、一部の統合機能は同じスケジュールではなかった。障害が正確に 10 時 40 分まで続いたという記述も、顧客が経験した段階的な復帰を平坦化するであろう。

分析上の推論は、サービス復旧には複数の尺度が必要であるということである。少なくとも、オペレーターは以下を区別すべきである。

根本的な依存関係状態
ほとんどの顧客にとっての使用可能なコアサービス
正常目標に対するエラー率とレイテンシ
バックログまたは遅延した作業
統合機能と二次機能
管理機能と監視機能
顧客固有の例外

単一の緑色のステータスは残存リスクを隠す可能性がある。逆に、改善を報告する前にすべての低重要度機能が正常化するのを待つことは、意味のある復旧を隠す可能性がある。段階的なコミュニケーションは、各マイルストーンがサービスの表面と残りの制限に名前を付けるときに、より正確である。

アカウンタビリティはまた、各マイルストーンを誰が宣言するかにも依存する。インフラエンジニアはパケットロスが終了したことを確認するかもしれない。サービス所有者はメッセージが完了することを確認するかもしれない。統合チームはカレンダーまたはメールの動作を検証するかもしれない。カスタマーサポートはアカウント固有の失敗を特定するかもしれない。信頼できるクロージャーは、単一の技術的メトリクスが顧客体験全体を表すと仮定するのではなく、それらのビューを組み合わせる。

インシデント記録は、失敗だけでなく肯定的な点も支持する。Slack のリトライ、サーキットブレーキング、ロードバランサーの動作は、劣化したヘルスシグナルの下でトラフィックの処理に役立った。システムは、すべての根本的な条件が正常になる前に有用なサービスを復元するのを待つ必要はなかった。レジリエンス分析は、機能した制御を保持すべきであり、失敗した制御のみを列挙すべきではない。

そのバランスの取れたアプローチは是正にとって重要である。1 つの相互作用が失敗したために設計全体を置き換えることは、害を制限したメカニズムを削除する可能性がある。より強力な方法は、各復旧マイルストーンをそれを可能にした制御にトレースし、監視、ヘルスチェック、スケーリングへの変更がそれらの利点を維持するかどうかをテストすることである。

AWS のアカウンタビリティは管理されたトランジット制御面に従った

AWS は Transit Gateway をマネージドサービスとして運用していた。Slack によれば、ゲートウェイは急激な 1 秒あたりのパケット増加に十分な速さでスケールしなかった。AWS の内部監視が AWS エンジニアに警告し、手動で容量を増加させた。Slack はまた、AWS が急激なトラフィック増加に対する Transit Gateway スケーリングアルゴリズムをレビューしていると述べた。[1]

これらの事実は、定義されたアカウンタビリティ面を支持する。AWS はマネージドサービスの内部スケーリング動作、エンジニアが利用できるテレメトリ、容量を追加した手動介入を制御していた。Slack はサービスを中心に設計し、事前対応的なスケーリングを要求することはできたが、AWS の内部アルゴリズムを直接変更したり、隠されたゲートウェイ容量を自分で追加したりすることはできなかった。

これは、AWS が契約に違反したことや障害の唯一の責任者であることを立証するものではない。ここで使用される公開記録には、該当するサービス条件、非公開の容量議論、内部の AWS 証拠、または別個の AWS ポストモーテムは含まれていない。したがって、「AWS の失敗」という表現は、完全な因果関係または法的結論を暗示する場合、あまりにも不正確である。

運用上のアカウンタビリティはそれらの非公開の詳細なしでも可能である。マネージドサービスは、顧客が重要なスケーリング制限と応答動作を理解するのに十分な証拠を提供すべきである。関連する質問は以下を含む。

公称スループット上限以下でも、どのトラフィック形状がスケーリングの遅延を引き起こす可能性があるか？
パケットロスがアプリケーションに影響を与える前に、顧客はどのメトリクスを観測できるか？
顧客は既知の不連続性に対して事前対応的な容量を要求またはスケジュールできるか？
どのような自動および手動介入が利用可能で、それらはどの程度迅速に伝播できるか？
マルチゾーン効果はどのように表現されるか？
プロバイダーは、内部監視が顧客がそれを分離する前に状態を検出した場合に、どのように通信するか？
スケーリングアルゴリズムの変更がトリガーパターンの下で機能するというどの証拠があるか？

これらはガバナンスの質問であり、2021 年に開示されていない AWS 機能についての主張ではない。それらは、AWS が持っていた制御と Slack が確認できた症状との間のギャップから生じる。

手動介入は特に重要である。手動アクションは、稀な条件に対する正当な安全機構であり得る。また、証明義務も生み出す。マネージドサービスが容量を追加するためにエンジニアに依存する場合、プロバイダーはアラートしきい値、スタッフ配置カバレッジ、意思決定権限、伝播時間、顧客に通知される状況を理解すべきである。記録は手動アクションが発生したことを示している。完全な運用手順は明らかにしていない。

Slack は次の休暇後の急増の前に、事前対応的な Transit Gateway スケーリングを要求すると述べた。[1] その提案は共有境界を認識している。Slack はカレンダーと需要パターンを知っている一方、AWS は容量アクションを制御していた。耐久性のある制御は要求だけではない。それは、繰り返し可能なトリガー、指定された所有者、容量が存在することの確認、期待されるスケーリングが発生しない場合のフォールバックである。

Slack のアカウンタビリティはアーキテクチャと自動化に従った

Slack は AWS Transit Gateway の内部スケーリングを制御していなかったが、それに依存するシステムを制御していた。そのシステムは、複数のアカウントと VPC にサービスを配置し、Transit Gateway をハブとして使用し、同じ依存関係を経由して監視トラフィックを送信し、自動化されたチェックを通じてヘルスを解釈し、使用率シグナルから Web 層をスケーリングし、独自のリソースとクォータ制約を持つプロビジョニングサービスに依存していた。[1]

これらの設計選択のどれも本質的に無責任ではない。複数のアカウントと VPC は有用な分離を提供できる。自動化されたヘルス交換は失敗したホストを削除できる。オートスケーリングは需要を吸収できる。中央トランジットは接続性を簡素化できる。アカウンタビリティの質問は、共有トランジット障害の下でのそれらの相互作用が理解され、テストされていたかどうかである。

ポストモーテムは、いくつかの Slack が制御する貢献要因を特定している。

ダッシュボードインスタンスとそのデータベースが影響を受けたトランジットパスによって分離されていたため、通常のダッシュボードが利用できなくなった。
ネットワーク待機が CPU 使用率を低下させ、一時的にスケールインを促進した。
後のワーカースレッド圧力が急速なスケールアウトを引き起こした。
依存関係に到達できなかった場合、ヘルスチェックがインスタンスの交換を引き起こした。
プロビジョニングは劣化したネットワークを必要とした。
プロビジョニングサービスがオープンファイル制限と AWS クォータに達した。
不完全なインスタンスがオートスケーリンググループの上限を消費した。
プロビジョニング解除が、対応担当者が調査していたホスト上の SSH セッションを中断した。[1]

このリストは制御カスケードの証拠であり、任意の 1 つの項目がインシデント全体を防いだであろうという証明ではない。ファイルディスクリプタ制限を修正しても Transit Gateway はスケールしなかったであろう。ダッシュボードを移動しても顧客トラフィックは復元しなかったであろう。グループ上限を引き上げてもプロビジョニングは完了しなかったであろう。各制御は検出、増幅、復旧に影響を与える。

適切な基準は、相互作用の証拠を伴う多層防御である。Slack は、トランジット障害が優先監視を同時に除去し、誤解を招くスケールインシグナルを生成し、制御不能な交換を引き起こし、健全な容量を追加する経路をブロックしないことを示せるべきである。すべての層を完全に独立させることは不可能かもしれない。1 つの条件がすべての層を同じ有害な方向に向けるのを防ぐことは可能であるべきである。

Slack が表明した是正措置は、観察された貢献要因を追跡していた。事前対応的なゲートウェイスケーリングの追求、ダッシュボードインスタンスをデータベースに近づける移動、プロビジョニングの定期的なロードテスト、ヘルスチェックとオートスケーリング設定の再評価を計画していた。[1] これらは信頼できる方向性である。なぜなら、それぞれが特定の障害メカニズムに対応しているからである。

それらは公開された説明におけるコミットメントのままである。情報源は、完了、テスト結果、または持続的な有効性を独立して証明しない。アカウンタビリティは次の層の証拠を必要とする。日付のある変更、定義された期待される結果、同等負荷テスト、観察された結果、残りの制限、残存リスクを受け入れる所有者。

是正措置リストとクロージャーの違いは重要である。ポストモーテムは、詳細で率直であるため、しばしば権威あるナラティブになる。その率直さは、未来形の行動を完了した制御に変換すべきではない。読者は診断の質を信用しつつ、実装の証明を要求することができる。

エンタープライズ顧客は継続性を所有していたが、インフラ障害は所有していなかった

Slack を使用している組織にとって、インシデントは異なるアカウンタビリティテストを生み出した。顧客は Transit Gateway をスケールしたり、Slack のプロビジョニングサービスを修復したり、そのヘルスチェックを変更したりすることはできなかった。技術的な失敗の責任を顧客に割り当てるのは不正確であろう。彼らの制御面は内部の継続性であった。

最初の質問はプロセスの重要度である。当時、どの活動が Slack に依存していたか？日常的な会話は数時間の中断に耐えるかもしれない。セキュリティエスカレーション、運用インシデント対応、カスタマーサービス調整、経営判断、時間に敏感な承認は耐えないかもしれない。企業はそれらの用途を分離するまで、比例したフォールバックを選択できない。

2 番目の質問は最小機能である。継続性計画は、チャンネル、検索、統合機能、履歴を再現する必要はない。回避可能な害を防ぐ最小限の意思決定とコミュニケーションのセットを保存する必要がある。それには、独立した連絡先ツリー、別個のインシデントブリッジ、ステータス場所、重要な文書へのアクセス、フォールバックを呼び出す既知の権限が含まれる可能性がある。

3 番目の質問は共通依存関係である。名目上の代替手段は、両方が同じ ID プロバイダー、デバイス管理パス、クラウドリージョン、インターネットルート、内部ディレクトリに依存する場合、プライマリサービスとともに失敗する可能性がある。顧客はすべてのベンダー依存関係を完全に可視化することはめったにないが、Slack が利用できないときに自身のフォールバックに到達できるかどうかをテストできる。

4 番目の質問は呼び出しである。Slack チャンネルにのみ存在する計画は、Slack 障害中は使用できない。スタッフはいつ切り替えるか、どこに行くか、誰が変更を伝えるかを知る必要がある。これは技術的なレプリカではなく、組織的な制御である。

これらの点は分析的推論である。インシデント情報源は特定の Slack 顧客の継続性計画を説明しておらず、顧客の計画失敗が特定の損失を引き起こしたことを立証していない。記録は、コラボレーションプラットフォームがリモートワークの依存関係となり、その利用不能が広範な混乱を引き起こしたという、より広い結論を支持する。

比例性は重要である。病院のインシデントチーム、金融取引所、学校、小規模デザイン会社は異なる結果とリソースを持つ。正しい質問は、各組織が 2 番目のエンタープライズプラットフォームを維持したかどうかではない。最も時間に敏感な機能が、そのリスクに適した独立したテスト済みの経路を持っていたかどうかである。

ベンダー管理は同じ現実主義を反映すべきである。顧客は Slack に可用性目標、インシデントコミュニケーション、ポストモーテム証拠を要求できる。すべての内部 AWS 制御を監査することはできない。明確な依存関係開示、エスカレーション経路、既知の障害モードがテストされたという証拠を要求できる。ポイントは、合理的な継続性決定のために残存依存関係を十分に可視化することである。

単一原因のストーリーに対する反論

大規模障害は単純なラベルへの圧力を生み出す。このケースでは、「AWS Transit Gateway の過負荷」は支持されたトリガーである。完全な説明ではない。

有用な因果マップには少なくとも 5 つの層がある。

需要条件:静かな休暇期間後の急激な仕事復帰トラフィック増加、コールドキャッシュによる取得増加。
インフラトリガー:管理された Transit Gateway が十分な速さでスケールせず、パケットロスとレイテンシを生成。
サービス増幅:Web 層の呼び出しが待機、ワーカーリソースが飽和、ヘルスチェックが失敗、自動化がフリートを変更。
復旧制約:プロビジョニングが劣化したネットワークに依存し、オープンファイル制限、AWS クォータ、グループ上限に遭遇。
診断制約:通常のダッシュボードとアラートが同じトランジットパスで利用できなくなったが、他のテレメトリは残った。

復旧は第 6 の層を追加した。AWS はトランジット容量を増加させ、Slack はプロビジョニングと十分なサービス提供ホストを復旧させ、劣化モード制御を使用し、統合機能を別のタイムラインで復帰させた。

このマップは差別化されたアカウンタビリティを支持する。AWS は管理されたトランジット動作と介入を所有していた。Slack はサービスアーキテクチャと増幅制御を所有していた。エンタープライズ顧客は自分たちの依存関係と継続性の選択のみを所有していた。単一の制御所有者がすべての段階を説明するわけではない。

マップはまた、反対の誤りを防ぐ。責任をあまりに広く分散させることで、誰も行動できなくなることである。共有アカウンタビリティは集団的な曖昧さではない。各項目は 1 つの実質的な所有者、1 つの観察可能な目的、1 つの検証方法を持つことができる。いくつかの制御が必要であったという事実は、所有権を知り得なくするわけではない。

例えば、AWS 所有者は急速なパケット増加下でのゲートウェイ動作を実証できる。Slack の可観測性所有者は、クロス VPC トランジットなしの緊急ダッシュボードを実証できる。Slack のプロビジョニング所有者は、遅延とクォータ圧力の下での使用可能なホストの提供を実証できる。顧客の継続性所有者は、重要なインシデントブリッジが Slack なしで開設できることを実証できる。これらのテストは異なる主張に対処する。

法的な割り当ては異なる可能性がある。契約、基準、管轄権がここで答えられない質問を導入するためである。運用上のアカウンタビリティはより早く進めることができる。それは、誰が制御を変更できるか、そしてその変更が機能することを示す証拠は何かを問う。これにより、インシデント後の記録は、責任を解決したふりをすることなく、行動可能になる。

集中リスクは相関する制御喪失についてである

インシデントは時々、クラウド集中に関する一般的な警告としてフレーム化される。そのフレーミングは有用であるにはあまりに広い。Slack の AWS 使用は過失であるとは示されておらず、すべてのコンポーネントを複数のプロバイダーに分散させることがより良い結果を生み出したであろうという証拠はない。マルチクラウド設計は、独自の複雑さ、運用負担、共通依存関係を導入する。

より正確なリスクは、内部クラウドトランジットハブを中心とした相関する制御喪失であった。同じネットワーク状態が、顧客サービス呼び出し、監視表示、復旧に必要なプロビジョニングパスに影響を与えた。ヘルスとスケーリングの自動化は、その後、その共有状態によって生成された症状に反応した。

したがって、集中は、単にベンダー数ではなく、一緒に失敗する制御によって測定されるべきである。異なるベンダーからの 2 つのサービスは、ID、ルーティング、運用スタッフを共有する可能性がある。10 個の VPC が依然として 1 つのトランジット層に依存する可能性がある。バックアップは同じプロビジョニング API またはクォータを共有する可能性がある。逆に、1 つのプロバイダーは、重要な制御パスが独立してテストされていれば、意味のある分離をサポートできる。

分析上の質問は次のものである。どの失敗の組み合わせが、サービス、診断、復旧を同時に除去するか？Slack のケースでは、トランジット障害が 3 つすべてに達した。ゲートウェイはサービス呼び出しに影響を与えた。ダッシュボードの配置は診断を減少させた。プロビジョニング依存関係は復旧を制約した。その 3 部構成の相関が特徴的なアカウンタビリティ問題である。

それをマッピングするには、アーキテクチャ図以上のものが必要である。図はコンポーネントがゲートウェイを介して接続することを示すことができる。制御マップは、ゲートウェイが遅いときに何が起こるかを示すべきである。どのヘルスチェックが失敗するか、どのメトリクスが変化するか、どの自動化が作動するか、どの API が到達不能になるか、どのクォータが上昇し、どの対応担当者がアクセスを失うか。

公開情報源は Slack の完全なマップを提供しない。ポストモーテムは、なぜそれが重要であったかを示すのに十分な相互作用を提供する。したがって、勧告は証拠に関するものである。管理されたトランジットハブを持つ組織は、サービス、可観測性、復旧パスのためのテストされた障害マップを作成できるべきである。

これが、「単一障害点」というフレーズが注意を必要とする理由でもある。Transit Gateway は共有依存関係であったが、インシデントは 1 つの壊れたホスト、デバイス、アベイラビリティーゾーンとして説明されていなかった。AWS の容量変更はアベイラビリティーゾーン全体に伝播し、Slack 自身のシステムがカスケードに寄与した。それを単一障害点と呼ぶことは、分散アーキテクチャと複数の関与した制御を不明瞭にする可能性がある。

より良い説明は、コモンモードのトランジット依存関係である。この言語は、1 つの物理オブジェクトまたはゾーンが失敗したと主張することなく相関を特定する。また、適切な是正措置を指し示す。実用的な場合は重要なパスを分離し、分離が実用的でない場合は劣化モードを作成し、自動化を共通条件に対してテストする。

テストは障害形状を再現しなければならない

Slack はプロビジョニングサービスを定期的にロードテストし、同等の休暇後の復帰の前に AWS に事前対応的なゲートウェイスケーリングを要求すると述べた。AWS は急速な 1 秒あたりのパケット増加に対するスケーリングアルゴリズムをレビューしているとされた。[1] 一緒に、これらのアクションは、通常の容量テストが観察された移行をカバーするのに十分でなかったことを示唆している。

意味のあるテストは、ピークだけでなく失敗の形状を再現すべきである。関連するシーケンスは、持続的な低トラフィックで始まり、キャッシュとフリート状態がその期間を反映することを許可し、その後、クライアント取得とサービス呼び出しの急激な増加を導入する。Web 層がスケーリングを試みる間に、トランジット遅延またはパケットロスを注入する。通常の監視パスを障害状態に保ち、対応担当者に独立したビューの使用を要求する。

テストは、要求されたインフラではなく、提供されたサービス容量を測定すべきである。要求された、起動された、プロビジョニングされた、登録された、健全な、顧客作業を完了しているインスタンスを区別すべきである。ファイルディスクリプタ使用量、接続プール、API クォータ、リトライボリューム、グループ占有率、不完全なホストの経過時間を記録すべきである。CPU 低下が低需要ではなく待機によって引き起こされた場合に、スケールインが中断されるかどうかを示すべきである。

これらの詳細は分析上のテスト要件である。公開記録は Slack がこの正確な設計を採用したとは述べていない。これらは、1 月のシーケンスが方向を変えた各報告点から導き出されている。

障害モードテストはまた、オペレーター権限を行使すべきである。対応担当者は交換チャーンを停止できるか？診断用にホストを保持できるか？既知のエスカレーションパスを通じてプロバイダーアクションを要求できるか？制御不能なコストや負荷を生み出さずにグループ上限を変更できるか？統合機能を早期に正常とマークせずに部分的な復旧を伝達できるか？

トラフィックが流れ始めた時点でテストが終了する場合、テストは不完全である。バックログ復旧、統合復元、緊急設定からの復帰を通じて継続すべきである。一時的な設定は、そのまま残ると後日のリスクを生み出す可能性がある。高い上限、無効化されたヘルスチェック、広範なリトライポリシーは復旧に役立つ一方で、その後コストや不安定性を増加させる可能性がある。

証拠は時間とともに比較可能であるべきである。1 回限りのテストは、是正措置が 1 つの構成で機能したことを示すことができる。サービス、クォータ、トポロジ、トラフィックパターンは変化する。制御所有者は再テストのしきい値を必要とする。重要なアーキテクチャ変更、主要なトラフィックシフト、プロバイダーサービス更新、定義された間隔。

プロバイダーと顧客の調整テストも存在する。Slack はカレンダーパターンを知っていた。AWS は隠された容量動作を制御していた。共有手順は、Slack が事前スケーリングを要求するタイミング、AWS が確認すること、顧客可視メトリクスが準備完了を示すもの、確認が利用できない場合のフォールバックを定義すべきである。測定可能な受け入れなしの要求メールは制御を閉じないであろう。

最後に、テスト結果は不確実性を保持すべきである。1 つのシミュレートされたトラフィック曲線に合格しても、将来のすべてのイベントの下での安全性を証明しない。指定された制御が文書化された条件下で機能したことを立証する。その範囲が、問題が解決されたという一般的な保証に変換されるのではなく、明示的であるときに、アカウンタビリティは改善される。

是正措置にはコミットメントだけでなく証明が必要である

Slack のポストモーテムは、具体的な障害メカニズムを提案された変更に結びつけたため、異常に有用であった。事前対応的なトランジットスケーリング、ダッシュボード配置、プロビジョニングロードテスト、ヘルスチェックとオートスケーリングの再評価を特定した。また、AWS によるゲートウェイスケーリングアルゴリズムのレビューを報告した。[1] 残りのアカウンタビリティ質問は、それらのコミットメントがどのように検証されるかである。

各アクションにはクロージャークレームが必要である。

トランジット容量:同等の急速なトラフィック増加がもはや同じパケットロス状態を生成しない、または顧客影響の前にアラートと介入が発生する。
可観測性:クロス VPC トランジットパスが障害状態にあるとき、対応担当者は運用ビューを保持する。
プロビジョニング:サービスは、遅延、部分的な障害、クォータ圧力が存在する状態で、復旧目標内に必要な数の使用可能なホストを提供できる。
ヘルスチェック:依存関係到達可能性の失敗は、破壊的な交換チャーンを避けるために十分に区別される。
オートスケーリング:待機によって引き起こされた低 CPU は有害なスケールインをトリガーせず、スケールアウト需要は提供可能な容量によって制限される。
フリート上限:不完全なホストが、実行可能なシグナルなしにすべての利用可能なグループ容量を静かに消費することはできない。
診断:選択されたホストとセッションは、相関状態を調査するのに十分な期間保持できる。

これらのクロージャークレームは分析的である。それらは、既知の失敗に答える証拠を示すものであって、Slack または AWS が公に証明したものではない。

完了記録は、所有者、日付、構成、テスト負荷、注入された障害、観察された結果、残りの制限を特定すべきである。また、証拠を現在のアーキテクチャに結び付けるべきである。主要なネットワーク再設計の前の成功したテストは、その後あまり確立しない可能性がある。

独立した挑戦は役割を持つが、独立性は形式的なサインオフではなく、意思決定権限と証拠アクセスによって定義されるべきである。制御を設計しなかったチームは、前提を壊そうと試み、生の結果を検査し、成功基準がテスト前に設定されたことを確認できる。ここで使用される公開記録にはそのような後日の保証は含まれていないため、完了した是正措置についての結論は正当化されない。

顧客コミュニケーションは証明の一部である。ユーザーは内部構成の詳細を必要としないが、障害境界、復旧段階、それらの段階に関連する変更の明確な説明から利益を得る。Slack のポストモーテムはその診断的透明性の多くを提供した。将来のクロージャーは、アクションが完了したかどうかとそれを支持するテストを追加するであろう。

過去の記録における古い公式ステータス URL は、証拠保存が重要である理由も示している。1 つのレガシー URL は現在リダイレクトされ、インシデントページを返さない一方、アーカイブミラーは 1 月 4 日の更新履歴を保持している。[2][3] 耐久性のあるインシデント記録は、1 つの可変 Web ルートに依存すべきではない。技術的なポストモーテム、ステータス更新、クロージャー証拠は、顧客が再発リスクを評価することが期待される場合、安定した保持を必要とする。

証明義務は、機密の容量値や悪用可能な詳細の公開を意味するものではない。事業者は、障害形状、制御目的、テスト方法、結果を、すべてのしきい値を公開することなく述べることができる。重要な特徴は反証可能性である。クロージャークレームは、将来の失敗またはテストがそれが成立するかどうかを示すことができるほど具体的であるべきである。

インシデントが証明しないこと

いくつかの結論は証拠を超えるであろう。

AWS だけが障害全体を引き起こしたことを証明しない。Slack はネットワークトリガーを十分な速さでスケールしなかった Transit Gateway に帰属したが、Slack が制御する監視、オートスケーリング、ヘルス交換、プロビジョニング制限、グループ上限がサービス影響と復旧を形成した。[1]

Slack に監視がなかったことを証明しない。外部監視が対応担当者にページングし、直接メトリクスはクエリ可能なままであり、ログ、コンソール、ステータスページが利用可能であった。通常のダッシュボードとアラートは利用できなかったが、それは深刻であったが、完全な盲目とは異なっていた。[1]

単一のアベイラビリティーゾーンが失敗したことを証明しない。Slack は AWS の容量増加が午前 10 時 40 分までにすべてのアベイラビリティーゾーンに到達したと述べた。説明された状態は共有トランジット容量とパケットロスであり、1 つのゾーンの喪失ではなかった。[1]

すべての顧客が固定の 5 時間オフラインであったことを証明しない。エラーは広範な使用不能の前に始まり、ほとんどの顧客はネットワーク正常化の前にコア使用を回復し、統合機能は別の経路をたどった。[1][3]

セキュリティ侵害または顧客データ漏洩を証明しない。ここで説明されたイベントは可用性インシデントであり、無関係なセキュリティイベントと組み合わせるべきではない。

正確な影響を受けたユーザー数を確立しない。メディア報道、顧客規模の数字、Downdetector レポートは異なる分母を使用する。検証されたインシデント人口を提供するものはない。

定量化された経済的損失、法的違反、規制上の判断、契約違反、特定の顧客に対するサービス保険の資格を確立しない。これらの質問はこの記録の外の証拠を必要とする。

発表されたすべての是正措置が実装されたことを証明しない。ポストモーテムは方向性とコミットメントを述べている。完了と有効性は後日の証拠を必要とする。

最後に、中央クラウドトランジット、VPC 分離、オートスケーリング、管理されたインフラが本質的に安全でないことを証明しない。それぞれが実質的な運用価値を提供できる。インシデントは、それらの相互作用と共有障害ドメインが理解され、観察され、テストされる必要があることを示している。

アカウンタビリティ基準

1 月 4 日の障害は、実質的な制御が分散されていたため、アカウンタビリティテストである。AWS は管理されたトランジットサービスの容量動作と内部運用を制御していた。Slack はそれに依存するアーキテクチャと自動化を制御していた。エンタープライズ顧客は自身の重要なコミュニケーションの継続性を制御していた。誰も単独で完全なリスクを閉じることはできなかった。

AWS の基準は、管理されたトランジットが急速な需要不連続性を処理または安全に信号できること、内部検出がタイムリーなアクションにつながること、顧客が事前スケーリングが必要な場合に容量を要求および確認するための使用可能な経路を持つことの証拠である。

Slack の基準は、1 つのトランジット状態が効果的なセーフガードなしに、優先診断を同時に無効にし、フリート自動化を誤った方向に導き、復旧容量をブロックできないことの証拠である。そのサービス提供、監視、プロビジョニングシステムは、パケットロス下で 1 つの制御システムとしてテストされるべきであり、通常の接続下での別個のコンポーネントとしてではない。

エンタープライズ顧客の基準は、比例した継続性である。彼らはどの重要な決定が Slack に依存するかを知り、独立した最小限のコミュニケーションパスを保持し、フォールバックが利用できないプラットフォームなしで呼び出せることをテストすべきである。

3 つの層すべてにわたって、基準はゼロ障害の約束ではない。既知の障害形状を検出し、増幅を制限し、測定された段階で復旧し、残存障害を伝達し、同等の条件下で是正措置を検証する実証可能な能力である。

Slack のポストモーテムは、イベントを 1 つの壊れたサービスに還元しないため、強力な事実上の出発点を提供する。管理されたゲートウェイ、不連続な負荷、相関する可観測性、矛盾するスケーリングシグナル、制約されたプロビジョニング、段階的な復旧を明らかにする。その詳細は責任をより正確にし、より曖昧にしない。

したがって、中心的な教訓は狭い。管理されたクラウドトランジットはネットワーク機能の運用を移譲する。その機能を中心としたアーキテクチャに対する顧客の責任を消去しない。サービス分離は一部のリスクを低減しながら、共通トランジット依存関係を作成する可能性がある。自動化は容量を追加しながら、相関する障害を増幅する可能性がある。メトリクスは利用可能なままでありながら、運用理解が低下する可能性がある。復旧は重要なサービスが依然として障害状態にある間に開始できる。

アカウンタビリティはそれらの区別に従う。それは各制御を変更できる当事者に属し、その当事者が変更をそれを露呈した条件の下で生き残ることを示すことができるときにのみ閉じる。リモートワークプラットフォームでは、その証拠は内部技術的な贅沢ではない。それは顧客が実際の作業を組織する信頼性の一部である。