オオカミ少年の
サイレン
「警告！」「警告！」「警告！」。Slackに響き渡る通知音。
しかし、誰も反応しません。「あー、いつものやつだから無視でいいよ」。
そんな日常が続くある日、本当の「致命的なエラー」が届きます。
もちろん、誰も気づきません。
- Slackのアラート用チャンネルを「ミュート」にしている
- `[Warning] Disk usage 80%` が常に出続けて半年になる
- エラーメールが1日100通以上届くフォルダがある
- 障害発生時、「どのアラートを見ればいいか」で毎回迷う
意味のないアラートは、エンジニアの注意力を削ぐ「攻撃」と同じです。
01. 埋もれる真実
[WARN] CPU usage 82% (normal spike)
[WARN] Memory usage 75%
[CRITICAL] Database Connection Failed!!
[WARN] CPU usage 81%
[INFO] Hourly backup started
上記のようなチャンネルを、毎日真剣に見続けることは不可能です。
人間は、頻繁に発生する無視可能な刺激に対して「順化（慣れ）」を起こします。
その結果、本当に重要な `[CRITICAL]` 通知が、無害な `[WARN]` や `[INFO]` の濁流に飲み込まれます。
「オオカミが来た！」と嘘をつき続けた少年と同じ結末が、システム運用でも起こるのです。
「誰も動かないアラート」を飛ばすな。
02. アクション可能なものだけ通知せよ
アラートの鉄則は、「受け取った人が、今すぐ何か行動を起こす必要があるか？」です。
「ディスク容量が80%になった（でも来週増設予定だから放置でOK）」なら、通知すべきではありません。
「夜中に叩き起こされてでも対応すべき事態」だけをスマホに通知し、
「明日確認すればいいこと」はレポートにまとめる。
この選別（トリアージ）こそが、SRE（サイト信頼性エンジニアリング）の第一歩です。
03. ログレベルの徹底管理
開発段階から `console.log` や `logger.error` を乱用しない教育が必要です。
一時的な通信エラーで `Full Stacktrace` を吐き出すのはやめましょう。
ログは「ラブレター」です。読み手（未来の自分や運用担当）を想って書くものです。
ノイズを減らし、シグナルを研ぎ澄ませることで、異常検知の初動は何倍も速くなります。