障害時の「責任逃れ」をどう防ぐ？ AWSが明かす報告書作成手順：“完璧な再構築”よりも優先すべきこと

システム障害の事後対処において、自己に都合の良い報告がなされるリスクは常にある。AWSが実施している、内部の責任逃れを排除し、原因究明を可能にする客観的なレビュー体制とは。

[TechTargetジャパン]

　ソフトウェアをインターネット経由で提供するSaaS（Software as a Service）やクラウドインフラの利用が定着する中、システム障害が事業に与える影響はかつてなく大きくなっている。障害対処において、システムの復旧と同程度に重要なのが、事後の情報開示だ。不透明な報告は顧客の不信感を増幅させ、最悪の場合はサービスの解約につながるからだ。

　Amazon Web Services（AWS）のサポートチームは、障害後の対処におけるRCA（Root Cause Analysis：根本原因分析）を単なる報告書ではなく、「顧客からの信頼を取り戻すための重要な手段」と位置付けている。同社は過去10年以上にわたり、障害発生時の分析とドキュメント作成のプロセスを磨き上げてきた。

　AWSのRCAは、「影響の概要」「根本原因」「詳細なタイムライン」「具体的な再発防止策」から構成されている。分かりやすい記述と、机上の空論ではない実行可能な改善策の提示を重視しているという。

　障害という混乱の中でどのように事実を収集し、報告書を作り上げているのか。AWSによるRCA作成の具体的な手順と、客観的な品質を確保するための仕組みを解説する。

「後からデータを収集すればよい」は誤り

併せて読みたいお薦め記事

システム障害で何をすべきか

• 「想定外の複合障害」に情シスはどう動く？　インシデント対応計画の実践アプローチ
• 給与システムの停止にどう対処する？　災害に備える「復旧チェックリスト」

　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)」を基に作成しました。