サーバー障害時の緊急連絡フローを事前に整備する方法

「サイトが落ちた！誰に連絡する？」と慌てないために。障害発生時の連絡体制・エスカレーションフローを事前に設計する実践的な手順を解説します。

「サーバーが落ちた。で、誰に電話すればいい？」

こんな経験はありませんか？

月曜の朝、出社したらお問い合わせフォームへのメールが届いていた。「昨日からサイトにアクセスできない」——慌ててブラウザを開くと、真っ白な画面。あるいは 500 Internal Server Error の文字。

このとき多くの現場で起きるのが、「誰に連絡すればいいかわからない」という混乱です。制作会社に電話すべき？ホスティング会社のサポートに問い合わせる？それとも社内のエンジニアに連絡？こうした判断に時間を取られているあいだにも、サイトは落ちたまま。売上機会やブランドへの信頼が削られていきます。

この記事では、障害発生時にチームが迷わず動けるよう、緊急連絡フローを事前に設計・整備するための具体的な手順をお伝えします。フロー図・シェルスクリプト例・連絡先テンプレートも交えて解説しますので、読み終えたあとすぐに自社の体制に落とし込める内容です。

なぜ「緊急連絡フロー」が整備されていないのか

中小規模のWeb運用現場では、連絡フローが整備されていないケースが非常に多く見られます。その背景には、いくつかの共通した原因があります。

「障害なんて滅多に起きない」という楽観が最も典型的です。確かにクラウドインフラの安定性は年々向上していますが、ソフトウェアの更新失敗・プラグインの競合・メモリ枯渇・証明書の期限切れなど、障害のトリガーは日常的に潜んでいます。「起きてから考える」では手遅れになります。

次に、属人化した運用体制の問題があります。「サーバーのことはAさんしかわからない」という状況は、Aさんが休暇中や退職後に致命的なリスクになります。

さらに、ベンダーの連絡先が散在していることも一因です。ホスティング会社・ドメイン管理会社・CDNプロバイダ・メールサーバー事業者——それぞれの緊急連絡先が誰も把握していない、というケースは珍しくありません。

弊社がサポートしているあるECサイト運営会社では、深夜にサーバーが落ちた際に「ホスティング会社のサポート電話番号が見つからず、翌朝まで復旧できなかった」という経験をされていました。その後、弊社と一緒に連絡フローと障害対応マニュアルを整備した結果、次回の障害では初動対応まで15分以内に完了できるようになりました。

緊急連絡フローの設計手順

ステップ1：関係者と役割を洗い出す

まず、サイト運営に関わる「人」と「組織」を全員リストアップします。役割ごとに整理すると以下のようになります。

flowchart TD
    A[障害検知] --> B{誰が気づいた？}
    B -->|社内担当者| C[第一次確認]
    B -->|監視ツールのアラート| C
    B -->|顧客からの連絡| C
    C --> D{サーバー側の問題？}
    D -->|Yes| E[ホスティング会社に連絡]
    D -->|Noまたは不明| F[制作会社・エンジニアに連絡]
    E --> G{解決した？}
    F --> G
    G -->|No| H[エスカレーション：上長・経営層に報告]
    G -->|Yes| I[原因記録・再発防止策の検討]
    H --> J[必要に応じ外部ベンダー追加対応]
    J --> I

このフローを「誰が読んでも理解できる形」で文書化しておくことが重要です。

ステップ2：連絡先マスターシートを作成する

連絡先は、以下のテンプレートをベースに整理します。スプレッドシートや社内Wikiに登録しておき、必ず複数名が参照できる場所に保管してください。

# 緊急連絡先マスター（サンプル）

## ホスティング・インフラ
- ホスティング会社: ○○株式会社
  - サポートURL: https://support.example.com
  - 緊急電話: 03-xxxx-xxxx（24時間対応）
  - 契約ID / ログイン: LastPassの「サーバー管理」フォルダ参照

## ドメイン管理
- レジストラ: △△
  - 管理画面URL: https://...
  - 担当者メール: [email protected]

## 制作・保守会社
- Fivenine Design
  - 通常窓口: [email protected]
  - 緊急連絡（保守契約者専用）: 担当者直通 / Slack #緊急対応

## 社内エスカレーション
- 第一連絡先: Web担当 山田（内線 xx / 携帯 090-xxxx-xxxx）
- 不在時: サブ担当 鈴木（内線 xx）
- 深夜・休日: 上長 佐藤部長（携帯 090-xxxx-xxxx）

ステップ3：監視アラートを設定して「気づく仕組み」を作る

連絡フローがあっても、障害に気づかなければ意味がありません。簡易的な死活監視であれば、無料ツールの UptimeRobot を使うと5分間隔での監視が可能で、メール・Slack・SMSへのアラート通知にも対応しています。

さらに踏み込んでサーバー側でも監視したい場合は、cronでシンプルなヘルスチェックを組む方法があります。

# /usr/local/bin/health_check.sh
#!/bin/bash

URL="https://your-site.example.com"
SLACK_WEBHOOK="https://hooks.slack.com/services/xxx/yyy/zzz"
NOTIFY_EMAIL="[email protected]"

HTTP_STATUS=$(curl -o /dev/null -s -w "%{http_code}" --max-time 10 "$URL")

