インシデント管理と問題管理の違い

毎日、世界中で何十億もの人々がコンピューターやモバイル・デバイスを使用してインターネットにアクセスしています。必ず、こうしたユーザーの一部は、読み込みに時間がかかるか、クラッシュしやすいWebサイトにアクセスしようとします。

Webサイトのパフォーマンスが低下した理由の1つは、同時にサイトにアクセスしようとしていた人が多すぎて、サーバーが圧倒されたことです。ただし、DNSの設定ミス、永続的なサーバー障害、悪意のある攻撃者による悪意のある攻撃など、より大きな問題を示している可能性もあります。

インシデントとは、修復が必要なITサービスのエラーや複雑さのことです。これらのインシデントの多くは、特定の解決策を必要とする一時的な課題ですが、より包括的な対処を必要とする根本的な、またはより複雑な問題を示すものは、問題と呼ばれます 。

これは、インシデント管理と問題管理の両方、問題とエラー制御のための2つの重要なプロセスの存在、アップタイムの維持、そして最終的には顧客やその他の利害関係者に優れたサービスの提供について説明しています。

組織は、顧客にサービスを提供し、パートナーとコラボレーションするために、デジタル・テクノロジーへの依存度が高めています。組織のテクノロジー・スタックは、ビジネスを成長させるための新しくエキサイティングな機会を生み出す可能性があります。しかし、サービスにおけるエラーは、指数関数的な混乱や、評判や財務の健全性への損害を引き起こす可能性もあります。

インシデント管理とは、組織が通常のビジネス・プロセスを中断させる可能性のあるインシデントを特定、追跡、解決する方法です。多くの場合、これはインシデントが発生し、組織が可能な限り迅速にインシデント対応を行う事後対応型のプロセスです。

デジタル・トランスフォーメーションやその他のテクノロジー主導のオペレーションを追求する組織の増加により、顧客にソリューションを提供するためのテクノロジーへの依存を考えると、インシデント管理の重要性がさらに高まっています。

組織のITサービスは、アプリケーション、ソフトウェア、ハードウェア、その他のテクノロジーの複雑なシステムで構成されていることが増えており、そのすべてが相互依存しています。個々のプロセスが故障し、顧客に提供するサービスを中断させ、ビジネスに費用がかかり、評判に問題が生じる可能性があります。組織はインシデントを最小限に抑えるために高度な開発オペレーション（DevOps）手順を採用していますが、インシデントが発生した場合の解決プロセスが必要です。

組織は毎日、軽微なインシデントに遭遇し、そのインシデントを管理する必要がありますが、そのすべてが通常の業務機能を中断させる可能性があります。組織は、システム停止、ネットワーク構成の問題、バグ、セキュリティー・インシデント、データ損失などの計画外の中断を含む、さまざまな種類のインシデントに注意を払う必要があります。

テクノロジー・スタックの複雑さが増すにつれて、インシデント管理プロセスを戦略的に管理することがさらに重要になっています。組織内の全員がインシデントに遭遇した際に何をすべきかを確実に把握できるようにします。

インシデント管理システムは、従業員が観察したインシデントを記録する（発生数時間後に発生する可能性がある）という単純なツールから進化しました。自動化とセルフサービス型のインシデント管理ソフトウェアを使用した堅牢な常時稼働のプラクティスにより、組織内の誰もがサービス・デスクにインシデントを報告できるようになります。

インシデントを直ちに解決し、再発を防ぐことが重要です。これにより、組織はサービス・レベル契約（SLA）を遵守でき、これにより、一定量のアップタイムやサービスへのアクセスが保証される場合があります。SLAを遵守しないと、組織は法的リスクや評判上のリスクにさらされる可能性があります。

インシデント・マネージャーは、インシデント管理プロセスの利害関係者です。インシデント・マネージャーは、インシデントへの対応を管理し、利害関係者に進捗状況を伝える責任があります。これは、従業員がビジネス内のさまざまな役割や優先事項を持つ利害関係者とコミュニケーションをとりながら、ストレスの多い状況下で業務を遂行する必要がある、複雑なITサービス業務です。

