サービスマネジメントの中でも特に試験で問われやすいのが、インシデント管理・問題管理・変更管理の3つです。名前が似ていて混同しやすいのですが、「何を目的にしているか」で整理すると一気にスッキリします。応急処置・原因究明・安全な改修、という流れで一緒に見ていきましょう。
せんせー、インシデントと問題って、どっちも『なんか起きてる』感じじゃん? 違いがマジでわかんないんだよね。
ふふ、そこでつまずく人は多いのよ。
まずインシデントは、いま実際に困っている『できごと』のこと。
サーバが落ちた、ログインできない、印刷が遅い…そういう目の前の不具合ね。
じゃあ『問題』のほうは何が違うんですかぁ?
問題は、そのインシデントを引き起こしている『根っこの原因』のことよ。
表に出ているできごとがインシデント、その裏に隠れている原因が問題、と覚えるといいわ。
補足すると、対応のゴールが正反対なんです。
インシデント管理のゴールは、原因がわからなくてもとにかく早くサービスを復旧させること。
問題管理のゴールは、時間をかけてでも原因を突き止め、二度と起きないようにすることです。
あぁ…熱が出たときに、とりあえず解熱剤で下げるのがインシデント管理で、なんで熱が出たのか検査して治すのが問題管理、みたいな感じですぅ?
おっ、ほのかちゃん今日キレてるじゃん! 応急処置と根本治療ね、それなら覚えられそう。
まさにその通りよ。
だから評価する指標も別物なの。
インシデント管理はスピード重視。
代表的な指標がMTTRです。
これが短いほど復旧が速い。
あわせてMTBFも押さえておくと安心です。
MTTRは『短いほど良い』、MTBFは『長いほど良い』と覚えてください。
Repairは修理だから短いほどいい、Betweenは故障と故障の間だから長いほどいい、ってことか。
逆にしたら間違えるやつだ。
よく整理できたわね。
さらにインシデント対応では、根本原因がわからなくても使える回避策を用意することがあるの。
原因はあとで問題管理に引き継ぐのよ。
問題管理の核心は根本原因分析です。
原因を特定したものの恒久対策がまだの状態を既知の誤りと呼びます。
これも試験で問われます。
原因がわかった『だけ』では、まだ終わってないんですねぇ。
そう、ちゃんと直して再発を止めるところまでが問題管理。
そして、その『直す』作業を勝手にやらないための仕組みが、3つめの変更管理なのよ。
勝手に直しちゃダメなの? 早く直したほうがよくない?
気持ちはわかりますが、無計画な変更は新しい障害の最大の原因なんです。
だから変更管理で、影響範囲やリスクを審査してから実施します。
審査をするのが変更諮問委員会ね。
リスクの大きい変更はここで承認を得てから進めるの。
でも、毎回みんなで会議してたら、急ぎのときに間に合わないんじゃ…?
いい着眼点です。
だから変更は3タイプに分けて手続きを変えます。
標準変更・通常変更・緊急変更の3つです。
標準変更は『いつものやつ』だから許可いらない、通常変更はちゃんと会議、緊急変更は非常事態だから特急で承認、って感じか。
マジでわかりやすい。
その理解で完璧よ。
承認された変更を実際に本番へ届けるのがリリース管理。
一気に全部入れ替えず、影響を抑える工夫があるの。
カナリアって聞いたことある! あの炭鉱のカナリアと関係あるの?
あります。
カナリアリリースは、まさに毒ガスをいち早く察知する炭鉱のカナリアが由来です。
少数で試して安全を確かめてから全展開するんです。
もう一つ、ブルーグリーンデプロイメントもあるわ。
問題が出たらすぐ旧環境へ戻せるのが利点ね。
切り戻しが速いと安心ですぅ。
ところで、どのサーバがどのバージョンか、誰が管理してるんですかぁ?
ふふ、最後のピースね。
それを担うのが構成管理よ。
管理対象の一つ一つをCIと呼び、それらの情報をCMDBに集約します。
変更の影響範囲を調べるときの土台になります。
なるほど、構成管理で『地図』を持ってるから、変更管理で『どこに影響するか』が読めるんだね。
全部つながってるじゃん!
いい締めくくりだわ。
整理すると、インシデント管理で素早く止血し、問題管理で原因を断ち、変更管理とリリース管理で安全に直し、構成管理がその全部を下から支える。
この役割分担で覚えれば、試験で名前が入れ替わっても迷わないわよ。
確認クイズ
ITILにおいて、インシデントの根本原因を特定し、再発防止を図ることを目的とするプロセスはどれか。
- インシデント管理
- 問題管理
- 変更管理
- リリース管理
こたえを見る
正解: 2. 問題管理
問題管理は、インシデントを引き起こしている根本原因を究明し、恒久対策によって再発を防ぐプロセスです。インシデント管理は原因が不明でもとにかく早くサービスを復旧させることが目的で、再発防止までは担いません。変更管理は本番環境への変更を安全に承認・実施する仕組み、リリース管理は承認済みの変更を本番へ展開する活動であり、いずれも根本原因の特定そのものを目的とはしていません。