エンジニアが実際に使用するウェブサイト監視のベストプラクティス

ほとんどのチームはウェブサイトの監視をしていますが、顧客、営業、サポートよりも先に問題を検知できる監視を持っているチームははるかに少ないです。そのギャップは、ほとんどの場合ツールではなく、それを取り巻く運用方法にあります。何をどこからどのくらいの頻度でチェックするか、ページをトリガーする条件、チェックが壊れているのかサイトが壊れているのかを誰が判断するのか、などです。

このプレイブックは、SREやDevOpsチームが信頼する設定と、静かにノイズに変わる設定を分ける8つのウェブサイト監視のベストプラクティスをまとめています。各項目は具体的で、しきい値、間隔、アンチパターン、効果が出た後に継続すべきことを含みます。マーケティングサイトの稼働監視であれ、SaaSのチェックアウト全体の合成トランザクション監視であれ、同じプラクティスが適用されます。

「良い」とは何か（そしてなぜ多くの設定がそれを逃すのか）

動作する定義はこうです：監視が良いとは、チームがすべての顧客向けの問題を顧客よりも前にモニターから知り、受け取るページのほとんどがほぼ常に実行可能であること。これが唯一の基準です。

3つの数値がそれを追跡します。平均検知時間（MTTD）は監視が十分に速いかを示し、平均解決時間（MTTR）はモニターが提供するデータが問題を解決するのに十分かを示します。アラートの精度―本物かつ即時対応が必要だったページの割合―は、6か月後もチームがアラートを信頼し続けるかを示します。ほとんどのSREチームはMTTDとMTTRは測定しますが、精度は測定しません。だから多くのオンコールローテーションは無言の了承と学習された無力感に陥るのです。

このプレイブックの残りは、両方の数値を同時に正しい方向に押し進めることについてです。

リクエストパス全体にわたる層別チェック

単一のHTTPSチェックは1つのセンサーの煙探知器のようなものです。何かが間違っていることは知らせますが、どこかは教えてくれません。ユーザーがURLを入力してページがレンダリングされるまで、リクエストはDNS解決、TCPハンドシェイク、TLSネゴシエーション、HTTPレスポンス、アセットロード、クライアント側での最終ビューのレンダリングという少なくとも6つの層を通過します。各層は異なる故障が発生し、それぞれに固有の根本原因があります。

実際のセットアップは以下のようになります：

• DNS： A、AAAA、CNAME、MXレコードが複数のリゾルバーから期待どおりに解決されるかをチェック。DNSの問題は見落としやすく、事後にデバッグが最も困難です。最高のDNS監視ツールは、無断のレコード変更、伝搬遅延、リゾルバー固有の障害を監視します。
• TCPとICMP： ポートが開いていてネットワークパスが健康か確認。443ポートを遮断するファイアウォール変更は、同じネットワークセグメントからのHTTPチェックではわかりません。
• TLS： 証明書チェーン、有効期限、ホスト名の一致、暗号サポートを検証。多くの証明書障害は防げるもので、多くは日曜日に証明書が失効したことが原因です。60、30、14、3日前に明確な期限切れ警告を受け取ります。設定の詳細はSSL証明書の有効期限監視方法を参照してください。
• HTTP： ステータスコード、応答時間、コンテンツの主張。ステータス200で空の本体は失敗とみなされ、成功ではありません。
• レンダリングとトランザクション： 実際のブラウザでユーザージャーニーを実行し、最終状態の既知の要素を検証し、インタラクティブになるまでの時間を測定。合成監視はプロトコルチェックでは検出できない壊れたJavaScript、ハングアップするサードパーティスクリプト、カートボタンが見えなくなるCSSファイルの欠損を捉えます。
• API： APIをファーストクラスのエンドポイントとして扱う。サイトが読み込まれても、決済APIがタイムアウトしてチェックアウトできなければ壊れています。API監視は依存するページとは別にチェックスケジュールを持つべきです。

何かが壊れた場合、最初にアラートを出す層が根本原因特定の出発点になります。HTTPのみを監視するチームは「ダウン」という一つの情報しか得られませんが、6層すべてを監視しているチームは障害ツリーを手に入れます。

合成監視とRUMは併用し、相互代替ではない

2つの方法は異なる質問に答え、代替手段ではありません。以下の表は、両方を四半期間運用した後に多くのチームが定めた分担を要約しています。

合成監視は固定スケジュールで固定されたロケーションからスクリプトチェックを実行します。データは時間とともに一貫しており、トラフィックのブレに左右されません。また、ログインページを壊すデプロイがあっても、実ユーザーのいない午前3時に動作します。だからこそ、SLAレポート、回帰検知、積極的アラートに最適です。

