このユニットの結論
「サーバーが動いている」ことは、「業務が回っている」ことの証拠ではありません。
システムが生きているか・速さ・誤り・量・業務の結果の5つの観点で見て、普段の値と比べ、おかしいと気づいたら誰が何をするかまで決めておくことで、利用者から連絡が来る前に異常に気づけるようにします。
1. 何の話か
朝、運用の担当者が監視の画面を開くと、すべての項目が「正常」を示しています。ところが昼前、利用部門から「昨日の分の処理結果が、いつもより少ない気がする」と連絡がありました。
監視は「正常」と言っていたのに、業務の側では困っていた。このずれは、何を見ていたかの問題です。
このユニットは、稼働したシステムが正常に動いているかを確かめる監視の観点の話です。監視とは、システムの状態を、仕組みを使って見続けることです。
2. なぜ必要か
見るものを決めずに監視を始めると、
- 部品の状態だけを見ていて、業務の処理が終わっていないことに気づけない
- 利用者からの連絡で初めて異常を知り、対応が遅れる
- 見る項目が多すぎて知らせが鳴りすぎ、本当に大事な知らせが埋もれる
- 知らせを受けても、誰が何をすればよいか分からない
ということが起きます。
3. このユニットで分かること
- 監視の5つの観点
- 「普段の値」を知っておく理由
- 見たあとに、誰が何をするかの決め方
4. 監視の5つの観点
一般的には、次の5つの観点で「何を見るか」を考えます。
| 観点 | 何を見るか | 例（教材上の例） |
|---|---|---|
| 生きているか | システムや処理が動いているか、応答があるか | 外から試しに操作して、答えが返るか |
| 速さ | 処理や応答にかかる時間 | 夜間処理の終わった時刻 |
| 誤り | うまくいかなかった処理の数や割合 | 連携で相手に届かなかった件数 |
| 量 | 処理の件数、たまっている件数、使っている資源 | 送り待ちの件数、記憶領域の使っている割合 |
| 業務の結果 | 業務として期待した結果になっているか | 日次の取り込み処理の件数が、普段と同じくらいか |
最初の4つは、システムの側から見る観点です。5つ目の「業務の結果」は、業務の側から見る観点で、見落とされやすいものです。処理が「正常に終わった」と表示されても、処理した件数が普段より極端に少なければ、業務としては正常とは言えません。
また、監視の仕組みそのものが止まると、すべてが「正常」に見えてしまいます。監視の仕組みが動いているかも、見る対象に入れます。
5. 普段の値を知っておく
「おかしい」と気づくには、「普段はどうか」を知っている必要があります。
- 曜日や時間帯ごとの処理の件数、終わる時刻
- 普段どのくらいの誤りが出ているか（誤りがゼロとは限りません）
- 資源の使い方が、時間とともにどう増えているか
稼働直後は、まだ普段の値が分かりません。稼働直後の集中対応の期間（14-01）に記録を取りながら、知らせる条件を少しずつ合わせていきます。
6. 見たあとに何をするか
見るだけでは、異常は止まりません。知らせを受けた人がすることを、事前に決めておきます。
- 知らせる条件と通知先：どうなったら、誰に知らせるか（OPS-002 監視・アラート一覧）
- 最初にすること：知らせを受けた人が最初に確かめること・行うこと（OPS-003 運用手順書）
- 毎日の確かめ：知らせが鳴らなくても、毎日決まった時刻に見る項目と、その手順
連携の監視は、連携の一覧（ARC-004 システム連携一覧）と突き合わせ、業務にとって大事な連携が監視の対象から漏れていないかを確かめます。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件に関係する記載
- システムに SYS-11 監視・ログ基盤がある
- IF-11 新基幹 → 監視・ログ、IF-12 連携基盤 → 監視・ログ
- Vendor B / クラウドブリッジの担当範囲に監視が含まれる
- P-011 山下 恵 — 本番移行・運用リーダー
- M18 本番稼働、M21 初期安定化完了
正本の連携の一覧で、監視・ログへの経路として書かれているのは IF-11・IF-12 です。ほかのシステムをどう監視するか、何を見て、どの条件で誰に知らせるかは、正本に記載がありません。未確定
7. THINK — 「正常終了」と表示されている
（教材上の例）ある日次の取り込み処理が、監視の画面では「正常終了」になっています。ただ、処理した件数を見ると、普段の1割ほどしかありません。当番の担当者は次のように言っています。
「エラーは出ていないし、正常終了しているので、問題ありません。」
問題
この判断でよいでしょうか。
判断例を開く
判断
まだ「正常」とは言えません。「誤り」の観点では問題がなくても、「量」と「業務の結果」の観点で普段と違います。
確認すること:
- その日に件数が少ない業務上の理由（休日、締めの前後など）があるか
- 取り込む元のデータが、そもそも少なかったのか、途中で欠けたのか
- この処理の結果を、誰が、いつ使うか
- 件数が普段と大きく違うときに知らせる監視があるか。なければ足すか
「エラーが出ていない」ことと、「業務として正しい」ことは別です。
8. よくある失敗
- サーバーや部品の状態だけを見て、業務の処理の結果を見ていない
- 知らせる条件を普段の値と合わせず、鳴りすぎるか、まったく鳴らない
- 監視を作ったが、鳴ったときに誰が何をするかを決めていない
- 監視の仕組みそのものが止まったことに気づけない
- 稼働後に、知らせる条件を一度も見直さない
9. 成果物との接続
- OPS-002 監視・アラート一覧：何を見て、どうなったら誰に知らせるか
- OPS-003 運用手順書：知らせを受けた人がすることと、毎日の確かめの手順
- ARC-004 システム連携一覧：監視の対象から漏れている連携がないかを確かめる
- OPS-009 稼働直後支援・運用引継ぎ計画：稼働直後に何を見て、通常の運用へどう引き継ぐか
10. AI WORKFLOW — 見る項目の抜けを探させる
AIは、今ある監視の項目を観点ごとに分け、抜けを探す下書きに役立ちます。
指示例:
「次の監視の項目の一覧を、生きているか・速さ・誤り・量・業務の結果の5つの観点に分けてください。観点ごとに項目がない処理を挙げ、足す候補を示してください。知らせる条件の値と通知先は決めないでください。」
11. REVIEW — AIの分類を確認する
- 分類が正しいか（「処理が終わった」を「業務の結果」と取り違えていないか）
- 足す候補が、業務にとって本当に大事な処理か（業務の担当に確かめたか）
- AIが知らせる条件の値を推測で埋めていないか
12. 人間が判断すること
- 何を監視し、どの条件で、誰に知らせるか
- 「業務の結果」として何を見るか（業務の担当と決める）
- 知らせが鳴りすぎ・鳴らなさすぎのときに、条件を変えるか
13. 判断演習
（教材上の例）あなたは、毎晩動く連携の処理の監視を任されました。
5つの観点（生きているか・速さ・誤り・量・業務の結果）それぞれについて、見るものを1つずつ挙げてください。そのうち、知らせが鳴らなくても毎日確かめたいものはどれですか。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
監視は、生きているか・速さ・誤り・量・業務の結果の5つの観点で見て、普段の値と比べます。
「エラーが出ていない」ことと、「業務が回っている」ことは別です。