アラートの運用/ Operations

アラートの運用画面（/admin/alerts）は、システム管理者だけが開けます。上から計器 4 枚 → 絞り込み 3 種 → カードの一覧の順で、上ほど「全体の量」、下ほど「個別の中身」になります。

計器 4 枚

画面を開いて最初に目に入るのは、いま抱えている量です。4 枚のうち3 枚は押すと、その計器が数えている集合そのものへ一覧を絞り込みます。

押せる 3 枚も、0 件のときは押せません。押した先が確実に空だと分かっている遷移を用意しないためです。

絞り込み 3 種

状態・重大度・種別・ページ・表示件数はすべて URL に載ります。「この条件の一覧を見てほしい」を URL のまま渡せます。表示件数は 10 / 20 / 50 から選べ、既定は 20 件です。絞り込みを変えたときはページを 1 に戻します。

並び順を固定する理由

並び順は最終発生が新しい順で固定し、並べ替えの操作を持ちません。この画面は 30 秒ごとに自動で更新されます。並び順まで変えられるようにすると、行が動いたときに「更新で動いた」のか「並べ替えで動いた」のかが判別できなくなります。代わりに、一覧の見出しの右へ「最終発生が新しい順」を常時表示して、順序の根拠を画面上に出しています。

ページ番号も URL に載るため、他の管理者が対応して行が減ると、開き直したときに範囲外のページに着地することがあります。総件数が確定した時点で範囲外なら、最後のページへ静かに寄せます。

空のときの 3 通り

なお、既定の条件（未対応）で 0 件と N 件の間を 30 秒ごとに行き来する面では、読み上げソフトがその都度しゃべると邪魔になります。自動更新で揺れる空状態は読み上げの対象から外し、利用者の操作の結果である「絞り込んで 0 件」だけを読み上げます。

1 件のアラートは 1 枚のカードです。4 行で構成し、上ほど「何が起きたか」、下ほど「どうするか」になります。

3 行目の「代表値 1 つ」は、自由項目の中から規模が一目で分かる 1 値だけを取り出したものです。滞留や積み残しなら件数、バウンス率なら 24 時間の率、クォータなら使用率、所要時間なら時間、バッチの失敗ならワーカーの名前、といった具合です。取り出せる値が無い種別では何も出しません。ここで失敗して画面ごと落ちることが無いように、値が取れないときは黙って空になります。

状態は「面の色」ではなく、要素で分ける

未対応と対応中は通常の面、終端（解決済み・無視）は無彩色の落ち着いた面にします。加えて、無視のカードだけ種別の名前に取り消し線が入ります。

重大度の左罫は状態によらず常に維持します。重大度は「そのとき何が起きたか」という記録の事実であって、対応が進んだから軽くなるものではないためです。重大度は色だけに頼らず、色・アイコンの形・和文の 3 つで同時に表しています。

カード 1 枚 ＝ タブ 1 回

カードは全体が 1 つのボタンとして働き、クリックでも Enter / Space でも詳細が開きます。4 行目のボタンはマウス用の近道という位置づけで、キーボードのタブ移動の対象から外してあります。20 件表示のとき、外さなければ一覧の中に最大 80 回のタブ停止が生まれ、ページ送りまで到達するのが困難になります。キーボードでの操作は「カードで Enter → 詳細の下部のボタン」の 1 本に集約しています。

状態は 4 つ、操作は 3 つです。解決済みと無視は終端で、そこから戻す操作は用意していません。再発は検知器が新しい行として起票するのが正しい形だからです。

理由の必須と任意

3 つの操作はいずれも確認のダイアログを挟み、そこで理由を書きます。理由が必須なのは「無視」だけです（10〜256 文字）。対応中にする・解決するは任意で、空のまま確定できます。

理由の入力欄には「監査ログに記録されます」と添えてあり、文字数の下限・上限とカウンタは入力欄自身が出します。取り消せない操作なので、確定ボタンには最初からフォーカスを当てません。ダイアログが開いた勢いで Enter を押しても確定しないようにするためです。送信中は確定と取消の両方が押せなくなり、二重送信を防ぎます。

