夜中の警報を減らす前に。当番を呼ぶ通知と、翌朝まで待てる通知の分け方

夜中に端末が鳴る。担当者が接続すると、処理は既に回復している。翌朝は別の通知が何十件も届く。ところが、本当に注文を受け付けられなくなったときには、いつもの警報に埋もれて発見が遅れた。これは運用設計を考えるための仮の場面である。

ここで「通知を半分にする」と決めても、必要な警報まで消せば逆効果になる。反対に、何も見逃したくないから全件を呼び出し対象にすれば、人が確認する時間そのものが足りなくなる。

選ぶべきなのは通知の総数より、対応の時間帯だ。待つと利用者への損失が広がり、今の介入で状況を変えられるものは呼び出す。待てる改善は期限のある作業へ、後の調査に使う情報は記録へ分ける。 本稿はこの区別を運用上の提案として示す。一律の警報削減率を勧める記事ではない。

警報の「正しさ」には、少なくとも二つある

GoogleのSRE Workbookは、重要な事象を知らせる警報について、通知したもののうち重要だった割合と、重要な事象を拾えた割合を分ける。さらに検出までの時間、回復後に警報が収まるまでの時間を評価する。主にリクエストを処理するサービスの運用知見であり、警報削減の効果を企業間の無作為実験で示した資料ではない。Google SRE「Alerting on SLOs」

この区別を使うと、「無駄な警報が減った」という報告には、もう一つの質問が必要になる。その変更で、重要な障害を拾えなくなっていないか。通知の的中率だけを上げるなら、極端に深刻な障害だけ知らせれば数字はよく見える。しかし、対応の余地がある段階で検出するという目的からは遠ざかり得る。

運用会議では、警報の件数と、実際に必要だった介入を対応させたい。受け取った人が何を確認し、何を変更し、待った場合に何が起きたかを振り返る。「確認済み」という記録だけでは、夜間に人を起こす必要があったかが分からない。

原因を示す数値と、利用者の困りごとを分ける

同じCPU使用率の上昇でも、夜間の予定処理が正常に進んでいるのか、注文画面が応答しなくなっているのかで対応は違う。機器の数値は原因調査に役立つが、それだけで緊急度が決まるとは限らない。

Googleの最初のSRE書籍も、監視において症状と原因を区別し、外から見えるサービスの挙動と内部の状態を組み合わせて考える。呼び出し、チケット、ログという出力の違いも扱う。これは同社の運用経験を整理したもので、日本のすべてのシステムに同じ監視項目を要求する標準ではない。Google SRE「Monitoring Distributed Systems」

例えば、注文失敗が増えているなら利用者の行動が既に妨げられている。一方、空き容量が少しずつ減っているなら、枯渇までの時間と、追加できる容量を確認する。同じ赤い表示でも、片方は今の復旧、もう片方は計画的な手当てを必要とするかもしれない。

ただし、利用者からの失敗が出るまで待つという意味ではない。処理不能になる前に手当てできる情報には価値がある。重要なのは、その兆候が、どの失敗へ、どれくらいの時間でつながり、何をすれば避けられるかを説明することだ。

呼び出す、期限を付ける、記録する

警報を棚卸しする際には、通知先の設定画面より先に、次のような判断表を作るとよい。これは本文の実務案であり、実証済みの診断尺度ではない。

「誰も対応できない警報」は、必ず不要とは限らない。重大な障害なのに権限や復旧手順がないなら、欠けているのは対応能力である。通知を消す前に、サービスを止める、利用者へ代替手段を知らせる、外部事業者へ連絡するなど、実行できる手段を用意する必要がある。

逆に、一つの障害で複数の機器から同時に通知が出るなら、原因ごとに全員を呼ぶことが必要かを見直す。利用者への影響を示す一つの警報から調査へ進み、内部の情報をその画面で確認できれば、調査材料を失わず通知だけをまとめられる場合がある。

同じ容量警報でも、深夜に起こす理由は変わる

仮に、翌営業日まで十分な容量があり、夜間の増加も予測できる保管領域を考える。追加作業を翌朝に実施しても処理が止まらないなら、深夜の呼び出しを期限付きの作業へ変える候補になる。担当者と実施期限を決めることが条件であり、通知をメール箱に移すだけではない。

ところが、書き込みが急増し、朝までに受注記録を保存できなくなる見込みがあるなら判断は逆転する。容量追加や処理の抑制を今行えるなら、呼び出す理由がある。警報名が同じでも、残された時間と介入方法が違うからだ。

さらに追加権限を当番が持たないなら、当番へ同じ通知を繰り返すだけでは回復しない。権限を持つ相手へつながる経路か、許可された代替処理を用意する。この問題を閾値調整だけで解こうとしない。

取引が少ないサービスは、割合だけで決めない

夜間の取引が少ないサービスでは、一件の失敗で失敗率が大きく動く。Googleの同章も、この条件では監視方法の調整が必要になると説明する。少数の失敗がすべて軽微とも限らず、一回限りの高価値な処理なら、一件を重く扱う理由がある。低トラフィックのサービスに関する説明

したがって、日中の大量処理向けの設定を、そのまま月次精算へ移さない。精算なら締切までに完了できるか、失敗した取引を回収できるかを見る方が、短い時間のエラー率より判断につながる場合がある。監視対象の業務周期と、失敗した一件の取り返しやすさを合わせて考えたい。

擬似的なアクセスを流す方法にも注意がある。Googleの同章は、擬似アクセスだけが成功すると、実利用者の失敗が見えにくくなる場合を挙げている。試験用の注文が通ることと、実際の注文が通ることを同一視しない。本稿なら、試験用の結果と実利用者の失敗を別に確認できる状態を保つ。

通知をまとめる際は、まとめ役が止まったときの扱いも決めたい。監視画面に何も出ていない理由が、正常だからなのか、情報が届いていないからなのかを分ける。これは通知を増やす口実ではなく、静かな状態を信用するための条件である。

呼び出した後の引き継ぎも対象にする。担当者へ届いても、応答がなければ損失を止められない。連絡経路を試す際には、最初の宛先だけでなく、返答がない場合の次の担当まで確認する。期限付き作業へ移した通知も、期限超過で誰が判断するかを決めて初めて、深夜対応の代替になる。

減らした後も、必要な呼び出しだったかを追う

変更の検証では、過去の障害記録に新しい設定を当て、どの時点で通知されるかを確認する方法がある。ただし、過去に存在しない失敗まで検出できる証明にはならない。まず一種類の警報で試し、旧設定なら拾った事象と、新設定の通知を比較する。

見るのは通知数に加え、重大な見逃し、検出の遅れ、回復後も続いた警報、対応に使えた情報である。警報を受けて何もしなかった場合も、不要だったのか、何をすべきか分からなかったのかを分ける。前者は設計の見直し、後者は手順や権限の整備が中心になる。

人を起こす警報には、今動く理由と、動ける手段を付ける。待てる問題は期限付きの作業へ移す。 この線を引くことが、監視を静かにすることと、必要なときに反応できる運用を両立させる出発点になる。