サイト監視とアラート：可用性・証明書・フォーム・クローラー異常

サイト監視とアラート：可用性・証明書・フォーム・クローラー異常

一、発見までの時間が損失の規模を決める

まず境界を整理します。月次メンテナンス毎月決まって行う作業を説明し、バックアップ演習バックアップが復元できるかを説明し、インデックス診断インデックス異常の調査方法を説明しますが、本記事では前提となる1つの問題だけを扱います。これらの作業が発見・実行される根拠はどこから来るのか。監視がなければ保守は手探りになり、監視があって初めてアラートが具体的な故障を指し示します。

企業サイトの事故の多くは壊滅的ではなく慢性的です。証明書の期限切れでサイト全体が開けない、フォームが1週間静かに失敗し続ける、インデックス数が気づかないうちに半減する。それぞれの損失を表で整理します。

一言で言えば、監視にお金を払って買うのはソフトウェアではなく発見までの時間です。週単位から分単位に縮めれば、問い合わせの損失は「全部失う」から「数件漏れる」に変わります。これがすべての意味です。

二、5種類の監視項目としきい値の一覧

5種類の監視でB2B公式サイトの重要な経路をすべてカバーします。しきい値はそのまま使えます。

この表が記事全体の核心で、以降のセクションで設定の詳細を展開します。設定が適切かどうかの判断基準もシンプルです。この表を一行ずつ見ながら「誰が見ているか、どのくらいの頻度で見るか、異常時に誰へ通知するか」と問いかけてください。3つの問いのうち1つでも答えられなければ、その行は設定されていないのと同じです。

三、可用性と証明書・ドメインの設定詳細

可用性監視で最も設定を間違えやすいのが、プローブの位置と判定条件です。

証明書とドメインのスケジュールは、記事全体で最も手間がかからず効果が確実な項目です。これは「事後アラート」ではなく「事前通知」だからです。

DNS 変更のアラートは省略されがちですが、これはドメインハイジャックの最初のシグナルです。名前解決が書き換えられてもサイト自体には異常がなく、トラフィックだけが他人の元へ流れます。この項目は毎日のコストがほぼゼロなので、設定する価値があります。

四、フォームメールとクローラーによるインデックス

フォーム監視のロジックは「ページが開けるかどうか」ではなく、「送信後にちゃんと届いているか」です。ページは正常なのに配信経路が切れているのは、B2B サイトで最も見つけにくく最も高くつく障害です。顧客は問い合わせを送ったつもりなのに、こちらには 1 通も届いていません。

クロールとインデックス監視は高頻度である必要はなく、週1回で十分です。見る指標は3つ。主要URL（トップページ、主要製品ページ、問い合わせページ）のクロールステータスコード、sitemap送信後のクロールエラー数、インデックス数の前週比。インデックス数は自然に変動するため、前週比20%以内の減少なら心配不要です。20%を超えた場合、または2週連続で減少した場合に初めてアラートを出す価値があります。クロールステータスの異常時の具体的な調査方法はインデックス診断の記事に完全な手順があり、監視は「確認すべき時だ」というシグナルを正確に届ける役割だけを担います。バックアップタスクの結果は毎日成功・失敗を確認するだけで十分で、復元能力そのものは監視ではなく訓練によって担保されます。

五、アラートのレベル分け、チャネル、誤報対策

全量アラートはアラートがないのと同じです。スマホが10回鳴っても誰も対応せず、11回目に本当の障害を見逃します。レベル分けの核心は、重大度ごとに異なるチャネルを使い、異なる担当者に届けることです。

誤報対策には一つ厳格なルールがあります。3ヶ月連続で誤報が多い監視項目は、しきい値を調整するか無効にするかの二択で、第三の選択肢はありません。各アラートルールには必ず担当者を紐付ける必要があります。アラートを受け取っても誰も対応しないルールは、設定していないのとほぼ同じです。よくある誤報源とその対策：ネットワークの揺らぎによる単発失敗（2回連続判定で解決）、CDNキャッシュにより内部ページの障害が検出できない（フォームページの検出ポイントを追加）、メールサービスプロバイダによるテストメールのマーク（固定テストメールアドレスをホワイトリストに追加）。

六、当番対応と新規サイト公開チェックリスト

アラートが鳴った後に何をするかは、発生前に決めておく必要があります。3段階のアクションを時間順に進めます。

当番体制は「誰が深夜に対応できるか」の一点で十分です。B2Bサイトは24時間の人的当番は不要ですが、P0アラートには少なくとも深夜に起こされ、サーバー権限を持つ人が必要です。この人がいなければ、監視をどれだけ整えても「翌朝に知る」だけです。

新規サイトの納品時に監視を一度に整え、構成は5つの監視と3人の受信者で固定します。

7. アラートデータから改善を逆算する方法と、自前で構築しない判断基準

監視は火消しだけでなく、改善の入口を見つけるセンサーでもあります。四半期ごとに振り返りを行い、3つの数字を見ます。アラートの総件数、そのうち実際の障害が占める割合、繰り返し発生している障害の種類です。実際の障害の割合が30%を下回るなら、ルールが騒がしすぎるので絞り込みが必要です。同じ種類の障害が四半期に2回以上起きたら、「アラートで気づく」段階から「恒久的に修正する」段階へ引き上げるべきです。たとえばメール配信が繰り返し不安定になるなら、そのアラートを残すのではなく送信方式を変えるべきです。この振り返りは月次保守の四半期版議題に組み込み、定例で進められます。

自前で構築しなくてよいケースも明確にしておきます。ほとんどのB2Bサイトに自前の監視体制は必要ありません。サードパーティのプローブサービスの最小構成3項目、つまり可用性、証明書の期限、フォーム送信が、損失の最も大きい3種類の障害をカバーし、コストはほぼゼロです。自前での構築を検討するのは2つの場合だけです。フォームの経路が複雑でサードパーティのプローブでは測定できない場合、またはコンプライアンス上、監視データを自社環境の外に出せない場合です。サイトの現状に合わせてこの監視とアラートを整える手助けが必要な場合は、こちらからお問い合わせ。

FAQ よくある質問

最後に

監視体制の価値はすべて1つの式に集約できる。損失は障害時間×単位時間あたりの損失。監視は前者を時間から分に圧縮する。5種類の監視を第2節の閾値で揃え、3段階のアラートを担当者ごとに通し、誤報を四半期ごとに収束させる。この3つを終えれば、サイト障害は「災難」から「ToDo」に格下げされる。

覚えておくべき判断は1つだけ。監視が買うのはソフトウェアではなく発見時間。担当者不在のアラートルールは、設定していないのと同じ。