弾かれたときに、ダイアログを閉じない

他の管理者が先に動かしていた場合、後から押した操作は拒否されます。このとき確認のダイアログは閉じません。閉じてしまうと、直後の自動更新で一覧が並び替わり、「どの行の話だったのか」を見失います。サーバから返った文（現在の状態が差し込まれています）をそのまま出し、一覧と詳細を取り直したうえで、利用者が自分のタイミングで閉じて判断し直せる形にしています。成功したときだけ、ダイアログが閉じます。

カードを押すと詳細が開きます。中身は 概要 / 対象 / 推奨アクション / 対応状況 の 4 区画で、この中だけで判断が終わることを設計の目標にしています。

関連画面のリンクは、実装済みのものだけ描く

推奨アクションには、次に開くべき管理画面へのリンクが付きます。29 種のうち21 種にリンクがあり、残る 8 種にはリンクを描きません。8 種のうち 3 種は行き先の画面が今後実装されるもので、リンクの名前だけを持たせてあります（実装時にパスを差せばそのまま活性化します）。残り 5 種は、対処がクラウド側の操作や手順書の中で完結するため、恒久的に行き先を持ちません。

対応履歴は監査ログから引く

アラートの行そのものが持つのは最新の遷移 1 つだけ（いつ・誰が・理由）です。状態ごとに列を増やすことはしていません。時系列は、遷移のたびに書かれた監査ログから引き直します。1 つの記録に 2 つの真実を持たせない形です。履歴がまだ無いときは「まだ対応履歴はありません」と出します。

開いている間は、足元を動かさない

詳細や確認ダイアログを開いている間、一覧の自動更新は止まります。理由を書いている最中に背後の一覧が入れ替わらないようにするためです。閉じた瞬間に取り直すので、戻ったときには最新になっています。

詳細の取得に失敗したときは、ウィンドウを閉じずに中身だけを「取得できませんでした」と再試行のボタンに差し替えます。閉じてしまうと、フォーカスの戻り先だったカードが自動更新で入れ替わっている可能性があり、何が起きたのかも伝わりません。遷移に成功したときも詳細は開いたままで、更新後の状態と履歴がその場に反映されます。

配送に関わる 3 種のアラートでは、詳細の中にいまのシステムの状態そのものが並び、そこから直接手を打てます。読んで理解しても、別の画面に移らないと何もできないなら、気づきは行動になりません。

上 2 つは 30 秒ごとに取り直すライブの一覧です。見出しには「現在 N 件」と書き、その下に「現在の状態を表示しています（起票時点の内訳は上の詳細データを参照）」と添えます。起票したときのスナップショットと、いま見ている数が違うのは正常で、その差をここで説明し切っています。3 つ目だけは起票時点の記録で、こちらは 30 秒更新をしません。ライブの一覧が 2 つあるのに 1 つだけ止まっている理由は、内訳の元になる数値が外部の監視から取った値で、都度引き直す種類の情報ではないためです。

一覧は 50 件ずつ読み込みます。アラートが解決済みや無視になっていても、一覧は常に表示します。これはアラートの付属物ではなく、いまのシステムの状態を映す窓だからです。

失敗イベントの 1 行に入るもの

外部へ配信できずに再試行の上限へ達したイベントは、4 行で表示します。中身は識別子の羅列ではなく、業務の言葉に直してあります。

2 行目の名前は、イベントの中身から取り出しています。中身に操作した時点の名前が凍結されて入っていればそれをそのまま使い、識別子しか無ければデータベースを引き直します。削除済みで引けないものは空欄になります。名前を後から引き直す方式だけにすると、「削除されたファイルの配信失敗」が名無しになって調べようがなくなるためです。

再投入と破棄

処分した行はその場で一覧から消えます。すべて処分し終えると一覧は空になり、「現在、配信に失敗したイベントはありません（すべて処分済みです）。このアラートは 5 分以内に自動で解決済みになります」と出ます。5 分ごとの検知器が 0 件を確認して、アラート自体を閉じるためです。

