通知はいつ人を起こすべきか — 実行可能なアラート設計

Pageは何を依頼する通知なのか

午前3時に鳴るPageは、システムの異常を見つけたという通知ではありません。今介入しなければユーザー被害が広がり、呼び出された人が実際に状況を改善できるという依頼であるべきです。

CPU使用率80%、メモリ90%のような数値だけでPageを設計すると問題が生じます。CPUが90%でも、余裕容量と自動拡張が機能し、ユーザーには何も問題がない場合があります。逆にCPUが普通でも、決済やログインのような重要なフローが失敗しているかもしれません。

通知の要否を決めるには、異常の大きさより先に3つを問います。ユーザーは実際に被害を受けているか。その被害はどれほど速く広がるか。今、人にできることはあるか。Google SREもPagerを人の時間を高く使う手段と捉え、緊急性、行動可能性、現在または目前のユーザー影響を設計時の主要な問いにしています。^[1]

Page・Ticket・Dashboardは優先度なのか

critical、warning、infoに分けるだけでは、実際の運用方法は決まりません。より有用なのは、人がいつ行動すべきかという区別です。Google SREの区分も近く、即時行動が必要な状況、人が処理すべきでも数日待てる状況、後の診断用に記録だけすればよい状況に分けています。^[1] 表はこれを3つの運用経路として整理しています。

Severityと経路を区別します。技術的に深刻に見えても、今人にできることがなければ無条件でPageにはなりません。逆に現在の被害が小さくても、短時間で復旧不能になり、今しか取れない緩和措置があればPageになり得ます。

Decision Matrixは何を見るのか

Pageの要否は一つのMetricではなく、表の条件を合わせて判断します。このMatrixのPageは実質的にAND条件に近いものです。ユーザー影響または目前の損害、短いTime to Harm、自動復旧だけでは不十分、今可能な人の行動、明確なOwner、中断の費用を受け入れられる信頼性です。複数の条件が欠けるなら、TicketやDashboardが適切な可能性が高くなります。

User ImpactとTime to Harmを合わせて見る

ユーザー影響があるだけで、すべての問題が同じ緊急度になるわけではありません。来週の証明書期限切れは解決すべき問題ですが、十分な時間があり自動更新の状態を点検できるなら、通常は業務キューで処理できます。

一方、ストレージが急速に枯渇し、現在の増加速度では次のOn-call交代前に書き込みが止まり、自動拡張もできないなら、ユーザーがまだエラーを見ていなくてもPageを正当化できます。Google SREも、発生済みのユーザー症状に限らず、確実に迫る問題を考慮しています。^[6] ただしPageにつながる規則は単純で理解可能であるべきだと強調しています。

disk > 80%より有用な問いは、現在の増加速度と残り容量から、危険な状態までどれだけ時間があるか、その前に自動または予定された措置を取れるかです。これが固定Thresholdと実行可能なAlertの違いです。

自動解決する問題なら、なぜ人が必要なのか

サーバー1台が異常になっても、Load Balancerが除外し、新しいインスタンスに正常に置き換わったとします。ユーザーに影響がなく追加措置も不要なら、観測データとして価値があっても、人を起こす理由は弱いでしょう。

繰り返す場合は話が変わります。毎日何度もインスタンスが停止・再起動してサービスは自動復旧するなら、Pageより原因を除くTicketが適切な場合があります。毎回同じコマンドを人が実行して正常化するなら、よいAlert設計ではなく、手動で自動化を運用している状態です。Google SREも、反復Pageへの対応が機械的に決まるなら、その対応の自動化を検討すべきだと述べています。^[1]

自動復旧があってもPageが必要な場合はあります。復旧自体の失敗、反復復旧中に続くユーザーの失敗、自動措置が障害を拡大する恐れがあり停止判断を要する場合です。問うのは自動復旧の有無ではなく、自動復旧だけで現在のリスクを十分に制御できるかです。

人にできることがなければPageの目的は何か

外部サービスが障害を起こしたとします。自分たちのサービスで別の供給者への切り替え、機能制限、キューへの作業保存、トラフィック迂回、顧客影響の縮小ができるなら、担当者を呼ぶ理由があります。

起きた担当者に外部Status Pageを見る以外の仕事がないなら、Page方針を見直します。ただし障害告知、取引停止、業務承認など、技術復旧以外の即時判断も有効なHuman Actionです。Actionabilityはエンジニアがコードを直せるかより広く、Rollback、Failover、Load Shedding、機能停止、トラフィック切り替え、供給者へのエスカレーションなど、今実行すれば損害を減らせる判断を含みます。

具体的なIncident対応順序とRunbook構成は、別のIncident Responseの問題です。Alert方針はその前段で、今人を呼ぶべきかまでを決めれば十分です。

OwnerのないPageはなぜ責任構造の問題なのか

#alertsのような共用チャンネルに積み、誰かが見つけることを期待する仕組みは、Pageとは呼びにくいものです。最低限、サービスや機能のOwnerが必要で、現在のOn-callをシステムが把握できなければなりません。外部Dependencyの問題なら、ユーザーの結果に責任を持つチームと、依存先自体を担当するチームも分けます。

緊急性が高いサービスでOwnerが未整理なら、中央On-callなどの一時経路で保護することはできます。ただし通常運用のモデルとして残してはいけません。Unowned PageはAlerting DebtではなくOwnership Debtだからです。

False Positiveはなぜ無料ではないのか

条件を敏感にすると障害を見逃す可能性は下がりますが、正常時にも頻繁に人を起こします。鈍感にしすぎるとPageは減っても、実際の障害を遅く発見します。