問題管理は、根本原因に対処することで、インシデントの再発を防ぐことを目的としています。特に、そのインシデントが複数回発生し、問題または既知のエラーとして診断されるべき可能性が高い場合は、論理的にインシデント管理に従います。

問題管理のないインシデント管理は、根本原因には対処せず、症状に対処するだけで、将来同様のインシデントが発生する可能性が高くなります。効果的な問題管理により、問題に対する永続的な解決策が特定され、組織が将来管理しなければならないインシデントの数が減少します。

問題管理チームは、観察されたインシデントと保有する履歴データに応じて、事後対応型または事前対応型の問題管理を実施することができます。

インシデントと問題を観察する際に考慮すべき大きな違いが1つあります。それは、短期的な目標と長期的な目標です。

インシデント管理は、追加の問題を発生させることなく、サービスをオンラインに戻すという目標を掲げ、問題のあるインスタンスにより介入することに重点を置いています。これは、その瞬間にサービスを実行し続けるための短期的なツールです。

問題管理は長期的な対応に重点を置き、潜在的な根本原因をより大きな潜在的な問題（つまり問題）の一部として対処するものです。

組織は、ITサービス管理（ITSM）を使用して、エンド・ユーザーのニーズを満たすサービスの実装、配信、管理を管理することで、ITインフラストラクチャーを良好な状態に維持しようとします。ITSMは、ダウンタイムを最小限に抑え、すべてのITリソースがすべてのエンド・ユーザーが意図したとおりに機能するようにすることを目指します。

組織がITSMにどれだけの労力を費やしたかに関係なく、問題は発生します。予期せぬ問題がより大きな問題になる前にそれに取り組み、修正する組織の能力は、大きな競争上の優位性となり得ます。ITサービスが一度停止すると、インシデントとみなされます。

たとえば、サーバーにアクセスしようとする人数が多すぎるとサーバーがクラッシュし、組織が修正する必要があるインシデントが発生する可能性があります。インシデント管理は、ユーザーに影響を与える特定の問題をできるだけ迅速かつ慎重に修正することに関連します。この場合、インシデント・マネージャーは組織の従業員に連絡し、組織が問題を解決する間プログラムを終了するよう求めることができます。

インシデント管理と問題管理はどちらも、情報技術インフラストラクチャー・ライブラリー（ITIL）によって管理されています。ITILは、両方の管理アプローチを実装および文書化するための広く採用されているガイダンス・フレームワークです。ITILは、インシデントが発生したときに事後的に対応するための構造を作成します。この記事の執筆時点で最新のリリースはITIL 4です。

ITILは、ITサービスを管理し、ITサポートとサービス・レベルを向上させるためのベスト・プラクティスのライブラリーです。ITILプロセスは、ITサービスをビジネス・オペレーションに結び付け、ビジネス目標が変更されたときにも変更できるようにします。

ITILの重要なコンポーネントは、ITサービスの提供に必要なすべてのソフトウェア、ITコンポーネント、ドキュメント、ユーザー、ハードウェアの相互依存性を追跡および管理する構成管理データベース（CMDB）です。ITILはまた、インシデント管理と問題管理を区別します。

絶えずクラッシュするサーバーは、ハードウェア障害や構成ミスなど、より大規模かつ体系的な問題を示している可能性があります。ITサービス・チームが根本原因を解明し、根本的な問題に対する解決策をマッピングできない場合、クラッシュは継続する可能性があります。この場合、対応としては、繰り返し発生するインシデントの修正を伴う問題管理へのエスカレーションが必要になることがあります。

問題管理では、問題の根本原因分析と推奨される解決策が提供され、問題が再発しないようにするために必要なリソースが特定されます。

効果的なインシデントおよび問題管理には、リアルタイムの監視、オートメーション、そして不必要なダウンタイムや事業の中断を回避するために、可能な限り迅速に問題を解決するための調整を必要とする構造化されたワークフローが含まれます。どちらの形式の管理でも、組織が知っておくべきコンポーネントがいくつかあります。

ITインシデント管理

