monitoring-and-alerting

モニタリングとアラート

何を監視し、何をアラートの対象にするか、そして障害が発生したときに適切な担当者へ確実に知らせる方法を決めます。

---

使用する場面

• 新しいサイトやサービスのモニタリングを設定するとき
• SLO（サービスレベル目標）とエラーバジェットを定義するとき
• 担当者を呼び出すアラートと、通知の少ないチャンネルに送るアラートを選ぶとき
• オンコールローテーションを設計または改善するとき
• アラート疲れの原因を診断するとき
• インシデントで明らかになったモニタリングの不足を補うとき
• モニタリングベンダーを移行するとき

使用しない場面

• 進行中のインシデントに対応するとき（incident-response を使用）
• 事後検証レポートを作成するとき（after-action-report を使用）
• プロダクト指標の分析ダッシュボードを設計するとき（analytics-strategy を使用）
• パフォーマンス最適化そのものに取り組むとき（performance-optimization を使用）

---

必要な入力情報

• 監視対象のシステム（URL、サービス、依存関係）
• 現在使用しているモニタリングツール（稼働状況、エラー、ログ、APM）
• 営業時間とチームのタイムゾーン
• インシデントのオンコール担当者または対応可能な担当者
• 既存のSLOや成功指標があれば、その内容

---

フレームワーク：4つのレイヤー

モニタリングはレイヤーごとに機能します。1つでも省くと、特定の問題を見逃します。

レイヤー1：可用性

サイトは稼働していますか？最もシンプルで、最も重要なレイヤーです。

• 複数のリージョンからのHTTPチェック（1〜5分ごと）
• DNS解決チェック
• 証明書の有効期限チェック
• ステータスコードチェック（タイムアウトだけでなく、5xxもアラート対象にする）

しきい値：継続的なダウンタイム（チェックが2回以上連続して失敗）があれば、担当者を呼び出します。

レイヤー2：正確性

サイトは稼働していますが、適切な内容を提供していますか？

• シンセティックチェック（ホームページを読み込み、ボタンをクリックし、想定されるテキストを検証するスクリプト）
• 重要なユーザージャーニー（登録、チェックアウト、検索）
• コンテンツの存在チェック（ホームページが空白になっていないか）
• APIコントラクトチェック（レスポンスの形式と主要フィールドが存在するか）

しきい値：クリティカルパスのシンセティックチェックの失敗では担当者を呼び出します。重要度の低いページレベルのシンセティックチェックでは、営業時間中のみアラートを送ります。

レイヤー3：パフォーマンス

サイトは稼働し、正しく動作していますが、十分な速度ですか？

• 実ユーザーからのCore Web Vitals（LCP、INP、CLS）（RUM）
• シンセティックパフォーマンス（Lighthouse、WebPageTest、カスタム計測）
• APIの応答時間（p50、p95、p99）
• 遅いクエリのデータベースクエリ時間
• 依存先の応答時間（サードパーティAPI）

しきい値：ベースラインからの悪化（例：5分でp95が2倍になる）。ベースラインなしで絶対値のしきい値に対するアラートを設定しないでください。

レイヤー4：エラーと異常

ほとんどのユーザーにとってサイトは稼働し、正しく動作し、速いものの、エラーが発生しています。

• エラー率（5xxを返すリクエストの割合）
• クライアント側のエラー率（捕捉されないJS例外）
• ログのエラー量（予期しない急増）
• 異常検知（トラフィックの急激な減少）
• バックグラウンドジョブの失敗
• キューの深さ

しきい値：件数ではなく、割合に基づいて設定します。「5分間、エラー率が1%を超える」は、「1分あたり100件を超えるエラー」より適切です。

---

SLOとエラーバジェット

サービスレベル目標（SLO）は、信頼性の目標です。一般的な形式は、「30日間の計測で、ホームページへのリクエストの99.9%が2秒未満で成功する」です。

構成要素：

• 計測対象（ホームページへのリクエスト）
• 成功条件（2秒未満で2xxを返す）
• 目標値（そのうち99.9%）
• 期間（30日間）

エラーバジェットはその逆で、リクエストの0.1%は失敗してもよいということです。バジェットを使い切った場合は、リスクの高い変更を控えてください。

