サイト障害再発防止（運用ガイド）

Issue #2643 対応。2026-07-05 に発生した本番・ステージング同時全落ちの再発防止手順をまとめる。

障害の概要

項目	内容
直接原因	ConoHa ユーザークォータ超過 → wp-content/cache/php-di へ書き込み不可 → PHP-DI コンパイル失敗 → HTTP 500
間接原因	debug.log が 1.7GB に肥大化（Codoc プラグインの Deprecated 警告が大量出力）
共有要因	本番 uploads 174GB + ステージング wp-content 123GB で同一アカウントのクォータ上限付近

コード側の自動対策（本 PR 以降）

1. debug.log 自動ローテーション — WP-Cron で定期実行する。閾値・保持期間・排他制御は 保守クリーンアップバッチ を参照
2. 管理画面 — ツール → デバッグログ から手動ローテーション、100MB 超過時に警告表示
3. PHP-DI フォールバック — コンパイル失敗時は非コンパイル DI で起動継続
4. deploy-all — activate 後に古い core_* を tiered ポリシーで自動削除（最新5件常時保持・最大10件・6件目以降で2日超は削除）

debug.log 容量の目安: 高頻度出力時は debug.log + debug.log.* の合計が大きくなる。check-remote-disk.sh は debug.log 本体のみ監視するため、ローテーション後は debug.log.* も合わせて確認すること。ローテーションの詳細は 保守クリーンアップバッチ を参照する。

定期メンテ（推奨：月1回）

# 本番
./bin/check-remote-disk.sh

# ステージング
./bin/check-remote-disk-staging.sh

# 古い core_* のみ削除（deploy-all 以外で手動実行する場合）
./bin/clean-remote-builds.sh              # tiered（デフォルト）
./bin/clean-remote-builds.sh --keep 3     # 単純モード: 最新3件のみ残す
./bin/clean-remote-builds-staging.sh

check-remote-disk.sh は以下を確認する:

• wp-content 使用量
• debug.log サイズ（100MB 超で exit 1）
• cache/php-di への書き込み可否（クォータ超過の早期検知）

緊急復旧手順

サイトが「重大なエラー」で落ちた場合:

1. PHP-DI キャッシュ削除

   ./bin/clear-cache.sh          # 本番
   ./bin/clear-staging-cache.sh  # ステージング

2. debug.log のローテーション / 削除（クォータ解放）

   • 管理画面「デバッグログ」→「ログをローテーション」
   • または SSH で rm -f wp-content/debug.log && touch wp-content/debug.log（: > truncate は fd 保持で解放が遅れる場合あり）

3. *古い core* 削除_*

   ./bin/clean-remote-builds.sh

4. サイト表示確認 — HTTP 200 を確認

ConoHa クォータ確認

• サーバーパネルでディスク使用量・クォータ上限を確認
• uploads/ が 174GB 規模のため、クォータ増量または不要メディア整理が必要な場合あり
• 本番とステージングは 同一ユーザーアカウント のクォータを共有

デプロイ時の注意

• deploy-all.sh / deploy-all-staging.sh を使う（build → deploy → activate → clean-remote-builds → ヘルスチェック）
• deploy.sh のみ実行して activate.sh を忘れない（VERSION 切替 + DI キャッシュ削除）
• デプロイ前に ./bin/check-remote-disk.sh でクォータ余裕を確認

関連ドキュメント

• ADM-014 デバッグログ管理画面
• 保守クリーンアップバッチ
• event-master-introduction-guide.md — PHP-DI キャッシュ削除手順