サイトを停止させた話 ～慢心は敵！バックアップはゼッタイ！～

はじめに

本番環境などでやらかしちゃった人 Advent Calendar 2023 という Advent Calendar 2023 があることを知りまして、自戒を込めて投稿したいと思います。

この記事は、本番環境などでやらかしちゃった人 Advent Calendar 2023 の10日目です。

使用・登場するものたち

• iMac（使用PC）
• WordPress
• React
• X サーバー（ホスティング先）
• Cyberduck（FTPサーバー）

やらかし、その概要

2つあるのですが、やらかしとしては同じ内容（サイトを停止させてしまった）なのでまとめて書いていきます。どちらもホスティング先は Xサーバー を使用しています。

1：WordPressサイト運用において、FTP サーバー（Cyberduck）での操作ミスでサイトを停止させた話
2：React制のサイトでサブドメインへのホスティングにおける設定ミスでサイトを停止させた話

WordPressサイトでのサイト停止

結論から申すと、筆者の油断と慢心、知識不足が大きな原因です。

筆者の所属企業が管理するサイトの中に、サブディレクトリ型で運用しているWordPressサイトがありました。
筆者が入社する前に制作されていたもの（筆者入社時点で制作者は退職済み）で、サブディレクトリで分割しているもののマルチサイトの設定はしておらず個々が独立している独特な構成でした。

// ルート直下
wp-content
wp-includes
wp-admin
：
：
sub-A
 ｜- wp-content
 ｜- wp-includes
 ｜- wp-admin
 ：
 ：
sub-B
 ｜- wp-content
 ｜- wp-includes
 ｜- wp-admin
 ：
 ：
 ：
 ： 
sub-F

ルート直下にはドメインのWordPressサイト（https: //expample.com）があり、その同階層に（sub-A ～ sub-F までの）6つのサブディレクトリWordPressサイト（https: //expample.com/sub-A）がありました。

それぞれのサイトは自然言語が異なるだけで内容は同じでした。
そのため更新がある場合は、各サイトの同じ場所（ディレクトリ内のファイルやデータ）を都度更新・修正する作業を行っていて、作業前には更新箇所のファイルやデータをローカルにダウンロードしてから進めるように徹底していました。

ことが起きた際は、いつもより少し更新作業が多かったのでFTPサーバーでの作業中も次の作業を考えながら行う注意散漫な状態だったと思います。

sub-A サイトで作業を終了して、Sub-B サイトの作業に移ろうと Sub-B ディレクトリをダブルクリックした際にSub-B ディレクトリが消えました。
むちゃくちゃ焦って、とりあえず Sub-B サイト（https: //expample.com/sub-B）を見に行くと……404 File Not Found。

この時点で頭は真っ白になり、震えてきました。

実はディレクトリ移動（ダブルクリック）操作の際に、マジックマウスの左上が少し高さ調整していたマジックキーボードの右下端の ほんの隙間に引っ掛かり（はさまり？）一瞬ドラッグ操作 になって Sub-B ディレクトリ（ファイル）がルート直下の別ディレクトリ（フォルダ内）に移動していました。

今でも「そんなことある！？」と自分でもそう思うのですが、当時はむちゃくちゃ焦っていたこともあって復旧に必死でした。

復旧

元に戻すべくディレクトリの再移動（ドラッグ）操作を試みましたが、ディレクトリ内には日本語名のファイルやデータがいくつも散らばっていて、それら長年の負債のせいで再移動がうまくいきませんでした（※いくつかのデータが文字化けしていたのが原因）。
結局問題となっている日本語名のファイルやデータをしらみつぶしに削除してディレクトリの再移動を実施。

無事に復旧して動作不良がないことも確認しましたが、おそらく5分～15分はサイトが停止していたはずです。削除した日本語名ファイルやデータの中には使用しているものもあったので、それらはリネームして再アップ及び関連ファイルのデータ取得パスの記述修正も行いました。

今回のやらかしは、そもそも注意散漫の状態で作業をしていた反省点（慣れてるし大丈夫という慢心もあったと思います）をはじめ、負債の放置やFTPサーバーのショートカットへの知識が無いことなどが挙げられると思います。

また、日本語名ファイル・データに関してはローカルにバックアップを取っていたからこそ、文字化けしているデータを認識及び復旧もできたので バックアップは大切 という当たり前のことを再実感する体験でした。

ただ、やらかした内容が内容なので暫く猛省＆落ち込みました……。
（その程度で済んで良かったなという話ですが）

React制サイトでのサイト停止

こちらも先に結論を述べると、READMEへの記載漏れと自信過剰が原因です。

会社では筆者以外Reactを触る人はおらず、数か月前に自分で作ったサイトで起きたことです。
当該サイトは、新規制作案件だったのですが社内向けなので「好きな技術で作って良い」と上長よりお許しを得ていたためスキルアップを兼ねて興味のあったReactで作ることにしました。

筆者はviteを用いてReactを触っているのですが、ビルドした内容をサブディレクトリに配置するにはvite.config.tsに記述が必要です。

参考情報：

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react()],
  base: '/hoge/foo', // サブディレクトリを指定（例：hoge 内の foo に配置する場合）
})

今回のやらかしは、この記述（base: ....）を行わずにビルドしたものをサブディレクトリにホスティングしてサイトを停止させてしまったことです。

誠に恥ずかしながら、当時はvite.config.tsの設定のような大切なことは「自分がしっかり覚えているはず」とREADMEに記載していませんでした。

とある日、更新・修正作業を行いビルドしてホスティングしてOK～! と、サイトを見に行くと……真っ白の画面。リロードしても、スーパーリロードしても真っ白の画面。

setTimeout(()=> console.log('やらかしに気付いて胃がキュッとなる'), 500);

さながら、こんな感じの心境でした。

取り急ぎ、ログに出ていたエラー文をコピーして、すぐさまバックアップしていたローカルファイル（更新直前のビルドファイル）を再アップして元に戻しましたが、この時は何が原因か全く分かっていませんでした。
（サイトが停止していたのは数秒ほどかもですが、バックアップが無かったらと考えると今でも血の気が引きます）

復旧 原因解明

エラー文を（翻訳して）読んでもよく分からず、調べる中で Stack Overflow にたどり着き手掛かりを得ました。
内容としては「vite.config.ts触ってない？」といった感じで、この時に「あぁ！！触ってる～～～！」となりました。なんとも間抜けですね……。

手元のvite.config.tsを見てみると更新していましたが 「自分がしっかり覚えているはず」という慢心から誤った記述（サブディレクトリ設定を削除） をしていました。

無事、設定を正してホスティングして表示された時は安心感と惨めさから何とも言えない気持ちになりましたね。そしてすぐに「自分以外の人が触っても分かるような内容に！」を念頭にREADMEを修正・更新しました。

まとめ

ここまで読んでいただき、ありがとうございました。
恥を忍んで、そして懺悔する心持ちで記事を書いてきました。
筆者の失敗談を通じてバックアップの大切さへの再認識と、慢心は敵ということをお伝えできれば幸いです。