SRE 実践 #3 アラート設計 — 症状ベースの通知とマルチウィンドウ・バーンレート
アラートの目的はひとつです。人の介入が必要な問題を、介入が必要な時点で、介入できる人に知らせること。 ところが多くの組織で、アラートチャンネルは誰も読まない通知の滝になっています。今回は 第 2 回で扱ったバーンレートをアラートとして実装する方法と、アラートシステムを信頼できる状態に保つ運用を扱います。
原因ではなく症状にアラートを掛けます #
伝統的なアラートは原因の候補に掛かっています。CPU 80% 超過、ディスク 90%、プロセス再起動。この方式の問題は、両方向に間違えることです。
- 誤検知: CPU が 90% でも、ユーザーリクエストがすべて正常に処理されているなら、夜中に起こす理由はありません。バッチ処理が走っているだけかもしれません。
- 見逃し: CPU、メモリ、ディスクがすべて正常なのに、上流の依存先の問題でユーザーリクエストが失敗しているなら、原因ベースのアラートは沈黙します。
症状ベースのアラートは、ユーザーが体験するもの、つまり SLI に掛けます。 エラー率がしきい値を超えているか、レイテンシの SLI が崩れているか。原因が何であれユーザー影響があれば鳴り、なければ鳴りません。第 1 回で SLI をユーザージャーニーから設計した理由がここで回収されます。CPU のような原因の指標はアラートの対象ではなく、アラートを受けたあとに開く診断ダッシュボードの持ち場に降りてもらいます。
ページとチケット — 応答時間の契約 #
すべての通知が同じ緊急度ではありえません。2 つの等級に分けます。
| 等級 | 意味 | 基準 |
|---|---|---|
| ページ(page) | 今すぐ人を起こす | 放置すると数時間以内に SLO が有意に毀損される |
| チケット(ticket) | 業務時間に処理する | 問題は実在するが数日の余裕がある |
判定の問いはひとつです。「この通知を深夜 3 時に受けたとき、今起きてやれること、やるべきことがあるか?」 なければページではありません。この基準を通らないページが積もると、本当に重要なページが来たときの反応が鈍ります。
マルチウィンドウ・バーンレートアラート — 速い消費も遅い消費も捕まえる #
SLI にアラートを掛けるとき、いちばん素朴な実装は「直近 5 分のエラー率が X% を超えたら通知」です。この方式はウィンドウが短いために瞬間的なスパイクで誤検知し、低強度で長く続く問題は取り逃がします。検証済みの解決策がマルチウィンドウ(multiwindow)・バーンレートアラートです。
構成の原理はこうです。28 日ウィンドウ、SLO 99.9% を基準に、広く使われている組み合わせは次のとおりです。
| 目的 | バーンレート | 測定ウィンドウ | 意味 | 対応 |
|---|---|---|---|---|
| 速い消費の検知 | 14.4 倍 | 1 時間 | 1 時間で 28 日バジェットの約 2% を消費 | ページ |
| 中程度の消費の検知 | 6 倍 | 6 時間 | 6 時間でバジェットの約 5% を消費 | ページ |
| 遅い消費の検知 | 1 倍 | 3 日 | この速度ならウィンドウ内にバジェットが全量枯渇 | チケット |
これに短い確認ウィンドウを組み合わせます。たとえば「1 時間ウィンドウで 14.4 倍、かつ直近 5 分でも 14.4 倍」のように、2 つのウィンドウが同時に条件を満たすときだけ鳴らすようにすると、問題はもう終わったのに長いウィンドウの平均のせいで遅れて鳴る、燃え残りアラートが消えます。
この構成の長所は、アラートの強度がユーザー影響の大きさに比例することです。バジェットを速く燃やす大きな問題は数分以内にページが飛び、じわじわ削る問題はチケットとして積まれて業務時間に処理されます。どちらも取り逃がさず、深夜の呼び出しは最小化されます。
アラート疲れ — 測らなければ減りません #
アラートシステムは作るときより維持するときに壊れます。鈍麻は徐々に来るので、定期的に数字を見る必要があります。
- 週次アラートレビュー: 先週鳴ったページ全部を並べて 3 つに分類します。対処が必要だった(正常)、対処が不要だった(誤検知、チューニング対象)、通知なしに別の経路で見つかったユーザー影響があった(見逃し、カバレッジ補強の対象)。
- 誤検知アラートはその場で処分します。 しきい値を調整するか、チケットに降格するか、削除します。「とりあえず置いておこう」の積み重ねが、通知の滝の正体です。
- ページ件数そのものを指標にします。 シフトあたりのページが一定数を超える状態が続くなら、それはオンコール個人の問題ではなく、システムの信頼性負債かアラート品質の問題です。この数字は次回(オンコール)で負荷の上限として再登場します。
もうひとつ、すべてのアラートにはランブックのリンクを付けます。深夜にページを受けた人に「このアラートは何を意味し、最初の 30 分で何を確認すべきか」をドキュメントなしで解読させるのは設計の失敗です。診断の最初の一歩が漠然としているなら、REST API が遅いとき — ボトルネックを探す順序のような診断手順の記事がランブックの素材になります。
まとめ #
- アラートは原因(CPU)ではなく症状(SLI)に掛けます。原因の指標は診断ダッシュボードに降ろします。
- ページの基準は「今起きてやるべきことがあるか」です。なければチケットです。
- マルチウィンドウ・バーンレートアラート(14.4 倍/1 時間、6 倍/6 時間のページ + 1 倍/3 日のチケット)が、誤検知と見逃しを同時に減らす検証済みの構成です。
- 週次アラートレビューで誤検知をその場で処分し、シフトあたりのページ件数を指標として管理します。
- すべてのアラートにランブックを付けます。次回はそのページを受け取る人たち、オンコール運用です。