AWSが2025年に開催した年次イベント「AWS re:Invent 2025」のセッション「Mastering Root Cause Analysis: Rebuilding trust after outages (ARC211)」では、同社のサポート部門でプリンシパルを務めるジョルジョ・ボンフィリオ氏とドナルド・クインダード氏が登壇した。両氏は、これまでに何百もの企業の障害対処を支援し、障害対応から信頼回復につなげるプロセスを共有してきた経験を持つ。同セッションでは、AWS社内で実践されているRCAの作成手順や、品質向上のためのメカニズムが紹介された。

　質の高いRCAを作成するための第一歩は、障害発生時に始まる。後からログやグラフを拾い集めればよいと考えがちだが、事態が収束した後では正確な状況把握が困難になるためだ。現場の混乱のさなかであっても、影響範囲、関連するシステム指標、サポートチームからの定性的な報告、タイムラインという4つの要素をリアルタイムに記録することが求められる。

　データの収集後に実行すべき項目は、真の根本原因の特定だ。例えば「データベースが応答しない」という事象に対し、「電源のコンデンサーが故障した」という物理的な原因だけを突き止めて終わらせてはいけない。「なぜ冗長化機構が機能しなかったのか」といったアーキテクチャの欠陥にまで視野を広げることが重要だ。これによって、単なる部品交換にとどまらない、システム全体の可用性向上に寄与する広範な再発防止策を導き出すことができる。

内部用語の徹底排除と「顧客の言葉」による記述

　RCAは、サービスベンダー目線で書かれるべきではない。顧客が知りたいのは、社内のどのモジュール（機能単位）が停止したかではなく、自分が利用しているどの機能に影響が出たのかだ。

　AWSは、内部でしか通じないシステム名や専門用語を、外部の人が理解できる言葉に翻訳する作業を徹底している。例えば、「L504が切断された」という社内ネットワーク用語は、「2つのデータセンター間を結ぶ特定のファイバー経路が利用不可になった」という表現に置き換える。社内のチーム間の連携不足といった内部事情をドキュメントに持ち込むことも禁止されている。顧客にとって、サービスベンダーは1つの組織であり、内部の縦割り構造は考慮すべき問題ではないからだ。

「バーレイザー」による客観的レビューと確約

　AWSのRCA作成プロセスにおいて特徴的なのが、「バーレイザー」（基準を引き上げる者）と呼ばれる外部レビュアーの存在だ。バーレイザーは、障害を起こしたチームとは無関係の別部門から選出される。彼らは当該システムに関する深い背景知識を持たないため、顧客に近い視点でドキュメントを読むことができる。

　障害を起こしたチームは、早期に報告書を提出したいという重圧から、無意識のうちに説明を省略したり、自己に都合の良い記述をしてしまったりする恐れがある。バーレイザーはこうした偏見を排除し、記述の一貫性と品質を厳しく審査する。

　AWSは、「再発防止策を確約できるまではRCAを顧客に提出しない」という方針を貫いている。原因の記述だけであれば障害発生から24時間程度で完了できる場合でも、関係各所と調整し、確実な再発防止計画を策定するために数日を費やすことをいとわない。実現不可能な「完璧なシステム再構築」を10年計画で掲げるよりも、数週間から数カ月以内で確実に実行できる中期の対策を提示し、顧客と合意することが信頼回復の鍵になる。

RCAを「実行される改善」へ

　RCAは、提出して完了となる文書ではない。策定した再発防止策がシステムに実装され、顧客のシステム構成において再発を防ぐ仕組みとして機能して初めて、その目的を果たしたと言える。

　障害による信頼の喪失は一瞬だが、RCAを通じた誠実な情報開示と、確実な改善策の実行を積み重ねることで、結果的に強固な信頼関係を再構築することができる。システムの安定稼働を担うIT担当者にとって、障害対処プロセスそのものを磨き上げることは、重要な経営課題だ。

本稿は、AWSが2025年12月9日に公開した動画「AWS re:Invent 2025 - Mastering Root Cause Analysis: Rebuilding trust after outages (ARC211)」を基に作成しました。