RUMは実際のブラウザからパフォーマンスとエラーデータを収集し、ユーザーが住む様々なデバイス、ネットワーク、地理分布を反映します。特定キャリアのAndroidユーザーの2%が最初のバイトまで9秒かかっていることを教えてくれる唯一の情報源です。RUMは実際の体験理解とエンジニアリング作業の優先順位付けに最適です。

合成監視でサイトが正常に動作しているかを知り、RUMでその挙動が支払ってくれる人々にどう対応しているかを知ります。どちらか一方を選んで片方をスキップすると、エッジケースに不意を突かれる（合成のみ）か、Twitterで障害を知る（RUMのみ）という結果になります。

収益を生む地域から監視を行う

隣のデータセンターからのチェックは、そのデータセンターがオンラインかどうかは教えてくれますが、サンパウロにいるユーザーが快適に使えているかは教えてくれません。

ルールは簡単です：収益に意味のある貢献をするすべての地域にチェックポイントを置き、プラス1～2箇所のコントロール用リージョンを置きます。EMEAの売上が35％なら、少なくとも2つのEMEAチェックポイントが必要です―フランクフルトやロンドンのような主要市場に1つ、マドリードやストックホルムのような二次市場に1つ。単一チェックポイントのEMEAカバレッジは地域ISPの障害やCDNのエッジ障害を隠します。

設定すべき3つのパターン：

1. 複数地域によるページングの確認。 60秒以内に2か所以上の異なる地域での障害を繰り返す場合のみページング。1箇所のみの障害は通常、地域キャリアの問題かチェックポイント単体の問題でありサイト障害ではありません。
2. 地域別ベースライン。 東京とアイオワではサイトの読み込み速度が異なるため同一しきい値は適用しません。地域ごとにp95レイテンシを追跡し、グローバル平均ではなく地域別の逸脱でアラートを出します。
3. 企業ネットワーク内のプライベートエージェント。 自社ファイアウォールの背後からアプリにアクセスする企業に販売する場合、その環境内にチェックポイントを設置してください。プライベートエージェントは顧客のネットワークが原因の問題を検出し、それは顧客にとっては自身の問題ではなく提供元の問題のように感じられます。

Dotcom-Monitorのチェックポイントネットワークは30カ国以上に展開しており、有効にする一覧はデータセンターの場所ではなく収益が発生する場所によります。

しきい値はベースラインから設定し、切りの良い数字からは設定しない

最も一般的な監視の過ちの一つは「応答時間＞3秒でアラート」というものです。3秒は切りの良い数字ですが、サイトは切りの良い数字に関心はありません。本当のp95が4.2秒で安定している場合、通常の動作で1日に24回もページングされます。一方で本当のp95が0.8秒から2.5秒に悪化しても3秒未満なので何も起きません。

修正方法はベースライン相対のしきい値です：

10分間の持続したp95が（ベースラインp95×1.5）または（ベースラインp95＋2σ）のいずれか大きい方を超え、2連続の評価ウィンドウで条件が続く場合にアラート。

この式は3つのことを同時に行います。1.5×の倍率はページスピードに応じて調整するため、速いページと遅いページで同じルールを適用可能にします。2σの項は通常の変動を抑制します。「2連続のウィンドウ」は、急上昇と回復に伴う誤検知を防ぎ、ほとんどのページングノイズを除去します。

ベースラインの計算は多くのチームが省略する部分です。過去14日間のデプロイウィンドウと既知のインシデント期間を除外して毎週ベースラインを再計算します。自動ベースライン化する異常検知ツールは便利なショートカットですが、除外しているものを必ず検証してください。先週のインシデントに汚染されたベースラインは、ないより悪いです。

稼働監視での同様のルールは、2つ以上の異なる地域で2連続の失敗があった場合にページング。1地点の単一失敗はほぼチェックポイントの一時的問題です。2つの違う場所からの失敗が本物です。

チェックだけでなくアラートも設計する

チェックは何かが起きたことを知らせますが、アラートは人に行動を促します。この2つは別の問題であり、多くのチームは最初のチェックだけを設計しています。

アラート設計の役割は、正しい情報を正しい人に60秒以内に行動できる形式で届けることです。障害となるのはたいてい：

