督促に持ち主を付け、重複を畳み、直ったら自動で取り下げる
今回やったこと
異常通知は、送った時点で仕事が終わるわけではない。誰が直すのかが曖昧な通知、同じ原因を何度も知らせる通知、問題が解消しても残り続ける通知は、受け手の注意を消費し、重要な変化を見えにくくする。通知を出口まで設計し直し、持ち主、重複抑制、解決時の取り下げを揃えた記録である。
対象は、定期ジョブや自動処理からDiscordやIssueへ異常を送っている運用担当者だ。通知件数を増やすことではなく、通知を受け取った人が次に何をすべきか判断でき、解決後に状態が閉じることを目指す。
通知の件数より、通知の持ち主を見る
運用記録では、ある督促が3週間で205件記録されていた。最初は未処理の案件が大量にあるように見える。しかし内容を突き合わせると、同一の通知が繰り返されていたうえ、未回収とされた題材は後続の処理ですでに扱われているものも含んでいた。問題は単純な処理能力の不足ではなく、通知が「誰に何を求めているか」を表現できていないことだった。
特に、次の処理で自動的に再選択できるものを、人間への督促として毎回鳴らすと、実際に人の判断が要る依頼と区別しにくくなる。通知の責任者は、異常を最初に発見した人とは限らない。次回実行で回復するなら自動処理が持ち主であり、人間しか決められない選択が残るなら、その判断を依頼する相手が持ち主になる。
| 状態 | 持ち主 | 通知の扱い |
|---|---|---|
| 次回実行で回復する一時的な失敗 | 自動処理 | 状態を記録し、必要以上に督促しない |
| 自動修復できるが介入が必要 | 修復レーン | 修復作業に結び付ける |
| 人間の判断が必要 | 判断する担当者 | 判断内容と期限を明確にする |
| 解決済み | 該当なし | 未解決通知を取り下げる |
この分類は通知の深刻さだけでなく、次の行動を基準にする。単に赤い表示を増やしても、解決する主体がいなければ運用は進まない。
同じ問題を一度だけ知らせ、回復時に閉じる
重複通知は、同じ根本原因から何度も発生するものを識別する鍵を持たせて抑える。通知元と対象を組み合わせた安定したキーを使えば、実行ごとに新しい通知を積むのではなく、同じ問題としてまとめられる。逆に、識別子を細かく作りすぎると同じ問題が別件に分裂するため、何を同一事象と見なすかを運用上の判断として定義する。
また、回復を検知したときの出口も用意する。異常発生の通知だけを実装し、正常化後の状態変更を忘れると、Issueや督促が未解決のまま残る。今回の対応では、問題の解消時に関連するIssueを閉じる経路を各スクリプトへ配線した。送信した通知と、その後の回復が同じ識別子で結び付くことが重要になる。
回復後に新たな問題が起きた場合は、前の事象を再利用せず、新しい通知として扱う。過去の履歴を保ったまま状態を閉じれば、同じ問題の継続と、いったん直った後の再発を区別できる。
導入時に確認すること
通知を整理するときは、本文の文言だけでなく、直近の記録を送信元・対象・発生時刻で集計する。記録上の件数が多くても、実際の案件数が多いとは限らない。集計方法自体が同じ在庫を重複計上していることもあるため、件数を改善目標にする前に、何を一件と数えたかを確かめる。
そのうえで、各通知に次の情報が揃っているかを見る。
- 誰が次の行動を取るか
- 受け手に求める行動は何か
- 同じ事象を識別するキーは何か
- どの条件で通知を抑制するか
- 何をもって回復と判断し、どう取り下げるか
回復経路を実装する際は、問題が続いている間は同じ事象として保たれること、回復後は閉じられること、再発時には新しい事象として扱えることをテストする。通知スクリプト単体だけでなく、実際の起動元から識別子や解決オプションが渡ることも確認する。
この設計は、あらゆる通知を静かにするためのものではない。人にしか判断できない異常は、担当者と依頼内容を明示して届ける。自動で回復するものは履歴に残しつつ繰り返し鳴らさない。状態が直ったときには未解決の印を外す。通知を「発生時のメッセージ」から「所有者と解決状態を持つ運用記録」へ変えることが、継続可能な仕組みにつながる。
更新履歴
- 2026-10-05: 初稿を作成。