ウェブサイトの稼働時間を監視する方法：ステップバイステップガイド

ほとんどのチームは、サイトがダウンしていることを顧客のメール、ソーシャル投稿、あるいは静かにフラットラインしている営業ダッシュボードから知ります。人間が気づく頃には、障害は苦情があった分の時間ずっと続いており、被害はその前から始まっています。

稼働時間監視は単純な仕組みでそのギャップを埋めます：あなたのネットワーク外からスケジュールに従って自動的にサイトにチェックを送り、レスポンスがおかしいか全く返ってこない瞬間にアラートを発生させます。設定は数分で終わります。正しく機能させるには、ほとんどのチュートリアルが省略するいくつかの判断が必要です。なぜなら、デフォルトのままの監視は実際の障害を見逃し、架空の障害を誤検知しやすいからです。

このガイドは7つのステップでそれらの判断を説明します：「アップ」の定義、チェックの種類の選定、頻度の設定、複数ロケーションからの検証、アラートの配線、誤検知のフィルタリング、SLAに基づく稼働率の報告。

7つのステップをつなぐアイデアは一つ：監視を単一のチェックではなく「真実の積み重ね（truth stack）」として扱うことです。DNSは名前解決を証明し、TCPはサービスへの到達性を証明し、TLSはブラウザの信頼性を証明し、HTTPはアプリケーションの応答を証明し、コンテンツ検証は正しいページが表示されていることを証明し、ジャーニーモニタリングは訪問者がタスクを完了できることを証明します。外側から内側へ積み上げるスタックを構築し、アラートは単に「サイトダウン」と言い訳するのではなく、どのレイヤーが失敗したのかを明らかにします。

ステップ1：サイトにとって「アップ」の意味を定義する

最も怠惰な「アップ」の定義は「サーバが応答する」です。これが人々を傷つける定義でもあります。ホストはウェブサーバプロセスが停止していてもpingには応答することがあります。ウェブサーバはメンテナンスページ、半分だけレンダリングされたテンプレート、あるいはDNSハイジャック後の他者のコンテンツを200 HTTPコードで返すことがあります。訪問者にとってそれらは「アップ」とは言えません。

「ダウン」の3つの状態を明確にすることが助けになります。ハードダウン：ホストが全く応答しない。ソフトダウン：200を返しているがデータベースエラーや空のテンプレート、DNSハイジャック後の他者のコンテンツを返している。ファントムダウン：サーバは健康だが壊れたCDNエッジや地域のルーティング障害がサイトを一部のユーザーから隠す。ハードダウンしか捉えない監視はより頻繁に起きる2つの状態を見逃します。

なので何かを設定する前に、サイトが真に利用可能であるために何が満たされる必要があるかを書き出しましょう：

• ドメインが正しいアドレスに、迅速に解決されること。
• 重要なページが成功ステータスコードで応答すること。重要とはホームページや失敗すると金銭的損失や信頼に関わるページ：チェックアウト、ログイン、サインアップ、重要なAPIエンドポイント。
• レスポンスに正しいコンテンツが含まれていること。ページが正しくレンダリングされた場合にのみ現れるキーワードや要素。エラーテンプレートが200で返ってもチェックは失敗。
• 証明書が有効であることと、ユーザーとして許容できる時間内にレスポンスが届くこと。

このリストは単なる手続きではありません。リクエストが実際に失敗する層に直接対応しており、DNS、TCP、TLS、HTTPのそれぞれで異なる方法で失敗します。一つのレイヤーだけ確認するチェックは他の3つに盲目です。このリストはどのURLを監視するかも決めます：サイト上の全ページではなく、あなたの定義にあるページだけです。

ECサイトの場合、ホームページの監視はこう書けます：3秒以内に200を返し、「Free shipping」を含み、証明書の有効期間が14日以上あり、期待されるCNAME経由でCDNへ解決される。チェックアウトの監視はより厳格です：200を返し、「Order Summary」を含み、決済プロバイダーのスクリプトが無い場合は失敗。両方のURLはアップとみなしますが、同じ定義ではありません。

