HCM ウェブサイトの緊急修復: 500/404、ハッキング、インターフェイスの破損、支払いエラー

広告の掲載中や販売のピーク時にウェブサイトが「調子が悪くなった」場合、一分一秒が無駄になります。この記事は、ホーチミン市の企業向けのP1 標準緊急対応ハンドブックです。インシデントの特定方法、最初の 2 時間の「消火」手順、データ リスク管理、持続可能な復旧ロードマップです。

1) 迅速な特定: どのような状況に直面していますか?

P1 グループ - 直ちに対応する必要があります

• HTTP 500: 空白page/「内部サーバー エラー」、ログは PHP 致命的/タイムアウト、バックエンド サービスの停止を報告します。

• バッチ HTTP 404/ソフト 404: 間違ったリダイレクト、展開/移行後に変更されたスラッグ、サイトマップ エラー。

• ハッキング/悪意のあるコード: 奇妙なポップアップ、別のドメイン、ファイルにリダイレクト.php が奇妙です。Google が「このサイトはハッキングされている可能性があります」という警告を出します。

• インターフェースの破損: CSS/JS が読み込まれていない、サードパーティのスクリプトの衝突、テーマ/プラグインの更新エラー。

• 支払いエラー: Webhook/支払いゲートウェイのタイムアウト、二重請求、注文が作成されていないCMS。

予兆

• GA4 セッションが突然低下。離脱率が異常に増加しました。

• 稼働時間モニターがダウンし、CPU/RAM が急増しました。

• Search Console でエラー 5xx/404 が増加しました。 Merchant Center が商品を拒否します。

2) 「ゴールデン 2 時間」ルール (最大損失)

1. 変更の凍結: すべての負荷の高いデプロイメント/プラグインの更新/Cron を一時停止します。

2. セーフ メンテナンス モードを有効にする: 必要な場合のみ (データが公開されるなど)

3. 現在のステータスのスナップショット: タッチする前に、データベース + バックアップ ファイル wp-content/app をエクスポートします。

4. ログと監視をオンにする: サーバー ログ (Nginx/Apache)、PHP-FPM、アプリケーション (error.log)、ゲートウェイログ。

5. 優先 P1 最初に P2: アクセス、支払い、広告ランディング ページを復元し、その後、美しく最適化します。

明確な SLA を備えた 24 時間年中無休のオンコール プロセスが必要な場合は、ホーチミン ウェブサイト メンテナンス サービス (柱記事、P1 レスキュー プロセスの完全な説明、チェックリスト、シフト割り当て) を参照してください。 Tan Phat Digital: ホーチミン ウェブサイト メンテナンス サービス。

3) インシデント処理プロセス

A. HTTP 500 / ホワイト ページ

• デバッグとログを有効にする: WP_DEBUG_LOG (WP)、APP_DEBUG (Laravel)、エラー トレースを確認します。

• 高速ロールバック: 500 を超えると最新のビルド/バックアップに戻ります。

• 元のアカウントを解放します: PHP-FPM を再起動し、OPcache をフラッシュし、DB 接続 (max_connections) を確認します。

• プラグイン/テーマを一時的に無効にします: サイトが最初に存続するようにエラーの原因となっているフォルダーの名前を変更し、後で元のフォルダーを修正します。

B.バルク 404/ソフト 404

• パーマリンクの復元 (WP)、ルート (フレームワーク) の再構築。

• 移行/再構築後に変更された URL の 1-1 301 マッピング。

• クリーン サイトマップ: URL のみが含まれます。 200 – インデックス可能 – 正規。 GSC を再送信します。

「トラフィックの移行とドロップ」の場合は、チームが標準化した月次メンテナンス プロセス (反復エラーの監視と防止のための SOP) に含まれる P1 ～ P3 (ロボット、301 マップ、正規、サイトマップ) に従って処理します: 月次 Web サイト メンテナンス プロセス。

C.ハック/マルウェア

• すべてのパスワードを隔離して変更します (ホスティング、DB、管理者、SFTP、API)。

• スキャンとクリーン: 奇妙なファイルを見つけ、署名を難読化します (base64/gzinflate/eval)。クリーンなコアを置き換え、wp-content/uploads を保持します。

• アップデートとパッチ: CMS/プラグイン/テーマのバージョン、古い匿名プラグイン タイプ、書き込みロック wp-config.php。

• WAF/CDN: ファイアウォール (レート制限、ボット ルール) を有効にし、攻撃元 IP をブロックします。 2FA 管理をオンにします。

• 検索で警告された場合は、 再審査をリクエストします。

D.インターフェイスが壊れています (CSS/JS)

• キャッシュ/CDN をパージ; 404 静的バンドルがバージョンと衝突していないか確認します。

• テーマ/プラグインのバージョンをロールバックします。一時的な自動更新ロック。

