3.3イベント管理と要求実現

サービスデスクに届くのは障害の通報だけではありません。監視システムが自動で上げる無数のイベントもあれば、「パスワードを再設定してほしい」といった定型の依頼も混在します。これらをすべてインシデントとして同じ列に並べると、本当に急ぐ障害が埋もれてしまいます。この節では、監視で捉えた事象をしきい値で仕分けるイベント管理と、低リスクの定型依頼を専用フローで捌く要求実現を区別し、どの通報をどのプロセスへ振り分けるかを学びます。

3.3.1イベント管理としきい値

• イベント＝サービスや構成要素の管理にとって意味のある状態変化。イベント管理は監視によってこれらを検知・分類し、必要なら是正処置（インシデントの自動起票など）につなげるプロセス。
• イベントは通常、情報（informational）＝記録目的の正常な通知、警告（warning）＝しきい値に近づいた注意喚起（例：ディスク使用率が80%到達）、例外（exception）＝合意水準を逸脱した異常（例：使用率95%超・サービス応答なし）に分類される。警告の段階で先手を打てば、例外（＝実際の障害）になる前に対処できる。
• しきい値の設計が要点：低すぎれば警告が多発してアラート疲れを招き重要な兆候が埋もれ、高すぎれば例外化（実障害）してから気づくことになる。適切なしきい値でプロアクティブに対処するのが監視の価値。

3.3.2要求実現とサービス要求

• サービス要求＝障害ではなく、利用者からの定型的で低リスクの依頼（パスワードリセット、標準ソフトウェアの導入、アクセス権の付与、備品の手配など）。あらかじめ手順・承認経路・費用が定められた「決まった依頼」である点がインシデントと決定的に異なる。
• 要求実現＝これらのサービス要求を、インシデントとは別の専用フローで受け付け・承認・実行するプロセス。定型で低リスクゆえにセルフサービスポータルやカタログからの自動化に馴染み、標準化することでサービスデスクの負荷を下げつつ迅速に応えられる。

あるサービスマネージャの前に、朝の時点で3件の通報が並んでいるとします。
①監視システムが「本番DBサーバのディスク使用率が80%に到達」という警告イベントを自動で上げている、
②営業部の社員から「パスワードを忘れたので再設定してほしい」という依頼が来ている、
③経理部から「月次締め処理の画面が真っ白で開けない」という通報が来ている。これらを同じ「インシデントの列」に一律で並べるのは誤りです。まず
③は明確なインシデント（サービスの計画外の品質低下）であり、影響度×緊急度で優先度を付けてインシデント管理で回復を図ります。
②は障害ではなく、あらかじめ手順が定まった定型・低リスクのサービス要求なので、インシデントではなく要求実現のフローへ振り分けます——理想的にはセルフサービスポータルで利用者自身が完結できるよう自動化し、サービスデスクの負荷を下げます。
①は現時点では障害ではなくイベント管理が捉えた警告です。使用率80%は合意水準を逸脱した例外ではないため直ちにインシデント化する必要はありませんが、しきい値に近づいた兆候なので、95%（例外＝実障害）に達する前に、不要ログの削除やディスク増設をプロアクティブに手配します。もししきい値を95%に設定していたら、実際に書き込み不能になる寸前まで気づけません。逆にしきい値を50%のような低い値にすると警告が頻発してアラート疲れを招き、本当に危険な兆候が埋もれます。「障害はインシデント管理、定型依頼は要求実現、監視の兆候はイベント管理で警告のうちに先手」と通報を正しく振り分けることが、限られた要員を効率よく使うサービスマネージャの判断です。

3.3.3この節のまとめ

• イベント管理は監視で捉えた事象をしきい値で情報／警告／例外に仕分け、警告段階でプロアクティブに先手を打つ
• サービス要求は障害ではない定型・低リスクの依頼であり、インシデントではなく要求実現の専用フロー（可能なら自動化）で捌く
• 通報は障害＝インシデント管理／定型依頼＝要求実現／監視の兆候＝イベント管理へ正しく振り分け、限られた要員を効率よく使う