広告掲載時にウェブサイトがダウン: 2 時間以内の P1 処理プロセス

ウェブサイトが広告予算を使い果たしているときに「突然病気」になった場合、その損害は広告費の使い果たしだけでなく、注文の喪失、評判の低下、社内の混乱などにも及びます。このサテライト記事では、P1 のトラブルシューティング プロセスを 2 時間でガイドします - 実践的かつ簡潔、チェックリスト付き - で、 広告予算の損失を削減 しながら、チームが冷静に Web サイトをできるだけ早く復元できるようにします。

これは、HCM のメンテナンス サービスに関するメイン記事の補足記事です。完全なロードマップ (SLA、プロセス、ツール) が必要な場合は、ウェブサイト メンテナンス サービス ホーチミン - ピラー ページ.

「広告が実行中に停止する」ときの典型的な状況

• TVC/インフルエンサー/パフォーマンスによる強力なポンピングによる突然の負荷 → CPU/RAM/DB が「真っ赤に燃えている」、完全な接続を待機する行、Web タイムアウト。

• キャンペーン実行前に急いでアップデート (プラグイン/テーマ/コア) → 競合、PHP/JS エラー、空白のページ。

• 弱いインフラストラクチャ: キャッシュ/CDN が最適化されておらず、DB のインデックス/キャッシュがありません。

• まさに「落下点」で DDoS/レイヤー 7 攻撃 – 競合他社/ボットネットからの疑惑。

• 支払い/カートの問題: ゲートウェイのタイムアウト、Webhook の失敗 → ユーザーが支払い不能、収益の損失。

2 年の P1 目標時間

1. アクセス回復 (最小限のページのホームページ/ランディング/チェックアウト) を「十分な」レベルで実現します。

2. 予算の消費を削減: 広告チャネルを一時的なランディング、予算の削減、または制御された一時停止に調整します。

3. インシデント時間内に原因を特定し、 再発を防止します。フレーム。

4. テストを学習するために 24 時間以内の短い事後レポート。

120 分 (分単位) のプロセス

T-00 → T-15: クイックレビューと通知

• フレンドリーなメンテナンス ページを有効にする (503 + 再試行後) または静的フェイルオーバーの着陸 (HTML + フォーム/CTA)、制限付きバウンス。

• 内部通知 (マーケティング/CS/営業/創設者) を一文で: 「P1 – サイトのダウンタイム、ETA 120」 – 更新間隔15 分。」

