インシデント対応マニュアルを作ってみた

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井 亮です。

今回はインシデント対応マニュアルについて書きます。
対応しているプロダクトでは、インシデント発生時の対応〜解決はかなりの優先度とエネルギーを持って取り組んでいます。
ただ、個人に依存している部分が大きく、またユーザーに対するケアが不十分であり、改善を思い立ちました。その改善の記録を残します。

きっかけ

なぜインシデント対応を改善しようと思ったのか、と言いますと、とあるクラウドサービスのサービス障害がきっかけです。
ある日そのサービスが24時間ほどダウンしました。我々のプロダクトは直接そのサービスを利用してはいないのですが、プロダクトが利用している外部 API がそのサービスを利用しており、間接的な被害にあいました。
外部 API が無応答になったところで、我々のプロダクトも無応答になってしまいました。ユーザーさんにはご不便をおかけしているのですが、インシデント発生を特に知らせる手段がなくケアができていない状況でした。
もしかしたらユーザーさんにストレスを与えてしまう可能性がありました。
また、開発目線としても、我々の問題ではなくても我々のプロダクトがダウンしていると思われてしまう不幸があります。

用語集

マニュアルの構成を考えてみました。

用語集は必要です。普段から1つのプロダクトを作っているチームメイトとはいえ、用語の定義はブレることはあります。
マニュアルの読み手次第で解釈が異なると、インシデント対応が混乱する可能性があります。
用語集を作り、用語の定義を統一しておくことが大切です。

本書の目的

何のためにマニュアルがあるのか、そもそも何のためにインシデント対応を行うのかを明記します。

ただインシデントを解決するのではありません。コインの裏返しのような対応は好みません。
目的を明記し、メンバーに理解してもらうことでインシデント対応を効果的に行うことができます。

我々のプロダクトの場合は、再発防止とユーザー体験低下の予防を主としているので、その旨熱い想いを込めて記述します。

影響が及ぶ関係者

インシデントの影響が及び関係者を記述します。

影響している人達が誰なのか、ということはインシデント対応の戦略を決めるうえで重要です。

• どこまでを自分たちのインシデントに含めるかの判断になります
• インシデント発生時にリアルタイムに状況を伝える相手は誰なのか明らかにしておきます
• インシデント対応時に連携を取る相手が明らかになります。
• インシデント事後報告が必要な相手が明らかになります。

インシデントの定義

インシデントの定義を記述します。
インシデントと呼ぶイベントは何かということを明確にします。

我々は、ユーザー目線からプロダクトの機能が使えなくなる事態をインシデントとしています。
どのような状況に陥ったらインシデントになるかを記述します。漠然としすぎていても駄目、具体的にしすぎても駄目です。チームメンバーがインシデント対応の行動を起こしやすい抽象度に調整します。

表示ずれや配色の不具合、他いわゆるバグはインシデントに含めないこととしました。バグはバグで粛々と対応します。

インシデントの重要度

インシデントの重要度を定義します。

すべてのインシデントを平等に全力で対応することは良い手段とは思いません。重要度に応じて対応レベルを変えます。
お知らせや Sorry ページの表示、ユーザーへの情報提供、PIR の実施など、重要度によって対応を変えています。

重要度は影響の範囲と時間軸のメトリクスで決定しています。ここはプロダクトごとに異なるところので、プロダクトの特性に合わせて定義します。
我々のプロダクトはユーザーさんがプロダクトを使う日時がある程度限定されています。イベント日にご利用が増える特性を持っているので、イベント日といった時間軸が重要度を決める指標になります。

インシデント対応フロー

インシデント対応フローを記述します。
フローは図を使います。フローチャートが書きやすいと思います。
フロー開始から終了までの流れを図示します。途中、分岐があれば図で示します。

インシデント対応者が漏れなく対応できることが目的です。インシデント対応中は心拍数が上がり、視野が狭まり、判断力が鈍ります。フローを見れば、次に何をすべきか一見できるようにしておきます。

重要度と対応

重要度に応じた対応を記述します。フロー図の文字説明といってもいいかもしれません。

重要度ごとの登場人物、コミュニケーションチャンネル、お知らせ有無、PIR 有無などを記述します。
繰り返しですが、すべての重要度を全力で対応する必要はありません。それをここで定義します。

ユーザーへのインシデント情報提供

ユーザーさんへのインシデント情報提供方法やタイミングを記述します。
インシデント情報提供は重要度 =「高」に限りました。ここもプロダクトごとの判断になると思います。
ステータスページのようなものを作るのか、メールや SNS で通知するのか、Sorry ページのようなものを表示するのか、様々な手段があると思います。
何れにしてもユーザーさんのストレスを軽減するためにインシデント情報を提供します。

インシデント中のコミュニケーションチャンネル

各関係者とのコミュニケーションチャンネルを記述します。

