インシデント管理とは

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

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

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

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

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

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

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

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

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

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

分類

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

優先順位付け

Every incident must be prioritized. Start by assessing its impact on the business, the number of people who will be impacted, any applicable SLAs, as well as the potential financial, security, and compliance implications of the incident. Compare this incident to all other open incidents to determine its relative priority. As a best practice, define your severity and priority levels before an incident happens, making it simpler for incident managers to gauge priority quickly.

応答

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

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

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

Increasingly the software you rely on for life and work is not being hosted on a server in the same physical location as you. It’s likely a web-accessed application deployed in a data center for thousands or millions of users around the globe. For teams tasked with running these services, agility and speed are paramount. Any downtime has the potential to affect thousands of organizations, not just one.

An advantage of the “you build it, you run it” approach is that it offers the flexibility agile teams need, but it can also obscure who is responsible for what and when. DevOps teams can be comfortable—and successful—with less structured development processes. But it’s best to standardize on a core set of processes for incident management so there is no question how to respond in the heat of an incident, and so you can track issues and report how they’re resolved.

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

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

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

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

インシデント管理ツール

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

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