インシデント管理とは

インシデント管理プロセスの種類

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

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

IT インシデント管理プロセス

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

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

IT インシデント管理プロセスの手順

インシデントの特定と記録

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

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

分類

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

優先順位付け

すべてのインシデントに優先順位を付ける必要があります。まず、インシデントの業務への影響、影響を受けるユーザーの数、適用される SLA、財務やセキュリティ、コンプライアンスへの潜在的な影響を評価します。このインシデントを他のすべての未解決インシデントと比較し、その相対的な優先順位を決定します。

応答

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

インシデント、問題、変更の違い

IT チームが一般的に遭遇する課題にはさまざまな種類があります。適切な管理手法を適用できるように、それらを分類します。

• サービス リクエスト — 提供されるものに関する顧客からの正式な要求 (新しいラップトップの提供など)。
• インシデント — IT サービスの予期しない中断または IT サービスの質の低下 (ウェブサイトの停止など)。
• 問題 — 問題は、インシデントの根本原因です (サーバー構成のミスなど)。インシデントの悪化を防ぐため、問題を把握する必要があります。
• 変更: ユーザーが実行するアクション (標準、通常、または緊急)。標準の変更には確立された手順があります。通常の変更は多くの場合重要で、承認プロセスが必要です。緊急の変更は緊急性をもって実施されます。ロールアウト前にテストすると理想的です。

DevOps および SRE インシデント管理プロセス

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

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

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

DevOps インシデント管理チームの 3 つの理念

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

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

Atlassian インシデント ハンドブックでは、DevOps に優しいインシデント管理アプローチの概要を説明しています。

インシデント管理ツール

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

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