監視対象を段階的に増やす
| 段階 | 確認するもの | 分からないこと |
|---|---|---|
| URL監視 | 接続、ステータス、応答時間 | 業務機能の成功 |
| 内容監視 | 想定した文字列や要素 | 外部メールの到達 |
| 機能監視 | ログイン・送信などの処理 | 監視対象外の操作 |
| 内部監視 | CPU、容量、PHP、DB | 利用者の回線状況 |
誤検知と見逃しを減らす
単一拠点の通信失敗とサイト全体の停止を分けるため、再試行や複数拠点の確認を検討します。CDNのキャッシュが正常ページを返していても、接続元サーバーで障害が起きることがあります。監視先と実際の配信構成を合わせます。
通知後の行動を決める
通知先、受付時間、代替担当、一次確認の期限、エスカレーション先を定めます。監視が24時間でも、人の復旧作業が24時間提供されるとは限りません。契約上の対応時間と混同しないようにしてください。
定期的に監視自体を試す
通知テスト、期限切れの監視、認証情報の変更、監視URLのリダイレクトを点検します。機能テストで実データを増やさないよう、専用アカウントと削除方法も用意します。
通知後の手順を試す
テスト通知を発生させ、担当者が受信し、サイトの状態を確認し、必要な人へ連絡できるか試します。受信だけでなく、休日や不在時に誰へ引き継ぐかまで確認してください。実際のサイトを停止させず、監視サービスの試験機能を使える場合は活用します。
監視データの読み方
一回の応答遅延と継続停止は分けます。タイムアウト時間、再試行、計測地点が違えば停止時間も変わります。月次報告では計測条件をそろえ、計画停止や監視側障害をどう扱ったかを説明します。
よくある質問
フォームを毎分実送信すべきですか?
実送信は通知の大量発生や個人情報の保存、利用上限に影響します。接続監視、画面確認、業務に合わせた到達試験を組み合わせ、専用データと通知先を使います。
監視が正常なら問い合わせ機能も正常ですか?
通常のURL監視だけでは判断できません。送信API、スパム認証、メール配送などの監視対象を確認し、実際に何を検知できるかを整理します。