最初に残す情報
製品名、変更前後の版、更新日時、症状、影響するURL・操作、関連ログを記録します。他の更新やサーバー設定変更が同時にないかも確認します。偶然同じ時刻に発生した別障害もあるため、「直後だから確定」とは判断しません。
症状別の切り分け
| 症状 | 確認するもの |
|---|---|
| 500・真っ白 | PHPログ、必須条件、欠損ファイル |
| 見た目の崩れ | HTML・CSSの変更、キャッシュ |
| 保存・送信できない | API応答、WAF、JavaScript、外部接続 |
| 特定機能だけ失敗 | アドオン、独自コード、設定移行 |
原因製品を限定して確認する
管理画面へ入れるなら対象を一つずつ確認します。入れない場合はサーバーから対象フォルダーを一時的に変更する方法もありますが、製品停止で保護や公開制限が解除される場合に注意します。検証環境で旧構成と新構成を比較し、停止時だけでなく必要な製品を組み合わせた状態も試します。
旧版へ戻す前の判断
旧版のファイルが信頼できるか、DBに変更が入ったか、既知の脆弱性がないかを確認します。製品がDBを移行した場合はファイルだけ戻すと壊れる可能性があります。サイト全体の復元では、その間の投稿・注文・登録が失われるため差分の扱いを決めます。
暫定復旧の条件を残す
旧版運用、機能停止、アクセス制限などの措置は、責任者・理由・期限を記録します。セキュリティ修正前へ戻すなら、再更新や代替製品への移行を並行して進めます。
復旧後の検証と問い合わせ
問題の操作、管理画面、フォーム到達、定期処理、エラーログを確認します。提供者へ相談する際は再現手順、版、匿名化したログを渡し、本番のパスワードや個人情報を公開しないようにします。原因と新しい確認項目を更新手順へ追加します。
業務影響から復旧方法を選ぶ例
会社案内の装飾だけが崩れた場合と、受注や会員認証が停止した場合では優先度が違います。後者では公開制限や代替受付を検討し、現在の取引データを保存します。旧版へ戻すだけでDBとの整合性が保てるか、復元で失われる差分はないかを確認して判断します。一時停止で直った場合も、該当製品を今後使わないのか、修正版待ちか、組合せの改修が必要かを決めます。保留の期限を置かないと、必要機能の停止や脆弱な旧版が通常運用として残ってしまいます。
提供者へ報告するときの書き方
「期待した結果」「実際の結果」「再現手順」「更新前後の版」「WordPress・PHP・テーマ」「匿名化したログ」をまとめます。全ての本番DBや秘密情報を先に渡すのではなく、再現に必要な最小資料から共有します。外部サービスの条件や独自改修も明記します。
キャッシュ削除で直れば原因はキャッシュですか？
関連する手掛かりにはなりますが、設定変更や再試行の影響が混ざる場合もあります。同じ条件で再現し、どの層が古い内容を返したかを確認します。
更新後に設定が変わることはありますか？
既定値や保存形式、DB移行が変わる製品があります。更新案内と変更履歴を読み、重要設定と実際の動作を比較します。