滞留した通知の再キュー

送信待ちのまま 30 分を超えた宛先も、同じ形で並びます。テンプレートの日本語名・通知の件名・伏せ字にした宛先・滞留が始まった時刻の 4 つで、行ごとの再キューと、古い順に最大 100 件の一括再キューができます。見出しには「送信前の状態のまま 30 分以上経過した宛先を表示しています」と書き、検知の条件と表示している母集団が同じであることを言葉でも保証しています。

なお、再キューで作る配送の指示は必ず新しい名前で作ります。同じ名前で作り直そうとすると、完了済みの名前は一定時間その名前を受け付けず、再キューが黙って失敗します。二重送信を防いでいるのは名前ではなく、配送する側が「送信待ち以外なら送らずに終わる」ことを毎回確かめている仕組みのほうです。

アラートは、席を外している間にも起票されます。見ていない時間のほうが長いという前提で、気づき方を 4 つ用意しています。

重大アラートの通知は時間で自動的に消えません。閉じるのは明示的に押したときだけです。監視の画面では席を外している時間が長く、数秒で消える通知は「気づく」役に立たないためです。初回の観測では鳴らしません（画面を開いた瞬間に既存の件数で鳴ってしまうため）。同数のときも、減ったときも鳴りません。

音は使いません

管理画面は複数のタブで開かれ、席を外している間に鳴った音は何の情報も残しません。加えて、ブラウザは操作を伴わない自動再生を制限するため、鳴る保証もありません。代わりに、消えない通知・件数バッジ・個別のメールの 3 つで受け止めています。

件数バッジは上部の 1 か所だけに置き、左のメニュー項目には件数を持たせていません。同じ数値を 2 か所に出すと、更新の間隔の違いで食い違って見えるためです。

アラートには、管理画面の中で対処が終わるものと、クラウド側の操作が要るものがあります。29 種のうち 13 種には、詳細の中に「開発者への連絡」のブロックが出ます。残る 16 種には出ません。

この線は固定ではありません。イベント配信の滞留・配信不能メッセージの超過・通知配送の滞留の 3 種は両方に足がかかります。まずアプリの中で再投入や再キューを試し、それでも戻らない場合にクラウド側の権限や設定を疑う、という条件つきの文になっています。次の一手の文（アプリ内でできること）と、連絡へ切り替える条件の文を、役割で分けてあります。

「詳細をコピー」

引き継ぎの手段として、すべての種別の詳細に「詳細をコピー」のボタンが常設されています。押すと、種別・重大度・状態・説明文・発生（初回 / 最終 / 回数）・アラートの識別子・自由項目の中身が、整形されたテキストとしてクリップボードに入ります。イベント配信の滞留と通知配送の滞留では、そのとき読み込んでいた一覧の行（最大 50 件と「他 N 件」）も一緒に入ります。宛先のメールは伏せ字のままで、開発者は識別子から引ける形にしてあります。

連絡の手段そのもの（メールの下書きを開くなど）は用意していません。連絡経路は運用側で変わるため、資料を作る側の仕事に留めています。

アラートに関わる操作は、すべてシステム管理者だけです。Box のロール（Owner / Editor / Uploader / Viewer）はここには関係しません。

確認は 2 段階です。まずログインしていること、次にシステム管理者であること。加えて、データベース側でも「システム管理者以外は 1 行も見えない」設定が別にかかっています。アプリ側の確認を通り抜けても、データベースが返しません。

操作の記録は 6 種類

アラートまわりで監査ログに残る操作は 6 種類です。状態遷移の 3 つ（対応中にする・解決する・無視する）と、配送運用の 3 つ（イベントの再投入・イベントの破棄・通知の再キュー）です。理由は専用の欄と自由項目の両方に入れてあり、1 行だけで「誰が・どのアラートを・なぜ動かしたか」が読み切れます。