• インシデントの特定：インシデントを解決するには、まずそれを観察する必要があります。組織は、インシデント発生時に検知して通知を送信するシステムを自動化するケースが増えています。しかし、その多くは、インシデントが発生していることを確認し、介入が必要かどうかを判断し、正しいアプローチを確認するために人手を必要としています。たとえば、サーバーのクラッシュはデジタル・ファーストの組織ではよくあるインシデントです。サーバーがオフラインになると、自動化ツールまたは従業員がインシデントを識別し、インシデント管理プロセスを開始する場合があります。
• インシデント報告：これは、機械または人間が観察したインシデントの記録をカタログ化する正式なプロセスです。これには、インシデント・ロギング（個人またはシステムが問題に対応する回答者を割り当て、インシデントを分類し、影響を受ける事業単位と解決日を特定するプロセス）が含まれます。
• インシデント解決の優先順位付け：ソフトウェアとITサービスは現代の組織において相互に依存していることが多いため、1つのインシデントが他のサービスに波及効果をもたらす可能性があります。時には、より大規模なシステム障害の一部としてインシデントが発生し、壊滅的な出来事の連鎖を引き起こす可能性があります。たとえば、複数のサーバーがクラッシュした場合、ビジネス分析チームが必要なデータにアクセスできなくなる可能性があり、また、会社のナレッジ・ワーカーがログインして業務に必要なソフトウェアにアクセスできなくなる可能性があります。または、企業のAPIに障害が発生した場合、その組織の顧客はエンド・ユーザーにサービスを提供するために必要な情報にアクセスできなくなる可能性があります。どちらの状況でも、対応チームは問題の範囲全体を評価し、どのインシデントを解決するか優先順位を付けて、事業への短期的および長期的な影響を最小限に抑える必要があります。また、組織に最も大きな影響を与えるインシデントに基づいて優先順位を付けることができます。
• インシデント対応と封じ込め：自動化されたソフトウェアやシステムによって支援される可能性のある対応チームが、インシデントのトラブルシューティングを行い、業務の中断を最小限に抑えます。通常、対応チームは、社内のITチームメンバー、社外のサービス・プロバイダー、オペレーション・スタッフで構成されます。
• インシデントの解決：これは、ITオペレーションが通常のサービスに戻るために重要です。ITインシデントに対する解決策として考えられるものには、誤って動作しているサーバーをオフラインにすること、パッチを作成すること、回避策を確立すること、ハードウェアを変更することなどが挙げられます。
• ドキュメンテーションとコミュニケーション：これは、将来のインシデントを回避するためのインシデントのライフサイクルにおける重要なステップです。多くの企業は、従業員が過去に発生した可能性のあるインシデントを解決するために検索できるインシデント・レポート用の知識ベースを作成しています。さらに、新入社員は、会社が最近どのようなインシデントに直面したか、適用される解決策について知ることができるため、次のインシデントに備えやすくなります。ドキュメンテーションは、問題が再発し、問題になりつつあるかどうかを判断するためにも重要であり、問題管理の必要性が高まっています。

問題管理

• アセスメント：次に、組織は、インシデントを問題の記録として分類するか、それとも単なる無関係なインシデントであるかを判断する必要があります。前者は、それが問題管理の一部になることを意味します。
• 問題のロギングと分類：ITチームは現在、特定された問題をロギングし、各発生を追跡する必要があります。
• 根本原因分析：組織は、これらの問題の背後にある根本的な問題を研究し、長期的な解決策を作成するロードマップを作成する必要があります。その達成方法の1つは、元の問題を特定できるまで、手順の各ステップで「どのように」という質問を再帰的に尋ねることです。
• 問題解決：問題とその根本原因を理解したITチームは、問題を解決できます。問題の重大度や複雑さに応じて、迅速な対応または長期にわたる対応が必要になる場合があります。
• 事後分析：関連する従業員がインシデント、根本原因、問題への対応について話し合う事後分析は、稼働時間を維持し、顧客に優れたサービスを提供することに関心のある透明性のある組織の重要なコンポーネントであり、重要な要素です。事後検証は、従業員をジャッジしたり、問題の責任を追及することなく、誰もが改善方法について話し合う機会を提供します。事後分析の目的は、何が起こったかを把握し、組織を改善するためのアクションを定義することです。また、将来のインシデントによりチームがどのように対応できるかについての洞察を得ることができます。組織がインシデントや問題の管理を活性化し、合理化するために、チェンジ・マネジメントが必要かどうかを特定できます。最良のアイデアと最良の成果は、オープンで率直な事後分析から生まれます。チーム文化は、これがチームがITサービスを改善する方法を発見する方法であり、批判されるべき人物を見つける方法ではないことをすべてメンバーに約束する必要があります。チームは、これが率直で協力的な演習であるかどうかをすぐに理解できます。

