症状
ロールバック後も障害が続く
中級以上の開発者、リリース対応を持つ人、障害対応の練習をしたい人向け
ロールバックは戻せば終わりではなく、設定・キャッシュ・依存状態のズレまで疑う必要があります。その初動を整理する入口です。
想定検索意図
ロールバック 失敗 本番 戻らない 確認ポイント
向いている人
中級以上の開発者、リリース対応を持つ人、障害対応の練習をしたい人向け
おすすめの進め方
症状を読む → 確認ポイントを押さえる → 関連シナリオで実際に手を動かす、の順で進めるのが最短です。
まずは自分の困り方がこのテーマに合っているかを確認します。
ロールバック後も障害が続く
一部のリクエストだけ失敗する
キャッシュや環境差分が残っている可能性がある
上から順に見ていくと切り分けが進みます。 途中で原因が分かればそこで止めて構いません。
リポジトリを戻したこと と 動いている実体が戻ったこと は別。 ビルド成果物、 配布されたアセット、 起動中のプロセスが古いままということが起きる。 バージョン番号やコミットハッシュを実際に応答させて、 意図した版が動いているかを目で確かめる。
ロールバックで戻らないものが必ずある。 データベースのマイグレーション、 外部サービス側の設定、 発行済みのキャッシュ。 コードだけ戻すと、 新しいスキーマに古いコードが当たって別の壊れ方をする。 何が前に進んだかを先に書き出す。
全部ではなく一部だけ失敗する場合、 配信の階層のどこかに古い応答が残っている可能性が高い。 CDN、 プロキシ、 ブラウザのキャッシュを順に切り分ける。 hard reload で直る人と直らない人が混在するなら、 手前の共有キャッシュが残っている。
本番だけ再発するなら、 依存パッケージの版、 ファイルの権限、 使っているポートといった 環境側の差分を疑う。 同じコードでも動く環境と動かない環境が分かれるのはここ。
復旧の直後は 「何が戻って何が戻らなかったか」 が分かっている唯一の時間帯。 次に同じことが起きたとき、 この記録があるかどうかで復旧時間が変わる。 原因ではなく 「ロールバックで戻らなかったもの」 を書き残す。
読んで終わらせず、そのまま手を動かせるシナリオに絞っています。