ステップ2：稼働時間チェックの種類を選ぶ

定義を書いたら、それぞれを検証するチェックを選びます。五つのチェックタイプでほとんど全ての稼働時間シナリオをカバーでき、それぞれは全体の体験の証拠と扱うと誤解を招きます：

HTTPおよびHTTPSチェック

基盤となるチェックです。URLへリクエストを送り、ステータスコードを確認し、適切に設定されていればレスポンスボディにキーワードが含まれるかも確認します。成功範囲外のコード（一般的な4xxや5xx ステータスコード）は失敗とみなします。コンテンツの確認が「サーバが応答した」から「ページが正しく読み込まれた」を区別します：200でエラーテンプレートを返しても単純なチェックは通りますがキーワードチェックは失敗します。

Ping（ICMP）チェック

ICMP ping監視はホストが到達可能か確認し、レイテンシやパケットロスを測定します。安価で高速、ネットワークレベルのトリアージに有用ですが、唯一のチェックとしては弱いです。なぜならWebサーバがダウンしていてもpingに応答できることや、一部のネットワークがICMPを優先度低またはブロックするからです。

TCPポートチェック

TCPポートチェックは特定のポートが接続を受け入れるかを確認します。ウェブトラフィックなら443、メールなら25、アプリケーションのカスタムポートなど。ホストはpingに応答し正常でもサービスプロセスがクラッシュし、ポートが接続を拒否する中間障害を検出します。

DNSチェック

DNS監視はドメインが期待通りのレコードに解決されるかを確認し、解決時間も追跡します。期限切れ登録、誤レコード変更、プロバイダ障害でDNSが止まると、すべてのサーバが健康でもサイト全員に対してダウンになります。チームが最も忘れがちな故障モードです。

SSL証明書チェック

SSL証明書監視は有効期限や検証チェーンの問題を追跡します。期限切れ証明書は実質的な障害で、多くのブラウザは全画面警告を表示し多くの訪問者が進みません。証明書寿命が短くなる中、カレンダーリマインダーだけでの期限管理は通用せず、30日、14日、7日前にモニターでカウントして警告するべきです。

理にかなった開始の積み重ねは：重要ページごとにコンテンツ検証付きのHTTP(S)チェック、加えてドメインのDNSと証明書チェック、ネットワーク問題とアプリ問題を区別するためにpingとTCPチェックを併用。

ステップ3：適切なチェック頻度を設定する

チェック間隔は検知速度の上限です。障害が良好なチェックの直後に起きると、次のチェックで検知されるまでほぼ間隔の全期間放置され、さらに検証やアラートの時間が加算されます。

可用性目標に照らすと遅延は高コストです。99.9%の月間目標は約43分のダウンタイムを許容します。5分間隔のチェックは、問題が誰も気づかないまま予算の1割以上を失う可能性があり、これは真のダウンタイムコストの一部です。検知予算として考え、月間許容の10%を最初の通知までの許容とすると約4分となり、5分間隔はエスカレーションの議論に入る前に除外されます。収益で言えば、1時間あたり5,000ドルのサイトは5分間の死角で400ドル以上の損失です。実務上のルールは：

• 収益に直結するターゲットは毎分チェック：チェックアウト、ログイン、支払いAPI、正式なSLA下のもの。
• 標準的なマーケティングサイトやコンテンツページは3〜5分毎。
• 内部ツール、ステージング環境、重要度の低いサービスは15〜60分毎。

軽量なHTTPチェックは高頻度で実行してもコストが安いです。重いブラウザベースのチェックは通常遅いスケジュールで実行され、基本チェックの上に層を成します。間隔と地理の関係の詳しい解説は監視頻度とロケーションのガイドを参照してください。

ステップ4：複数のロケーションから監視する

