ITIL 4を活用した『監視設計』入門— モニタリング計画
はじめに：なぜ「モニタリング計画」が必要なの？
前回の記事「ITIL 4を活用した『監視設計』入門 - 概念と用語」では、ITIL 4における「監視（モニタリング）」の基本的な用語や考え方を紹介しました。
今回はその続きとして、「モニタリング計画（Monitoring Planning）」にスポットを当てて、「どうやって監視を始めればいいのか？」を初心者の方でもわかりやすくご紹介します。
「監視ってツールを入れればいいんでしょ？」と思われがちですが、本当に大事なのは“どんな目的で、何を、どう監視するか”を最初にきちんと考えることなんです。
モニタリング計画ってなに？
ITIL 4では、モニタリング計画を次のように定義しています：
サービスを構成する機器やアプリケーションなどの状態を観察・分析し、必要な対応をとるための準備をすること
つまり、監視を行う前に、「どこをどう見張るか」「何が起きたらどう反応するか」をあらかじめ整理しておくのがモニタリング計画の役割です。
モニタリング計画でやること（ざっくり）
- どこを監視する？（対象の特定）
- 何のために監視する？（目的の明確化）
- どんなサインをキャッチする？（イベントの定義）
- 何を使って監視する？（ツールや手法の選定）
- キャッチしたらどう動く？（対応方法の決定）
この流れを整理するのが「モニタリング計画」です。
モニタリング計画の中身をもう少し詳しく
モニタリング計画プロセスの概要
これは、監視を行うための“設計図”づくりのようなものです。計画を立てることで、後々の監視や障害対応がスムーズになります。ここでは、モニタリング計画を進めていくうえで「どんな順番で、何を考えていけばいいのか？」を、初心者の方にもわかりやすく説明していきます。むずかしく考えすぎず、ひとつずつ整理していきましょう。
入力（インプット）になる情報
- システムやサービスの設計資料
- 監視してほしい対象（サーバーやアプリなど）
- 契約やルール（SLAやコンプライアンス）
- 過去のトラブル事例やログ
出力（アウトプット）としてできるもの
- モニタリング方針（何を見るか、どれくらいの頻度で見るか）
- イベントの分類（警告、例外など）
- 使用するツールの選定
- アラートが出たときの対応ルール
- 関係者向けの運用ガイド
ステップごとに見てみよう
ここでは、ITIL 4プラクティスで紹介されているモニタリング計画プロセスの考え方を元に、各ステップで「何を」「どのように」進めていけばよいか、実際の例を交えながら紹介します
監視する対象を決める
まずは「どこを見張るか？」を決めましょう。対象にはサーバーやネットワーク機器、クラウド上のアプリケーション、さらにはユーザーの操作ログやトランザクションまで含まれます。
例：ECサイトであれば、注文処理API、DB接続数、決済サービス連携など
監視する目的を考える
なぜ監視したいのか？という問いに答えましょう。障害の早期発見、パフォーマンス維持、セキュリティ確保、コンプライアンス対応など、目的によって監視内容が変わります。
例：法律や社内ルールに合わせてログをちゃんと残したい、といった目的もあります。
どんなサインに注目する？（イベントとしきい値）
トラブルのサインをどう見分けるかを決めるステップです。ITILでは4つのタイプ（情報／指示／警告／異常）に分けて考えます。
- 情報（Informational）
- 指示（Instructional）
- 警告（Warning）
- 異常（Exception）
また、アラートを出す基準（しきい値）も設定しましょう。
例：CPU使用率が80%を超えたら「警告」、95%以上が10分以上続いたら「異常」など
どうやって見張るの？（アクティブ or パッシブ）
ステップ4：アクティブ監視とパッシブ監視を選ぶ
- アクティブ監視：こちらから定期的に様子を見に行く（例：1分ごとに応答時間をチェック）
- パッシブ監視：相手から「こうなったよ」と知らせてくれる（例：ログの通知やシステムイベント
どちらかに決める必要はなく、組み合わせることで効果的になります。
アラートが出たときの流れを考える
通知の出し方、誰が見るか、どう対応するかも決めておくと安心です。
例：重要なサインが出たら、夜間でも担当者に通知して自動的に対応チケットを発行するなど
定期的に見直す
一度決めた計画でも、実際に使ってみると「うまくいかない」「アラートが多すぎる」なんてこともあります。そういうときは見直して、もっと良くしていきましょう。
例：うるさいアラートは条件を調整して静かに、逆に気づきにくい問題はアラートを追加するなど
最近よく聞く「Observability（可観測性）」との関係
Observability（オブザーバビリティ／可観測性）とは、「中の仕組みが見えないシステムでも、今なにが起きているのかを外から推測できる力」のことです。具体的には、メトリクス（数値）・ログ（記録）・トレース（処理の流れ）という3つの情報を使って、トラブルの早期発見や原因の特定がしやすくなります。今回はくわしい説明は省きますが、特に次の3つが重要とされています。Observabilityについては別の機会に解説したいと思います。
- メトリクス（数値的なデータ）
- ログ（記録）
- トレース（処理の流れ）
モニタリング計画でも、これらを意識することで「気づく→原因を探す→直す」までの流れがスムーズになります。
おわりに：モニタリング計画は“備えあれば憂いなし”
モニタリング計画は、「準備しておくこと」が目的です。何か起きてから慌てるのではなく、“普段から見ておく・気づける・動ける”ための土台になります。
次回は、ITILの考え方だけではイメージしにくいという声も多いので、具体的事例もしくは、フレームワークを使用し、考えていきたいと思いますのでよろしくお願いいたします。
内容に関するご意見、ご感想などございましたら、x でお待ちしております。