• 多すぎるアラート。平均してオンコールエンジニアがシフトごとに3回以上のページングを受けると、次のページは注意が散漫になります。これは道徳的失敗ではなく、人間の注意力の仕組みです。
• 文脈のないアラート。「チェックアウトが遅い」は実行不能ですが、「EU地域からのチェックアウトp95が4.8秒（ベースライン1.1秒）、14:32 UTCに開始、14:30のデプロイabc123と相関あり」は実行可能です。
• 誤ったチャネル。Slackやメールはページングではありません。SMS、プッシュ通知、電話がページングです。混ぜるとシグナルが薄れます。

有効なパターンは：

1. 3つの重大度レベル、3つのチャネル。 致命的（サイトダウン、決済故障）→SMSまたは電話。警告（持続的劣化）→プッシュまたはオンコール言及付きチャット。情報（単一失敗チェック、ベースライン逸脱）→ダッシュボードまたは日次ダイジェスト。情報でのページングはしない。
2. 依存関係の抑制。 DNSが失敗したら、DNSに依存する14の下流HTTPチェックでもページングしない。アラートグルーピングと依存関係抑制は最低限の機能です。対応していないプラットフォームは睡眠を失います。
3. 昇格は鎖ではなく格子状に。 主たるオンコールが5分で応答しなければ、副次的なオンコールへページし、さらにチャネルにも通知。連続した昇格はサイトダウン時に1ホップごとに5分の遅れを生みます。
4. 非致命的は静かな時間帯を設ける。 日曜午前2時の性能退化は通常、午前2時の起床を必要としません。致命的障害は必要。設定時に正直に区別すべきです。

そして精度を測定します。毎月、発生したページの数を数え、それぞれに「実際のインシデント」「誤検知」「対応不要」とタグ付けします。80%未満なら騒音の多いアラートを直してから新規追加しましょう。

自分でコントロールできない部分をカバーする

サイトは単に自分のコードだけではありません。現代のチェックアウトページは、決済プロセッサー、タグマネージャー、分析プロバイダー、チャットウィジェット、A/Bテストツール、CDN、時には不正検出サービスからスクリプトをロードします。どれもページをダウンさせる可能性があります。

サードパーティの依存先にはそれぞれの監視が必要です：

• 地域別CDNエッジ応答時間。 CDNは地域イベント時に障害を起こすことがあります。
• 決済ゲートウェイの往復時間。 ゲートウェイの状態エンドポイントやサンドボックスに対する合成APIチェック。
• タグマネージャーと分析スクリプトの読み込み時間。 合成トランザクションの一部として測定。解析タグがブロックするとすべてのページで2秒遅延が生じ、その事実を把握したいはずです。
• 外部認証プロバイダー（OAuth、SSO）。「Googleログイン」ボタンが動かなくなった場合、サポートに問い合わせが来る前に知る必要があります。
• DNSプロバイダー。 複数リゾルバーからDNS監視を実施し、伝搬遅延やプロバイダ側の部分的な障害を検知。

どのサードパーティがどのユーザージャーニーを阻害するのか文書化してください。サードパーティ障害時には、「フォールバックする」「待つ」「ベンダーのオンコールへページ」のどれが正しい対処かランブックに示すべきです。これがないとサードパーティ障害は即興の演習になってしまいます。

すべてのモニターにランブックを紐づける

インシデントの中でオンコールエンジニアがアラートの意味を理解しようとする5分間が最もコスト高い時間です。

一回直しましょう：すべてのモニターがランブックのエントリにリンクします。ランブックは複雑である必要はありません。3つのセクションで十分です：

1. このチェックがカバーする内容を一文で。（例：「フランクフルトとアムステルダムからのEUチェックアウトが5秒以内に完了することを検証する」）
2. 発火時に最初に確認すべき5つの項目。ステータスページリンク、ダッシュボード、最近のデプロイ、関連アラート、ベンダーのステータスページ。
3. 既知の誤検知パターン（あれば）。例：「フランクフルトのチェックポイントはベンダーメンテナンスウィンドウ（土曜02:00-02:30 UTC）中にタイムアウトすることがあり、抑制対象」

ランブックを初めて書くのに15分かかり、以降はそのモニターでのインシデントごとに15分短縮されます。計算は明白ですが、多くのチームはまだ実施していません。

モニターの検証とカバレッジ監査を四半期ごとに行う

未検証のモニターは保証ではなく願望です。ギャップを発見するために2つの手法があります。

アラートに対するカオスドリル。 四半期に一度、意図的にチェックを壊します―テストエンドポイントを停止、ステージング環境で証明書を失効、閾値を0に落とす―そしてアラートが発火し、昇格し、適切な人物に届くことを確認します。約3分の1のアラートは初回のドリルに失敗します。よくある原因はオンコールローテーションの陳腐化、期限切れの統合トークン、誰も読まなくなったSlackチャネルです。

