インシデント対応しながら書くポストモーテム
このエントリーは 3-shake Advent Calendar 2022 8日目の記事です。
サービスにおいてインシデントが発生した場合に書くポストモーテムについて，書く負担を減らせるようなテンプレートを提案します。
ポストモーテムのテンプレート
ポストモーテムのテンプレートは，例えば以下のようなものが公開されています。
Google SRE
- タイトル・インシデント ID
- 日付
- 対応者
- ステータス
- 概要
- 影響
- 主な原因
- 障害発生のトリガー
- 解決策
- 検知
- アクションアイテム
- 学んだ教訓
- うまくいったこと
- うまくいかなかったこと
- 運が良かったところ
- タイムライン
- 補足情報
PagerDuty
- 概要
- 起きたこと
- 原因
- 解決策
- 影響
- 対応者
- タイムライン
- 振り返り
- うまくいったこと
- うまくいかなかったこと
- アクションアイテム
課題感と動機
私が担当しているプロジェクトでは PagerDuty のテンプレートをベースにポストモーテムを書いていました。
何度か書いているうちに以下のような課題を感じました。
- インシデントが落ち着いて，後日ポストモーテムを埋めるのに手間がかかる。
- 細かいところは忘れてしまって何を書けばいいかわからなくなる。
- PagerDuty のテンプレートでは「概要」と「起きたこと」をどう書き分けたらよいかわからない。
そこで，インシデント対応とポストモーテムを一つにしてしまおうというアイデアが浮かびました。
インシデント対応が終了したら，そのままポストモーテムとして使えるので，便利になります。
またインシデント対応の項目については，項目に従って書けば自然と原因特定ができるようにしたいと思い，簡素化・明確化してテンプレートに盛り込みました。
ポストモーテムのテンプレート案
以下の内容のテンプレートを作っておき，インシデント発生時に同時に共同編集できるツールを使って関係者が記入して情報を集約する使い方を想定しています。
また，インシデントが解決したら，後日残りの項目を埋めて，振り返り会などを実施してレビューする想定です。
状況把握
- 現象
- 該当するアラート・ログとその意味
- 影響範囲
- 指揮官
原因調査
- 切り分け（Web ならフロントエンドからたどってどこに問題がありそうか？）
- 仮説・試したこと（ここが原因かもしれないと仮説を考えて，調べてみて，結果どうだったか？）
| 提案者 | 仮説 | 結果 |
|---|---|---|
| （名前） | （原因の仮説についての説明） | （仮説を検証した結果） |
- 結論
対処
（インシデントを解消するために実施した内容）
タイムライン
- アラート発生
- インシデント宣言
- 原因判明
- 復旧
（以下は後日書く。）
振り返り
- よかったこと
- 改善点
アクション
- （アクションアイテム）
実際に使ってみた結果
このテンプレートを使って実際にポストモーテムを書いた・書いてもらった結果を振り返ります。
後日のポストモーテムの記入
インシデント対応が落ち着いて，後日ポストモーテムを書き始めるときにすでに半分書けているのは，精神的にも手間的にも楽でした。
負担が小さくなったので，当日の対応者が書き上げるだけでなく，振り返り会で全員で記入する使い方もできます。
当初の主な課題感は解消されました。
振り返り会
インシデント発生当日に直接対応に関わらなかったメンバーも，後日の振り返り会ではポストモーテムに書かれた当時の生の情報に触れることになり，当事者意識が生まれやすくなりました。
これにより，当日対応の有無に関わらず，建設的な意見を出すことができました。
切り分け・仮説
インシデント対応時に原因特定に役立つ箇所についてです。
仮説検証の表は毎回使われていました。
表形式のテンプレートをパッと見て意図が分かり，すぐに活用できたと思われます。
一方，切り分けが利用されるかどうかは，対応者・ケースによってまちまちでした。
切り分ける範囲はインシデントの内容によって異なるのでテンプレート化しづらく，対応者がその場で考えて補足しなければなりません。切り分け範囲が思い浮かばない対応者はサポートする必要があります。
ここは改良の余地がありそうです。
まとめ
インシデント対応時にも使えるポストモーテムのテンプレートを紹介しました。
障害報告書のようなかっちりとした書式が決まっている組織では使いづらいですが，ポストモーテムを気軽に始めてみたいプロジェクトでは使えるかもしれません。
Discussion