Getting Started

自組織にまだプロセスがない場合や、始めたばかりの場合、このドキュメンテーションの膨大な情報量に圧倒されるかもしれません。重要なのは、これは一晩で実装できるものではないということを覚えておくことです。これは時間をかけて構築されるべきプロセスです。私たちがこの段階に到達するまでに何年もかかりましたが、このドキュメンテーションを利用して、私たちが経験した厄介な成長の痛みのいくつかをスキップし、もっとも効率的な方法でより成熟したインシデント対応プロセスに到達できることを願っています。

そのために、私たちのプロセスのもっとも重要な部分をナビゲートし、どの部分から始めるべきかについてのガイドラインを提供する「はじめに」ガイドを作成しました。自社のインシデント対応プロセスを始めたばかりの場合、これは私たちが考える順序を知るための素晴らしい方法です。

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

必ずしも私たちの定義を使う必要はありません。それらは単なる出発点です。自由に自分たちの望むものを考え出してください。重要なのは、定義が短く簡潔な文で、全員が同じ認識を持てるようにすることです。目的は、対応プロセス中にそれがインシデントかどうかについての議論を排除することです。使用する指標がある場合（例：「エラーが1分間に100を超えたら重大インシデント」）、それは素晴らしいことです。ない場合でも、重大インシデントの定義を妨げるものではありません。

これを最初のステップにすべき理由は、インシデントが何であるかを知るまでインシデントに対応できないからです。ある人がそれをインシデントと考えても、組織の残りの人々がそう考えない場合、インシデント対応中に曖昧さと混乱を生み出します。明確な定義を組織全体に周知することで、全員が同じ理解を持ち、混乱を防ぐことができます。

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

何があなたのインシデント対応プロセスをトリガーしますか？指標に紐づいた自動アラートですか？それは素晴らしい出発点です。たとえ対応者のグループに送信される単一のアラートだけでも。

インシデント対応専用の電話会議とチャットルームを設定してください。これを事前に準備し、番号と接続情報を書き留めて、対応が必要な可能性のある人全員と共有してください。インシデントに対応しながら通話とチャットルームを設定したくはありません。通話とルーム名は静的にするか、できるだけ簡単に見つけられるようにしてください。

また、対応者に期待することを設定する必要があります。ページを受け取ったら通話とチャットルームに参加する必要があること、そして問題の解決に飛び込むべきではないことを確認してください。

最後に、アラートが実行可能であることを確認してください。制御できないことで全員を起こすほど悪いことはありません。インシデント対応をトリガーし、担当者を呼び出すものは、解決するために即時の人間の行動が必要なものであることを確認してください。

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

始めはインシデントコマンダーの役割だけを気にすればよいでしょう。十分な人数がいれば、書記も置くことができます。しかし、始めはインシデントコマンダーと対応者だけで十分です。インシデントコマンダーは修復作業を一切行うべきではなく、対応をリードし、決定を下すだけです。最初はトレーニングガイド全体に従う必要はありません。質問をし、タスクを割り当てるという基本だけで始めるのに十分です。

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

始めるには私たちのテンプレートを使用するか、独自のバージョンを考え出すことができます。インシデント同士を比較しやすくするために、構造化されたテンプレートがあることを確認してください。始めは以下の3つの見出しだけでも十分です：

1. 何が起こったか？
2. なぜそれが起こったのか？
3. 再発を防ぐためにどうするか？

より詳細なフィールドと情報の追加は後で行うことができます。

練習する#

偽のインシデントを実行し、対応者を動員し、誰かにインシデントコマンダーの役を演じてもらいます。通常の日常業務からインシデントの緊急業務への切り替えに慣れてください。インシデントコマンダーが指揮を執る状況に切り替わるのは最初は戸惑うかもしれないので、低リスクの状況で練習するのが役立ちます。

「Keep Talking and Nobody Explodes」というゲームをプレイすることは、インシデント対応に必要なスキルを練習する手軽な方法です。また、Failure Fridayの独自バージョンを実行することもできます。システムに手動で何らかの障害を注入し、それを重大インシデントとして扱います。

実際のインシデントに使用する#

基本を整えたら、実際のインシデントにプロセスを使い始めることができます。使用すればするほど、より自然になっていきます。使用を重ねるにつれて、より多くのプロセスを追加し、必要に応じて調整できます。最初はスムーズに行かないかもしれませんが、諦めないでください！

次は何をすべきか？#

これで、プロセスを拡張し、さらに多くのことを追加し始めることができます。次に取り入れるべきことについての私たちの推奨事項は以下の通りです：

まだ導入していない場合は書記を追加する#

イベントの正確なタイムラインを保持することは、インシデントを振り返る際に非常に重要になります。書記は次に設置すべき役割です。

ICのローテーションを拡大する#

単一のICだけでなく、できるだけ多くのICを持ちたいでしょう。より多くの人々のトレーニングを開始し、オンコールローテーションを作成します。最初は、おそらく週単位のローテーションを使用するでしょう。できるだけ早く日単位のローテーションに移行することをオススメします。

副官を役割として追加する#

ICが数人増えたら、対応に副官を追加し始めます。副官を持つことで、長期のインシデント中に迅速に引き継ぐことができ、また短期のインシデントでもICのバックアップとなります。

重大度レベルを定義する#

プロセスがうまく機能し始めたら、対応とインシデントの定義にさらに細かい粒度を追加し始めることができます。みなさんはおそらく特定のインシデントに対して「完全な」対応を行いたくないでしょう。望む対応レベルを文書化するために重大度レベルを定義します。

他の役割を追加し始める#

プロセスがより確立されてきたら、他の役割を追加たくなるでしょう。次に含めるべき役割として顧客リエゾンをオススメします。

練習、練習、練習#

インシデント対応の練習がどれほど役に立つかは、いくら言っても言い過ぎではないでしょう。インシデント対応をトリガーし、実際にはインシデントではないと気づいた場合でも、それをインシデントとして扱います。すでに対応者を動員しているので、実質的に、そのまま練習として活用できます。

より大規模なインシデントのためのプロセスを定義する#

私たちはこれを複雑なインシデントと呼んでいます。頻繁に使用することはありませんが、電話会議の番号とチャットルームを事前に準備しておきたいでしょう。また、対応者がプロセスを認識していることを確認する必要があります。