🚗

ITILもとにインシデント対応フロー作成しました

2023/07/09に公開

はじめに

先日社外で初LTをしました
テーマも自由だったので、共通の話題になるものがいいなと思い、
インシデント周りで作成してみたので、今回はその共有です。

昨年末〜今年にかけて、CTOに教えていただきITILを勉強し始めました。
進めていく中で、特にインシデント管理に対して
これはうちのチームでもと入れられるのではと思い、
作成させてくれい！とCTOにお願いし、レビューいただきながら進めることに。

ITIL（Information Technology Infrastructure Library）とは、
ITサービスの運用に関するベストプラクティスがぎゅっと集まったもので、
以下の3つのカテゴリーに分けられます。

更に、サービスマネジメントプラクティスには、以下の10の要素が含まれています。

これらの中から、「モニタリングおよびイベント管理」「インシデント管理」「問題管理」に
焦点を当て、インシデントのフロー作成しました。

主な取り組みは以下の通りです

ステークホルダーの洗い出し
これまでそれぞれの判断で進めていたところをビジネスサイドも含め、
インシデントの関与頻度や誰がどの意思決定をするのかを整理しました。
優先度の定義付け
こちらは完全にITILに沿って策定しました。
・優先度=緊急度×インパクト
緊急度=事業にとってどれだけ早く解決する必要があるか
インパクト=ビジネスへの影響

緊急度、インパクトを高・中・小に分け、優先度としては1~4の4段階としました。

こちらについては、↓の記事で詳細を書いているので読んでいただければと思います。

フロー図の作成
2で決まった優先度をもとに、具体的なフローを書き出しました。

ここで意識をしたのは、インシデントのcloseの定義は何かということ。
というのも、これまでは
復旧はしたけど、インシデントとしてはcloseでいいんだっけ、、？ となっていたり
誰がボール持っているんだっけといったことがあったので、定義を明確にすることで
浮いているボールがないようにしようとしたかったという背景です。

4.チーム横断の説明会
1~3で決まったことをエンジニア以外も含めてチーム横断で説明会を行いました。
そもそもこのプロダクトにおけるインシデントとは何を指すのかの認識統一から
報告するときのフォーマット、具体の事例など、1つずつ説明させていただきました。

既に運用開始して3ヶ月ほど経過していますが、
チームを横断して認識をあわせられたことは大きな一歩になったと思います。
とはいえ、運用面での課題は既に出ているのでこちらは引き続き改善です。

社外で初めてLTを経験させていただき、とても貴重な経験になりました。
LT後もいろんな方とお話する機会になり、
これうちで取り入れてみようかな　だったり、どこでもあるあるなんだな〜 だったり。
また機会あれば参加させてもらえたらと思います

LiB Consultingに所属するエンジニア・デザイナーの個人記事を集めています。記事内容はあくまでも個人の見解であり、会社としてレビュー等はしておりません。あらかじめご了承ください。