インシデント発生時に慌てないように関係者ごとのコミュニケーションチャンネルを明記します。
担当者名と同時に、メールであればメールアドレス、Slack であればチャンネル名と Slack 表示名を記述します。

ここも重要度に応じて連絡先を定義します。重要度が低ければチームメンバーのみ、高ければ広範囲な関係者といった具合です。

チーム外へ連絡をする場合では、連絡係を1人に絞ることが効果的です。情報錯綜による混乱を避けるためです。

ライブインシデントドキュメント

インシデント中のすべてのイベント（作業、デプロイ、変更、メトリクスの変化、内外コミュニケーションの結果）を記録する手段・方法を記述します。

複数人が同時に編集できるドキュメントを用意します。Google Docs や Notion などが使いやすいと思います。Slack チャンネルでもいいかもしれません。

現在進行しているインシデント状況の把握に役立ちます。対応にあたる関係者全員が参照・編集できるドキュメントにすることで、異なる変更を同時に行うことを防止できます。
複数人の考察を得ることで解決が早まる可能性が高まることもあるでしょう。行動の共有はインシデントコマンダーの意思決定の正確さにも影響すると思います。

また、PIR のドキュメントに流用することもできます。効率化と正確性を実現できます。

インシデント中の役割

インシデント中の役割を記述します。

役割を明記することで、すべての関係者が自分の役割を理解し全うします。また、他人の領域に踏み込まないよう注意書きをしておくことも大切です。
インシデントコマンダー、コミュニケーション係、技術者、ユーザーサポート、マネージャーなど、インシデント中に必要な役割と期待するタスクを記述します。
個人への過度な負荷を避けるために、インシデント対応負荷が高まった場合に申告可能な旨も記述します。
インシデントコマンダーにスタッフ増員の権限を与えておくことと安心だと思います。

Post Incident Review (PIR) の実施

発生してしまったインシデントを無駄にはしないように、将来のインシデント対応力を向上させ、継続的改善に努め、フィールバックループの好循環を作るために PIR を実施します。

Correction Of Error (COE) 文書を作成し、PIR の成果を残します。COE 文書には根本原因を分析し今後の再発防止に活かすことが目的です。
また、知識をチームのものにするためにも必要です。
すべてインシデントで COE 文書を作成することは考えません。重要度に応じて COE 文書を作成するかどうかを決定します。
COE 文書はインシデント対応終了後すぐに作成します。人々の記憶が薄れる前に、メトリクスやログが消失する前に情報を収集します。

COE 文書テンプレート

COE 文書はテンプレートを用意しておいて、コピーしてすぐに作成できるようにしておきます。

• 要約
  • インシデント全体を完結に説明するもの
  • 誰が、いつ、どこで、どのように影響を受けたのか？
  • アプリユーザー体験にどのような影響があったのか？
  • 問題をどのように軽減したか
  • 再発防止策をどのように講じるか
• 影響範囲
  • アプリユーザーや関係者、ビジネスにどのような影響があったのかを定量化して説明するもの
  • 影響を受けたユーザー数は？
  • 具体的な影響は？
  • どのような非機能要件が影響を受けたか？
• タイムライン
  • インシデント中に発生したあらゆるイベントを時系列で表現
  • 時系列はインシデント対応を開始した時刻ではなく、インシデントの最初のきっかけから記述する
  • 時系列のタイムゾーンは JST で記述する
  • 時系列は明確に連続しているものでなければならない。読んだ人にストーリーを伝えることが目的
  • データによる裏付けを可能な限り含める
• メトリクス
  • インシデントから回復を示すメトリクスを取得する
  • メトリクスをグラフ化する場合は、時間軸は JST を使用する
  • メトリクスを取得できていない場合は、後述のアクションアイテムでメトリクスを追加するタスクを設定する
• インシデントに関する質問
  • インシデントが発生したことをどのように知ったか？
  • インシデントの根本原因は何だったか？
  • インシデント前にシステム変更（リリース、デプロイを含む）はあったか？
  • アプリユーザーへの影響が緩和され、インシデント前に戻ったのはいつか？
  • 問題があった場所の特定と復旧方法をどのように決定したか？
  • 復旧をどのように判断したか？
  • どうすれば復旧までの時間を短縮できるか？
• アクションアイテム
  • 改善するための活動を明確にする
  • 将来同じ問題を発生させない予防、根本原因の解決
  • Notion データベースにアクションアイテムを登録し、担当者、期限日を設定する
• 関連アイテム
  • この COE に関連するアイテムをリンクする
  • 他の COE や Notion 上のエピックやタスクなど

関係者の合意

インシデント対応は関係者の合意が必要です。インシデント対応マニュアルを作成したら、関係者に共有し、対面またはオンラインでレビューし、合意を取ります。

参考

Goole SRE Book Chapter 9 - Incident Response
AWS Well-Architected フレームワーク - オペレーショナルエクセレンスの柱 - イベントへの対応
PagerDuty - 「システム障害」についてもっと知ろう！