監視の次は、知らせ方

第4回で「何を見張るか」を決めました。次は見つけたことを、誰に、どう知らせるかです。障害のときに呼び出しを受ける当番のことを「オンコール」と呼びます。

特定の有料ツールの使い方ではなく、どのツールにも共通する設定の考え方を押さえます。

全部を同じ重さで知らせると、本当の障害を見落とす

通知を全部「重要」にすると、どうなるか。最初はすべてに目を通します。でも、すぐに対応しなくていい知らせが毎日何十件も来ると、人は通知を見なくなります。これを「通知疲れ」と呼びます。そして、本当の障害の通知も、ほかと同じ見た目で埋もれます。

naminori でも起きました。2026年9月にエラー監視を見直すと、ボットの探索が起こす、対応のいらないエラーが1,143件通知されていて、その中に本物の不具合が33件埋もれていました（登録の通知が、特定の入力で丸ごと落ちる不具合でした）。対応のいらないものを通知から外したことで、「見れば異常が分かる」状態に戻りました。

ただし、外したものは見えなくなります。講座34の第5回で見たとおり、外した種類のエラーの中に、あとで本物の不具合が混ざることもあります。通知から外すときは、何を、なぜ外したかを書き残しておきます。

重さを3段階に分ける

知らせる前に、その知らせで人が何をすべきかで分けます。

「この通知が来たら、何をするか」を答えられない通知は、重さを下げるか、通知をやめます。

通知先を、役割で分ける

naminori では、知らせの種類ごとに行き先を分けています。

• エラーは GlitchTip に集める。チャットには流さない
• 会員の行動（登録・診断・講座の開始・応募など）は ntfy（スマホに通知を送る仕組み）に送る。求人への応募と無料相談の申し込みは、ほかより重さを1段上げている
• OSの更新のような夜中の作業は、段階ごとに ntfy に知らせ、失敗したときだけ最も重い通知にする

会員の行動の通知は、30日で登録7件・診断1件・講座の開始4件という件数だったので、まとめずに1件ずつ送ると決めました。件数が増えたら、まとめて送るように見直します。通知の設定は、件数を見て決め、件数が変わったら見直すものです。

当番とエスカレーション

呼び出しは「誰かが見るだろう」では届きません。どのツールでも、次の3つを設定します。

• 当番表: いま誰が受けるか。人の名前ではなく、当番に送る
• 受けたことの合図: 当番が「見ています」と返すと、ほかの人への呼び出しが止まる
• エスカレーション: 一定の時間、合図が無ければ次の人へ回す

通知に、次にやることを添える

夜中に起こされた人は、頭が回っていません。通知の本文には、次に何を見て、何をすればいいかを添えます。手順を書いた文書を「ランブック」（手順書）と呼びます。

• どこを開けば詳しく分かるか（naminori の会員の通知は、管理画面の該当ページへのリンクを付けている）
• 何が、いつから、どのくらい起きているか（定期処理の見張りは、何が何日古いかを本文に書く）
• 手順書の場所

通知の経路そのものも壊れる

最後に、通知が届かないことにも気づける必要があります。naminori では、ntfy の鍵（トークン）が無効になっていた期間、要望フォームの通知が届いていませんでした。定期処理の失敗通知を作る途中で、ようやく気づきました。

• 大事な知らせは、2つの経路に送る（naminori の定期処理の失敗は、エラー監視と ntfy の両方へ）
• 両方に失敗したら、その事実を記録に残す
• 鍵を差し替えたら、実際に1件送って届くことを確かめる

• 通知疲れで本当の障害を見落とす理由
• 重さを3段階に分け、通知先を役割で分ける
• 当番・受けた合図・エスカレーション
• 通知に手順書を添える、通知の経路も確かめる