システム管理のお仕事(その３)

10/19(日)にAP試験を受けてきました。
情報処理といえば、昔はプログラミング試験に近かったのですが、今の試験は、サポートや経営に近い内容の試験問題が多いですね。
前回記載した、インシデント管理、今回説明する問題管理について、午後試験に出題がありました。
日々、問題意識を持って仕事をするのが大事だとつくづく思いました。

AP試験の問題解答は、以下URLにあります。（問１０が問題管理の問題）
http://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2014h26.html#26aki


●問題管理

１、問題とは？
ITサービスの品質低下をもたらしている状態、または、もたらす可能性のある状態を引き起こしている「根本原因」を問題といいます。

IITL（システムの運用、管理業務に関する体系的なガイドライン）では「インシデントを発生させる可能性のある未知の原因」のことを「問題」といっています。
つまり、問題＝インシデントの根本原因となります。

原因が明らかになり、一時的な回避策、あるいは永続的な解決方法が判明したら、問題は既知のエラーと呼ばれます。

２、問題管理とは？
ITサービスの品質低下をもたらしている、または、品質低下をもたらす可能性のある状態を引き起こしている根本原因 を効果的・効率的に認識し、特定し、速やかな解決に導くためのIT運用管理上の1つのプロセス」といわれています。
（サービスの品質低下の対策をインシデント管理で行い、問題解決を問題管理で行います）

 問題管理を、大きく2つに分けると次のようになります。

1) インシデントの、原因と追究
インシデント管理がビジネス側の業務を復旧させることを最優先に活動しますので、
原因追求を行わず、とにかくビジネスを復旧させます。
その後、問題管理が原因追求を行います。
よって、インシデント管理と問題管理を別プロセスと捉えています。

2) 恒久的な解決策の、立案と実施
問題の根本原因が明らかした後、恒久的な解決策の立案と実施を行います。

日々の業務に埋もれがちな予兆を発見し、大事に至る前に予防措置をとるというプロアクティブな活動も含まれます。
予兆の発見や根本原因の特定には、経験によって養われる直感が威力を発揮しますが、まずは情報が必要になります。
経験済みの障害だけでなく、類似する障害の発生を未然に防ぐことも大事となります。

原因追求には次の４点を視点に行います。
（1）問題の明確化
（2）事実の明細化（整理)
　3W1E（What、Who、Where、Extent）の項目ごとにIS（起きている事実）とISNOT（起きても良さそうなのに起きていない事実）を列挙する。
（3）原因の想定
（4）原因の絞込と裏づけ

３、 ワークフロー
参考URL:
http://www.newton-consulting.co.jp/itilnavi/glossary/problem_m.htm
http://www.manageengine.jp/products/ServiceDesk_Plus/problem-management.html


(1) 問題の識別と記録
　インシデントの発生をもたらした根本原因が不明な場合に、問題として認識されることになります。
  その問題を識別し、問題管理表を作成して、問題レコードとして記録する。
　問題管理表作成時には、問題管理発生元のインシデント番号 も記載します。
　（インデント管理表には、リンクしている問題管理番号を記載します）

　
(２) 優先度の設定、調査と診断
　記録された問題を、緊急度で分類し、優先度を決定する。
　緊急度は、「ビジネスに対するインパクトと緊急度」という観点から行います。

　優先順位にもとづき、より優先度の高い問題から、調査を開始し、根本原因の究明を目指します。

　必要に応じて専門家チームを結成し、問題の根本原因を調査する。
  根本原因が判明した問題は既知のエラーとして、記録します。

(３) エラー制御（対策）・記録
  既知のエラーについて、実質的な解決策を施し、再発防止につなげます。
　必要に応じて専門家チームを結成し、エラーに対する恒久的な解決策を行います。

　根本的な解決に対して、IT構成に何らかの変更が必要だと判断された場合は変更要求書(RFC:Request For Change)を作成します。

　解決策は、問題レコードに詳細に記録します。
　この情報は、将来のインシデントに対するワークアラウンドや、インシデントを回避 するための情報として有意義なものになるかもしれない。
　RFCが作成されている場合、このRFCを次のステップである「変更管理」プロセスに渡します。

(4) クローズ
　変更実装が終ったり、既知のエラーが完全に取り除かれたことを確認したら、問題レコードをクローズする
　（この時点で問題はすでに既知のエラーになっているため、エラーレコードという場合もある）


最後に、問題管理についてテストです。
以下のURLの問題で、問題管理について理解できたか確認してください。
http://www.ap-siken.com/kakomon/22_haru/q54.html