組織は多くの場合、いくつかの主要業績評価指標（KPI）に基づいてインシデント・マネージャーとインシデント管理プロセスを評価します。

• 行動までの平均時間：インシデントには検知、対応、修復が必要です。組織は、平均確認時間（MTTA）、平均対応時間、および平均修復時間（MTTR）によってインシデント管理サービスの正常性を判断します。これらの指標はすべて、組織がインシデントにどのように対応できるかを明確に示します。
• 平均故障間隔（MTBF）：ITサービスのインシデントが発生している時間的間隔。MTBFの頻度が予想よりも高い場合、より積極的な対応が必要となる大きな問題を示している可能性があります。
• アップタイム：サービスが利用可能であり、意図したとおりに機能している時間。アップタイムが少なすぎると、組織はエンド・ユーザーとのSLAに違反したり、そうでなければ競合他社にビジネスを奪われたりするリスクにさらされる可能性があります。
• 報告されたインシデントと問題：一定期間にインシデント・マネジャーが報告したインシデントの数。報告されるインシデントの増加は、より大きな問題の兆候である可能性があります。

包括的な問題とインシデント管理計画を立てている企業は、インシデントに迅速に対応し、競合他社を上回る業績をあげることができます。以下にいくつかのメリットを挙げます。

• 顧客満足度とロイヤルティの向上：顧客は、自分が支払ったサービスや製品が必要なときにいつでも機能することを期待しています。ますます多くの製品がソフトウェアとなっています（あるいは、スマート・デバイスなどがソフトウェアに接続されています）。スマート・ドアベルを製造している企業でサーバーがクラッシュした場合、人々が家やアパートなどに入ることができなくなります。DNSエラーの問題が発生したホテル予約Webサイトは、その日の収益を失い、生涯顧客を競合他社に奪われる可能性があります。インシデントや問題の影響は、組織に大きな影響を及ぼす可能性があります。インシデントに迅速に対応し、ダウンタイムを最小限に抑えるプロバイダーは、不満があるとプロバイダーを切り替える可能性が高い顧客から忠誠心を獲得できます。強固なインシデント管理ストラテジーにより、ダウンタイムと顧客や従業員を失う可能性を低減することで企業のコストを節約できますが、どちらもハード・コストにつながります。
• 従業員満足度の向上：深刻なITインシデントは、顧客と同様に従業員にも影響を与えます。重要なビジネス・ソフトウェアにアクセスできない従業員は、職務を遂行できません。会社が物事をオンラインに取り戻そうとするにつれて、従業員の仕事は山積みになっています。追いつくために残業や週末勤務をしなければならない場合、ストレスが生じ、士気が低下する恐れがあります。
• SLA要件を満たす：組織は、SLAの中で製品とサービスに対する顧客の期待を詳細に説明します。SLAでサービス条件を保持していない場合、組織は法的措置のリスクにさらされる可能性があり、顧客を競合他社に奪われる可能性があります。

IBM® Turbonomic は、既存のITOpsソリューションと統合し、サイロ化されたチームとデータを橋渡しして、手動の事後対応的なプロセスを継続的なアプリケーションの最適化に変換しながら、クラウドの消費を安全に33%削減します。

インシデント管理用のセルフ・ホスト・オプションであるIBM® Cloud Pak for AIOpsは、事前対応的なインシデント管理と自動修復を実現し、顧客対応の停止を最大50%削減し、平均復旧時間（MTTR）を最大50%削減します。

Thinkニュースレターを購読する