朝6時半。スマホのアラームで目が覚めた。
昨夜は0時過ぎまで新機能のデプロイをしていた。寝る前に本番URLを確認して、ちゃんと表示されているのを見て、満足してベッドに入った。
朝のルーティンは決まっている。アラームを止めて、メールを確認して、Slackを見る。
Slackに、ハッチからメッセージが来ていた。午前2時。
おい、お前のサイト落ちてるぞ。502 Bad Gateway出てる。
502 Bad Gateway。
一瞬、意味がわからなかった。昨夜寝る前は動いていたのに。血の気が引くのを感じた。自分が作ったサービスが、インターネット上で死んでいる。
布団から飛び出して、MacBookを開いた。ブラウザにURLを入力する。
白い画面に「502 Bad Gateway」の文字。
冷や汗が出た。人事の仕事で冷や汗をかいたことは何度もある。内定辞退の連絡を受けたとき。退職交渉が決裂したとき。でも、あのとき感じた冷や汗とは質が違う。
人事のミスは、時間をかけて修復できる。退職した人の穴は、新しい採用で埋める。評価の誤りは、次の評価期間で正す。でも、本番環境が落ちている今、全世界からアクセスできない状態が続いている。リアルタイムの障害だ。
$ fly status App: arata-app Status: suspended Instances: 0 running
$ fly logs 2026-02-22T02:13:44Z [error] Out of memory 2026-02-22T02:13:44Z [error] Process exited with signal: killed 2026-02-22T02:13:45Z [info] Starting clean up
Out of memory。メモリ不足。
昨夜追加した機能が、メモリを食い尽くしていた。データを一括で読み込む処理を入れたのだが、データ量が想定以上に多くて、サーバーのメモリが足りなくなったらしい。
本番が落ちてる。Out of memoryって出てる。どうすればいい
落ち着いてください。まず現状を整理しましょう。
- 即座にやること：前のバージョンにロールバックして、サービスを復旧する
- そのあと：原因を特定し、修正してから再デプロイする
ロールバックの方法は、fly releases で前のリリースを確認して、fly deploy --image で前のイメージに戻せます。
ロールバック？ 前に戻すってこと？
はい。問題のあるバージョンを使い続けるのではなく、動いていた前のバージョンに戻すことです。まず復旧を最優先にしましょう。
「まず復旧を最優先に」。この言葉が、パニック状態の僕の脳を少しだけ冷却した。
ロールバックは、やってみると意外と簡単だった。前のバージョンに戻すだけだ。5分もかからなかった。
$ fly deploy —image registry.fly.io/arata-app:deployment-v3 ==> Deploying image —> v5 deployed successfully
サイト確認: 200 OK 復旧完了。ダウンタイム: 約4時間45分（02:13〜06:58）
4時間45分。深夜2時から朝7時まで、サイトが落ちていた。
正直に言えば、僕のサイトにアクセスする人なんてほとんどいない。たぶん、誰にも気づかれていない。でも、それは問題じゃない。本番環境を壊したという事実は変わらない。
復旧後、ハッチに報告した。
復旧した。ロールバックってやつで前のバージョンに戻した。ダウンタイム約5時間。
おつ。ちゃんとロールバックできたじゃん。それが一番大事。
で、原因は？
昨夜追加した機能がメモリ食い過ぎてた。データを全件一括読み込みしてた。
あー、ページネーションしてなかったか。本番のデータ量は開発環境と違うからな。
それ、テストしてたら気づけたかもな。
テスト。その言葉が刺さった。テストなんてしていない。動いたから本番に出した。「出してから直せ」と言っていたハッチが、今度は「テストしてたら」と言う。矛盾じゃないかと一瞬思ったけど、違う。「出す」と「テストせずに出す」は別物だ。
その朝、僕はクロにテストの前に聞いたことがある。
test が本番にデプロイされてるから、本番環境のものは前のものにもどしてほしい
本番環境を前のバージョンに戻しましょう。テスト用のコードが本番に入ってしまったということですね。
本番デプロイ前にステージング環境でテストするフローを作ることをお勧めします。具体的には：
- developブランチで開発
- ステージング環境でテスト
- 問題なければmainブランチにマージ
- mainからの自動デプロイで本番反映
このフローなら、テストコードが直接本番に出ることを防げます。
テストコードが本番に出た。笑い話のようだけど、僕は本当にやった。開発と本番の区別がついていなかった。
人事の世界で言えば、社内の人事評価シートを、うっかり求職者向けの募集要項として外部公開してしまったようなものだ。大事故だ。
この日から、僕のコードの書き方が変わった。
【ポストモーテム（障害振り返り）】 日時: 2026-02-22 02:13〜06:58 影響: サイト全体がダウン（約4時間45分） 原因: データ全件一括読み込みによるメモリ不足 根本原因: テスト未実施、ステージング環境なし
再発防止策:
- デプロイ前にローカルでテストする
- データ読み込みはページネーションを使う
- ステージング環境を構築する
- デプロイは深夜にしない（問題が起きても対応できる時間帯に）
ポストモーテム。障害の振り返りレポートだ。クロに「エンジニアは障害のあとに何をするの？」と聞いたら、この概念を教えてくれた。
犯人探しではなく、プロセスの改善に焦点を当てる。誰が悪いかではなく、何が足りなかったかを考える。
これ、人事のインシデント対応と同じだ。ハラスメントが起きたとき、加害者を罰するだけでは再発は防げない。組織構造やコミュニケーションフローの問題を見つけて、仕組みを直す。
ポストモーテムって、人事のインシデント対応と似てるね。
その通りです。ポストモーテムの文化は、エンジニアリング組織の成熟度を示す指標の一つです。「Blameless（犯人探しをしない）」な振り返りができる組織は、障害から学び、強くなります。
Blamelessな文化。それは、人事が作るべき組織文化でもある。
壊した朝は辛かった。でも、壊したからこそ学んだことがある。テストの重要性、ステージング環境の必要性、ロールバックの手順、そしてポストモーテムの文化。
本番環境を壊したのは、39歳の人事。でも、ロールバックして、原因を特定して、再発防止策を立てたのも、39歳の人事だ。
壊すことを恐れていたら、何も作れない。