単一の監視ロケーションは単一の視点だけを提供し、そのために二つの障害状態が同時に起こります。特定地域のみを襲う障害（壊れたCDNエッジ、ジオDNS誤設定、ISPとホスト間のルーティング問題）を見逃し、そのロケーションのネットワーク問題を誤検知として受け入れてしまいます。

ユーザーの居場所に合わせたロケーションを選びましょう。北米とヨーロッパをサービスするサイトは、両米国西海岸と少なくとも一つのヨーロッパの都市からチェックされるべきで、一国の単一データセンターでは足りません。グローバルな監視ネットワークを持つDotcom-Monitorのようなプラットフォームは、大陸間にチェックポイントを選択でき、実際のユーザー視点を把握します。

複数のロケーションはクロス検証も可能にし、ステップ6に依存します。一つの場所で障害が報告された場合、サイトダウンと宣言される前に他の場所から再チェックされます。本物のインシデントでは地理的パターンが最初の診断になります。すべての場所で失敗はオリジン、グローバルDNS、証明書、失敗したデプロイを指し、特定地域での失敗はCDNエッジや地域ルーティング、ローカルプロバイダを指します。HTTPは全場所で通ってコンテンツ検証だけ失敗は誤ったテンプレートやキャッシュされたエラーを示します。それぞれのパターンは異なるベンダーへ異なるチケットを切るべきであり、ロケーションの内訳は誰かがサーバを再起動する前に必ず読まれるべきです。

ステップ5：アラートとエスカレーションの設定

検知は正しい人が対処して初めて意味があります。最初のインシデントの前に、誰がどの故障についてどのチャネルでどの順番に知るか決めておきましょう：

• 深刻度に合ったチャネルを選ぶ。30日以内の証明書有効期限はメールで十分です。確定したハード障害は電話、SMS、チームが既に注視しているオンコールツールに届くべきです。アラート配信はメール、SMS、電話、Slack、Teams、PagerDuty等のツール統合を通じて可能です。
• 沈黙によるエスカレーション。最初のアラートはオンコールエンジニアに届きます。指定時間内に認識されなければ自動的に次の階層に移行します。誰にも見られなかったアラートは存在しなかったのと同じです。
• 単純な停止ではなく劣化にもアラート。応答時間が3倍になることはしばしば障害の前触れです。性能警告は二進のアップ/ダウンアラートでは得られない猶予を与えます。
• 計画メンテナンスは無音に。スケジュールされたウィンドウ中はデプロイで誰も呼ばれないようにし、発生したアラートの信頼性を守ります。

アラート自体を契約として書きましょう：何がどこでどれくらいの時間失敗し、最後の正常チェックから何が変わったか。「フランクフルトとロンドンから2回連続のチェックアウトコンテンツチェック失敗、DNSとTLSは通過、『Order Summary』が見つからず、最後の成功は09:41 UTC」は対応者に仮説の出発点を与えます。「サイトダウン」だけではサイレンです。

閾値、ルーティング、エスカレーション階層のより詳しいルールはウェブサイト監視アラートの実践を参照してください。

ステップ6：誤検知を排除する

誤検知は監視プログラムの寿命を縮めます。夜中3時の数回の無意味なページングでオンコールエンジニアは本物の通知も無視しだします。誤警報の大半は以下四つの原因から来ます：チェックポイントとサイト間の一時的なネットワークノイズ、サイトの通常行動よりも厳しいタイムアウト設定、監視場所自身の問題、そしてモニターに伝えられていないデプロイ。

それぞれに直接的な対策があります：

• アラート前に2箇所目から確認。一つの失敗チェックはすぐに他のチェックポイントから再検証を呼び、ページングはしません。Dotcom-Monitorでは一つの場所が異なる結果を返すと他の全選択ロケーションからもチェックが行われ、単一チェックポイントの不調だけでチームに通知されることはありません。
• タイムアウトは希望でなくデータに基づく。サイトの実際の応答時間＋余裕を設定し、動作は遅いが正常なページはパフォーマンス警告にしてファントムダウンを避けます。
• 接続だけでなくコンテンツも検証。キーワードによる主張は双方向に効きます：ステータスコードが見逃すソフト障害を発見し、遅い第三者ウィジェットだけが問題の場合にページダウンと誤認しません。チェックは必須要素に基づきます。
• デプロイはカレンダーに登録。メンテナンスウィンドウは最も安価な誤検知対策です。

