死活監視は、Webサイトやサーバーが応答しているかを定期的に確認し、停止を担当者へ知らせる仕組みです。中小企業では多機能な監視基盤を最初から用意するより、止まると業務へ影響する入口を外部から確認する方法が続けやすいです。

導入の成否は、監視項目の数では決まりません。通知を受けた人が何を確認し、どの時点で制作会社やサーバー会社へ連絡するかまで決める必要があります。対応できない通知を増やさず、重要なURLから小さく始めます。

サイト監視との違いより運用範囲を明確にする

死活監視は「生きているか、停止しているか」を継続的に確かめる考え方です。WebサイトではURLへHTTPリクエストを送り、期待する状態コードや本文が返るかを見ます。サーバーのポート接続だけを確認する方法もありますが、ページが利用できることまでは分かりません。

実務では、死活監視とサイト監視を厳密に別製品として分ける必要はありません。誰のどの利用を確認するかが重要です。会社サイトなら、外部の利用者と同じ経路からトップページや問い合わせ入口を開く監視を基本にします。

サーバー内部で動くWordPressプラグインだけに監視を任せると、サーバーごと停止したときに通知できない場合があります。外部サービスからの確認を一つ持ち、必要に応じてサーバー会社の障害通知や内部ログを組み合わせます。仕組みの基礎はサイト監視とは？表示停止に早く気づくための基本で説明しています。

監視対象は業務影響を三段階で決める

最初に、停止したときの影響を「すぐ対応が必要」「営業時間内に確認」「記録だけ」に分けます。予約や購入の入口が事業の中心なら、トップページより優先度が高い場合があります。採用情報の一部だけが表示されない状態は、営業時間内の確認で足りるかもしれません。

一つ目の監視には、会社サイトのトップページを選びます。二つ目は問い合わせ・予約・購入など業務へつながる入口です。三つ目は、トップページと異なる仕組みで動くページを選びます。すべて同じWordPressから返るなら、固有の文字列も成功条件へ加えます。

メール・DNS・外部予約サービスは、Webページとは停止原因が違います。一つのURL監視で全部を正常と判断しません。メールが重要なら送受信テストやサービス側の監視を別に設計し、外部サービスにはその提供元の稼働情報も確認します。

監視間隔は復旧に動ける時間から逆算する

一分間隔にすれば必ず安全になるわけではありません。夜間に誰も対応しない体制なら、深夜の即時電話を増やしても復旧時間は短くなりません。停止から何分以内に状況を確認したいかと、誰が対応できるかを先に決めます。

一時的な通信失敗で毎回通知すると、誤報に慣れて重要な通知を見落とします。Amazon Route 53のヘルスチェックのように、確認間隔と連続失敗回数を組み合わせて異常を判定する考え方が使えます。回復通知も有効にし、停止が続いているのかを区別します。

監視間隔より短い停止は、確認と確認の間に起きて記録されないことがあります。月間稼働率を見るときは、監視地点・間隔・成功条件・計画停止の扱いも一緒に残します。数字だけをサーバー会社の保証値や業務全体の稼働率と比較しません。

通知先より先に一次対応の責任者を決める

主担当者と代替担当者を決め、どちらも通知を受け取れるようにします。会社サイトと同じドメインのメールだけを通知先にすると、DNSやメール障害の際に届かない可能性があります。別系統のメールや会社で利用するチャットなど、少なくとも一つは異なる経路を用意します。

通知には対象URL・検知時刻・状態コード・監視地点を含めます。一次担当者は別回線から確認し、サーバー会社やCDNの障害情報を見ます。直前の更新がある場合は作業担当者へ連絡し、原因が分からないまま設定を変更しないようにします。

Prometheusのアラート設計では、利用者へ見える症状と人が対応できる事象へ通知を絞る考え方が示されています。CPU使用率など原因候補をすべて緊急通知にせず、調査用の情報と分けます。担当者が行動を選べない通知は、内容か緊急度を見直します。

最小構成は一つずつ動作確認して増やす

最初の導入は次の順番で進めます。

  1. 停止時の業務影響と対応可能な時間帯を決める
  2. 外部から確認する重要URLを二つか三つ選ぶ
  3. 状態コードと変わりにくい本文を成功条件にする
  4. 監視間隔と連続失敗回数を設定する
  5. 主担当と代替担当へテスト通知を送る
  6. 通知後の一次確認と外部連絡先を一枚にまとめる

設定直後に、異常通知と復旧通知の両方を試します。サービスに一時停止やテスト機能がある場合は、それを使います。実サイトを止めて試す必要はありません。通知が迷惑メールへ入り、担当者が気づかないケースも確認します。

一か月ほど運用したら、誤報・見逃し・対応できなかった通知を見直します。必要があれば監視URLや条件を追加しますが、誰も見ない項目は削除または記録用へ下げます。料金よりも、通知を受けて動ける範囲を基準にします。

保守停止と担当者変更を監視設定へ反映する

計画メンテナンスでは、通知を削除せず保守時間として一時停止します。終了時刻を設定できる機能なら、自動再開を使います。作業後は監視が正常へ戻ったことを確認し、フォームなど業務機能は別に手動確認します。

担当者が変わったときは、通知先だけでなくサービスへのログイン権限も引き継ぎます。旧担当者の個人アカウントや私用メールを削除し、新担当者と代替担当者がテスト通知を受け取ります。監視契約の更新日と支払方法も会社の管理資料へ残します。

運用資料には、監視URL・成功条件・間隔・連続失敗数・通知先・対応時間・外部連絡先・最終テスト日を記録します。死活監視は停止を直す仕組みではありません。担当者が早く事実をつかみ、決めた順番で復旧へ動けるところまで設計して価値が生まれます。