このインシデントの原因は?問題管理は「根本治療」:ITILの基本(5)

問題管理は、ITシステム運用では、インシデント管理と同様に重要なプロセスです。問題管理とは、予期せずに起きたインシデントの原因を突き止め、分析し、回避策や再発防止策を立て、根本的な解決へと導くプロセスです。ユーザが信頼できる高い品質で、ITサービスを提供し続けるには、不可欠な取り組みです。

問題管理は、インシデント管理とは別モノ

問題管理は、「インシデント管理」と混同されることもありますが、これらは分けて考える必要があります。インシデント管理を、トラブルが発生したときに対処する、いかに迅速に復旧させるかの「応急処置」だと考えられます、一方、問題管理は、インシデントそのものを避け、原因を究明するための「恒久対策」といえます。
インシデント管理と問題管理とを分けて考えることで、今すぐに対処しなければならない障害と、より深く広範囲な視点から対応しなければならない問題を明確にし、サービス停止による影響を最小限に抑えることができます。障害の内容や影響に応じた、トリアージ(選別・分類)と考えることもできます。

問題管理は、すでに発生しているインシデントへのさらなる対策なので、後追いにならざるを得ません。しかし、過去のインシデントの発生傾向を分析したり、外部から提供される新しい情報を参考にすることで、将来発生する可能性があるインシデント自体を減らすこともできます。つまり、待ちの姿勢ではなく、積極的な問題管理が、運用全体のパフォーマンスを向上させます。

問題管理が必要となるタイミング

問題管理は、通常の定型業務ではありませんが、必要になるタイミングがあります。

・過去に起きていないインシデントが発生した時
問題管理として、最もよくあるケースです。未知のインシデントが起きると、問題管理の対象となります。同様のインシデントが再発することを防ぐためにも、根本的な原因究明が必要になります。

・解決済みだったはずのインシデントが再発した時
解決済みとしてクローズされていたインシデントが再発してしまった場合は、残念ながら、過去の問題管理と対策が不十分・不適切だったことを意味します。また、過去の時点では有効だった対策が、仕様や設定、技術などの変更・更新で、無効または不十分になり、似たようなインシデントが発生することもあります。何れにしてもこの場合は、改めて、より徹底した原因究明と解決に向けた具体策が求められます。

・過去のインシデント分析から、問題の傾向が推測できる場合
先の2つが、インシデントが起きてから対処する「リアクティブ(受動)」なアクションなのに対し、トラブルを未然に防ぐ「プロアクティブ(能動)」な分析や対応も可能です。集積されているインシデントのログから、問題管理のきっかけやヒントになる点を細かく分析します。

<PR>問題管理とインシデント管理が別だとはいえ、管理しなければならないのは同じ。だったらできるだけ楽に!賢いエンジニアなら、SaaS型の統合運用管理サービス「UOM」を使ってとことん効率化。詳しくはこちら

問題管理の4つのステップ

問題管理には、解決までに主に4つのステップがあります。

1.問題の記録・分類
発生したインシデントが解決しても、その根本的な原因がわからない場合は、未知のエラーである「問題」として認識されます。発見し、認識された問題は、漏れを防ぐために詳細を記録しておきます。発見した担当者や発生日時、ステータス、関連するインシデントの情報などが必要になります。記録した問題は、影響や緊急性などから、優先順位を判断して分類されます。

2.問題の調査・診断
問題を認識した後は、原因を究明するフェーズです。問題が単独の場合は、そのまま根本的な原因を調査し、診断していきます。複数発生している場合は、優先順位に沿ってよりリスクが高い問題から、調査・診断に進みます。原因が判明した問題は「既知のエラー」として識別されます。

3.エラー制御
問題の原因が判明した時点で、根本的な解決策を検討します。ただし、根本的な問題解決には、当初の予定にはなかったコストや時間というリソースが、新たに発生する可能性があります。そのため、影響する範囲や費用対効果を見極める作業が必要です。条件が許せば、具体的な再発防止策を取って解決を目指します。

4.問題のクローズ
問題が解決されたことを確認したら、問題をクローズします。発生経緯などの情報を詳細に記録し、共有しておくことで、同じようなインシデントが再発しても、次回以降は迅速に解決できます。

問題管理の目的は再発防止

インシデントが発生すれば、ユーザが通常通りサービスを利用できるように、迅速な復旧が求められます。その時、起きている、ユーザの困りごとを解決します。通常の状態に戻れば、そこでインシデント管理はクローズします。
一方、問題管理は、そもそも、ユーザにとって困りごとが起きないように、対処します。インシデント管理がクローズした後も、原因を究明して解決するまで続いていきます。このように、インシデント管理と問題管理を分けて、目的に応じたタイミングで対処することが必要です。
ITシステムの運用は、インシデントが絶対に起きないまま使い続けることは困難です。しかし、適切に問題管理することで、インシデントの発生を可能な限りゼロに近づけ、自動化できるシステムによって徹底的に効率化し、ビジネスへの悪影響を最小化させていくことは十分可能です。

<PR>未知のインシデントや解決済みだったはずが再発する、システム運用あるある…もう効率化・自動化しませんか?統合運用管理サービス「UOM」はSaaS型で導入が楽なのに、プロ向けの機能が充実!詳しくはこちら

関連記事

∞∞∞∞∞∞∞ おすすめ記事 ∞∞∞∞∞∞

  1. コレって我が社だけ!?システム「運用」と「保守」ってどう違う?

    現代のビジネスで欠かせないITシステム。システム「運用」や「保守」は、企業の安定した組織運営の重要な…
  2. アジャイル開発のメリットとは?システム運用にどう関係する?

    アジャイル開発のメリットとは?システム運用にどう関係する?

    ITシステムの開発スタイル(モデル)は、業界ごとに異なるだけでなく、時代のニーズでも変化し続けていま…
  3. 無駄な手順から見直そう:もう一度システム運用を考える(3)

    一般的には、発生した障害を通知するアラートの多くは、事前に作成された手順書に基づいて対応します。想定…
  4. ITILの中心的プロセス、構成管理って?ITILの基本(2)

    ITILの中心的プロセス、構成管理って?ITILの基本(2)

    ITILに関する前回のエントリーでは、サービス運用や管理の事例集としての概要に触れました。今回は、I…
  5. 過酷に思われがちな「ひとり情シス」による運用は、本当に不幸なのか?

    近年の業界ワードの一つが「ひとり情シス」。1人(または2~3人程度の少人数)で、システム運用を始めと…
ページ上部へ戻る