Close

インシデント管理改善への道はここから始まります

The 7 stages of effective incident response

インシデント対応とは、サイバー攻撃、セキュリティ侵害、サーバーのダウンタイムなどの IT の脅威に対応する組織のプロセスです。

Other IT Ops and DevOps teams may refer to the practice as major incident management or simply incident management.

次のセクションでは、Atlassian 独自の Incident Handbook 内の資料に基づいて、インシデント対応プロセスについてと、サービスの停止に気付いてからサービスを再起動するまでにすべきことについてを説明します。

この記事では、インシデント対応の 7 つの主な段階について説明します。

  1. インシデントを検出する
  2. チームのコミュニケーション チャンネルを設定する
  3. 影響を評価して、重大度レベルを適用する
  4. 顧客とのコミュニケーション
  5. 適切な対応者にエスカレートする
  6. インシデント対応ロールを委任する
  7. インシデントを解決する
インシデント対応ワークフロー

インシデントを検出する

できれば、モニタリング ツールとアラート ツールにより、顧客が気付く前にインシデントが検出されてチームに通知されることが理想です。しかし、Twitter やカスタマー サポートのチケットからインシデントについて最初に知ることもあります。

インシデントがどのように検出されようとも、最初のステップは、インシデントを追跡するツールに、新しいインシデントが未解決であることを記録することです。これは、Opsgenie Enterprise のような Ops 固有のツールや、Jira のようなより広範な追跡ツールの場合があります。

チームのコミュニケーション チャンネルを設定する

インシデント マネージャー (IM) がオンラインに参加したときの最初の重要なステップの 1 つは、インシデント チームのコミュニケーション チャンネルを設定することです。この時点での目標は、すべてのインシデント チームのコミュニケーションを、次のようなわかりやすい場所に確立して集中させることです。

  • Slack または別のメッセージ サービス内のチャット ルーム
  • Zoom などの会議アプリ内のビデオ チャット (または、全員が同じ場所にいるのであれば、実際に会議室に集まってミーティングを行います)

ビデオ チャットとテキスト チャット ツールは別々の用途で優れているため、Atlassian では、インシデント中にこの両方を使用するのが望ましいと考えています。ビデオ チャットは、グループ ディスカッションを通じてインシデントについての共通イメージを作り出すことに優れています。Slack は、タイムスタンプ付きのインシデントの記録と併せて、スクリーンショット、URL、ダッシュボードへのリンクのコレクションを生成することに活用できます。

Slack やその他ほとんどのチャット ツールでは、ルームのトピックを設定できます。インシデント マネージャーは、インシデントに関する情報と便利なリンクのためにこのフィールドを使用する必要があります。

最後に、IM 自身のチャット ステータスを、管理中のインシデントの課題キーにセットします。これで、同僚は IM がインシデントの管理にあたっていることがわかります。

影響を評価して、重大度レベルを適用する

インシデントチームのコミュニケーションチャンネルが設定された後は、インシデントを評価する時間です。それによって、チームはスタッフにインシデントについて何を話すか、誰が修正するかを決定します。

IM からチームに行う質問をまとめて示します。

  • 顧客への影響は何か(内部または外部)?
  • 顧客には何が起こっているか?
  • 何人の顧客が影響を受けているか(一部、全員)?
  • いつ開始したか?
  • サポートケースはいくつ開いているか?
  • Twitter、セキュリティ、データの損失など、その他の要因はあるか?

次のステップは通常、重大度レベルの割り当てです。

インシデント対応の重大度レベル

重大度 1
説明: 非常に大きな影響がある重大なインシデント
例:

  • 顧客向けサービスの 1 つが、すべての顧客でダウンしている
  • 機密情報やプライバシーが侵害された
  • 顧客データの損失

重大度 2
重大な影響がある深刻なインシデント
例:

  • 顧客向けサービスの 1 つを一部の顧客が使用できないが、すべての顧客が使用できないわけではない
  • コア機能が重大な影響を受けている

重大度 3
影響の少ない軽微なインシデント
例:

  • 顧客が少し不便だと感じているが、回避方法がある。
  • 使用可能なパフォーマンスが低下。

重大度レベルに番号付けシステムを使用すると、インシデントを素早く特定して伝達できます。誰かが「SEV 1 が発生している可能性がある」と言うだけで、それ以上の情報が得られていなくても、適切な人々が問題の重大さをすぐに理解できます。

また、重大度レベルは、対応の予測に対するガイドラインの作成にも役立ちます。

