WordPress本番切替を土壇場で止め、旧サーバーの畳み方を決めた

知人から連絡が来た。旧WordPressサイトを動かしているVPSを見てくれている人で、PHPの期限が切れていること、バックアップの仕組みが入っていないことを指摘してきた。保守を引き受けてもいい、という申し出だった。

言われるままに頷いてもよかった。だが提案を鵜呑みにする前に、まず自分の目で確かめることにした。

指摘は当たっていた

PHPのバージョンを見ると、セキュリティサポートはすでに切れていた。バックアップの設定を探しても、自動で取得する仕組みはどこにも見当たらなかった。

指摘の2点は、どちらも事実だった。ここまでは、まだ想定どおりだった。

WordPress本体とデータベースの手動バックアップを取ることにした。サーバー上でファイルを固め、ローカルへ落とし、ハッシュ値を突き合わせ、圧縮ファイルの中身まで壊れていないことを確かめた。ここまでは順調だった。

つまずいたのは、その先だ。サーバーに残っている管理者権限のあるアカウントが、手元に見当たらない。心当たりのあるパスワードを一つずつ試したが、全部弾かれた。

正面から入れないなら、別の入り口を探すしかない。

サーバーの起動プロセスを経由すれば、今のパスワードを介さずに管理者権限を取り戻せる手段が残っていた。ただし手順を一歩間違えると、サーバーごと起動しなくなる作業でもある。

この作業はブラウザ越しの遠隔コンソールを使う必要があった。自分では手を出さなかった。 Codex CLIに手順ごと委譲し、結果だけを見守った。

しばらくして、権限を取り戻したという報告が返ってきた。既存のサービスは無停止のまま動き続けていることも、あわせて確認できた。

鍵が全滅した先に、起動プロセスから回り込むという道が残っていた。そこに気づけたことで、詰みを避けられた。

権限を取り戻したあと、判断すべきことが一つ残っていた。自動バックアップの仕組みまで、恒久的に整えるかどうかだ。

このサーバーは、別のプロジェクトで近く退役させる予定になっている。恒久的な保守契約を結んでまで維持する意味は薄い。ワンショットのバックアップは、もう手元にある。

延命ではなく、畳む。そう決めた。

作業の途中、接続時のログに出ていた失敗ログインの累積回数に、思わず二度見した。公開サーバーによくある雑音だろう、と最初は考えていた。

念のため認証まわりの設定を辿ってみると、雑音では済まない状態だった。外部から総当たりを受けやすい設定が残ったままになっていたので、その場で締め直し、反映まで確かめた。

新しいパスワードそのものが実際に機能するかを、別の経路で二重に確かめる作業も検討した。だが接続がうまく繋がらず、これ以上時間を使う理由がないと判断して見送った。退役が決まっているサーバーに、保険の保険までかける必要はない。

保守提案は、もともと本題ではなかった。本題は、旧WordPressサイトをNuxt Contentへ移す、もっと大きな移行プロジェクトのほうだ。その本番切替が、同じ日のうちに回ってきた。

記事の変換もアセットの移設も、残っていた懸案の決着も、別セッションによる検証も、すべて済んでいた。残るは本番切替そのものだった。

DNSを向け替えれば、旧サイトの代わりに移行先サイトが世に出る。不可逆で、しかも現役で動いている事業サイトの話だ。各ステップの直前に必ず立ち止まって確認する、という条件だけをつけて進めることにした。

準備は淡々と進んだ。コミットを済ませ、現在のDNS設定とロールバックの手順を書き残し、切替の確認画面まで辿り着いた。旧サイトを指すレコードを、移行先を指すレコードへ置き換える。その一歩手前だった。

画面の裏側で、移行先サイトのトップページを開き直してみた。挨拶文が一枚あるだけで、200本を超えるはずの記事への入り口が、どこにもなかった。

手が止まった。止めた。設定は何も変えていない。

読者が最初にたどり着く場所に、読むべきものへの道がない。それを本番と呼ぶわけにはいかない。

中止した作業は、そのまま記録に残した。到達した画面の中身、設定値、ロールバックの手順、すべてを手順書に書き写し、コミットした。旧サーバーは止めず、切替後もロールバック先として当面残す、という前提も変えていない。

代わりに、次へ進むための条件が一つ、はっきりした。トップページに全記事のインデックスを作ること。それができて初めて、確認画面の続きに進んでいい。

保守提案から始まった一日は、権限を失っては取り戻し、畳む対象を見極め、切替の手前で自分から手を止めるところまで進んだ。どちらのときも、最後に手を止めるかどうかを決めたのは自分だった。

#WordPress移行#サーバー運用#本番切替#意思決定記録