問題管理
問題管理のメリット
問題管理は、IT サービス全体の品質を向上させるために、インシデント管理を論理的に拡張したものです。問題管理の正式なアプローチのメリットには、以下のものがあります。
- IT サービスの質の向上とビジネス向けの信頼性の高いサービス
- ビジネスのインシデント量の削減とサービスの中断の最小化
- チームが過去の誤りや問題から学ぶことによる、IT 組織全体での知識の共有の向上
- チームが障害の防止や障害の影響の軽減の傾向および方法を特定するために役立つ、履歴データから得た貴重なレポートと分析的洞察
- インシデントの数や影響を長期にわたって軽減するのに役立つ、永続的なソリューション
- 一元化されたナレッジ ベースにドキュメント化された教訓、既知のエラー、および回避策にアクセスできることによる、サービス デスク チームでの初期解決率の向上
問題管理プロセス
このプロセスは、ITIL の推奨事項に基づく問題調査のサンプルを示しています。他の ITIL およびサポート プロセスに合わせて調整できます。
問題管理では、分析を使用して問題の原因を特定します。このため、インシデント管理よりも時間がかかり、インシデントが緊急ではなくなったときにのみ実行する必要があります。問題調査は多くの場合、サービスが繰り返し停止する根本原因を IT チームで知る必要がある、インシデント後レビュー (PIR) の直接的な結果となります。問題管理には時間がかかる場合があるため、解決コストを抑えるために時間の制限を設けることが重要です。
問題調査の最初のステップは、問題の診断、回避策の検証、および調査結果のドキュメント化です。問題が診断され、回避策が特定されると、その問題は "既知のエラー" になります。既知のエラーは、既知のエラー データベース (KEDB) と呼ばれる集中ナレッジベースにドキュメント化されます。サービス デスク チームは新しいインシデントに対応するときに、既知のエラー データベースの知識を使用できます。
問題管理プロセスの概要
ITIL 問題管理プロセスは、問題調査を正常に完了するためのものです。問題調査に含まれる手順の概要は、以下のとおりです。
- 問題の検出 - サービス デスク チームは、インシデントが組織全体に同様の条件で発生していたり、再発していたりすると見なした場合、問題を提起します。問題調査チームは、これらの問題、インシデントのパターン、およびイベント管理からのアラートをレビューして、IT サービス全体の品質に影響を与える可能性があるパターンを特定します。
- 問題レコードの作成 - チームが問題を検出すると、サービス デスクまたは問題管理チームが問題を記録します。問題レコードには、発生日時、症状、関連インシデント、過去のトラブルシューティング手順、問題のカテゴリとソースが記録されます。この情報は、問題管理チームが根本原因を調査するのに役立ちます。
- 問題の分類 - 問題の分類は、サービス デスクによる一般的なインシデントの整理やモデル化、問題の傾向の追跡、サービス キャパシティ、需要、および品質の影響評価に役立ちます。問題の分類はインシデントの分類と一致している必要があります。
- 優先度の決定 - 問題の優先度は、緊急度とユーザーおよびビジネスへの影響力によって決定されます。緊急度は、組織で問題をどれだけ迅速に解決する必要があるかを示します。影響度は、問題によってサービスや組織が受ける可能性がある潜在的な損害を示します。
- 調査と診断 - 問題の調査や診断の速さは、その優先度によって決まります。優先度の高い問題はサービスや組織への影響が最も大きいため、最初に対処する必要があります。 診断フェーズでは、問題につながったインシデントと、サービス デスク チームが回避策を見つけるために実行したトラブルシューティングを分析します。このレベルの分析では、データのレビューや専門家との打ち合わせを行い、課題の根本原因を見つけるために必要な適切な情報を得ます。
- 回避策の特定 - 回避策により、問題の調査中に、サービス デスクでオープンなインシデントに対処し、通常のサービスを復旧することができます。
- 既知のエラー レコードの作成 - 回避策は既知のエラーとしてサービス デスク チームと共有されます。既知のエラーをナレッジ ベース (KB) の記事に記録することをおすすめします。ITIL では、この KB を既知のエラー データベース (KEDB) と呼びます。回避策をドキュメント化することで、サービス デスク チームはインシデントを迅速に解決し、同じ原因で発生するさらなる問題を回避できます。
- 問題解決 - 一連のインシデントの根本的な原因が見つかり、インシデントの再発が防止されると、問題の調査が解決されます。解決には、最終的な解決を適用するための変更リクエストが必要になる場合があります。たとえば、既知のパフォーマンスの課題に対処するために、ソフトウェア更新プログラムを本番環境に適用する必要があります。解決フェーズのステップは、解決を適用するための手順をドキュメント化することです。サービス デスクで将来情報を参照できるように、これを IT ナレッジ ベースに公開する必要があります。
- 問題のレビュー - ITIL では、これを主要な問題のレビューと分類します。レビューでは、問題管理チームが問題調査ドキュメントを評価して、何が起こったのか、およびそれがなぜ起こったのかを特定します。これによってチームは改善が必要なプロセスを特定できます。このステップで学んだ教訓はドキュメント化し、IT 組織と共有する必要があります。
Jira Service Desk で問題管理をセットアップする
ワークフローとフィールドの構成
次のワークフローで問題レコードを管理することをおすすめします。
問題管理フィールド
問題管理プロセスには次のフィールドを使用することをおすすめします。
| フィールド | 説明 | サンプル値 |
|---|---|---|
| 説明 | 問題に関する基本的な情報を取得します。 | |
| ステータス | 問題の状態です。 | |
| 保留理由 | 問題管理プロセスが保留になっている理由です。 | ベンダー待機中、詳細情報が必要、承認待ち、変更リクエストで保留 |
| Priority | 問題の緊急性と影響に応じて判断されます。チームは独自のプロセスに従って値を定義できます。 | 重大、高、中、低 |
| 緊急性 | 問題を解決すべき速さです。 | 重大、高、中、低 |
| 影響 | 問題の範囲と、問題が未解決なことによって発生する可能性がある損害です。 | 膨大 / 広範囲、重大 / 大、中 / 限定的、マイナー / 局部的 |
| 操作分類 | 運用の観点から、割り当ておよびレポートのために問題を分類します。 | 設定 > プリンター |
| 製品分類 | 製品の観点から、割り当ておよびレポートのために問題を分類します。 | ハードウェア > プリンター |
| ソース | 問題が発見された場所です。 | 電話、メール、イベント監視 |
| コンポーネント | 問題の影響を受けるサービスです。 | |
| ソリューション | 問題がどのように解決されたかを分類します。 | Known error |
| 根本原因 | 問題の原因です。ナレッジ ベースで既知のエラーとしてドキュメント化する必要がある可能性があります。 | |
| 回避策 | 問題が解決されるまでチームで使用できる、一時的な解決策です。 |
Confluence の IT スペースへの既知のエラーの公開
問題が診断され、回避策が特定されると、その問題は "既知のエラー" になります。既知のエラーはチームのナレッジ ベースでドキュメント化されます。Confluence は、インシデント管理で既知のエラーの解決に役立てる目的でナレッジ ベースの記事を公開するのに最適な場所です。既知のエラーが特定されたら、次のステップはその修正方法を決定することです。これには通常、影響を受けるシステムの変更リクエストが含まれます。
以下は、Confluence で公開されている既知のエラー データベース (KEDB) の例です。