たとえば、一部の企業では、重大度 3 のインシデントは営業時間内に対応できますが、重大度 1 と 2 の場合はただちに修正する必要があるため、チーム メンバーを呼び出す必要があります。

インシデントの重大度の定義は、文書化して組織全体で一貫性を持たせる必要があります。

顧客とのコミュニケーション

インシデントが本物であることをチームで確認したら、できるだけ早く社内外の関係者に伝えなければなりません。

社内コミュニケーションの目標は、インシデント対応を一元化して混乱を減らすことです。

社外コミュニケーションの目標は、チームが不具合の発生を把握して解決に向けて行動していることを顧客に伝えることです。迅速かつ正確に伝えることで、顧客や組織のその他の関係者との信頼関係を築くのに役立ちます。

多くのチームが、社内外の両方とのインシデント コミュニケーションに Statuspage を使用しています。社内外の Statuspage を更新するための 2 つの簡単なテンプレートを次に示します。

社内の Statuspage
<インシデント課題キー> - <重大度> - <インシデントの概要>

<製品 x>、<製品 y>、<製品 z> に影響を与えているインシデントについて調査中です。間もなくメールと Statuspage で最新情報を提供する予定です。

社外の Statuspage
<製品> の課題を調査する

<製品> の課題を調査しています。間もなくこちらで最新情報を提供する予定です。

適切な対応者にエスカレートする

最初の対応者はしばしば、インシデントを受け取った人物になります。このような対応者がさらに Opsgenie などのアラート ツールを使用して他のチームに通知し、インシデントに他のチームを参加させる必要があります。

アラート ツールを使用すると、チームはオンコール当番表を定義して、インシデント中に連絡がつくと予想されるスタッフのローテーションを作成できます。この方が、インシデントが起こるたびに特定の人に頼るより効率的です。ただし、同じ人が常に対応可能であるとは限りません (休暇を取得したり転職したりすることがあり、呼び出しが多すぎれば消耗します)。

インシデント対応ロールを委任する

新しいインシデント対応者が呼び出されてオンラインに参加したら、インシデント マネージャーがこれらの対応者にロールを委任します。これらの対応者は、そのロールに求められていること、およびインシデント チームに迅速かつ効果的に貢献する方法を理解することが重要です。

ロールを定義するもう 1 つのメリットは、適応性と柔軟性が向上することです。スタッフが特定の役割で何をすべきかを知っていれば、どのようなインシデントでもその役割を担当できます。

3 つの主要なインシデント対応ロール

インシデントマネージャー

インシデントごとに、当該インシデントに対する全責任と権限を持つインシデント マネージャーを配置します。

インシデント マネージャーには、インシデントを解決するのに必要な行動を取る権限が与えられています。組織内の任意のスタッフを呼び出し、可能な限り迅速にサービスを復元させることにインシデントに関わるメンバーを集中させる権限も含まれます。

テック リード

上級技術対応者です。テック リードは、何がどのような理由で壊れたのかに関する理論を発展させ、変更を決定し、技術チームを指揮します。この人物は、インシデント マネージャーと緊密に連携します。

コミュニケーション マネージャー

パブリック コミュニケーションに精通している人が担当します。カスタマー サポート チームや広報のスタッフが担当する場合があります。インシデントについて、社内外のコミュニケーションを作成して送信する責任があります。

インシデントを解決する

すべてのインシデントを解決できる万能のプロセスは存在しません。もしそのようなものがあれば、それを自動化して実行していたでしょう。Atlassian ではその代わりに、科学的方法からインスピレーションを得ています。さまざまなインシデント対応シナリオに迅速に適応するために、以下のプロセスを繰り返し適用しています。

  • 何が起こっているのかを観察します。見解を共有し確認します。
  • 起きている理由に関して、理論を発展させます。
  • それらの理論を証明または反証する実験を開発して実行します。
  • インシデントが解決されるまで繰り返します。

現在または差し迫ったビジネスへの影響が終了したら、インシデントが解決したと言えます。その時点で緊急対応プロセスは終了して、チームはクリーンアップ タスクと事後分析に移行します。

インシデントが解決されたら、最終的な社内外のコミュニケーションを送信します。社内コミュニケーションでは、インシデントの影響と継続時間の振り返りを記載します。何件のサポート ケースが提出されたかなど、その他のインシデントの重要な側面を含みます。インシデントが解決したこと、これがこのインシデントについての最後のコミュニケーションであることをはっきりと示します。通常、社外コミュニケーションは簡潔に済ませます。サービスが復元されたこと、事後分析でフォロー アップをすることを顧客に伝えます。

次の記事
Postmortems