重大インシデント管理プロセスの実行方法

影響の大きいインシデントの管理と解決

重大なインシデント管理 (Atlassian では単にインシデント管理ということが多いです) は、DevOps チームと IT 運用チームが予期せぬイベントまたはサービス中断に対応して、サービスを運用状態に戻すために使用するプロセスです。

重大インシデントとは

では、重大なインシデントを構成するものは何でしょうか? 重大なインシデントとは、緊急レベルの停止またはサービスの喪失です。

緊急レベルの定義は、組織によって異なります。Atlassian では 3 つの重大度レベルがあり、上位 2 つ (SEV 1 と SEV 2) はどちらも重大なインシデントとみなされます。

すべての Atlassian の顧客に対して顧客向けサービスがダウンしている場合、それは SEV 1 インシデントです。同じサービスでも一部の顧客に対してのみダウンしている場合、それは SEV 2 です。いずれも重大なインシデントという項目に分類されて、インシデント管理チームによる即時対応が必要です。

重要なタスクを妨げない課題はすべて SEV 3 とみなされて、重大なインシデントではありません。

重大インシデント管理プロセスの定義

インシデント ライフサイクル (インシデント管理プロセスとも呼ばれます) は、インシデントを特定、解決、理解、再発防止するための手順です。

インシデント管理プロセスは企業によって異なりますが、どのチームにとっても、成功の鍵は、重大度、優先度、役割、プロセスを事前に定義して、重要なインシデントが発生する前に伝達することです。

優先度、役割、プロセスの理解を共有するには、重大インシデント管理プロセスを開始または再確認するチームが、次のような質問に対する回答を明確にすることから始める必要があります。

• 当社/製品の重大なインシデントとはどのようなものですか?
• インシデントの重要度と優先度の各レベルはどのように定義しますか? 一度に複数の重大なインシデントが起こった場合は、最初に何に対処すべきかをどのように把握できますか?
• 重大インシデントを処理する責任は誰にありますか? チーム メンバーにはどのような役割がありますか? それらの役割はどのように定義されて伝達されますか?
• 重大なインシデントが発生した場合、チームはどのようなプロセスに従いますか? インシデントの種類に応じて、複数のプロセスがありますか?
• 社内外の関係者とやり取りする頻度はどれくらいですか? どのようなコミュニケーション計画がありますか?
• 重大なインシデントに対するオンコール スケジュールはどうなっていますか? 午前 2 時に発生したインシデントには誰が対応しますか? 週末はどうですか? 休日をまたぐ場合はどうなりますか?
• アラートによる疲弊を避けつつ重大なインシデントの迅速な解決を優先するには、オンコール インシデント マネージャーにはいつどのようにアラートを発したらよいですか?

Atlassian の重大インシデント管理プロセス

Atlassian では、インシデント管理プロセスには、検出、新しいインシデントの報告、コミュニケーションの開始、評価、初回コミュニケーションの送信、エスカレーション、権限委譲、フォローアップ コミュニケーションの送信、レビュー、解決が含まれます。

検出

まずインシデントは、当社の技術、顧客レポート、または担当者によって検出されます。インシデントを検出した者 (課題に気づいた技術者、または不満を抱いたクライアントから電話を受けたカスタマー サービス担当者) は、インシデントをシステムに記録して重大度レベルを特定する責任があります。

インシデントがチームに到達するまでに、すでに SEV 1、2、または 3 が設定されています。SEV レベル 1 と 2 は重大なインシデント、SEV 3 は影響の小さいインシデントとみなされます。

新しいインシデントの報告

インシデント チケットが作成されると、そのサービスを担当するオンコール プロフェッショナルに通知が送信されます。

Atlassian で送信するページ アラートには、インシデントの重大度と優先度の情報、および要約が含まれているため、これが最優先事項であるか、別のインシデントが進行中である場合に待機できるかが一目でわかります。

コミュニケーションの開始

インシデント マネージャーがアラートを受け取った後の最初の業務は、インシデントの修正が進行中であることを伝えることです。彼らはインシデントのステータスを修正中に変更して、チームのコミュニケーション チャネルを設定します。

柔軟なコミュニケーション チャンネルをインシデント対応プロセスを通じて提供することで、各チームは希望する方法で連絡を取り続けられるようにすることが不可欠です。Jira Service Management は複数のコミュニケーション チャンネルを統合して、埋め込み可能なステータス ウィジェット、専用 Statuspage、電子メール、チャット ツール、ソーシャル メディア、SMS などのダウンタイムを最小限に抑えます。

評価

インシデント マネージャーにアラートが通知されて、コミュニケーション チャネルが開いています。次のステップでは、インシデント自体を評価します。

チームにとってこのプロセスは、チームが答える必要のある次の一連の質問から始まります。

• Atlassian の顧客と従業員にはどのような影響があるか?
• 顧客には何が起こっているか？
• 何人の顧客が影響を受けているか? (一部か? 全員か?)
• インシデントが始まったのはいつか?
• このインシデントに関してサポート ケースはいくつオープンしているか?
• 重大度や優先度に影響を与えたりインシデントへのアプローチ方法を変更したりする要因が他にもあるか? (例: セキュリティ上の懸念、ソーシャル メディアの PR リスクなど)

これらの質問に答えたら、診断と提案された修正を自信を持って進めるか、インシデントの SEV レベルと優先度レベルを必要に応じて変更できます。

初回コミュニケーションの送信

