何でも書き込もう

ITIL連載講座－4－インシデント管理のライフサイクルとKPI

今回は「インシデント管理」を扱う。簡単に言えば社内のトラブル対応をまとめたものなのだが、ここにもITILならではの考え方がある。「インシデント／問題／既知のエラー」を理解する　この3つの用語と考え方を理解することが、ITILのインシデント管理を理解する上での基本となる。筆者は、ITIL最大の発明とも言われている「インシデント」という概念だけは、ITILを導入する予定のない企業でも、ぜひ導入してほしいと考えている。　筆者は今まで、あえて「トラブル」という言葉を使ってきた。しかしITILにおいては「サービスの標準の運用に属さないイベントであり、サービス品質を阻害、あるいは低下させる、もしくはさせるかもしれないイベント」のことを「インシデント」という。インシデントという言葉そのものは珍しい用語ではない。もともとは「出来事、事件」といった意味の英単語だし、ITの世界でも（ITILでなくても）使用上、あるいは運用上の困った出来事を、インシデントと呼ぶことが多い。　しかしここで注意したいのは、ITILではインシデントのことを「標準の運用に属さないイベント」であると定義していることである。ここには、通常の業務を遂行できない何らかの状態すべてが含まれる。ネットワークがつながらない、アプリケーションが起動しない、プリンタが動作しない、ウイルスに感染した、といった「障害」と、パスワードを忘れた、アプリケーションの操作方法が分からない、ウイルス対策ソフトのパターンファイルが正しく更新されているかどうか知りたい、といった「サービス要求」が含まれる。　インシデントはあくまでもイベント（状態）であり、そのインシデントを引き起こす結果となった根本原因を含まない。IITLでは、インシデントを引き起こした原因のことを「問題」と呼んで、インシデントと区別している。さらに「インシデントを発生させる可能性のある未知の原因」のことを「問題」と呼び、原因が特定されたものを「既知のエラー」と呼んで区別している。　たとえ話で説明しよう。筆者は旅行に出かけるときも、デジカメではなく、ひと昔前の銀塩カメラを持ち歩いている（写真1）。筆者が持っているようなカメラではあり得ないことだが、コンパクトカメラであれば、レンズキャップをしたままカメラのシャッターを押してしまって、現像してみたら写真が真っ黒、ということがよくあった。写真1：筆者の愛機。レンズキャップつき。なかなかの年代ものだ　この場合「写真が写っていなかった」というイベント（状態）が「インシデント」である。そしてその原因は「レンズキャップをしたままシャッターを押してしまった」ということにある。しかし写真を撮る時にレンズキャップをはめたままシャッターを押したということには気付いていないため「なぜ、写真が真っ黒なんだろう？」と悩んでいるうちは、その根本原因は未知であり「問題」であるといえる。ある日「なぁんだ、レンズキャップをはめたままだったんだ」と気付けば、その原因は「既知のエラー」と呼ばれることになる。　ITIL最大の発明とは、この「インシデント」と「問題」を完全に分離したことにある。詳細は後で述べるが、インシデント管理では、そのインシデントが発生した原因を追究しない、ということに大きな特徴があるのだ。インシデント管理プロセスの役割　インシデント管理の目的は、インシデントによって中断されたITサービスを一刻も早く復旧させて、ビジネスの負のインパクトを最小限にすることにある。　インシデントの受け付け窓口は、SPOC（Single Point Of Contact）であるサービスデスクが担う。ここに、あらゆるインシデントコールが集まることになる。前述の通りインシデントは「障害」と「サービス要求」に分けられるが、受け付ける際にはこれらを区別しない。ITサービスの利用が止まってしまうイベントは、たとえ「パスワードを忘れた」というようなものも、インシデントである。　インシデント管理を行う目的は「一刻も早くITサービスを復旧させる」点にある。そのためには、各インシデントの対応がどの程度急を要するものなのか、という見極めが必要である。プリンタから紙が出力されない、というインシデントであれば、ビジネスに対するインパクトは低いかもしれないが、その紙（提案書かもしれない）を持って今すぐにでも客先に行かなければならない営業マンにとっては、非常に緊急度の高いものである。また、ネットワークがつながらないというインシデントはインパクトは高いが、もし電話やほかのコミュニケーション手段でその場をしのげるのであれば、緊急度は低いだろう。　図2は、ITILの参考書でもよく見られる、ビジネスに対するインパクトと緊急度から優先度を割り出すマトリクスである。さまざまなインシデントに「ビジネスに対するインパクト」と「緊急度」を割り当て、それぞれの優先度を決めておけば良い。さらにその優先度に対して目標解決時間を定めておくことも重要である。図2：優先度と目標解決時間の例インシデント管理のライフサイクルインシデント管理の具体的な活動は、図3の通りである。図3：インシデントのライフサイクル1．検知と記録　サービスデスクが受け付けたインシデントはすべて記録する。これは同様のインシデントが発生した場合にすぐに対応できるようにするためと、インシデントのトレンド（傾向）を分析するために意味がある。インシデントを記録するために、検索性の高い専用のツールを導入することが望ましい。2．分類と初期サポート　記録されたインシデント情報から、そのインシデントのビジネスへのインパクトと緊急度を分類する。この分類のためには、正確なCMDBが必要不可欠である。もしCMDBが整備されていなかったり、現状を正確に把握できていなかったりすると、正しい分類が行われないばかりか、インシデントを適切に解決できなくなる恐れもある。3．調査と診断　インシデントが障害かサービス要求かを見極める。軽微な問い合わせであればサービス要求とみなし、あらかじめ取り決めておいたサービス要求手順を実行する。障害であればさらに詳細な情報を得るために調査を施し、適切な解決策を試みる。既知の解決策のことを「ワークアラウンド」という。インシデント管理が成熟していくと、さまざまなインシデントに対するワークアラウンドがたまっていくことになる。4．解決と復旧　インシデントに対してワークアラウンドを施して、障害を取り除く。しつこいようだが、ここでは原因の特定はしない。例えばアプリケーションが頻繁にフリーズするようなインシデントでも、いったんパソコンを再起動すれば取りあえず使えるのであれば、それがワークアラウンドとなる。5．インシデントのクローズ　ITサービスが正常に使えるようになったことを確認して、インシデントをクローズする。インシデントをクローズしたということも、正確に記録されなければならない。インシデント管理のKPIインシデント管理が効率的に運用されているかどうかを評価するためのKPI（重要業績評価指標）には、次のようなものが考えられる。　　　単位期間当たりのインシデントの総数 　　　インシデント解決にかかった平均時間 　　　目標解決時間内に解決できたインシデントの割合 　　　確立されたワークアラウンドの数 　　　2次サポートに問い合わせずに解決できたインシデントの割合 　インシデント管理の成熟は、とりもなおさずサービスデスクの成熟につながる。また、正確なCMDBが存在しなければ、インシデント管理は成功しない。さまざまな管理プロセスは、それぞれが密接かかわっているのである。＝＝＝＝＝＝＝＝＝＝＝＝＝＝関連リンク：ITILとは（itSMF Japanオフィシャルサイト） ITIL連載講座－1－ITILの成り立ちと現状を知る ITIL連載講座－2－「サービスデスク」導入は即効性アリ！？ ITIL連載講座－3－「構成管理」への理解を深める 出所