正確なアラートも積み重なれば不正確になる

一言でいうと

アラートの品質は、正確さではなく行動可能性で測ります。鳴るたびに人がすることのないアラートは、1つ1つが正確でも、全体としては嘘になります。

なぜ必要なのか

アラートを増やすのは簡単です。事故が起きるたびに「これを事前に知っていれば」と思う指標が1つずつ生まれ、その指標にしきい値を設定すれば、次の会議で話すことができます。そうして1年たつと、ルールファイルにアラートが80個積み上がります。

問題はその先です。夜間のオンコール担当者のスマートフォンが夜に20回鳴り、そのうち19回は、朝に見ると何でもありませんでした。人は学習します。次からは、通知を見てもすぐには起きなくなります。そして21回目に、本物の障害が同じ音で届きます。

これがアラート疲れです。個々のアラートの正確さをどれだけ上げても解決しません。問題はページの総量だからです。Google SRE Bookはこれについて、「モニタリングシステムの出力は、人が引き受けられるものでなければならない」と述べています。引き受けられるかどうかは、ルール1つ1つではなく、合計で決まります。

どう動くのか

解決の骨組みは2つです。

1つ目は、症状でアラートを出し、原因で調査します。ユーザーが体験するもの(リクエストが失敗する、遅い、結果が間違っている)は、数種類しかありません。一方で、その症状を生み出す原因は数十種類あります。原因ごとにアラートを付けると数十個のページが生まれますが、症状にアラートを付ければ数個に減ります。原因の指標は、なくすのではなくダッシュボードと調査ツールに移します。人が起きたあとに見るものと、人を起こすものは、別の場所です。

2つ目は、アラートに継続時間を持たせます。条件が一度真になったからといってすぐに鳴らすと、一瞬跳ねた値がそのままページになります。forを5分にすれば、5分以上続いたものだけが鳴ります。このノブ1つで、ページ数が1桁に下がることはよくあります。ただしその分だけ検知が遅れるので、どれだけ遅れてもよいかは、エラーバジェットが答えを出します。

アラートを選ぶときに尋ねるべき質問は、1つに絞れます。このアラートを受け取った人に、今できることはあるか。ない場合、それはページではなく、チケットかダッシュボードのパネルです。

性質	送り先	例
今すぐ人が介入する必要があります	ページ(page)	ユーザーリクエストのエラー率が目標を超えています
今週中に対応すれば済みます	チケット	6時間後にディスクが満杯になります
調査のときに見ます	ダッシュボード	p99レイテンシ、キューの深さ、インスタンスごとのCPU

継続時間だけでは足りない場面もあります。条件が5分続くのを待っていると、小さな事故は見逃し、大きな事故は遅れて知ることになります。そのためSLOベースのアラートは、継続時間の代わりに消費速度を使います。今の速度でバジェットをどれだけ速く食っているかを、短いウィンドウと長いウィンドウの両方で見て、2つが同時に超えたときだけ鳴らします。短いウィンドウが素早い検知を、長いウィンドウがノイズの除去を担う構造です。

アラートにはバジェットを設けるとよいでしょう。1人が1週間に受け取るページを2件以下にする、という類の約束です。バジェットがあれば、新しいアラートを足すたびに「何を減らすか」を一緒に問うことになり、その問いが、ルールファイルが育つ速さを遅くします。バジェットを超えたときは、ルールを直す代わりにシステムを直すほうが答えになることが多いものです。頻繁に鳴るアラートは、たいてい頻繁に起きる故障を正直に知らせているからです。

そして、アラートごとに2つを強制します。1つはランブックへのリンクです。明け方3時に、初めて見るアラートを受け取った人が、何を確認し何を元に戻すかを、そのリンク1つでわかる必要があります。もう1つは所有者です。誰も責任を持たないアラートは、誰も消せないので永遠に残ります。四半期ごとにアラートの振り返りを開き、「過去90日間で一度も鳴らなかった、または鳴ったが何の対応もしなかったアラート」を一覧にして削除するチームが、ルールファイルを小さく保てます。

現場での姿

あるチームのルールファイルには、「リクエスト数が普段より少ない」というアラートがありました。意図は良いものでした。トラフィックが途絶えたら障害かもしれないからです。ところが明け方は、もともとトラフィックが少ないのです。そのアラートは、12時間のうち609分、つまり半分近くが真で、オンコール担当者はその通知を自動的に無視するフィルターを作っていました。あってもなくても同じだったのではなく、フィルターを作る習慣を育てたという点で有害でした。

反対側の事例もあります。p99レイテンシが0.5秒を超えると鳴るアラートは、継続時間がなかったので、12時間に65回鳴りました。for: 5mを付けると8回になり、for: 15mでは1回になりました。ルールの条件は、1文字も変わっていません。変わったのは、「どれだけ続いたら人を起こす価値があるか」についての、チームの合意だけです。

次のラボですること

原因基準のアラート4つをルールファイルに書き、バックフィルされた12時間のデータに対して、それぞれが何回鳴ったかを自分で数えるツールを作ります。継続時間を0分・5分・15分に変えて、ページ数がどう減るかを測り、症状基準のアラート1つと比べます。そのあと、原因のアラートが鳴った時間のうち、ユーザーが何も体験しなかった時間が何分かを数え、その数字を根拠に、何をページとして残し何を下げるかを表で決めて、最後にページ用のルールファイルだけを別に作って検査を通します。