インシデント管理とは

インシデント管理は、開発チームと IT 運用チームが予期せぬイベントまたはサービス中断に対応し、サービスを運用状態に戻すために使用するプロセスです。

アトラシアンでは、インシデントをサービスの中断や質の低下を引き起こす、緊急対応が必要なイベントとして定義しています。ITIL または ITSM の実施基準に従うチームでは、メジャー インシデントという用語を使用することがあります。

Incidents are events of any kind that disrupt or reduce the quality of service (or threaten to do so). A business application going down is an incident. A crawling-but-not-yet-dead web server can be an incident, too. It’s running slowly and interfering with productivity. Worse yet, it poses the even-greater risk of complete failure. Incidents can vary widely in severity, ranging from an entire global web service crashing to a small number of users having intermittent errors. An incident is resolved when the affected service resumes functioning in its intended state. This includes only those tasks required to mitigate impact and restore functionality.

インシデント管理は、組織が適切に理解する必要がある最も重要なプロセスの 1 つです。サービスの停止はビジネスにとってコストがかかり、チームはこれらの問題に迅速に対応して解決するための効率的な方法を必要としています。チームには、インシデントの優先順位を決め、迅速な解決を実現し、ユーザーに優れたサービスを提供するための信頼性の高い方法が必要です。

チームがインシデントに直面している場合、チームが次のことを実行できるような計画が必要です。

• 迅速な復旧を可能にするために、効果的に対応する。
• 顧客、関係者、サービス所有者、および組織内の他のユーザーに明確に通知する。
• 効果的にコラボレーションして、チームとして問題を迅速に解決し、問題の解決を妨げる障壁を取り除く。
• 継続的に改善できるようにこれらの停止から学び、学んだ内容を適用してサービスを改善し、将来のプロセスを改善する。

さまざまな種類の企業が、異なるタイプのインシデント管理プロセスに引き寄せられる傾向があります。すべての企業に適した万能なプロセスは存在しないため、さまざまな企業の多様なアプローチを目にすることになります。

多くのチームは、ITIL 認定に概説されているような、より伝統的な IT スタイルのインシデント管理プロセスに依存しています。その一方で、サイト信頼性エンジニア (SRE) または DevOps スタイルのインシデント管理プロセスに傾くチームもあります。

インシデント管理プロセスは、IT チームがサービスの中断または停止について調査、記録、解決する際に役立ちます。ITIL インシデント管理ワークフローは、ダウンタイムを削減し、インシデントによる従業員の生産性への影響を最小限に抑えることを目指しています。インシデントを管理するように設計されたテンプレートを使用して、繰り返し可能なインシデント管理ワークフローを作成できます。これにより、チームはインシデントを記録、診断、解決し、そのアクティビティを記録できます。

ITIL フレームワークは、主に企業内でサービスを実行している IT チームによって使用されます。ITIL は IT チームが直面する可能性があるほぼすべてのタイプのインシデントや課題、プロセスをカバーしますが、チームは通常、ITIL から必要なものだけを採用します。ITIL は、チームがアクティブなトラブルシューティングの文化の醸成に集中する必要がある場合に最適です。所定のプロセスは、チームがインシデントとアクションを一貫した方法で追跡する上で役に立ち、レポートと分析を改善します。そして、より健全なサービスとチームの成功につながります。

インシデントは、従業員、顧客、ベンダー、監視システムのどこからでも発生する可能性があります。どこから報告を受けたかに関係なく、最初の 2 つのステップはシンプルです。誰かがインシデントを特定した後に、誰かがそれを記録します。通常、これらのインシデント記録 (すなわち、チケット) には以下の内容が含まれます。

• そのインシデントの報告者の名前
• インシデントが報告された日時
• インシデントの説明 (何がダウンしているか、または何が適切に動作していないか)
• 追跡するためにインシデントに割り当てられた一意の識別番号

論理的で直感的なカテゴリ (必要に応じて、サブカテゴリ) をすべてのインシデントに割り当てます。これは、効果的な問題管理と将来のインシデント予防にとって重要な、データのトレンドとパターンの分析にも役立ちます。

すべてのインシデントに優先順位を付ける必要があります。まず、インシデントの業務への影響、影響を受けるユーザーの数、適用される SLA、財務やセキュリティ、コンプライアンスへの潜在的な影響を評価します。このインシデントを他のすべての未解決インシデントと比較し、その相対的な優先度を決定します。ベスト プラクティスとして、インシデントが発生する前に重大度と優先度を定義しておくと、インシデント マネージャーが優先度を迅速に判断しやすくなります。