SLOの選び方

100%を目指さないでください。本当に必要でない限り、「ファイブナイン」（99.999%）も目指さないでください。9を1つ増やすごとに、コストは桁違いに増加します。

SLO	月間で許容されるダウンタイム
99%	7時間18分
99.9%	43分
99.95%	21分
99.99%	4分22秒
99.999%	26秒

ほとんどのマーケティングサイトでは、99.9%で十分です。SaaSでは、99.95%が妥当です。それ以上を目指すには、多額のインフラ投資が必要です。

エラーバジェットの活用

バジェットに余裕があるときは、積極的にリリースします。バジェットを半分消費したら、ペースを落とします。バジェットを使い切ったら、信頼性が回復するまでリスクの高い変更を凍結します。

これが SLO を有用にする理由です。信頼性と開発速度の間にフィードバックループを作り出します。

---

ワークフロー

ステップ 1：すでに監視しているものを棚卸しする

どのツールが導入されていますか？どのようなチェックがありますか？ダッシュボードはありますか？アラートはありますか？

多くのチームでは、設定が不完全なツールが絡み合っています。最初にすべきことは棚卸しです。

ステップ 2：システムを把握する

アーキテクチャを図にします。フロントエンド、バックエンド、データベース、サードパーティ API、キュー、ワーカーなどです。それぞれの要素が監視対象の候補になります。

それぞれの要素について、次のことを確認します。

• 「稼働中」とはどういう状態ですか？
• 「正しい」とはどういう状態ですか？
• 「速い」とはどういう状態ですか？
• 最もよくある障害モードは何ですか？

ステップ 3：SLO を定義する

3～5 個の SLO を選びます。次の条件を満たす必要があります。

• ユーザーに見える動作に関連している（内部メトリクスではない）
• 現在のインフラで達成可能である
• 自動的に測定される
• 少なくとも四半期ごとに見直される

ステップ 4：4 つのレイヤー全体にチェックを設定する

それぞれの要素について、各レイヤーにチェックを設定します。4 つすべてに対応しない要素があっても問題ありません。

要素	可用性	正確性	パフォーマンス	エラー
ホームページ	HTTP チェック	合成テスト	LCP/INP	JS エラー
ログイン API	HTTP チェック	合成フロー	p95 レイテンシ	5xx 率

ステップ 5：ページ通知するものと、しないものを決める

3 つのティアがあります。

1. ページ通知（担当者を起こす）： サイト停止、重要なフローの障害、エラー率の急増、セキュリティインシデント。
2. 通知（営業時間中）： 重要度の低い合成テストの失敗、パフォーマンスの低下、クエリの遅延、依存関係の劣化。
3. ログ記録（通知なし）： 後で確認する異常、優先度の低い警告、情報レベルのイベント。

ティア 1 に含めるものは、次の条件を満たす必要があります。

• 対応可能である（オンコール担当者が対処できる）
• 重要である（実際の影響を示している）
• 発生頻度が低い（週に 1～2 回未満が目標）

ティア 1 のアラートが頻繁に発生すると、アラート疲れが起きます。人々は対応しなくなります。

ステップ 6：ルーティングを設定する

アラートの通知先はどこですか？

• ティア 1：ページングシステム（例：PagerDuty）。Opsgenie への登録は行わないでください。Atlassian は 2025 年 6 月に販売を終了し、サポートは 2027 年 4 月に終了します。オンコール担当者に直接通知します。
• ティア 2：チャットチャンネル（Slack、Teams）。対象領域のタグを付けます。
• ティア 3：ダッシュボードまたはログのみ。

各ティアについて、エスカレーション経路を文書化しておく必要があります。オンコール担当者が 5～15 分以内に応答確認しない場合は、エスカレーションします。

ステップ 7：ダッシュボードを作成する

対象者ごとにダッシュボードを用意します。

• リアルタイム運用ダッシュボード： 現在の健全性、最近のアラート、エラー率、スループット
• SLO ダッシュボード： SLO の状態とエラーバジェットの消費状況
• サービス別ダッシュボード： 個々のサービスやページの詳細
• 経営陣向けダッシュボード： 数週間／数か月にわたる稼働時間、主要なビジネスメトリクス

