本番障害が起きたとき、原因をどう絞り込むか
障害で時間を食うのは、直す作業より「何を見ているのか分からない」時間です。まず現場を固定し、それからコードに触れます。
進め方
ログを一本の時系列にまとめる
障害時間帯のログ、関係するサービス、対象期間をまとめて「ログから障害の現場を読む」に渡します。時系列のイベント連鎖、最初の異常点、ログが直接示していることと推測の二欄、結論を出すために足りないログを出させます。最初の ERROR から説明させないのが要点です。
原因を可能性順に並べ、一つずつ確かめる
ステップ1の時系列と足りないログをもとに、技術スタックのバージョン、スタックトレース全体、すでに試した方法を「エラーの原因を特定する」に渡します。可能性の高い順に原因を並べ、それぞれにコマンド一つか最小の再現コードを付けさせます。試済みの項目は飛ばさせ、情報が足りなければ何が必要かを言わせます。
修正前に必ず落ちる最小テストを書く
不具合の症状と関係するコードを「最小の再現テストを書く」に渡します。トリガーに必要な入力と状態だけを残し、期待値と実際値を断言させ、修正前に失敗し修正後に通ることを確認します。再現できない場合は、足りない環境条件を挙げさせ、作った手順で埋めさせません。
直す前に、影響が及ぶ範囲を見る
修正方針が決まったら、diff と依存関係を「変更の影響範囲を見積もる」に渡します。影響を受ける呼び出し元、データ、定期処理を挙げ、影響人数と復旧の難しさで上位三件を並べ、切り戻しのしきい値を出させます。一行の修正でも下流の前提を変えることがあります。
検証できる振り返りに仕上げる
最後にタイムラインと対応記録を「検証できる振り返りを書く」に渡します。タイムラインは状態や判断が変わった点だけに絞り、タイムゾーンを統一します。原因は欠けていた仕組みまで書き、改善項目は実施済みと未実施に分け、担当、期限、確認方法を付けます。運が良かった点も別に残します。
使うプロンプト
よくある質問
本番でエラーが出たら、再起動とログ確認のどちらを先にしますか
まず現場を残します。障害時間帯のログ、監視指標、直近のリリース記録を保存してから、再起動するか決めます。再起動するとメモリ上の状態と一時ログが消え、その後は推測に頼るしかなくなります。
AI はバグの場所を直接教えてくれますか
返ってくるのは可能性順の仮説と検証方法で、結論ではありません。ステップ2で一つずつ検証し、ステップ3の再現テストで確認します。再現できないうちにコードを変えると、障害の場所が移るだけです。
障害が直ったら、振り返りは省略できますか
直したのは今回の一件だけです。振り返りの価値は「どの前提が崩れたか」「どの仕組みが欠けていたか」を、担当と確認方法のある作業に変えることです。「監視を強化する」だけの振り返りは、振り返りになっていません。