その後、週次レビューで残ったノイズを3つに分類します：不適切な視点、閾値設定ミス、アップ定義の誤り。不適切な視点は複数ロケーションで確認、閾値の誤りはサイトの実データで再設定、アップ定義の誤りはより厳密なコンテンツ検証で対処。どれにも当てはまらないアラートはノイズのままにして本当の障害まで感知を遅らせるより理解するまで放置しましょう。

ステップ7：SLAに対して稼働時間を計測する

すべてのチェック結果は恒久的な可用性記録に送られ、その記録が監視を煙探知機から証拠に変えます。稼働時間の目標は抽象的に聞こえますが分単位に変換すると実感できます：

算数は以前の頻度のアドバイスを説明します：フォーナインの場合、5分間隔のチェックは月間予算全体より多いダウンタイムを見逃す可能性があります。自身の目標を可用性計算機にかけてSLAが実際に何分を約束しているか確認してください。

記録は独立して保持してください。ホストやCDNがSLAを約束しても、クレジット請求はプロバイダのステータスページではなく自分の外部計測データに基づきます。その証拠は堅実かつエクスポート可能であるべきで、タイムスタンプ、チェックポイントロケーション、解決されたIP、TLS結果、HTTPステータス、応答時間、失敗した主張が含まれます。ステータスページのスクリーンショットは議論材料ですが、ロケーションが刻まれたチェック履歴は証拠です。クレジット申請時でも自身の公開ステータスページの根拠としても使えます。スケジュールされた稼働時間とSLAレポートは記録を自動で利害関係者の受信箱に届け、チェックやロケーションごとに分類します。この分類は重要です：健康なグローバル平均は火曜日丸一日ダウンしていた地域を隠すことがあります。

稼働時間を超えて：ユーザージャーニー全体を監視する

上記は一つの質問に答えます：「サイトに到達可能で正しく応答しているか？」。カタログ検索、カート追加、支払い、ログインは複数ページ、スクリプト、第三者サービスをまたぎ、単一URLチェックでは触れられません。

マーケティングチームにとってスクリプト化する価値があるジャーニーはキャンペーンが約束する道筋です。有料検索で「無料トライアル開始」へ訪問者を送るなら、そのスクリプトはランディングページを読み込み、CTAをクリックし、テスト安全なデータでフォームを埋め、サンキューステータスを確認すべきです。キャンペーン中にその経路が壊れれば、ホームページの稼働率は虚飾の指標となります。

これが合成監視の仕事です：スクリプト化された実ブラウザセッションが重要なジャーニーを一歩ずつ進み、壊れた正確なステップを報告します。EveryStepのようなレコーダーを使えば、チェックアウトやログインフローはコードを書くことなく繰り返し監視できるスクリプトになります。ここにある7ステップが固まったら、トランザクションレベルの監視が自然な次の層です。

まとめ

ウェブサイト稼働時間の監視を正しく行うには、真実の積み重ねを構築することが必要で、単にボックスにチェックを入れることではありません。ビジネス用語で「アップ」を定義し、防御すべきダウンの状態を明確にします。HTTP、ping、TCP、DNS、証明書チェックでリクエストが通る全ての階層をカバーし、それぞれのチェックの誤解を理解し、SLAが許す検知予算で運用します。ユーザーがいる場所から検査を行い、仮説を伝えるアラートを書き、無応答時はエスカレーションし、ページ通知前に確認し、実際の可用性をロケーションとチェック別に独立してエクスポート可能な記録を残しましょう。

こう設定すれば、稼働監視は単なるチェックボックスではなく、顧客より何分も先に問題を知らせる最初のシステムになります。その先手が全てです。

よくある質問