小規模Webサイトの監視：通知を受けた後まで設計する

生きていることと使えることは別

サーバーが応答しても、エラー画面やログイン失敗が続いている場合があります。トップの表示だけでなく、会社にとって重要な経路を選び、期待した内容まで確認する方法を検討します。試験で本物の注文やメールを大量に作らないよう、監視用の経路を設計します。

内部指標は原因を調べるために使う

Google SREでは遅延、トラフィック、エラー、飽和が監視の基本指標として説明されています。小規模サイトでも、この考え方を起点に、応答時間、エラー件数、空き容量等を整理できます。すべてを高頻度で保存する必要はなく、調査に使う目的を明確にします。

通知条件は通常時を見て決める

一時的な遅延まで毎回緊急通知すると、重要な通知を見落としやすくなります。継続時間、連続失敗回数、業務時間、予定された作業を考慮します。逆に通知を抑えすぎて障害の発見が遅れないよう、実際の発生履歴で調整します。

一次対応の短い手順を用意する

通知には対象URL、発生時刻、症状、直前の変更、確認先を添えます。担当者は事業者の障害情報と自社側の状態を切り分け、判断できなければ決めた窓口へ引き継ぎます。無条件の再起動を最初の動作にすると、証跡や原因が失われる場合があります。

通知には対象、検知時刻、症状、最初に見る情報、連絡先を含めます。同じ障害の通知が連続する場合のまとめ方も決めます。平常時に通知先を試験し、迷惑メール振り分けや担当変更によって受信できなくなっていないか確認します。

導入・見直しのチェックリスト

• 通知を受ける担当と代理は決まっていますか。
• メンテナンス時の扱いを決めましたか。
• 通知から調査へ進む手順がありますか。