警報が一日に何十件も届く状態が続くと、人は開かなくなります。悪気があるのではなく、開いても手を打てない件が続けば、優先順位が下がるのが当たり前だからです。
そうなったあとで本当の異常が鳴っても、同じ束の中に埋もれます。件数が多いことは、安心ではなく危険な状態です。
一日に何件までなら必ず開けるか。先にその数を決めておくと、増えたときに減らす理由がはっきりします。当社は、人数と使える時間から逆算しています。
よくある作り方は、数値がある線を超えたら鳴らす、というものです。これだと線の引き方だけで件数が決まり、たいてい多すぎるほうに寄ります。
当社が使っている基準は一つです。鳴ったとき、人が今すぐ何かをするか。しないなら、それは警報ではなく記録です。
「念のため」で作った警報は、ほぼ確実に読まれなくなります。念のためは、記録の側に置きます。
「利用者への影響が出ているときだけ鳴らす」という考え方は、運用の実務書でも中心に据えられています。Google SRE Workbook「Alerting on SLOs」（英語）↗
全部を同じ強さで出さないことが、いちばん効きます。当社は三段に分けています。
今すぐ ── 止まっている、または外に影響が出ている状態です。すぐ手を動かします。
今日中 ── 動いてはいますが、放っておくと悪くなるものです。まとめて一日一回。
記録だけ ── あとで傾向を見るためのもの。通知はしません。
迷ったものは、まず記録だけに置きます。上げるのは、実際に手を打った回数が出てからで間に合います。
下から上へ上げるのは簡単ですが、上から下へ落とすのは決断が要ります。ですから、最初は低いほうから始めます。
どの段に置くかは、作った人ではなく受け取る人が決めます。受け取らない人が決めた警報は、たいてい一段高いところに置かれます。
一つの不具合が、下流の十か所で失敗を起こすことがあります。そのまま出せば十件の警報になりますが、人が知りたいのは一件です。
ですから、同じ原因のものは束ねて一件にします。件数は本文に書けば足ります。数えるのは仕組みの仕事、読むのは人の仕事と分けておくと、束ね方は自然に決まります。
まとめ方や重複の抑制は、監視の道具側にもともと備わっている考え方です。Google Cloud「Cloud Monitoring の概要」↗
作った警報を消すのは、なんとなく気が引けます。消した直後に限って問題が起きるのではないかと思うからです。
それでも当社は、月に一度は棚卸しをして、一度も手を打たなかった警報を落としています。判断は簡単で、鳴った回数と、それを見て何かをした回数を並べるだけです。後者がゼロなら、それは記録に落とします。
落とすときは、いきなり消さずに一か月だけ記録に置いて様子を見ます。それで困らなければ、そのまま消します。
宛先が「全員」になっている警報は、結果として誰も見ません。全員宛は、誰の仕事でもないという意味になります。
当社は、今すぐ手を打つ種類のものだけ受け取り手を一人に決めています。承認の置き方と同じ考え方です（C-07-2 承認をどこに置くか）。読む人が決まっていない知らせは、届いていないのと同じです。
受け取り手を決めると、休みの日の扱いも自然に決まります。誰も見ていない時間帯に鳴るものは、翌朝に届けば足りることがほとんどです。
当社では 221本 の定期実行と 85体 の稼働があり、素直に全部を通知に回せば、一日で読めない量になります（AIの中身）。
そこで、通知に出すのは外に影響が出る種類のものだけに絞り、残りは画面に集めています。集めておけば、見に行くことはできます。見に行けるものと、押しかけるものを分けるのが、件数を保つこつです。
知らせ方が決まったら、次は直し方です。仕組みが自分で直せる範囲と、直してはいけない範囲を見ていきます。
章と記事の全体は図書館の見取り図で一枚にまとめています。