• 初期診断: 最前線のサポート チームがインシデントを診断からクローズまで確認できるのが理想ですが、それができない場合、関連する情報をすべて記録し、次の階層チームにエスカレーションします。
• エスカレーション: 次のチームはログに記録されたデータを受け取り、診断プロセスを続行します。このチームがインシデントを診断できない場合は、次のチームにエスカレーションします。
• コミュニケーション: チームは、影響を受ける社内外の関係者と定期的に情報を共有します。
• 調査と診断: これは、インシデントの性質が特定されるまで続きます。解決の助言と支援を受けるため、チームが外部リソースまたは他の部門のメンバーに参加を依頼する場合もあります。
• 解決と回復: このステップでは、チームは診断を完了し、インシデントを解決するために必要な手順を実行します。一部の修正 (バグのパッチなど) は、適切な解決策が特定された後もテストおよびデプロイが必要な場合があるため、復旧は単に運用が完全に元どおりになるまでにかかる時間を意味します。
• クローズ: インシデントがエスカレーションされた場合、最終的にサービス デスクに戻されてクローズされます。品質を維持してスムーズなプロセスを確保するため、インシデントのクローズは、サービス デスクの従業員のみに許可されています。インシデントの所有者はインシデントの報告者に解決が満足のいくものであったことを確認する必要があり、確認できたらインシデントをクローズできます。

DevOps または SRE アプローチによるインシデント管理では、サービスを構築するチームがサービスの実行も担当し、サービスが中断した場合には修正します。このアプローチは、常時稼働クラウド サービス、グローバル アクセス Web アプリ、マイクロサービス、サービスとしてのソフトウェアの成長に伴い、人気が高まっています。

生活や仕事で利用しているソフトウェアが、物理的に同じ場所にあるサーバー上でホストされないケースが増えており、世界中の数千または数百万のユーザー向けにデータ センターにデプロイされた Web アクセス アプリを利用していることがあります。これらのサービスの実行を担当するチームにとっては、アジリティとスピードが最優先です。ダウンタイムは、1 つの組織だけでなく、何千もの組織に影響を及ぼす可能性があります。

"構築した者が運用する" アプローチの利点は、アジャイル チームが必要とする柔軟性を実現できることです。その一方で、誰がいつ何を担当しているのかが不明瞭になる場合もあります。DevOps チームは、あまり構造化されていない開発プロセスでも快適に作業し、成功することができます。それでも、インシデント管理の中核的なプロセスに基づいて標準化することが最善です。そうすることで、インシデント発生時の対応方法が明確になり、課題を追跡して解決方法を報告できます。

• 交代制オンコール: DevOps チームは通常、特定のチーム メンバーがオンコール専門になるのではなく、インシデントに対応するために夜間に起こされる可能性がある負担をすべてのメンバーが共有する、オンコール スケジュールでローテーションします。
• 構築したエンジニアが修正に適任: "構築した者が運用する" という方針の中心となる考え方は、サービスに最も精通している人 (ビルダー) が停止の修正に適任であるということです。
• 迅速に構築し、説明責任を果たす: エンジニアがシステム停止中に彼らとそのチームメイトが困難な状況に置かれていることを知ると、確実に質の高いコードをデプロイしようとするインセンティブが高まります。

このアプローチにより、信頼性の高いサービスを構築する方法を知る必要のあるチームへの迅速な対応とフィードバックを保証します。

アトラシアンの Incident Handbook では、DevOps に優しいインシデント管理アプローチの概要を説明しています。

インシデント管理は、ツールだけで行われるのではなく、ツール、プラクティス、人材を適切に組み合わせて行われます。効果的なインシデント管理のための最も一般的なツール カテゴリをいくつかご紹介します。

• インシデント追跡: すべてのインシデントを追跡し、文書化することで、傾向を特定し、経時的に比較できます。
• チャット ルーム: リアルタイムのテキスト コミュニケーションは、チームでインシデントを診断して解決するための基盤となります。また、事後対応分析のために豊富なデータ セットを提供します。
• ビデオ チャット: ビデオ チャットは、多くのインシデントでテキスト チャットを補完します。チーム ビデオ チャットは、調査結果を議論し、対応戦略をマッピングするのに役立ちます。
• アラート システム: Jira Service Management などのツールを使用して、監視システムと統合し、オンコール ローテーションとエスカレーションを管理します。
• ドキュメント作成ツール: Confluence などのツールを使用してインシデント状況のドキュメントと事後分析を取得できます。
• Statuspage: Statupage を使用して内部の関係者や顧客に状況を伝えることで、すべての人が最新情報を入手できます。