インシデント対応を標準化するテンプレート活用事例

この記事は 株式会社ログラス Productチーム Advent Calendar 2024 のシリーズ 2、14日目 の記事です。

はじめに

本記事においてのインシデント対応は、組織において発生したセキュリティインシデントやシステム障害などの事象に対し、影響範囲の調査、復旧作業、お客様への通知などを迅速かつ効果的に対処するためのプロセスや活動を指します。

課題感

インシデント対応においてよくある課題として、以下のような声を聞くことがあります。

• ビジネスサイド
  • 作業中に誰が何をやってるか分からない
  • いつ、何が起こったのかを知りたい
• エンジニアサイド
  • 後から振り返るときに情報を探すのが大変
  • 必要な作業がパッと分からない

インシデント対応の課題は、単なる業務負担以上に、プロダクト全体の信頼性やユーザー体験にも影響を与えます。
こうした課題を解決すれば、インシデント対応の効率化だけでなく、チームの心理的負担も軽減されます。
インシデントが起きないようにすることが最も重要ではあるものの、上記のようなインシデント対応そのものに関する課題もあることから、インシデントが起きてしまったときの対応フローも改善すべきです。

インシデント対応用テンプレートの作成

インシデント対応時に作成する作業記録資料のテンプレートとして以下のようなものを運用すると効率的に対応を進めることができます。ベタなやり方ではありますが、テンプレートを用意することで、誰がどのような作業が必要なのかを大まかに把握することができますし、どういった情報を記録に残せばいいのかがわかりやすくなります。
以下が実際に作成したテンプレートのイメージです。

# 概要
* ビジネスサイドからお客様に共有するための情報や、エンジニアサイドがポストモーテム時などに参照できる情報をまとめます
* 「後から振り返るときに情報を探すのが大変」といった課題に対応します

## 作業ステータス
<調査中 / 復旧作業中 / 完了>
* 現在対応中なのか、完了しているのかといったステータスを共有するために記載します

## 事象
* ユーザがどのような操作をすると何が発生するのか、を記載します

## 影響範囲
- 影響のあるお客様
    - 株式会社A様
    - 株式会社B様
- 対象機能
    - xxx
* どの機能、どのお客様で事象が発生するのか、発生する可能性があるのかをまとめます

## 原因
* 事象が発生する原因を記載します

## 回避策
* システムの変更を加えない状態で、事象を回避する方法があれば記載します

## 暫定対応
* すぐに対応できる復旧対応案を記載します
* 例えばアプリケーションコードの修正や、DBレコードの修正などです

## 恒久対応
* 中長期的な改善案を記載します
* 例えば運用フローの改善、テスト観点の見直しなどです

## 関係者
- インシデントコマンダー
- 調査担当
- カスタマーサクセス担当
* 役割ごとにバイネームで担当者が誰かを記載します
* 「作業中に誰が何をやってるか分からない」といった課題に対応します

## 時系列ログ
| 日時　　　　　　　　| 概要 | リンク |
| ----             | ----   | ---- |
| yyyy/mm/dd hh:mm | リリース | link |
| yyyy/mm/dd hh:mm | 検知 　　| link |
| yyyy/mm/dd hh:mm | 影響調査 | link |
| yyyy/mm/dd hh:mm | 復旧作業 | link |
| yyyy/mm/dd hh:mm | 復旧完了 | link |
* 何時何分にどのような出来事があったかを記載します
* リンクにはSlackのチャットや関連資料など、エビデンスとなる情報のURLを記載します
* 「いつ、何が起こったのかを知りたい」といった課題に対応します

## 関連Slackリンク
* 作業時に利用したSlackのリンクを貼り、後からどのようなやり取りがあったか辿れるようにします

# 作業手順
* 主にエンジニアサイド向け作業のチェックリストです
* これによりどのような作業が必要か、どこまで作業が完了しているのかを確認します
* 「必要な作業がパッと分からない」といった課題に対応します

## 検知・起票
担当：インシデントコマンダー
- 障害レベルの判定
- 担当者を決める
- 起票する
- 障害かどうかを判定する
- 関係者に報告する
- （調査進み次第）障害レベルの再判定

## 顧客通知
担当：カスタマーサクセス担当
- 影響のあるお客様へ一次連絡
- 調査担当の調査完了後、原因、対応方法、復旧目処をお客様へ連絡

## 調査
担当：調査担当
- 原因調査
- 影響範囲調査
- 対応策の検討
調査メモ

## 復旧対応
担当：調査担当
作業記録

## ポストモーテム準備
担当：インシデントコマンダー
- ポストモーテムページの作成

上記はNotionの利用を想定したテンプレートとして作りましたが、G Suite, Microsoft 365, Confluenceなど他のツールでも応用可能と思います。
インシデントを検知したらまずはテンプレートを元に起票して、それをベースに動くことにします。
必須の作業は共通化し定常業務にできます。
ただしテンプレートを一方的に決めるのは効果的でない可能性があります。
例えば誰も使わない、役にたたないものになってしまうことが考えられるからです。
ビジネスサイドが求める情報を提供できているのか。
エンジニアサイドが使いやすい状態になっているのか。
少なくとも利用する人には過不足ないか確認する必要がありますし、実際に利用しないと見えないものもあります。
テンプレートの叩き台を作成した後は、ビジネスサイド・エンジニアサイドの関係者に確認してもらい、その後プロダクト関係者全体に周知するとよいでしょう。

テンプレート運用後に感想などヒアリングし、活用できているかを確認することもできるとテンプレート自体のブラッシュアップのヒントを得ることができます。自身でもテンプレートを使った対応を経験した後で、改善点がないか見直すとよいかと思います。

結果

テンプレートを利用したとしても、インシデント対応の大変さがなくなることはありません。
冒頭にあげたように急を要する状態での調査、調整を行うのは負担がかかるものです。

とはいえ最低限必要な情報は何か、ということは明らかなのでテンプレートをひとまず埋めていけば情報をまとめて共有出来るようになります。
またポストモーテムの際においてもこのテンプレートに沿って対応のログを書き留めていけば、Slackの情報や調査メモを見返して新たに資料を作成するコストを減らすことができます。また、テンプレート化することで、テンプレートに記載しきれていなかった作業フローがあることに気付くなど、まだまだ改善の余地の発見もあるかと思います。

本記事はインシデント対応に絞った記事ですが、実際にはインシデントを予防するような取り組みからポストモーテム、ネクストアクションといった一連のフローを改善し、システムの品質を向上することが必要です。
また、こういったインシデントを取り巻く活動については以下の書籍も参考になります。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

この記事を通じて、皆さんのインシデント対応が少しでもスムーズになれば幸いです。ぜひ、テンプレートを自分たちの形にカスタマイズして試してみてください！
より高品質なシステムを目指して一緒に頑張りましょう！