原因が分からない障害を、API・DB・インフラを横断して切り分ける手順

この記事で扱う問題

「一部のユーザーで API がときどき遅い」「特定の操作だけ失敗する」といった障害は、原因がアプリにあるのか、DB なのか、キャッシュなのか、ロードバランサなのか、最初は分かりません。

このとき一番まずいのは、思いついた原因を順に直してみることです。直したつもりで症状が消えても、偶然かもしれません。本当の原因が残ったまま、次の障害で同じ調査を繰り返すことになります。

私は次の順で切り分けます。

影響範囲を確定する：全員か一部か。一部なら、どのエンドポイント・どのユーザー・どのクライアントのバージョンか
時系列を並べる：いつから起きているか。その前後にデプロイ、設定変更、トラフィックの変化、外部サービスの障害はなかったか
1件のリクエストを端から端まで追う：Request ID で、ロードバランサ → アプリ → DB・キャッシュ・外部 API のログをつなげる
層ごとに「正常」を確かめて除外する：ロードバランサの応答時間、アプリの処理時間、クエリの実行時間、外部 API の応答時間を比べ、どの層で時間を使っているかを特定する
仮説を立てて、再現で確かめる：「この条件なら必ず起きる」を作れてから直す
再発しない形に直す：その場の修正に加えて、同じ種類の問題が起きない設計・監視を入れる

障害調査で時間がかかるのは、たいてい「どこで起きているか」の特定です。層をまたぐシステムでは、症状が出る場所と原因の場所が違うことが普通です。アプリがタイムアウトしていても、原因は DB のロック待ちかもしれませんし、キャッシュの接続数の枯渇かもしれません。

だから、推測より先に事実を並べて、除外していくことを優先します。影響範囲と時系列が固まれば、候補はかなり絞れます。

この手順を回すには、日頃からの仕込みが要ります。

障害が起きてからでは、この情報は取り戻せません。