カバレッジマップの四半期監査。 すべてのユーザージャーニー、外部依存先、URLカテゴリの一覧ドキュメントを維持します。各行にはそれをカバーするモニターをリストアップ。空行はギャップです。直近四半期に追加された新機能は通常この空行に含まれます。

監査は逆の発見ももたらします：存在しなくなったURLをカバーするモニター。削除しましょう。410エンドポイントの監視は永遠にノイズを生み、何も守りません。

監視プラットフォームで見るべきポイント

ほとんどのプラットフォームはURLにpingを送れますが、違いは難しいケースで現れます。ツールを評価する際は、ダッシュボードのデモを超えて以下を尋ねてください：

• 条件ロジック付きの実ブラウザトランザクションをスクリプト化できるか？ 静的録画はページが変わるとすぐ壊れます。スクリプト化トランザクション監視（Seleniumスタイルまたは独自）が通常のプロダクト進化に耐えられます。
• どれだけ多くのネイティブプロトコルをサポートしているか？ HTTP、HTTPS、DNS、FTP、SMTP、IMAP、POP3、TCP、UDP、ICMP。これらを別ツールに外注すると、ベンダー関係もログインも増えます。
• グローバルチェックポイントの実態は？ 200の「チェックポイント」が3つのクラウドリージョンに集中しているだけではグローバルとは言えません。都市リストを要求しましょう。
• 社内ネットワーク内から動作可能か？ ステージング環境、内部アプリ、顧客専用デプロイメント監視にはプライベートエージェントが必須です。
• アラート依存関係とグルーピングはどう扱うか？ 1回のDNS障害で14回ページするプラットフォームはストレスの源です。
• データエクスポートはどうか？ 生のチェック結果を自社の分析スタックに取り込めないと、難事件の調査が困難になります。
• インシデントツールとの統合。 PagerDuty、Opsgenie、Slack、Microsoft Teams、ServiceNow、Jira。ネイティブ統合はWebhook連携より優れています。

より詳細な購入チェックリストとスコアリング基準は最高のウェブサイト監視ツールの選び方とDatadogの競合・代替をご覧ください。プレイヤーごとの位置づけの参考になります。

一般的な障害モード

以下のパターンはほぼすべての監視レビューで見られ、いずれも新しいツールを必要としません。

• 多地域サイトで一つのグローバルしきい値。 速い地域が遅延し、遅い地域が劣化し、グローバル平均は正常でアラートが出ない。
• コンテンツ検証なしのステータス200チェック。 CDNエラーページの空白200がチェックを通過し、本番で問題となる。
• 実際の顧客アカウントに依存する合成トランザクション。 パスワード期限切れ、多要素認証登録、アカウントロック。監視範囲が明示されたサービスアカウントを使うべき。
• 7日だけの証明書アラート。 7日は期限で警告ではない。既に炎上している状態。60、30、14、3日前に警告。SSL証明書監視は段階的に設定すべき。
• デプロイとの相関なし。 「このアラートはデプロイabc123の3分後に発火」と見えなければ、すべてのインシデントは手動gitログ確認から始まる。CIを監視注釈と連携しましょう。
• しきい値を見直さない。 2年前に「>5秒」で設定したままサイトが2倍速くなっている場合、そのしきい値は機能していません。
• ホームページは監視するが収益経路は監視しない。 ホームページの可用性は自己満足指標。チェックアウト、サインアップ、ログインの可用性がビジネスです。

API、スクリプト化ジャーニー、マイクロサービストポロジー周りの詳細はウェブアプリケーション監視ベストプラクティスと併せてご覧ください。遅延予算がSEOに与える影響についてはウェブサイト速度がSEOに与える影響も参考にしてください。

プレイブックを活用しましょう

このリストから現在の設定で対応できていないプラクティスを3つ選び、今スプリント内で実装しましょう。完成と呼ぶ前に新しいモニターでカオスドリルを実施し、30日後に精度を監査します。

プラットフォームがボトルネックなら、Dotcom-Monitorは一つの場所でフルスタックをカバーします：実ブラウザ合成監視、多プロトコルチェック、プライベートエージェントを備えたグローバルチェックポイントネットワーク、先述のパターンに対応したアラート設計機能。ウェブアプリケーション監視、API監視、DNS監視、SSL証明書監視を見たり、より大規模環境向けのエンタープライズ監視概要に直行しましょう。

よくある質問