複数地域からの継続的なチェックを実行し、顧客が気付く前にアラートをルーティングする可用性監視ダッシュボード。[ /caption]
サイト所有者は通常、顧客と同じ方法でサイトがダウンしていることを知ります。サポートメール、チャージバック通知、または翌朝の分析ダッシュボードに表示されるチェックアウトの減少です。その時点でインシデントは数時間経過しており、収益は失われています。
ウェブサイトの可用性監視は、そのような事態が起こる前に障害を検知する手法です。しかし、「サイトが稼働しているか」という質問は見た目より難しいことが分かります。サイトはチェックアウトボタンが壊れているにもかかわらず200 OKを返すことがあります。米国からはアクセスできるがヨーロッパでは死んでいることがあります。技術的にはオンラインでも、DNSプロバイダーがタイムアウトしていたり、SSL証明書が午前2時に期限切れになっているためにユーザーには失敗していることもあります。
本ガイドでは、ウェブサイトの可用性監視の運用面を扱います：何をチェックし、どこからチェックし、どの頻度で実行し、アラートが発生したときに何をすべきか。対象は専用のダッシュボードを持つSREチームではなく、自分でサイトを運営するオーナー向けです。信頼できる監視をセットアップし、通知が来るまで無視できる状態を目指します。
「利用可能」が実際に意味すること
「サーバーが応答した」と「ユーザーが何かを購入できる」の間にはギャップがあります。可用性監視はそのギャップの間に存在します。
基本的なアップタイム監視チェックはURLにpingを送り、200ステータスコードを探します。これは最低限です。サーバーダウン、DNS障害、ネットワーク到達不可といった壊滅的な障害を検知しますが、もっと繊細な障害は見逃します。例えば、チェックアウトで500エラーを返すペイメントプロセッサ、空白ページを返すCDN構成、Safariでログインボタンを壊すJavaScriptエラーなどです。
真の可用性監視は複数のチェックを重ね、「サイトが稼働している」とは実際のユーザーが、実際のブラウザーを使い、実際の場所から来て、目的を達成できることを意味します。Dotcom-Monitorの用語集にはウェブサイトの可用性の正式な定義があり、詳しい説明を求める場合はこちらを参照してください。
一般的な実際の障害パターン：金曜夜のデプロイで新しい分析タグが導入されます。HTMLは全地域から200 OKを返すため基本的なアップタイムツールは週末中グリーンを報告します。月曜朝、Safariで第三者タグがチェックアウトフォームの送信ハンドラをブロックするためサポートには大量のチケットが来ます。リアルブラウザによるチェックアウトページのチェックであれば、ポーリング間隔内で障害を検知できました。単純なHTTPチェックでは不可能です。
なぜ可用性監視が重要なのか
ダウンタイムのコストはビジネスによって大きく異なりますが、被害のカテゴリーは一貫しています：取引損失、SLA違反、ブランド評判の損傷、長時間の障害中にクローラーがエラーページに当たることによる検索ランキングのペナルティ、そしてインシデント対応にかかる社内コスト。
eコマースサイトにとっては、ピークトラフィック中の数分のダウンタイムでも数千ドルの注文損失となりえます。SaaSプロバイダーにとっては、単一の継続的障害でSLAクレジットが発生し、長年かけて築いた顧客信頼を損ないます。メディア・出版サイトにとっては、大きなニュースサイクル中のダウンタイムは戻らないトラフィックとなります。
可用性監視は、何かが問題になる時間と誰かがそれを修正する時間の間の窓を縮めます。この平均検知時間（MTTD）は、インシデントの総影響を軽減する最大のレバーとなることが多いです。
可用性監視の仕組み
ほとんどの可用性監視は合成チェックに依存しています：世界各地に分散された監視ノードから自動リクエストを送信します。これらのチェックは定期的に実行され—数秒ごとから数分ごとまで—応答が許容時間内に正しかったかを記録します。
典型的なチェックは特定の地理的位置にある監視エージェントがURLへHTTPリクエストを送り、応答を一連のルールで評価します。2xxステータスコードを返したか、クリティカルなサーバーエラーを引き起こしたか。応答時間は閾値内か。ページに期待されるコンテンツが含まれているか。ページ上の全リソースは正常にロードされたか。
チェックが失敗すると、通常監視システムは即座にアラートを発生させません。同じノードから再試行し、重要なこととして異なるノードからも再試行します。これは、一時的なネットワークの不調や監視ノード自体の局所的な問題を除外し、頻繁な誤警報を防ぎます。複数の場所での失敗が確認された場合にのみ、アラートをエスカレートします。
ウェブサイトのアップタイムを監視する方法：全てのサイトが必要とする5つのチェック
一般的なアドバイスは「アップタイムを監視する」ですが、これは大半の障害を見逃します。以下はサイト所有者が実際に本番環境で見る障害を検知する5つのチェックタイプです。
各レイヤーは下のレイヤーでは見えない障害を検知します。[ /caption]
1. HTTP(S) ステータスチェック
基本的なチェック。URLにアクセスし、2xxレスポンスを期待し、それ以外はアラートを出します。ホームページ、料金ページ、チェックアウトページ、そして有料トラフィックに紐付くランディングページに設定してください。これで重大な障害やSSLハンドシェイク失敗を検知します。
複数の場所から実行してください。米国の単一のデータセンターからのチェックは「稼働中」と報告しても、シドニーの顧客はCloudFrontエラーを見ています。
2. DNS解決チェック
名前解決できないサイトは存在しないのと同じです。サーバーが正常でもそうです。DNSの問題は通常プロバイダーの障害（例えばRoute 53の notable outages）、ドメインの期限切れ、レコード変更後の伝播問題に起因します。
DNS監視は複数のパブリックリゾルバーに対してドメインを解決し、答えが予期せず変わったり、完全に失敗した場合にアラートを出します。
3. SSL証明書の有効性
証明書は期限切れになります。失効します。Let’s Encryptの更新に失敗して誤設定されることもあります。期限切れ証明書警告に直面した訪問者は離脱し、「詳細設定 > 続行」には進みません。
SSL証明書監視は証明書チェーン、有効期限、失効状況をチェックします。30日前、14日前、7日前にアラートが発生するように設定し、証明書のローテーションに余裕を持たせてください。
4. 実ブラウザによるフルページチェック
200レスポンスと動作するページは同じではありません。現代のサイトはJavaScriptバンドル、サードパーティスクリプト（分析、決済、チャット）、CDN配信アセットに依存しています。これらはHTMLが2xxを返す間に失敗することがあります。
実ブラウザウェブページ監視は、Chromeと同様にページを読み込み、JavaScriptを実行し、重要なDOM要素の存在を検証します。これによりHTTPチェックでは見逃す「サイトが壊れている」問題を検知できます。
5. 重要トランザクションチェック
SaaSアプリでは「ユーザーがログインできるか」が最重要チェックです。Eコマースサイトでは「ユーザーがチェックアウトを完了できるか」です。これらはセッション、フォーム送信、API呼び出し、最終確認ページを含む複数ステップのフローです。
合成監視は定期的にスクリプト化したユーザージャーニー（ログイン、検索、カート追加、チェックアウト）を実行し、どのステップで失敗してもアラートを発生させます。Dotcom-MonitorのEveryStepはコードを書かずにリアルブラウザでこれらのフローを録画できます。
基本的なHTTP以外に1つだけチェックを追加するならこれにしてください。トランザクション監視は実際の収益に最も近い信号です。
監視間隔と場所の選択
どこからチェックするか
単一の監視場所は監視の単一障害点です。バージニアにある1つのチェックノードでAWS us-east-1に地域障害が起これば誤警報が発生します。バージニアにノードがあり、CDNのヨーロッパエッジが劣化している場合、実際の障害を見逃します。
解決策は複数地域からの分散チェックです。Dotcom-Monitorのグローバル監視ネットワークは北米、ヨーロッパ、アジア太平洋、南米のデータセンターでチェックを実行します。
小規模サイトなら3〜5拠点で十分です。主要な顧客クラスタの近くに1つずつ、加えてネットワーク経路問題を検知するためのアウトライヤーを1つ選びます。顧客が1カ国に集中しているなら30拠点も必要ありません。
実用的なルール：30〜60秒のウィンドウ内に少なくとも2拠点が障害を報告した場合にアラートを出します。そのウィンドウは1分間のチェックサイクル2回分に相当し、一時的な単一ノードのノイズを除外しつつ本当の障害を迅速に検知します。
どのくらいの頻度でチェックするか
チェック頻度はコストと検知時間のトレードオフです。一般的な間隔は以下の通りです：
- 1分間隔：収益発生ページ（チェックアウト、ログイン、有料トラフィックのランディングページ）
- 5分間隔：主要マーケティングページとAPI監視
- 15分間隔：サブページ、内部ツール、低トラフィックコンテンツ
5分間隔のチェックの場合、最大で5分間の障害が発生していても検知まで時間がかかります。この時間窓のコストは影響を受けるページあたりの1分間の収益額によります。Dotcom-Monitorの可用性計算機でSLAと比較できます。
1分間隔のチェックはコストが高くなります（ツールによってはチェック毎の課金もあります）。小規模サイトでは、収益経路3つに1分間隔、それ以外の場所は5分間隔が最適です。
実際に目に留まるアラートのルーティング
障害モードとしてよくあるのはアラート疲れです。あらゆるノイズでページングされ続けると監視を無視し始め、本当の障害が来ても鈍くなります。実践的なルール：
N-of-Mポリシーを設定する。1回のチェック失敗でアラートを出さず、3回中2回（または5回中3回）の連続失敗でアラート。これで誤警報の大半を潰し、リアルな障害の遅延を意味ないレベルに抑えます。
重要度で分ける。チェックアウトが壊れたアラートは午前3時に電話してください。「マーケティングページが遅い」アラートは営業時間のチャットチャンネルに届くべきです。別々にルーティングを設定してください。Dotcom-Monitorのアラート機能はモニタごとのチャネル、エスカレーションチェーン、営業時間外ルールをサポートします。
計画メンテナンス中は抑制ウィンドウを利用する。リリースを展開して30秒程度のノイズが予想される場合、その監視対象のアラートを抑制してページングを止めます。完全に無効化しないこと。抑制は自動的に解除されるべきです。
遅延後にエスカレーション。最初の担当者が5分以内に認知しなければ2人目をページング。15分経ったら3人目。会議から呼び出しても問題ないが、応答者が飛行機中で判定漏れは問題です。
デッドマン・スイッチを追加する。監視ツールが沈黙するのはサイトが健康ということではありません。10分間チェック報告がなければページングするハートビートチェックを走らせてください。監視ベンダ自体の障害を検知できます。
チャネルに優先順位をつける。重要なアラートは電話やSMSへ、メールは日次要約や99.95％SLA違反報告に使います。警告は賑やかなSlackチャンネルで構いません。午前3時の電話は本当に何か問題があることを意味すべきです。
アラート発生時にすべきこと
アラートはプロセスの始まりであり終わりではありません。最も可能性の高い3種類のアラートについて、あらかじめ対処法を書き留めておきます。インシデント最初の5分間の意思決定を排除することが目標です。
「サイトがダウン」のアラート用最小限のランブック：
- 監視ダッシュボードを開き、少なくとも2か所以上で障害を確認して本物として扱う。
- 直近のデプロイを確認。30分以内にリリースがあるならまずロールバック、その後調査。
- 上流を確認：DNSプロバイダーのステータスページ、CDNステータスページ、ホスティングプロバイダーのステータスページ。多くの障害は他者の問題。
- 第三者問題の場合は自社のステータスページに掲載し、修復を試みるのはやめる。
- 自社問題の場合はアプリログでエラースパイクを調査し、故障サービスを特定してリスタートまたはロールバック。
- 復旧後15分の振り返りを実施。何が失敗し、どう気付いて、何が直したかを書き留める。数か月後には詳細を忘れます。
よくある障害モードとその特徴
障害の特徴は通常、どこを最初に調べるべきかを示します。[ /caption]
症状を初めて見るのがアラートではないように、簡単な現場ガイドです。
期限切れSSL証明書。全HTTPSチェックが全拠点同時に失敗。HTTPチェックは（ポート80を提供していれば）まだ動作。対処：証明書のローテーション。予防：T-30、T-14、T-7日にSSL期限切れアラート。
DNSプロバイダーの障害。場所によってチェックが通るところと失敗するところが混在し、地域で明確なパターンなし。ユーザー視点の障害持続時間はTTLに依存。対処：プロバイダー変更か復旧待ち。予防：同一ドメインのセカンダリDNSプロバイダー。
CDNの地域障害。1地域のチェックだけ失敗し他地域は通る。ページロードは5xxエラーかフリーズ。対処：CDNキャッシュのパージまたはオリジンへのフェイルオーバー。予防：複数地域からの監視で数分以内に検知。
デプロイで壊れたJavaScriptバンドル。HTTPチェックは通る（200 OK）。実ブラウザチェックはDOM欠落で失敗。症状：顧客から「ボタンが動かない」とのメール。対処：ロールバック。予防：重要ページに実ブラウザチェック、合成チェック成功時のみデプロイ。
第三者スクリプトのタイムアウト。ページロードはするが遅い。トランザクションチェックは、スクリプト依存のステップ（チャットウィジェット、分析、A/Bテスト）で断続的に失敗。対処：スクリプトを非同期読み込み、タイムアウト設定、不要なら除去。予防：重要ページのページロード時間アラート。
適切なツールの選び方
市場には数十の選択肢があります。UptimeRobotやPingdomは基本的なアップタイム監視に優れています。StatusCake、Site24x7、Uptrendsは価格や機能の広さで競います。Datadog SyntheticsやNew Relic Syntheticsは既存のAPMプラットフォームを利用しているチームに適しています。
以下の順で質問してください：
- 実際の顧客がいる地域からチェックが実行されるか？
- HTTPだけでなく実ブラウザチェックや多段トランザクションをサポートしているか？
- 実際に使っている通知チャネル（SMS、電話、PagerDuty、Slack）と統合できるか？
- 顧客が購読できる公開ステータスページを提供しているか？
- 重要チェックを1分間隔で実行する際の価格は？
Dotcom-Monitorは1つのプラットフォームでアップタイム、合成、ウェブアプリケーション監視、API監視、アラート層およびアップタイムとSLAレポートをカバーします。ご自身のサイト規模における1分間隔のマルチチェックカバレッジの価格は価格ページをご覧ください。
今週やるべきこと
3つの最重要収益ページに対して、3カ所以上の地理的位置から1分間隔でHTTP(S)チェックを設定する。SSL期限切れ監視を追加。最も重要なトランザクション（ログインまたはチェックアウト）に実ブラウザチェックを追加。2回中3回失敗ポリシーでSMSアラートを設定する。各アラートが発生した場合の対処法を書き留める。
