異常の検知/ Detection

全 29 種です。重大度は 2 段（重大 / 警告）で、種別ごとに固定しています。ただし 3 種だけ、影響の範囲によって重大度が変わります。29 種すべてに起票する実装があります（表示だけの枠は残っていません）。

種別の名前・日本語の表示名・重大度と状態の日本語は、すべて共有の定数 1 か所が持っています。種別が増えると、関連する対応表（表示名・アイコン・系統・推奨アクション）の型が合わなくなり、コンパイルの時点で落ちます。更新の漏れが本番まで届きません。

1 種だけ、退役したものがあります

当初は 30 種でしたが、1 種（Drive のゴミ箱送り失敗）を退役させて 29 種になりました。理由は、起票する経路が一度も存在しなかったこと、そしてその失敗の形はほかの 2 つの仕組み（同期ジョブの失敗記録・配信不能の監視）で二重に見えていることが分かったためです。鳴らない枠を残すと、「この種類は本番で 1 件も出ていない」と「この種類は動いていない」が区別できなくなります。

29 種は、性質の違う 4 つの場所から起票されます。実行体は Node.js 側と Go 側にまたがりますが、書き込み先は1 つのテーブルです。

dlq-monitor という 1 つのバッチが、5 分ごとに 6 つの検知器を順に回します。見る先はアプリのデータベースが 5 つ、クラウドの監視から数値を取るものが 1 つです。

6 つを互いに独立に回す

6 つは順番に、しかし互いに独立に回します。1 つが例外で落ちても残りは実行し、失敗はその場でログに出したうえで、全部を試したあとにまとめて投げ直します（バッチが異常終了 → 5 分後に再実行）。

1 つの失敗で全部が止まる作りにすると、この仕組み自身が「静かな欠落」を作ってしまいます。塞ぐつもりの穴を検知器が自分で開けることになるので、ここは最初から独立に組んでいます。

滞留の検知に、なぜ 2 つの検知器が要るのか

② と ③ は名前が似ていますが、別の故障を見ています。片方がもう片方の代わりにはなりません。

⑤ が別にあるのも同じ理由です。通知を実際に届ける段には、配信できないメッセージの置き場という概念がありません。試行の回数を使い切った依頼は痕跡なく消えます。そのとき宛先の状態は「送信待ち」のまま残るので、画面の「配信失敗」の一覧にも現れません。画面にもログにも監視にも出ない完全な死角だったため、「送信待ちのまま 30 分超」を数える検知器を足しました。

5 分ごとに数える形にすると、素朴に作れば滞留が続くあいだ 5 分ごとに 1 行ずつ増えます（12 行 / 時間・288 行 / 日）。これでは一覧が使えません。

対処は「時間の窓で止める」ではなく、解決済み以外の同じ種類の行がある間は起票しない方式です。時間の窓（たとえば 24 時間）にすると、管理者が対応中で抱えている案件が翌日また新しい行として湧いてきます。

調査中は「対応中」が正しい一手

5 分ごとに数える種類のアラートでは、「解決」を押すと同じ内容の再通知が再開します。まだ滞留が続いている状態で解決にすると、数分後に新しい行が立ちます。これは仕様どおりの動きですが、知らないと「何度も同じアラートが出る」と見えます。

そこで、この 5 種類の推奨アクションの文の末尾には共通の一文が付いています。「調査中は『対応中』にしてください」という案内で、こうすると同じ内容の再通知が止まったままになります。

一部の種類は、条件が消えたことを検知器が観測した時点で、自動的に解決済みになります。人が押す必要がありません。

自動で閉じる仕組みを入れた理由は、逆の状態が実際に起きたからです。本番で「イベント配信の滞留」のアラートが 1 件、未対応のまま残っていました。中身のイベントは既に処分済みで、検知の条件はもう消えていたのに、アラートだけが残っていた形です。

手で解決できない 2 種類

逆に、Workspace 系の 2 種類は手で「解決」にできません。条件が消えると自動で閉じる作りなので、手で閉じても翌日の同期でまた未対応に戻ります。押せるのに翌日戻るボタンは嘘なので、窓口が拒否し、画面はそのボタン自体を出しません（二重の防御）。「対応中」（判断を保留する）と「無視」は選べます。

3 つの経路で届きます。管理画面を開いていない時間帯にも届く必要があるので、メールが要ります。逆に、メールだけだと埋もれるので画面が要ります。

29 種のうち共通の文面で送らないのは 6 種です。うち 5 種は上の「個別の文面」が受け持ち、残る 1 種（アップロード整合性エラー）は意図的にメールを送っていません。この事象は提出者側の再アップロードで解消するもので、管理者が即座に動く必要がないためです（画面の一覧には出ます）。

本番で仕組みが実際に事象を捕まえた例を 1 つ取り上げます。

「イベント配信の滞留」1 件の中身

この 1 件は、この資料でいちばん説明したい形の故障です。ファイルの検査完了を伝えるイベントが、発行の権限が足りないために送れず、再試行の上限に達して溜まりました。

• 画面にはエラーが出ていません。利用者から見て、ファイルは正常にアップロードされています。
• クラウド側の監視にも異常が出ていません。サービスは正常に応答しています。
• 結果として起きたのは「通知メールだけが出ない」ことです。これは、受け取る側が「来ていない」と申告するまで誰にも見えません。

5 分ごとの検知器がこれを拾い、アラートの自由項目に内訳を残しました。どの種類のイベントが何件、いちばん古いものはいつ発生したか、直近のエラーは何か、です。この 4 つが揃っていたので、原因の特定はすぐに済みました。