• 競合するスクリプトを切り離す/無効にする (チャット、ピクセル、A/B テスト) → 条件付きでロードします。

E.支払いエラー

• ログ制御: Webhook (200/400/500)、CMS の注文ステータス、cron キュー。

• フェールセーフ: 支払いは成功したが注文が作成されなかった場合、手動注文を補正し、顧客に通知します。

• タイムアウトを増やし、再試行: ゲートウェイ/Webhook で、SSL/TLS と IP の許可リストを確認します。

4) 商用サイト (WordPress/Woo、Shopify、カスタム) の「酸素呼吸」チェックリスト

WordPress/WooCommerce プラットフォーム

• 「奇妙な」プラグインをオフにし、新しく更新されたプラグインをロールバックします。

• .htaccess/permalink を再生成します。

• 挿入された mu-plugins を削除し、シェルの wp-content/uploads をスキャンします。

• Woo キュー (アクション スケジューラ) を確認し、 webhook。

Shopify

• テーマのバージョンをロールバックします。新しくインストールしたアプリをオフにして、カート/チェックアウトを再度テストします。

• checkout.liquid (Shopify Plus) に挿入された ScriptTag/アプリを確認します。

Custom/Laravel/Next.js

• Healthcheck DB/キャッシュ/キュー。ロールバックビルド。 .env 接続変数を確認してください。

• SSR/CSR を確認してください: バンドル エラー、Nginx でのルートの書き換え。

5) コミュニケーションをとり、被害を最小限に抑えます (黙ってはいけません)

• バナー/FAQ/FB ファンページのステータス メッセージ: 修正予定

• エラー ページまで広告を一時停止します。予算をホットライン/チャット チャネルに転送します。

• 保留中の注文に関する顧客ケア: 妥当な補償 (クーポン/送料無料) への取り組み。

6) インシデント ブックの終了: RCA と強化 (24 ～ 72 時間後)

1. RCA – 根本原因分析: タイムライン、根本原因、

2. SOPification: 環境に応じた 500/404/ハック/支払いプレイブック。

3. 強化:

   • 2FA、最小原則に基づく分散化。

   • 3–2–1 バックアップ: 3 コピー、2中、1 オフサイト。毎月のテスト復元。

   • 稼働時間とコア Web バイタルの監視。

4. 毎月カオスデー: 30 分間のロールバック/復元訓練。

再発を防ぐために定期的に運用する「引き継ぎ」チームが必要ですか? ウェブ メンテナンス パッケージ (速度/セキュリティ監査、勤務時間、インシデント レポートを含む) に切り替えることができます: ウェブ メンテナンス サービス.

7) 「迅速対応チーム」に対する SLA の提案

• P1 – サイトダウン/ハッキング/支払いエラー: シフトの受け入れは 15 分以内、基本アクセスの復元は 15 分以内120 分。

• P2 – インターフェースが壊れ、404 の小規模グループ: ≤ 24 時間。

• P3 – 速度の最適化、テクニカル SEO: 1～2 週間のスプリント。

• コミュニケーション チャネル: Slack/Zalo グループ、24 時間年中無休オンコール スケジュール。P1 の場合、毎日更新されます。P1 の場合は 30 ～ 60 分です。

8) よくある質問

P1 がダウンしたサイトを復元するのにどのくらい時間がかかりますか?
近くにバックアップとサーバーへのアクセスがある場合、通常30 ～ 120 分です。ディープデータのハッキング/破壊には4 時間かかる場合があります。

サイトにパッチを適用している間、広告を掲載することは可能ですか？
問題が発生しているページでは広告を一時停止する必要があります。ホットライン/チャット チャネルまたはランディング ページのキャンペーンを一時的に保持します。

マルウェアがクリーンかどうかを確認するにはどうすればよいですか?
署名をスキャンし、コア差分をクリーンアップし、cron/管理エントリ ポイントをチェックし、送信接続を監視し、24 ～ 48 時間後に再スキャンします。

技術的な修正後もトラフィックがすぐに返されないのはなぜですか?
SEO では、Google が再度クロール/インデックスを作成する時間が必要です。販売 Web サイトの場合、全体のトラフィックの前に収益が回復します。

9) インシデント後に「最低限必要な」設定

• 毎日の自動バックアップと展開時のスナップショット。

• ステージングが必要。運用環境に投稿する前にチェックリストを確認してください。

• モニタリング:稼働時間、エラー ログ、CWV、成功した支払い率。

• 権限とログ: 所有者、マネージャー、開発者。

サイトの障害は避けられませんが、明確な P1 プレイブック、適切なアクセス、バックアップ/監視の習慣、導入時の規律があれば被害は制御可能です。正しい順序 (アクセスの復元 → 感染対策 → 修復 → 強化) で処理すると、最初の 2 時間 以内にシステムを安定した状態にし、繰り返しを回避できます。