if [ "$HTTP_STATUS" != "200" ]; then
  MESSAGE="[警告] サイトが応答していません。HTTPステータス: ${HTTP_STATUS}\nURL: ${URL}\n時刻: $(date)"

  # Slack通知
  curl -s -X POST -H 'Content-type: application/json' \
    --data "{\"text\": \"$MESSAGE\"}" \
    "$SLACK_WEBHOOK"

  # メール通知
  echo "$MESSAGE" | mail -s "[緊急] サイト障害検知" "$NOTIFY_EMAIL"
fi

# crontab -e に追加（5分ごとに監視）
*/5 * * * * /usr/local/bin/health_check.sh >> /var/log/health_check.log 2>&1

<?php
// app/Console/Commands/SiteHealthCheck.php

namespace App\Console\Commands;

use Illuminate\Console\Command;
use Illuminate\Support\Facades\Http;
use Illuminate\Support\Facades\Log;

class SiteHealthCheck extends Command
{
    protected $signature = 'site:health-check';
    protected $description = '外形監視：サイトの死活確認';

    public function handle(): void
    {
        $targets = config('monitoring.urls', []);

        foreach ($targets as $url) {
            try {
                $response = Http::timeout(10)->get($url);

                if ($response->failed()) {
                    $this->notifyFailure($url, $response->status());
                }
            } catch (\Exception $e) {
                $this->notifyFailure($url, 'TIMEOUT or CONNECTION_ERROR');
            }
        }
    }

    private function notifyFailure(string $url, string|int $status): void
    {
        $message = "[障害検知] {$url} が応答していません。ステータス: {$status}";
        Log::critical($message);

        // Slack Webhookへの通知
        Http::post(config('monitoring.slack_webhook'), [
            'text' => $message,
        ]);
    }
}

ステップ4：障害レベルを定義する

すべての障害に同じ対応をするのは非効率です。事前に重大度を定義しておきましょう。

よくある失敗パターンと対処法

失敗1：「口頭で共有していた」連絡先が誰も知らなかった

よくあるのが「Aさんが管理している」と思っていたら、そのAさん自身もどこかにメモしたまま見つからないケースです。連絡先は必ず文書化し、Slack・Notion・Googleドライブなど複数名がアクセスできる場所に保存してください。Slackチャンネルのピン留めは特に有効です。

失敗2：「深夜は誰も気づかない」体制のまま運用していた

前述の監視ツールを設定していても、通知先が個人のメールアドレス1件だけでは、担当者が寝ていたら誰も気づきません。Slackのチャンネル通知（@channel）やSMSを組み合わせ、必ず複数名に届く設定にしましょう。

失敗3：フローを作ったが誰も読んでいない

「緊急対応マニュアル」を丁寧に作っても、平時に一度も確認されないまま棚に眠っているケースは非常に多いです。弊社では、半年に1度「障害対応訓練」として連絡フローを声に出して確認するロールプレイを推奨しています。訓練で初めて「このベンダーの連絡先が変わっていた」「担当者が変わっていた」に気づけます。

失敗4：原因究明より復旧優先にしすぎて再発した

障害が落ち着いた後、「とりあえず直ったからOK」で終わらせると、同じ原因で再び落ちます。障害後72時間以内に簡易ポストモーテム（振り返り）を行い、原因・対応内容・再発防止策を記録する習慣をつけましょう。

# 障害振り返りテンプレート

## 発生日時
20xx/xx/xx xx:xx〜xx:xx（影響時間: xx分）

## 障害の概要
（例）WordPressプラグインのアップデートによりDBコネクションが枯渇

## 検知・対応の経緯
- xx:xx: 監視アラートがSlackに通知
- xx:xx: 担当者が確認・制作会社に連絡
- xx:xx: 原因特定・プラグインをロールバック
- xx:xx: 正常復旧確認

## 根本原因
（例）stagingでのテストなしに本番へ直接プラグインをアップデートした

## 再発防止策
- [ ] プラグイン更新はstaging確認後に実施するルールを明文化
- [ ] 更新前の自動バックアップを設定

緊急連絡フロー整備の効果

上記は弊社クライアントの事例を参考にした参考値ですが、フロー整備の効果は「初動の速さ」に如実に現れます。復旧時間そのものはインフラ側の問題に依存しますが、「誰に連絡するか判断する時間」はゼロに近づけることができます。

まとめ：今週中にやっておくべき5つのこと

緊急連絡フローの整備は、一度作ってしまえばあとはメンテナンスするだけです。「いつか作ろう」と思いながら障害が起きてから後悔するケースを、弊社は何度も見てきました。まず今週中に以下を実行してください。

「うちはまだ大丈夫」という現場ほど、いざというときに動けないものです。サーバー障害は「もし起きたら」ではなく「いつか必ず起きる」ものとして備えることが、Web担当者としての責務です。

連絡フローの設計や保守体制の整備について、「何から手をつければいいかわからない」という方は、ぜひ一度ご相談ください。弊社では保守契約の中で緊急連絡フローの整備支援も行っています。神奈川を拠点に、長年にわたって中小企業のWeb運用を支えてきた実績を、貴社の安心なサイト運用にお役立てください。