Google SRE Workbookは、Precision、Recall、Detection Time、Reset Timeの関係で説明しています。^[2] 意味ある事象をどれだけ正確に通知するか、見逃しはないか、検出までの時間、復旧後の解除時間を合わせて見ます。

PageではPrecisionの費用が特に大きくなります。繰り返すFalse Positiveは、一度の中断だけでなく、Pager自体への信頼を損ないます。ただし完全な確信を待つべきという意味ではありません。Time to Harmが非常に短く、見逃した場合の損害が大きければ、遅延を減らすため多少の不確実性を受け入れる必要があります。

Confidenceも固定数値より、誤検知で人を起こす費用と、数分遅く発見した場合の損害のどちらが大きいか、というTrade-offで決めます。

Dependency一つで数十のPageが鳴るべきか

一つの原因が、多数のコンポーネントのAlertを同時に発生させることがあります。データベース接続の問題が、APIエラー、Queue遅延、Worker失敗、Health Check失敗、ユーザーエラー率の増加につながります。各Alertが別々のPageを作ると、人には5つの問題に見えます。

Prometheus AlertmanagerはDeduplicationとGroupingに加え、上位Alertが有効な間に関連する下位通知を抑えるInhibitionを提供しています。^[3] ただしDependencyグラフを賢くしすぎるのも危険です。Google SREは、構造が変わり続ける環境では、複雑な依存関係ベースの警報階層を維持しにくいと説明しています。^[1]

正確なRoot CauseをAlertシステムに推定させるより、一つのIncidentを代表Page一つで見せ、他の信号は調査Contextに残す方が現実的です。警報システムが診断システム全体を代替する必要はありません。

繰り返すPageではThresholdより先に何を問うか

反復Alertが増えると、まずThresholdを上げがちです。CPU 80%で騒がしいから90%へ変え、それでも多ければ継続時間を延ばします。

一時的なSpikeやFlappingを減らすため、一定時間続いてからAlertを有効にする、復旧直後もしばらくFiringを維持する機能は有用です。Prometheusもforとkeep_firing_forを提供しています。^[3] ただしこれは、もともとPageが必要という判断が正しい場合の調整手段です。

受信しても何も行動しないならThresholdの問題ではありません。同じ作業を毎回行うなら自動化、一つの障害が10のPageを作るならGrouping、別チームが既に対応しているならRoutingやInhibitionの問題です。条件式の精緻化より、Pageの存在理由を先に見直します。

固定CPU 80%はなぜよい出発点ではないのか

CPUやメモリ使用率が不要という意味ではありません。原因の説明やSaturationの接近を判断する重要な資料です。問題は、資源使用率とユーザー被害が1対1で対応しないことです。表の2状況では、同じCPU数値でも別の判断になります。

何%が危険かではなく、どの条件で実害につながり、その前に人が何をすべきかを検証してから閾値を決めます。Prometheusも、個別原因をすべてAlert化するより、ユーザーの苦痛に結び付く症状を上位レイヤーで通知し、小さな変動には余裕を持たせることを勧めています。^[3]

実際の状況を分類するとどうなるか

6つの例のとおり、経路を決めるのはMetricの種類ではなく、損害と行動の時間関係です。購入完了の失敗と目前の容量枯渇はPage、早期に検出した証明書期限切れと毎日のWorker再起動はTicket、ユーザー影響なく自動代替されたインスタンスはDashboardです。

Pageには最低限何を含めるべきか

受信者が状況を最初から解釈し直すなら、Alertシステムの仕事を人に渡しています。よいPageには、影響するサービスやユーザー機能、開始時点と範囲、現在の担当者、初動Runbookや確認点、関連Dashboard、同じIncidentをまとめる識別情報が必要です。PrometheusのAlerting Ruleもannotationに説明やRunbookリンクを追加できます。^[3]

AlertがRoot Causeを確定する必要はありません。決済失敗率の上昇だけでなく、原因のデータベースまで推論しようとすると規則が複雑になります。確実に伝えるべきなのは、何が影響を受け、なぜ今人が必要で、誰が応答すべきかです。

運用中のAlertも再分類し続けるべきか

当初は価値のあったPageが不要になることがあります。自動復旧の追加、Architectureの変更、問題の反復による対応の定型化などが理由です。逆にDashboardだけの信号が障害の先行指標だと繰り返し確認されれば、上位の経路が必要になる場合があります。

Alert Rule Reviewでは、Thresholdの妥当性だけでなく実際の発生履歴を使います。人が実際に行動したか、被害が存在または目前だったか、確認前に自動復旧した割合、同じIncidentの複数Page、同じ手動対応の反復、担当者が信頼して即応するかを確認します。

Google SREも、個別Alertだけでなく、On-callの持続可能な運用負荷としてPage頻度を追跡しています。^[7] 多すぎるPageは、実際の問題を調査・改善する時間を奪います。

人を起こす前の最後の質問は何か

Alertingの目的は、すべての異常を人に伝えることではありません。運用データはもっと多く集めて構いません。原因調査のMetric、ログ、Trace、Dependency状態は豊富なほど有用です。ただし、すべての信号に睡眠や集中を中断させる資格があるわけではありません。

Pageの作成前には、今受け取る人が何をすべきで、朝まで待つとどのユーザー被害が拡大するか、という問いを残します。明確な答えがあればPage候補です。行動は必要でも待てるならTicket、行動を求めないならDashboardや記録にします。

警報の品質は、異常をどれだけ多く見つけるかより、本当に人が必要なときに呼べるかに表れます。