深夜2時のデバッグ：本当に役立つこと
本番が落ちて頭がボーッとしている時、あなたを救うツールと習慣。
深夜2時。PagerDutyのアラートでスマホが鳴りました。本番で何かが壊れている。脳はせいぜい40%の稼働率。
こういう時に、クレバーなデバッグは要りません。半分寝ていても機能する、体系的で退屈で信頼性の高いテクニックが必要です。
深夜のインシデントを重ねて学んだことを共有します。
ステップ1：何が変わった？
本番バグの90%は、最近変わった何かが原因です。デプロイ。設定の更新。データベースのマイグレーション。期限切れの証明書。
コードを読み始める前に、最後に動いていた時と何が違うのかを把握しましょう。
現在の設定と、最後に正常だった設定を比較する。テキスト差分ツールを使えば、2つのファイルを並べて目を凝らす代わりに10秒で完了します。
本気で言ってます。一度、「謎の」APIエラーのデバッグに45分費やしたことがあるんですが、原因はJSON設定ファイルのカンマの位置ミスでした。差分ツールなら数秒で見つけられたのに。
ステップ2：実際のエラーを読む
当たり前に聞こえるでしょう。でも実際はそうでもない。
疲れている時、エラーメッセージを見た瞬間に仮説を立て始めます。「あぁ、たぶんデータベースの接続だな」。20分かけてデータベースを調べる。エラーメッセージは TypeError: Cannot read property 'name' of undefined と言っていた。データベースとは何の関係もない。
エラーを読む。もう一度読む。スタックトレースを読む。コードの該当行まで辿る。
ステップ3：エラーを読みやすくする
本番ログはカオスです。すべてが1行で、JSONオブジェクトは未整形で、タイムスタンプはUnixエポック形式。
そのJSONの塊をコピーして、JSONフォーマッターに貼り付ければ、突然エラーレスポンスが読めるようになります。
フォーマッターのタブは常に開いたままにしています。インシデント中は数分おきに使って、APIレスポンス、ログエントリ、設定ファイルを理解します。
ステップ4：推測するな、切り分けろ
疲れた脳は推測が大好き。「たぶんこれかな。あれを変えてみよう。」
これに抵抗してください。ランダムな変更を一つするたびに、不確実性が増します。元の問題が直ったのか、それとも修正が新しい問題を生んだのかわからなくなる。
代わりに：最小の入力でエラーを再現する。必要ないものをすべて削ぎ落とす。重要な変数を一つだけ見つける。
ステップ5：つまらないことをチェックする
コードに飛び込む前に確認：
- DNS: 正しく解決されているか？
- 証明書: 期限切れじゃないか？
- ディスク容量: サーバーが満杯じゃないか？
- メモリ: リークしてないか？
- 依存関係: 外部APIが落ちてないか？
モニターにこの5項目の付箋を貼っています。インシデント中、まずこれらをチェック。実際のコードバグよりも、これらが根本原因だったことの方が多いです。
深夜2時のデバッグツールキット
アラートで起こされた時に開くブラウザタブ：
- テキスト差分 — 設定、環境変数、デプロイファイルの比較用
- JSONフォーマッター — APIレスポンスとログエントリの読解用
- 正規表現テスター — パターンでログを検索する用
- プレーンテキストエディタ — 試したことのメモを書く用
最後のやつ、思っている以上に重要です。深夜2時の短期記憶はゴミです。何を試して何が起きたかを書き留める。未来の自分が過去の自分に感謝します。
インシデントの後
火が消えたら、すぐに寝ないでください。5分だけ書き留める：
- 何が壊れたか
- なぜ壊れたか
- 何で直ったか
- 次回どう防ぐか
明日にはこれを覚えていません。今書き留めましょう。
最高の深夜2時のデバッグは、賢いことではありません。体系的であること。設定を差分。エラーを読む。ログを整形。つまらないことをチェック。書き留める。これが全プレイブック。