ダッシュボードとアラートは別のものです。アラートは「今すぐ確認してください」と伝えます。ダッシュボードは「現在の状況はこちらです」と示します。

ステップ 8：アラート監査を実施する

四半期ごとに、次の項目を監査します。

• どのアラートが発生しましたか？対応可能なものでしたか？
• 発生すべきときに発生しなかったアラートはありますか？
• ノイズの多いアラート（週に 1 回を超える頻度で発生し、対応可能性が低いもの）はありますか？
• ランブックは最新の状態ですか？
• SLO は達成されましたか？継続的に未達となっているものはありますか？

システムを調整します。積極的に保守しないと、監視は徐々に現状からずれていきます。

---

障害パターン

症状ではなく原因にアラートを出します。 「CPU 使用率が高い」は原因です。「ユーザーの動作が遅い」は症状です。症状に対してアラートを出し、原因を調査します。

ランブックなしでアラートを出します。 オンコール担当者が何をすべきかわからなければ、そのアラートは役に立ちません。ページングアラートにはすべてランブックが必要です（1 行だけでも構いません）。

「正常」のベースラインがありません。 「1 分あたりのエラーが 100 件を超えたら」アラートを出すのは妥当に思えますが、何も問題がなくても、繁忙日にはその数を超えることがあります。レートベースと異常検知ベースのアラートを使用します。

単一リージョンでの監視。 サイトと同じリージョンに監視サービスがあると、リージョン障害を見逃し、監視自体に問題が起きたときにも起こされることになります。

監視の監視。 というより、監視していない状態です。アラートプラットフォームがダウンしたら、誰が知らせてくれるでしょうか。ほとんどのページングサービスでは、独自のステータスフィードを提供しています。登録しましょう。

重要度の段階が多すぎます。 SLA が異なる P0／P1／P2／P3／P4 は、振り分け作業になってしまいます。3 段階（ページング、通知、ログ）で十分です。

実態に合わないシンセティック監視。 1 分ごとにホームページへアクセスするシンセティック監視では、「ホームページが稼働しているか」は確認できますが、「実際のユーザーフローが機能しているか」は確認できません。重要なユーザージャーニーを対象にシンセティック監視を構築します。

調整されないままの静的なしきい値。 トラフィックは増え、ユーザーの行動は変わります。昨年設定したしきい値は、もう適切ではありません。しきい値を四半期ごとに見直します。

引き継ぎのないオンコールローテーション。 新しいオンコール担当者は、システムを自分で把握しなければなりません。ドキュメントを作成しましょう。毎週、引き継ぎ会議を実施するか、非同期で更新情報を共有します。

ページャー疲れ。 オンコール担当者が週に 1、2 回を超えてページングを受けるなら、何かが間違っています。アラートを監査します。根本的な問題を減らす、調整する、または修正します。

---

出力形式

監視計画には、次の内容が含まれます。

• システムマップ： 監視対象
• SLO： 3～5 個の信頼性目標
• レイヤーごとのチェック： 可用性、正確性、パフォーマンス、エラー
• アラートの段階分け： ページングするもの、通知するもの、ログに記録するもの
• ルーティング： アラートの通知先、エスカレーション経路
• ダッシュボード： 各対象者が確認する内容
• ランブック： 各ページングアラートからリンク
• 監査頻度： 見直しの時期

---

必要なデータを入手できない場合

このスキルの出力は、単独では生成できないデータ、測定値、またはツールの結果に依存します。必要な入力、ツール、またはデータソースを利用できない、あるいは検証できない場合、許可される出力は、その不足を明記した成果物です。つまり、何が必要だったか、実際に何を取得または検証できたか、出力のどの部分に影響するかを記載します。成果物を完成させるために必要な数値を捏造、推定、または補間することは、いかなる場合も認められません。不足を明記すれば、それだけで完全な回答です。

---

参考ファイル

• references/slo-design-guide.md：ウェブサービス向けの SLO 作成、エラーバジェットポリシー、よくある SLO の誤りについて詳しく解説しています。