インシデントが実際に発生していることが確認されると、顧客や従業員とのコミュニケーションが最優先になります。Atlassian のハンドブックでは次のように説明しています。

「最初の社内コミュニケーションの目標は、インシデント対応を一元化して混乱を減らすことです。社外コミュニケーションの目標は、チームが不具合の発生を把握して、それを緊急の問題と捉えて解決に向けて行動していることを顧客に伝えることです」

迅速で正確なコミュニケーションは、顧客の信頼の構築と維持に役立ちます。

私たちには戦略的なインシデント コミュニケーション計画があり、簡単なフォーマットに従った定期的なステータス更新を提供します。また、エンジニアリング リーダーシップ、主要インシデント マネージャー、その他の主要な社内スタッフを含む、登録された一連の関係者にメールを送信します。前述のとおり、これらのコミュニケーション方法はすべて Jira Service Management 内でカスタマイズ可能であり、あらゆる組織のインシデント対応計画に合わせることができます。

エスカレーション

オンコール チームによってインシデントが迅速に解決される場合もあります。しかしそうでない場合の次のステップは、特定のインシデントの解決により適した別の専門家または専門家チームに課題をエスカレーションすることです。

Jira Service Management では、対応者は関連するチケットをグループ化し、アラートを調整するためのコラボレーターを課題に追加することができます。また、対応者は、豊富なインシデント タイムラインですべてのアクションを自動的に記録し、自動化やナレッジ ベース記事にアクセスして、インシデントを迅速に調査して修復することができます。

権限委譲

課題が新しい人にエスカレーションされると、インシデント マネージャーは役割をそれらの人に委譲します。Atlassian では、これらの役割は事前に設定されているため、チーム メンバーはそれらの役割に何が期待されているかをすばやく理解できます。

重大なインシデントでは、1 名のインシデント マネージャーと小規模なチームが必要になる場合があります。また状況によっては、複数の技術リードや複数のインシデント マネージャーが必要になる場合もあります。元のインシデント マネージャーは、状況に応じて適切な人員を配置する必要があります。

フォローアップ コミュニケーションの送信

インシデントが進行し続けるにつれて、技術チーム外の別のコミュニケーションによって、顧客と従業員を落ち着かせて信頼を維持し、最新情報を共有できます。コラボレーターが異なるコミュニケーション プラットフォーム間でアラートを管理し、インシデント対応をすべて把握できれば、これは容易なことです。

レビュー

残念ながら、インシデント解決に関しては万能なアプローチはありません。そのため、プロセスのこの段階において、次の事項に時間をかけます。

• 何が起こっているかを観察して、チームとその見解を共有して確認します。
• なぜそれが起こっているのか (そしてそれをどのように修正できるか) についての理論を立てます。
• それらの理論を証明または反証する実験を開発して実行します。
• 繰り返します。

このプロセス全体を通じて、インシデント マネージャーは事態の進行を注意深く見守ります。特定のチーム メンバーの作業負荷が過剰になっていますか? 休憩が必要な人はいますか? 新たな視点を持ち込む必要がありますか? 必要に応じて、より多くの権限委譲が行われます。

ソリューション

当社の Incident Handbook では、解決を「現在または差し迫ったビジネスへの影響が終了したとき」と定義しています。

この時点で緊急対応は終了して、チームはクリーンアップと事後分析に移行します。

事後分析

当社のインシデント ライフサイクルはインシデントが解決された時点で終了しますが、それは Atlassian のプロセスの終わりではありません。また当社は、インシデントの再発を防止するために全力を尽くしたいと考えています。そのため次のステップは、インシデントの原因を特定して将来のリスクを軽減するために設計されている、誰も責めることのない事後分析です。

Jira Service Management で事後分析テンプレートを使用すると、事後分析レポートを簡単に作成し、関連するインシデント タイムラインとともに Confluence にエクスポートできるため、対応者は部門横断型チームと引き続き協力してフォローアップ アクションを追跡して、将来的に同様のインシデントを回避することができます。

役割と責任

役割と責任は、組織の文化、チームの規模、オンコール スケジュールなどによって異なります。重大なインシデントに関する一般的な役割は次のとおりです。

インシデント マネージャー: インシデントの解決を監督する責任者。

技術リード: 何に不具合が発生していて、原因が何かを理解して最善の対応を決定し、技術チームを運営する責任を負うシニア レベルの技術専門家。

コミュニケーション マネージャー: インシデントの影響を受ける社内外の顧客とのコミュニケーションを担当するコミュニケーションのプロ (多くの場合は PR チームまたはカスタマー サポート チーム内)。

カスタマー サポート リード: インシデントに関する受信チケット、電話、ツイートがタイムリーかつ適切に対応されていることを確認する責任を負う人物。

ソーシャル メディア リード: ソーシャル チャネルでのインシデントに関するコミュニケーションを担当するソーシャル メディアのプロ。

その他の一般的な役割は次のとおりです。

根本原因アナリストまたは問題マネージャー: インシデントの解決を超えて根本原因を特定して、将来における課題を回避するために行う必要がある変更を特定する担当者。

重大なインシデント調査委員会: 調査および変更管理を担当するグループ。

Jira Service Management などのインシデント管理ソリューションは、オンコール スケジュールやアラートの整理から、コラボレーション向上のためのチームの統合、インシデントの事後分析の実行まで、対応プロセスを各ステップにおいて支援します。