これは何か
監視・アラート一覧は、システムの何を見張り（監視）、どうなったら人に知らせるか（アラート）、知らせを受けた人が何をするかを一覧にした成果物です。
監視とは、システムの状態（動いているか、遅くないか、処理がたまっていないか など）を、仕組みを使って見続けることです。アラートとは、決めた状態になったときに、人に自動で知らせることです。
なぜ作るか
- 利用者から連絡が来る前に、異常に気づけるようにする
- 知らせを受けた人が、何をすればよいか迷わないようにする
- 鳴っても誰も見ない「鳴りすぎるアラート」を減らす
- 稼働直後の集中対応（14-01）で、何を見ればよいかをはっきりさせる
誰が使うか・いつ作るか
- 作る人：運用の担当と、各システムの担当（監視の仕組みを担当する会社を含む）
- 使う人：運用の担当、当番、障害対応の指揮役
- 一般的には、運用設計の段階で作り、テスト・リハーサルで鳴るかを確かめ、稼働後に実際の鳴り方を見て直します
- アステリア案件の監視の項目・閾値・通知先は、正本に記載がありません。未確定
CASE FACTFROZEN正本に記載されたアステリア案件の事実
監視に関係する記載
- SYS-11 監視・ログ基盤
- IF-11 新基幹 → 監視・ログ、IF-12 連携基盤 → 監視・ログ
- Vendor B / クラウドブリッジの担当範囲に監視が含まれる
- P-011 山下 恵 — 本番移行・運用リーダー
- M18 本番稼働、M21 初期安定化完了
IF-11・IF-12 の経路は正本にありますが、何を監視するか、どの状態で知らせるか、誰に知らせるかは、正本に記載がありません。未確定
主な項目（列）
一般的には、1行に次の列を持ちます。
- 監視の番号と名前
- 対象：どのシステム・どの処理・どの連携か
- 見るもの：何の値や状態を見るか
- 知らせる条件（閾値）：どうなったら知らせるか。「閾値（しきいち）」は、知らせるかどうかの境目の値のこと
- 重大度：知らせの重さ
- 通知先：誰に、どの手段で知らせるか（当番・時間帯で分ける）
- 最初にすること：知らせを受けた人が最初にすること（手順書への参照）
- 確かめた記録：テストで実際に鳴ることを確かめたか
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — 一覧の数行
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
次の表は、一覧の書き方を学ぶための例です。対象・条件・通知先は、すべて教材上の架空の例で、アステリア案件の監視ではありません。条件の値は伏せています。
| 番号 | 対象 | 見るもの | 知らせる条件 | 重大度 | 通知先 | 最初にすること |
|---|---|---|---|---|---|---|
| MON-EX-01 | 夜間の連携処理 | 処理が終わったか | 決めた時刻までに終わらない | 高 | 夜間の当番 | 連携の手順書の該当箇所に従い、状態を確かめる |
| MON-EX-02 | 連携の送り待ち | たまっている件数 | 決めた件数を超えた状態が続く | 中 | 連携の担当 | 相手のシステムの状態を確かめる |
| MON-EX-03 | サーバーの記憶領域 | 使っている割合 | 決めた割合を超えた | 中 | 基盤の担当 | 不要なファイルを確かめる（消す前に担当に相談） |
| MON-EX-04 | 監視の仕組みそのもの | 監視が動いているか | 一定の時間、監視の記録が届かない | 高 | 基盤の担当 | 監視の仕組みの状態を確かめる |
読み方
- 「最初にすること」が、知らせを受けた人に分かる言葉で書かれているか
- 通知先が、夜間・休日も含めて決まっているか
- 知らせる条件が、業務への影響とつながっているか（小さな揺れで鳴りすぎないか）
- 監視の仕組みそのものが止まったときに気づけるか
- テストで実際に鳴ることを確かめたか
書き方
- 業務にとって大事な処理・連携から、何が起きたら困るかを洗い出す
- 困ることの前ぶれとして見る値や状態を決める
- 知らせる条件と重大度を決める
- 通知先と、最初にすることを決める
- テスト・リハーサルで実際に鳴らして確かめる
- 稼働後、鳴りすぎ・鳴らなさすぎを見て直す
何を書いてはいけないか
- 通知先が「全員」（誰も動かなくなる）
- 最初にすることが空欄
- 確かめていないのに「監視あり」とすること
どこを見るか
- 業務にとって大事な処理・連携が対象に入っているか
- 知らせる条件と重大度
- 通知先（夜間・休日）
- 最初にすることと手順書への参照
- 鳴ることを確かめた記録
赤信号
- アラートが毎日たくさん鳴り、誰も見ていない
- 連携の監視が一行もない
- 通知先に、すでにいない人の名前がある
- 監視の仕組みそのものの停止に気づけない
よくある失敗
- システムの部品の状態だけを見て、業務の処理が終わったかを見ていない
- 知らせる条件を厳しくしすぎて鳴りすぎ、本当に大事な知らせが埋もれる
- 監視を作ったが、鳴ったときに誰が何をするかを決めていない
関係するUnit・成果物・危機演習
- Unit：14-01 稼働直後の集中対応期間、13-02 障害の重大度を判断する、08-04 誰が何をしたか残す、13-01 本番障害が起きたら最初に何をするか
- 成果物：OPS-004 障害対応計画、OPS-005 障害報告書、ARC-004 システム連携一覧
- 危機演習：この成果物を直接の題材にする危機演習はありません
AI WORKFLOW
AIは、一覧の抜けを探す下書きに役立ちます。
「このシステム連携一覧と監視・アラート一覧を比べ、①監視の対象になっていない連携、②通知先または最初にすることが空欄の行、③テストで鳴ることを確かめた記録がない行、を挙げてください。知らせる条件の値は決めないでください。」
REVIEW
- AIが挙げた抜けを、人が元の一覧で確かめたか
- AIが知らせる条件の値や通知先を推測で埋めていないか
- 抜けを埋める担当と期限を、人が決めたか
人間が判断すること
- 何を監視し、どの条件で知らせるか
- 通知先と、夜間・休日の体制
- 鳴りすぎ・鳴らなさすぎのときに、条件を変えるか
いつ使うか
この教材では STAGE 14｜稼働した後が本当のスタート の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。
最後の問い
この一覧のアラートが夜中に鳴ったとき、受け取った人は「何が起きている可能性があり、誰が、何をすればよいか」が分かりますか？