• クイックチェック:

  • TTFB/稼働時間 (StatusCake/UptimeRobot)。

  • CPU/RAM/IO/DB 接続 (クラウド/ホスティング ダッシュボード) 呼吸」

    • 高値の疑いロード: CDN/WAF を有効/強化し、ページをキャッシュし、TTL を削減します。

    • コードの競合の疑い: 最新バージョン (Git/バックアップ) をロールバックし、疑わしいプラグインをオフにします。

    • DDoS レイヤ 7:攻撃中モード (Cloudflare) をオンにし、異常な IP/ASN をブロックし、重いエンドポイント レート制限 (/search、/cart、/checkout) を行います。

    • DB の輻輳: 遅いクエリ キャッシュをフラッシュし、一時的に max_connections を増やし、サービスを再起動します。必要です。

    T-30 → T-60: 回収を最小限に抑え、広告コストを削減します。

    • 販売/ランディング/チェックアウト ページのルートを最初に再開します。ブログ/紹介部分はそのままにしておいても構いません。

    • マーケティング:

      • サイトが安定していない場合: 予算を静的ランディング (AMP/静的 HTML、CDN) またはバックアップ リード フォーム (Google フォーム/タイプフォーム) に移します。

      • 30～70% 削減激しい攻撃を行っているチームの予算を、低品質のプレースメントを一時的に無効にします。

      • カスタマー サービスを更新します。「システムは緊急メンテナンス中です。ホットライン/受信箱から注文してください。」

    • クイック QA: デスクトップ/モバイル、ログイン/登録/カート/チェックアウト (サンドボックス)、リード フォーム、ピクセル/GA4/UTM。

    T-60 → T-90: 安定化および強化

    • 追加の保護:

      • ページ全体の HTML をキャッシュします (カート/チェックアウトを除く)。

      • JS を遅延/非同期にし、不要なスクリプトを無効にします。

      • 重大な機能制限: ライブ検索、比較、関連

    • インフラストラクチャ:

      • 一時的に vCPU CPU/RAM を増やし、可能な場合は自動スケールを有効にします。

      • 可能な場合はメディアを CDN に移動します。まだです。

    • DB:

      • 頻繁にクエリされるテーブル (注文、投稿、製品) の折りたたみインデックスを最適化します。

      • オブジェクト キャッシュ (Redis/Memcached) をオンにします。

    T-90 → T-120: 軽負荷と広告の再差別化を試す ADS

    • 軽負荷テスト (メイン ユーザー ジャーニー シナリオ 5 ～ 10 リクエスト/秒)。

    • 広告の再割り当て: 小さなグループで、負荷のしきい値に応じて徐々に増加します。

    • インシデント ログ:タイムライン – 予備的な原因 – 適用された変更 – バックログは後で実行します。

    役割設定とコミュニケーション チャネル (5 人で十分)

    • インシデント リード (DevOps/技術リード): 技術的な意思決定、15 分の更新。

    • ウェブ エンジニア: ロールバック、ホットフィックス、機能のオフ/オン、技術的な QA テクニック。

    • パフォーマンス/マーケティング: 広告/ランディング、カスタマー サービス メッセージを調整します。

    • CS/CRM: リード/注文を手動で受け取り、顧客を安心させ、フィードバックを総合します。

    • ステークホルダー (PM/創設者): 公開メッセージを承認し、ソースの力を優先します。

    チャネル: 1 つの一般的なチャット グループ (Slack/Telegram)、1 つのタスク ボード (Trello/Jira) → 情報の混乱を回避します。

    簡単な戦闘チェックリスト

    A.技術的 (2 時間以内に復元)

    • 503 または静的着陸 (CTA あり) を有効にします。

    • CDN/WAF: 攻撃中、レート制限、ボットとの戦い。

    • コード/プラグインをロールバックし、新しく更新されたものを無効にします。

    • 準重要なページを再度開きます。重い機能をオフにします。

    • Redis/Memcached + ページ キャッシュがいっぱいです。 DNS/CDN TTL を削減します。

    • DB: 一時的な接続を増やし、遅いクエリを最適化し、ロックされている場合は再起動します。

    • QA checkout/form/pixel/GA4/UTM。

    B.マーケティング/CS (予算の消耗を減らす)

    • キャンペーン予算を調整し、リスク グループを一時的にオフにします。

    • 静的なランディング/バックアップ フォームにリダイレクトします。

    • ファンページ/CS での簡単な通知: 緊急メンテナンス中です。

    • 手動のリード収集 (ホットライン/受信箱) – CRM に再入力します

    C.安定化後 (24 時間)

    • 事後分析: 根本原因 (RCA) + 予防措置。

    • インフラストラクチャ最適化計画 (キャッシュ/CDN/WAF/自動スケール)。

    • 訓練スケジュールと安全性の最新情報を復元します。

    全体的なメンテナンス状況を月ごとに理解するため (カレンダー、リズム、レポート）、月次ウェブサイト メンテナンス プロセスと戦略的観点を参照してください。 href="https://tanphatdigital.com/vi/blog/dich-vu-bao-tri-website-and-hau-mai-thiet-ke-website">メンテナンスとアフターセールスに関する記事.

    6 つの一般的な根本原因と「穴を塞ぐ」方法

    1. キャンペーン直前のコード/プラグインの競合
       予防: ステージング → QA → 導入チェックリスト付き。時間の 48 時間前にコードを凍結します。 監視: ヒット/ミス キャッシュ、TTFB。
       修正: フル ページ キャッシュをオンにし、メディアを CDN に移動し、スクリプトを削減します。

    2. DB の混雑 - クエリが遅い
       予防: インデックス、クエリ プラン、ページネーション、キャッシュを追加します。
       監視: 遅いクエリ ログ、
       修正: 負荷の高いクエリをすぐに最適化し、リソースを増やし、レプリカを分割します。

    3. 適切なタイミングでの DDoS/レイヤー 7
       予防: WAF、ボット管理、IP/ASN ごとのしきい値。
       監視: 異常なスパイク国/ASN。
       修正: 攻撃中、チャレンジ、ブロック範囲。

    自動スケール
    予防策: 負荷ベンチマーク、自動スケール、DB/ファイル ストレージの分離。
    解決策: アーキテクチャを計画するキャンペーンの後、構成を一時的にアップグレードします。

    通信メッセージのサンプル (短い – 安心させる – 代替案あり)

    「ご迷惑をおかけして申し訳ありません。トラフィックの突然の増加により、システムが一時的に停止しました。」技術チームは120 分以内に復旧します。バックアップ リンクですぐに注文するか、受信箱/ホットライン 09xx…にテキスト メッセージを送信してください。ご理解いただきありがとうございます。」

    インシデント後: P1 をなくす

    1. します。キャンペーン 48 ～ 72 時間。

    2. ステージングが必要 + QA チェックリスト、1 クリックでロールバック。

    3. CDN + フルページ キャッシュ + オブジェクト キャッシュは実際に機能します (ヒット/ミス測定)。

    4. WAF/ボット管理はピーク用にプリセットされています。

    5. 自動スケールを計画します（少なくとも一時的なスケールアップ）。

    6. DR/バックアップ: キャンペーン前のスナップショット。定期的に復元訓練を行ってください。

    7. ランブック「P1-Ads」: 誰が何をするか、どのチャネル、どのメッセージをメッセージにするか - 作戦室にすぐに投稿します。

    いつメンテナンス チームをアウトソーシングするべきですか?

    • 24 時間年中無休のオンコールがありません。またはDevOps が 1 つもありません。

    真剣に、Web メンテナンス サービス ページを参照して、適切なパッケージを選択してください。 HCM の長期的な戦略的視点 (SLA、役割、プロセス) が必要な場合は、ホーチミンにおけるウェブサイト メンテナンスの柱をお読みください。

    広告の掲載中にウェブサイトがダウンするのは、チームが明確なP1 ランブックを持ち、120 分以内の最小限の復旧を優先し、予算を適切に消費し、インシデント後にアーキテクチャの脆弱性を解決すればリスクを制御できます。次のダウンロードを待って計画を立てる必要はありません。

    キャンペーン シーズン中に「完全に安全」にするための 90 日間の計画が必要ですか?

    • 無料の60 分間の技術監査と特定の SLA 提案を受け取ります。

    • 詳細な記事とメンテナンス プロセスは毎月です。

    • または、ウェブ メンテナンス サービスでは、適切なパッケージに関するアドバイスを提供します。