はじめに

Credit: Breakingpic @ Pexels

まだ組織に決まったプロセスが無かったり、作り始めようとしているのなら、このドキュメントに圧倒的な情報量があることでしょう。 これは一晩で実装できないということを覚えておいてください。 これは時間をかけて築き上げるべきプロセスです。 この時点まで何年もかかりましたが、このドキュメントによって私たちが遭遇した苦難や、可能な限り効率化した成熟したインシデント対応に到達できることを祈ります。

そのためにも、このガイドをまとめて、私たちの最も大事な部分を案内し、あなたがどこから始めるべきかのガイドラインを提供します。 もし独自のインシデントプロセスを始めているのなら、このドキュメントはどこから始めるべきかを知るための素晴らしい方法です。

あなたにとっての「インシデント」と「重大インシデント」を定義する#

あなたは、私たちの定義を使い必要はありません。 これは単なる出発点です。 あなたが必要だと思うもでよいです。 重要なのは、全員が同じ認識を持てるように、この定義が短くシンプルな文章であることです。 インシデント対応プロセスの間は、何がインシデントで何がインシデントが無いかの議論はしないでおくべきです。 もしメトリクスを使う（例えばエラー率が100/min.を超えると重大インシデントである）のならそれは素晴らしいことです。 もしそうでないなら、何がインシデントかの定義を止めないでください。

これが最初のステップである理由は、インシデントとは何なのかを知るまではインシデントに対応できないからです。 たとえば誰かがインシデントとみなしていても、他の人がインシデントではないとします。 これはインシデント対応中に曖昧さと混乱を招きます。 組織全体で明確な定義を組織全体に広げることで、全員が同じ理解を持つことができ、混乱を防ぐことができます。

対応者を動員する方法を決める#

なにがインシデント対応プロセスをトリガーしますか？ メトリクスに基づく自動アラートですか？ それは始めるのにとてもよいです。 たとえそれが、応答社のグループに通知される単一のアラートであっても。

インシデント専用のWeb会議とチャットルームを設定しておいてください。 これを事前に準備して、応答する必要がある人たちに共有しておきます。 インシデントに対応しようとしているときには、通話とチャットルームの設定はしたくありません。 通話とルームの名前は静的にしておくか、簡単に見つけられる必要があります。

また対応者への期待があります。 ページを受け取ったときは、単に問題を解決するためだけに飛び込むのではなく、通話やチャットルームに参加する必要があります。

最後に、アラートには実行可能なアクションがあることを確認します。 なにか制御ができないことに対して、全員が起こされることは避けたいです。 インシデント対応のトリガーとページは、即座に人が対応できるもののみに対して実行される事を確認してください。

インシデント対応の役割を定義#

まずはじめはインシデントコマンダーを気にするだけで大丈夫です。 十分な人数がいるのなら、記録係も割り当てる事ができます。 しかし始めは、インシデントコマンダーと対応者で十分です。 インシデントコマンダーは復旧アクションを実行するのではなく、対応をリードして意思決定するだけです。 初めはトレーニングガイド全体に従う必要はありません。 基本的な質問をして、タスクを割り当てるだけで十分です。

ポストモーテムテンプレートを作る#

私たちのテンプレートを利用して始めるか、独自のバージョンから始めることができます。 構造化されたテンプレートを用意することで、それぞれのインシデントの比較が簡単になります。 まず最初は「何が発生したか？」「なぜ発生したか？」「再発防止のためにはどうすればよいか」の3つの見出しがあるものから始められます。 あとから必要に応じて詳細なフィールドと情報を追加できます。

練習#

偽のインシデントを実行し、対応者を動員して、誰かにインシデントコマンダーとして行動してもらいます。 日々の業務からの切り替えや、インシデントの緊急的なオペレーションに慣れます。 最初は主導権を握るインシデントコマンダーの切り替えに戸惑うかも知れないので、リスクの低い状況で練習すると良いでしょう Keep Talking and Nobody Explodesというゲームは、インシデント対応スキルを練習するお手軽な方法です。 また独自のFailure Failureも実行できます。 これはシステムに何らかの障害を手動で注入して、それを重大インシデントとして扱います。

実際のインシデントで利用する#

基本ができれば、このプロセスを実際のインシデントに利用します。 使えば使うほど、より自然になります。 使い続けるに連れ、必要に応じてプロセスを追加したり調整ができます。 最初はスムーズに進まないかも知れませんが諦めないでください。

次に何をするか？#

あなたのプロセスの拡張や、いくつかの追加ができます。 次に取り入れるべき推奨事項がいくつかあります。

記録係の追加#

正確なイベントのタイムラインの記録は、インシデントを振り返ったりレビューする時に重要になります。 記録係は次に追加すべき役割です。

インシデントコマンダーのローテーション#

1人のインシデントコマンダーだけではなく、より多くの人が必要になります。 さらに多くの人にトレーニングをして、オンコールのローテーションを組みます。 最初は週ごとのローテーションでよいでしょう。 できるだけ早く、日ごとのローテーションが開始できるようお勧めします。

補佐の追加#

インシデントコマンダーが複数人いれば、対応の補佐を追加できます。 補佐がいると、長時間に及ぶインシデントを委譲でき、短いインシデントでもインシデントコマンダーのバックアップができます。

深刻度の定義#

プロセスが正常に機能したら、応答とインシデントの定義にさらに詳細な情報を追加できます。 おそらく特定のインシデントに対して「完璧な」対応はしたくないでしょう。 必要な対応レベルを文書化できるように、深刻度レベルを定義しましょう。

他の役割の追加#

プロセスが確立してくると、他の役割も追加してみましょう。 まずは顧客連絡を追加することをお勧めします。

練習、練習、そして練習#

インシデント対応対応の練習は役立つと行っても過言ではありません。 もしインシデント対応をトリガーしてしまって、もし本当のインシデントでは無いとわかっても、本当のインシデントとして扱えます。 すでに対応者を動員してしまってるので、自由に練習できます。

より大きなインシデントに対するプロセスを定義#

私たちは複雑なインシデントと呼んでいます。 これは頻繁には使用しませんが、事前にWeb会議とチャットルームを用意しておく必要しておきましょう。 また対応者がプロセスを理解していることも確認しましょう。