構成と依存関係を記録する
本体、PHP、テーマ、プラグイン、独自コードの版を一覧化し、変更履歴と必須条件を照合します。有料製品は更新の利用権も確認します。本番だけに置かれたファイルやMUプラグインも対象にします。
作業可否を判断するチェック項目
- 直前バックアップがあり、復元経路を確認している。
- フォーム・受注など、停止すると困る機能を列挙している。
- テスト用アカウントとデータを用意している。
- 作業時間、承認者、緊急連絡先が決まっている。
- 復旧への切替条件と、中止時刻を決めている。
一項目でも未確認なら、影響と緊急性を整理してから進めます。重大な脆弱性への対応では、準備不足を理由に放置せず、利用制限を含む対策を判断します。
作業を実施する順序を決める
検証環境へ反映し、依存関係に沿って小さな単位で更新します。PHP更新、本体更新、キャッシュ変更を同時に行うと、障害原因が分かりにくくなります。必要な変更を分離し、各段階で確認します。
完了条件を作業前に共有する
「更新が終わった」ではなく、代表ページ、ログイン、保存、検索、フォーム到達などの確認項目を定めます。社内担当者の承認が必要な業務機能は、作業時間内に確認してもらえるよう調整します。
中止条件を共有する例
作業終了予定から復元に必要な時間を逆算し、「この時刻までに原因が絞れなければ戻す」と決めます。フォームや決済が失敗した場合、トップの表示が正常でも中止判断の対象にします。作業中に承認者が不在になると判断が遅れるため、連絡手段も確認しておきます。
更新通知がない製品の点検
有料製品、独自製品、配布終了した製品では、更新情報を管理画面だけで把握できないことがあります。配布元と契約者を台帳に残し、通知方法や代替の確認経路を用意します。
よくある質問
バックアップ取得後に記事を公開してもよいですか？
更新と復元の計画によります。復元対象にその記事が含まれないなら、作業後の差分回収や再取得が必要です。更新時間中の書込みルールを先に共有します。
ステージングで成功すれば本番確認は省けますか？
省けません。サーバー、URL、外部許可、キャッシュなどの差があるため、本番でも主要機能とログを確認します。検証先で確認できなかった項目は明示しておきます。