中小企業の会社サイトなら、外部の監視サービスにURLを登録し、停止時にメールやチャットで知らせる構成から始められます。自社で監視サーバーを作る必要はありません。

まずトップページと、お問い合わせや予約など重要な入口が対象になります。監視できる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と発生時刻が分かれば、保守会社へ具体的に相談できます。最初から細かな内部監視を増やすより、必要な通知が届き、確認先が分かる小さな構成の方が続けやすいかと思います。