変更要約: 初版
6.1システム監視とジョブ管理
サービスの異常を早期に捉える監視項目（CPU・メモリ・ディスク・応答時間）としきい値/アラートの設計、SLAを守るためのジョブスケジューリング、複数ジョブの前後関係を束ねるジョブネットの依存関係と異常処理（打切り・リラン・スキップ）、そして誤検知を抑える警告/危険の二段しきい値を学びます。
システム運用の起点は「異常をSLA違反になる前に捉えること」です。サービスマネージャには、どの項目をどのしきい値で監視すれば兆候の段階で気付けるかを設計し、夜間バッチのような多数のジョブを依存関係を保ったまま時間内に流し切るスケジュールを組み、途中で異常終了したときにサービスへの影響を最小化する処理（打切り・リラン・スキップ）をあらかじめ決めておく判断が求められます。監視が細か過ぎればアラート洪水で本当の異常が埋もれ、粗過ぎれば手遅れになる——このバランスの設計が実務の核心です。
6.1.1監視項目としきい値・アラート
- 監視項目＝サービスの健全性を表す指標。リソース系（CPU使用率・メモリ・ディスク空き・ネットワーク帯域）と、利用者視点のサービス系（応答時間・トランザクション成功率・エラー率）を区別する。SLAが「応答時間」で結ばれているなら、CPU使用率だけでなく利用者が体感する応答時間そのものを監視しないとSLA違反を直接検知できない。
- しきい値（threshold）＝アラートを発する境界値。単一のしきい値ではなく、警告（warning）と危険（critical）の二段階に分けるのが定石。警告で余裕をもって是正に着手し、危険に達する前にSLA違反を未然に防ぐ。しきい値を厳し過ぎる値に置くと誤検知（false positive）でアラートが多発し、運用者が慣れて本物を見逃す（アラート疲れ）。
6.1.2ジョブスケジューリングとジョブネット
- ジョブスケジューリング＝バッチ処理などのジョブを、実行順序・起動時刻・実行契機（前ジョブの正常終了・特定ファイルの到着など）に従って自動起動する仕組み。夜間のバッチ処理を業務開始までの時間枠（バッチウィンドウ）内に確実に完了させることがSLA順守の前提になる。
- ジョブネット＝複数のジョブを依存関係（前後関係）で結んだ実行単位。ジョブAの正常終了を条件にジョブBを起動する、といった連鎖を定義する。先行ジョブが異常終了した場合に後続をどう扱うか（止めるか、飛ばすか）を定義しておかないと、不完全なデータのまま後続が走り障害が下流へ連鎖する。
- 異常終了時の処理＝(1)打切り（abort）＝後続を止めて運用者に通知し原因調査・手動対応へ回す、(2)リラン（再実行）＝リカバリ後に異常終了したジョブから再開する、(3)スキップ＝影響の小さいジョブを飛ばして重要な後続を先に流す、を状況に応じて使い分ける。リランは中途半端に更新されたデータを二重計上しないよう、リスタート地点の設計（チェックポイント・再実行可能性）が肝心。
「SLAが応答時間なら応答時間そのものを監視」「しきい値は警告/危険の二段で余裕をもって是正」「厳し過ぎるしきい値は誤検知＝アラート疲れを招く」「ジョブネット＝依存関係で結んだ実行単位」「先行ジョブ異常時は打切り/リラン/スキップを影響度で使い分け」が最頻出です。バッチウィンドウ内に完了できるかで判断する視点で問われます。
6.1.3しきい値と異常処理の設計判断
あるサービスマネージャが、オンラインサービスのバックエンドで毎晩走る売上集計バッチのジョブネットを運用しているとします。SLAでは「翌朝8時までに前日の売上レポートが利用可能」と定められ、バッチウィンドウは深夜1時〜7時です。ジョブネットは「A:データ抽出 → B:集計 → C:レポート生成 → D:配信」の順で依存し、Cは容量の逼迫でしばしば遅延します。まず監視設計として、ディスク使用率に警告80%・危険90%の二段しきい値を置き、単一のしきい値で90%到達時に初めて騒ぐのではなく、80%の警告段階で一時ファイルの掃除や増設の是正を余裕をもって始められるようにします——SLAは応答時間ではなく「8時までの完了」なので、あわせて各ジョブの完了予定時刻に対する遅延（予実差）そのものも監視項目に加えます。次に異常処理の設計です。もしB（集計）が途中で異常終了したら、後続のC・Dは不完全な集計を配信してしまうため打切りが正しく、飛ばして(スキップ)先へ進めるのは誤りです。一方、B自体はチェックポイントを設けてリラン可能に作り、リカバリ後に最初からではなく中断点から再開して、限られたバッチウィンドウ内での復旧を狙います。逆に、レポートに含まれる補助的な参考指標を作るだけのジョブE（Dと独立で顧客配信に必須でない）が失敗した場合は、Eをスキップして本体のD配信を8時に間に合わせ、Eは翌営業時間に手動で補完する、という影響度に応じた使い分けをします。このように「SLA目標（8時完了）から逆算し、しきい値は余裕段階で気付ける二段に、異常処理は各ジョブの下流影響で打切り/リラン/スキップを選ぶ」のが運用設計の判断です。
| 異常時の処理 | 内容 | 適する状況 |
|---|---|---|
| 打切り（abort） | 後続を止めて通知・原因調査へ | 後続が不完全データで走ると害がある |
| リラン（再実行） | リカバリ後に中断点から再開 | 必須ジョブ・時間内に復旧したい |
| スキップ | 影響の小さいジョブを飛ばす | 独立・非必須で本体を優先したい |
ひっかけ： 「しきい値は危険の1本だけ置けば十分」は誤りです——危険到達時には既に是正の余裕がなくSLA違反に直結しがちで、警告/危険の二段で早期に着手するのが定石です。「異常終了したら常にスキップして先へ進めればサービスを止めずに済む」も危険な誤解＝集計のような下流に影響する必須ジョブは打切りすべきで、スキップすると不完全データが配信されます。「SLAが応答時間でもCPU使用率さえ監視すればよい」も誤りで、利用者が体感する応答時間そのものを監視しないとSLA違反を直接検知できません。
6.1.4この節のまとめ
- 監視項目はSLAの尺度に合わせる（応答時間SLAなら応答時間そのもの）、しきい値は警告/危険の二段で余裕をもって是正
- 厳し過ぎるしきい値は誤検知でアラート疲れを招く、ジョブネットは依存関係で結んだ実行単位でバッチウィンドウ内完了を狙う
- 先行ジョブ異常時は下流影響で打切り/リラン/スキップを使い分け（下流に影響する必須ジョブは打切り、独立・非必須はスキップ）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. あるサービスのSLAは「応答時間3秒以内」で定義されている。運用チームはCPU使用率のみを監視していたが、CPUに余裕があるのに応答時間が悪化しSLA違反が発生した。監視設計の是正として最も適切なものはどれか。
Q2. 夜間バッチのジョブネット「A:抽出→B:集計→C:レポート生成→D:配信」を運用中、集計ジョブBが途中で異常終了した。SLAは翌朝8時までのレポート提供で、バッチウィンドウにはまだ余裕がある。最も適切な異常処理はどれか。
Q3. ディスク使用率の監視で、危険しきい値90%の1本だけを設定していたところ、90%到達を検知した時点では是正の余裕がなくバッチが溢れてSLA違反になった。しきい値設計の改善として最も適切なものはどれか。