はじめに

障害対応や不具合調査をしていく中で、
「これ前にもあった気がする、、」「これって〇〇さんじゃないとわからないかも、、」 といったことありません、、？ありますよねあります。
それはインシデント管理が適切にできていないのではということで、まずインシデント管理とはなんぞやということで今回ITIL4を学び始めることにしました。
ITILとはなんぞや？は今回は大きく取り扱わないため、
気になる方は「ITILファンデーション」など調べてみていただければと思います。

ITIL4におけるサービスマネジメントプラクティス

ITIL4では管理プラクティスとして「一般的マネジメントプラクティス」「サービスマネジメントプラクティス」「技術的マネジメントプラクティス」の3つに大きく分けられます。
詳細は省略しますが、それぞれベストプラクティスがぎゅっとまとめられている ようなものです。

そのうちの「サービスマネジメントプラクティス」はインシデント、問題管理、サービスデスクなど、システム運用に大きく関わる部分が記載されています。

サービスマネジメントプラクティスとは下記の7つで構成されています。

①モニタリングおよびイベント管理
②インシデント管理
③問題管理
④サービス要求管理
⑤変更実現
⑥リリース管理
⑦サービス構成管理
⑧IT資産管理
⑨サービスデスク
⑩サービスレベル管理

今回はこの中でも

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

について取り上げたいと思います。

①モニタリングおよびイベント管理

ITILにおけるモニタリングおよびイベント管理は下記のように記載されています。

サービスの提供に必要なサーバ、アプリケーションなどから通知されるすべてのイベントを監視し、異常状態を通知するイベントが発生した場合にはイベント管理プラクティスにエスカレーションするなど、適切な対応を行います。

この中で

　すべてのイベントを監視し

個人的にはここがミソだと思いました。
インシデントに繋がるから監視、記録するのではないとうことですね。

上記を踏まえた上で①モニタリングおよびイベント管理では下記の3つのイベントに分類されます。

①情報

どのような対処も必要とされないイベント が該当します。
例えば

・バッチ処理が正常に終了した
・ユーザーAがアプリケーションに正常にログインした

など、その場で何か対処が必要ではないですが、記録しておくことで分析すると何か改善が見えるかもしれません。

②警告

あるしきい値に達したときに生成されるイベントです。
例えば

・メモリの使用量が80%を超えるとレスポンスが遅くなる場合に、メモリ使用量が70%を超えていて
今も上昇し続けている
・正常状態と比較して、バッチ処理完了までの時間が15%も長くなっている

など、このまま放っておくと危ないよ〜というイベントが該当します。
警告イベントはインシデント管理プラクティスや変更実現プラクティスにエスカレーションしたりする場合があります。放っておいたらまずいから今のうちに改善しようといったイメージです。

③例外

いわゆる障害やインシデントというときにはこちらを指すケースが多い印象です。

・サーバーがダウンした
・ネットワークの応答に20秒以上かかっており、許容できる範囲を超えている

正常に運用できていない場合に生成されるイベントです。
ここの「正常」というのはサービス提供者と顧客で合意している基準（SLAといったりします）を満たしているかどうかということになります。

②インシデント管理

やっとタイトル回収。ここまでも長かったですね、、

ここでいうインシデントとは
「サービスを中断させる、または中断させる可能性があるすべての事象」 が対象です。

そしてインシデント管理では
可能な限り迅速に運用を回復させることを第一に考えます。
逆に言うとこのインシデント管理では問題の根本原因の調査や解決などは実施しないです。
それは後ほど説明させていただく③問題管理の役割です。

インシデントは下記3つを経由して記録されます。

①サービスデスク経由でユーザーから直接伝達された現象

システムを使われているユーザーから「アクセスできない」「レスポンスが遅くなった」など
いわゆる問い合わせをいただくことで記録されます。

ここは個人的には１番避けたいですね、、ユーザーから問い合わせをもらう前に検知したいものです。

②モニタリングおよびイベント管理プラクティスからのエスカレーション

先程説明させていただいた①モニタリングおよびイベント管理で、警告イベントや例外イベントなど
エスカレーションされたものがこちらに該当します。

③技術スタッフによる記録

技術スタッフがハードウェアやネットワークの不具合に気づいたケースなどが該当します。
例えば深夜帯に技術スタッフが気づき、ユーザーが気づいていない場合もインシデントとして扱います。

そしてインシデント管理では
可能な限り迅速に運用を回復させることを第一に考えます。

と記載させていただいた通り、
①②③を経由して登録されたインシデントをできるだけ早く正常に運用できるよう回復させるのが
インシデント管理の役割です。

様々インシデントが記録されていく中でどのように優先順位をつけるのでしょうか。
一旦正常に運用できるよう回復したとして、根本解決はどうするのでしょうか。

、、、思ったより長くなってしまったため、こちらは次回に持ち越したいと思います！

終わりに

そもそもインシデントとはなんぞや、という部分は
今回を通して少しは理解が深まったような気がします。
実際にこの通りに運用とはなかなかいかないかもしれないですが、そもそもや
ベストプラクティスを知っておくのは大事だなと。
次回はインシデント管理→問題管理まで書きたいと思います！

参考

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