[記事公開日]2016/11/16
[最終更新日]2016/12/06

ITIL ファンデーション試験(サービス・オペレーション1)

●サービス・オペレーション

 

イベント
重要性のある状態の変更のこと
(正常の場合も、異常の場合もイベントである)

 

 

イベント管理
⇒サーバやアプリから通知(イベント)を受け、
異常時にはインシデント管理にエスカレーションする。

 

インシデント管理
迅速に復旧させる
(原因は突き止めない)
⇒繰り返し問題が起きたら「問題管理」へ渡す

 

問題管理
原因を特定する。

予防や次回発生時の迅速な対応に使う。

そのため、既知エラーの作成、ワークアラウンドの提供を行う。

 

A.変更が必要 ⇒「変更管理」へ変更要求(RFC)をする
B.変更が不要 ⇒ コスト面から”不要”と判断することがある。

それでも「インシデント管理」へ回避策を提供する。

 

ユーザ「サービス要求」→プロバイダ「要求実現」 

 

要求実現

リスク、コストが低い要望に対して応えること。

(PCの設置、トナーの交換など)

 

アクセス管理
ユーザに使用権を付与

 

★全体の流れ
PCを使用中

イベントが多々発生する

(イベント管理として、良いイベントも悪いイベントも把握しておく)

PCにエラーメッセージがでた!!

インシデント管理として扱う


インシデント管理では、直ぐに回避策を見つけ、ユーザに答えていた。

だが、他のユーザからも多々問い合わせが入ってきた。

インシデント管理は、問題管理へその旨を報告した。

問題管理では、原因を特定した。

問題がある、または変更が必要であると判断し、

変更管理へ渡すことにした。

※このとき変更の必要がなければ、

”回避策(対応案)”をインシデント管理に提供して終了となる。

変更管理で、変更のための計画を練った!!

※変更管理では、実際に変更は行わないので注意。

(終わり)

 

イベントの種類
情報のイベント:何もしない
警告のイベント:エスカするなど注意を払っておくだけ
例外のイベント:インシデント管理にエスカ

※「警告」と「例外」の混合に注意!!

 

イベント発生時の対応
自動応答:PCの再起動、スイッチの入り切りなど。
アラート:人の介入を要する(=人に対して発せられる)

エスカレーション

 

インシデント管理
⇒サービスを中断させる、またはその可能性がある事象に対応すること。

 

インシデントの経由例
・顧客→サービスデスク→インシデント管理へ
・イベント管理から
・自社(他社)の技術スタッフから

 

インシデント・モデル
⇒処理手順を定義しておく

 

問題管理 ⇒原因を追究する

インシデント管理⇒原因を追求しない