2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

インシデントって結局なに?〜ITIL4から学ぶインシデント管理・問題管理〜2/2

Posted at

はじめに

当初は記事を分けるつもりではなかったのですが、
思ったより長くなってしまったので1/2、2/2とさせていただきました。
前回の記事は↓です!

①モニタリングおよびイベント管理
②インシデント管理
③問題管理

の②インシデント管理の続きからスタートです!

②インシデント管理

前回の記事ではインシデントは
①サービスデスク経由でユーザーから直接伝達された現象
②モニタリングおよびイベント管理プラクティスからのエスカレーション
③技術スタッフによる記録

の3つに分けて記録されること、そしてインシデント管理では
可能な限り迅速に運用を回復させることを第一に考えることを学びました。

ではインシデントはどのように対応順位がつけられていくのでしょうか

ここでインパクトと緊急度という考え方が出てきます。
この2つの指標を持って優先度が確定していきます。

インパクトとは?

インシデント、問題、変更によるビジネスへの影響です。
一般には下記の項目を考慮し確定して大きさを確定していきます。

・生命や健康に関わるリスク
・影響を受けるサービスの数
・財政上の損失
・事業の評判への影響
・規制上、法律上の違反

例えば、影響を受けるユーザーが1人であっても、ビジネスに多大な損失がある場合は
インパクトは大きくなる場合もあるといったイメージです。

緊急度とは?

ではもう1つの指標、緊急度についてです。ITILでは下記のように定義されています。

インシデント、問題、変更が事業に顕著なインパクトを与えるまでに残された時間の指標

要するに 「事業にとってどれだけ早く解決する必要があるか」 ですね。

上記のインパクト、緊急度をもとにインシデントの優先度が確定されていきます。

例えばインパクトが大きいインシデントだったとしても、
5年先までに解決しないといけない(=5年間は影響がない)といった場合は
緊急度が低く、結果インシデントの優先度が低くなったりします。
この2つの指標をもってインシデントの優先度は確定されていきます。

問題管理

①モニタリングおよびイベント管理
②インシデント管理
③問題管理

の③問題管理まできました。(思ったより長かった、、)

問題管理とは?

ITILでは下記のように定義されています。

インシデントの実際の原因と潜在的な原因を特定し、ワークアラウンドと既知のエラーを管理する。ワークアラウンドと既知のエラーを管理することでインシデントの発生する可能性とインパクトを抑える。

インシデント管理では運用を回復させることが第一だったかと思います。
なのでインシデントの発生を減らすなどはインシデント管理の役割ではないということです。

逆に(?)問題管理では実際の原因、潜在的な原因まで特定をしていきます。
そしてインシデントの発生する可能性を減らしたり、発生した場合のインパクトを抑えていきます。

そもそもになりますが、ここでいう問題とは何なのか
こちらもITIL内で下記のように定義されています。

1つまたは複数のインシデントの原因、または潜在的な原因のこと

この問題に対して「既知のエラー」なのかどうかをまず特定します。

既知のエラーとは

分析済だが、未解決の問題のこと

該当箇所はわかっているけど、修正には時間がかかりそうなケースなどが該当します。
問題管理の1つのステータスのようなイメージです。
こういった場合には既知のエラーとして文書化しておくことが重要です。

インシデントが発生する度に問題管理で原因を特定して、
これ、前にも調べたやつだ、、となるのを防ぐためですね

前回の記事のはじめにで記載をした
「これ前にもあった気がする、、」「これって〇〇さんじゃないとわからないかも、、」 は
文書化することで防いでいくということですね。

ここの文書化に関連してナレッジ管理というものが出てきます。

ナレッジ管理とは?

組織全体の情報とナレッジの利用の有効性、効率性、利便性を維持し、改善すること。

知識の再発掘を減らし、適切な人材が適切なタイミングで適切な知識を保持できるような仕組みです。
ナレッジ管理については、これまた長くなってしまうので一旦ここまでとします。

ワークアラウンドとは?

問題管理の定義で出てきたワークアラウンドについてです。

完全な解決策がないインシデントまたは問題のインパクトを軽減または排除するソリューションのこと

要するに「問題に対する回避策」というイメージです。

先程の「既知のエラー」の例で解決までに時間がかかりそう、、といった場合に
ワークアラウンドもあわせて文書に残しておくことで、インシデントのインパクトを軽減することができます。

おわりに

自分のアウトプットとしてつらつら理解したままに書いてみました。
インシデント管理、問題管理に限らずですが、ナレッジ管理は肝になってくるような気がします。
ITILにはベストプラクティスがぎゅっとつまっているので
実務でも活かせるよう落とし込みしていけたらと思います!

参考

今回はこちらの本をもとに書かせていただきました、ありがとうございました!

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?