# My Philosophy on Alerting Navigation: [[sources/_index]] | [[index]] ## 出典情報 - **タイトル**: My Philosophy on Alerting - **著者**: [[Rob Ewaschuk]] (Google SRE) - **媒体**: Google Docs (公開ドキュメント / 後に『Site Reliability Engineering』書籍 第10章「Practical Alerting from Time-Series Data」の基礎となる) - **公開日**: 2014〜2015年（継続的に改訂・参照されている古典的バイブル） - **URL**: https://docs.google.com/document/d/199PqyG3UsyXlwieHaqbGiWVa8eMWi8zzAn0YfcApr8Q/mobilebasic ## 概要 元 [[Google]] の SRE である [[Rob Ewaschuk]] が、7年間にわたる大規模インフラおよび急速に変化する製品サービスのオンコール待機経験に基づいて執筆した、本番システムにおけるモニタリングおよびアラート設計の基本哲学。 Nagios 的なしきい値監視やサーバー内部状態に基づく旧来の「原因監視（Cause-based monitoring）」を痛烈に批判し、ユーザー影響から逆算する「症状監視（Symptom-based monitoring）」への転換を提唱した。この哲学は、後に『Site Reliability Engineering: How Google Runs Production Systems』（SRE Book）第10章として結実し、[[Jamie Wilkinson]] らによる SLO ベースアラート理論や現代のオブザーバビリティ設計思想の出発点となった。 --- ## 主要な原則と詳細解説 ### 1. ページャーの本質とオンコール保護の原則 - **ページの4原則**: - ページ（緊急呼び出し）は **Urgent（緊急）**、**Important（重要）**、**Actionable（実行可能）**、**Real（実在する）** でなければならない。 - 「また鳴ったか」と確認するだけのページは存在してはならない。すべてのページは人間の知性と判断を要するものでなければならず、定型的・スクリプトで自動復旧できる対応に人間を起こしてはならない。 - **過剰監視（Over-monitoring）の害**: - 人間が緊張感を持って緊急対応できる回数は1日あたり数回が限界である。ノイズの多いアラートは削除・無効化を第一に検討すべきであり、「過少監視（under-monitoring）」よりも「過剰監視によるオンコール疲弊とオオカミ少年効果」のほうが組織的に解決が困難な深刻な害悪をもたらす。 ### 2. ユーザーのための監視 (Monitor for your users: Symptom-based) ユーザーがサービスに対して関心を持つ対象は、極めて限られた以下の4カテゴリに集約される： 1. **可用性と基本機能 (Availability & Basic Functionality)**: エラー（5xx系）、画面のハング、JS/CSS/画像の欠落などのないこと。 2. **レイテンシ (Latency)**: 迅速に応答すること。 3. **正確性・完全性・鮮度・永続性 (Correctness / Completeness / Freshness / Durability)**: ユーザーのデータが安全に保持され、破損せず、インデックスが最新であること。 4. **個別機能 (Features)**: 計算機機能や株価ティッカーなど、サービス固有の重要機能が正しく動作すること。 ユーザーは「MySQL サーバーが死んだか」には関心がなく、「自分のクエリが失敗しているか」にしか関心がない。MySQL のダウンは近接原因（Proximate Cause）であり、クエリの失敗が症状（Symptom）である。 ### 3. 原因ベースアラート（Cause-based Alerts）の弊害と例外 - **弊害**: - 冗長化や高速フェイルオーバー、自動再試行が機能していれば、個々の DB サーバーやプロセスの死滅はユーザー影響を及ぼさない。 - 原因を監視すると、インフラの変更やメンテナンスのたびに偽陽性アラート（Bogus pages）が多発し、ルール保守と例外設定の泥沼に陥る。 - 原因と症状の両方にアラートを張ると、重複アラートによるアラームストームが発生する。 - **例外として原因アラートが許容されるケース**: - **崖に向かって歩いている状態（Imminent Disaster / N+0 状態）**: クオータ枯渇、ストレージ満杯（ほぼ満杯でさらに増加中）、冗長性が失われた N+0 状態など、「放置すれば確実にユーザー影響が出るが、今なら事前に対処可能な事象」。 - **症状のノイズに埋もれる原因**: サービス全体としては 99.99% 可用性があるが、特定イベントで 0.001% のリクエストが確実に落ちているような、トップレベルの症状メトリクスでは埋もれてしまう事象。 ### 4. クライアント視点（Spout / ロードバランサ）からのアラート設計 - 多段アーキテクチャでは、最前線のロードバランサやミキサー、クライアント視点（Spout）から監視・アラートを張るのが最も効果的である。 - バックエンドのファンアウト先（数十〜数百のクエリサーバー）は世界の一部分しか見えておらず、全体障害の判断ができない。 - 最前線のアグリゲータは、ネットワーク遅延、タイムアウト、コネクション切断、ドロップを含めた真のユーザー体験を捉えられる。 ### 5. 原因情報の正しい活用法（Also Firing 機構） - 原因監視を完全に捨てるのではなく、**症状アラートの付帯情報** または **デバッグダッシュボード** として活用する。 - **Also Firing**: 症状アラートが発報された際、同時に発火している原因系ルール（例: `UserDatabaseShardDown`, `FreshnessIndexBehind`）のサマリを通知本文に1行で添える。これにより、オンコールエンジニアは「何が起きているか（症状）」で叩き起こされ、「どこが怪しいか（原因）」を一瞥で把握できる。 ### 6. サブクリティカル通知の階層化（Tickets, Reports, Email） 即座の起床や夕食の中断を必要としない非緊急の通知は、明確なアカウンタビリティ（責任追跡）を持った別経路へ逃がす： - **Tickets / Bugs**: 数時間〜数日以内に対応すべき課題。重複アラートが自動で1つのチケットに集約される仕組みが必須。週次のオンコール引き継ぎでトリアージする。 - **Periodic Reports**: 「DB容量が90%超過」「過去24時間で極端に遅いリクエストが1,000件」といった長期トレンドを日次サマリとしてレポート。 - **禁止事項**: 単なるメーリングリストや Slack/IRC チャンネルへのアラートの垂れ流しは、例外なく黙殺（Summary Ignore）されるため避ける。 ### 7. Playbook（対応手順書）の要件 - 各アラートには必ず対応手順書（Playbook）への直リンクを貼る。 - 複雑で長大なフローチャートを書くのはアンチパターンであり、システム自体を自動修復・自律保護できるように改修すべきである。 - 最良の Playbook は、「このアラートが何を意味しているか」「初動で確認すべき箇所」「現在発生している既知パターン（例: 特定ベンダーの電源瞬断バグの追跡チケット）」を記した、Wiki 等で迅速に更新できる簡潔なメモである。