ガバメントクラウドチームではポストモーテムの雛形として、Googleが「Site Reliability Engineering」の書籍で紹介している「ポストモーテムの例」を自分達用にカスタマイズしたものを雛形として利用している。

• Table of Contents
  https://sre.google/sre-book/table-of-contents/open_in_newOpens in new tab
• Example Postmortem
  https://sre.google/sre-book/example-postmortem/open_in_newOpens in new tab

ここでは参考として、ガバメントクラウドチームで利用しているポストモーテムの雛形を公開用に汎化したものを記載する。ガバメントクラウドチームでは、インシデント対応の初期からこのポストモーテムの雛形を活用し、対策チーム内外の関係者間の情報共有を図っている。

インシデント対応中は、即時性と関係者内の情報共有を重視し、「12. タイムライン」とインシデントの概要把握のための「1.エグゼブティブサマリー」の更新を中心に更新を行う。インシデント対応がひと段落ついた後の後日の「ふりかえり会」までにページ全体を更新し、「ふりかえり会」はこのポストモーテムページを基に議論を進めている。

---

1.エグゼブティブサマリー

💡
このセクションは非技術者でもわかる表現で記載してください。

また本項目は、インシデントの全体把握のため判明している範囲で随時更新します。調査中の場合は「調査中」と記載します。

1-1.影響

YYYY 年 MM 月 DD 日 X曜日 HH から YYYY 年 MM 月 DD 日 X曜日 HH の HH 時間 MM 分にわたって、<影響のあったユーザー> に、<影響の概要> がありました。

1-2.直接原因

<直接原因を引き起こす操作や事象> することで事象が発生しました。

1-3.根本原因

💡
根本原因は、対応が落ち着いた後、ふりかえりに向けて更新します。

<直接原因> は、<根本原因> のため引き起こされました。

2.問題の概要

💡
本項目は、インシデント対応中の更新は難しいため、通常は対応が落ち着いた後の振り返りまでに更新します。インシデント対応中も更新が可能であれば、判明している範囲で随時更新するのが望ましいです。

YYYY 年 MM 月 DD 日 X曜日 HH から YYYY 年 MM 月 DD 日 X曜日 HH の HH 時間 MM 分の間、<より具体的な影響> がありました。

<以降の説明を理解するためのアーキテクチャや技術要素に関する補足>

<どのように直接原因が引き起こされたか>

<どのように問題を検知したか>

<どのように問題を切り分けたか>

<何をもとにシステム障害と判断し、どのようにエスカレーションしたか>

<どのようにして復旧し、何をもって復旧を確認したか>

<その他補足すべきこと>

3. 検知

💡
本項目は、判明している範囲で随時更新するのが望ましいです。

監視システムからのアラートで検知できなかった場合には、その旨を明記します。

<コンポーネント名称> の が <具体的な数値> を示し、<検知のしくみ> が <通知先> へ通知することによって気づきました。

4. 影響

💡
本項目は、判明している範囲で随時更新するのが望ましいです。

HH 時間 MM 分にわたって、<影響のあったユーザー> に、<より具体的な影響> がありました。

本件に関して、ユーザーからの申告や苦情は <ユーザー申告の件数> 件ありました。

5. テスト環境での動作確認

<この障害に関連するアプリケーションなどのテストはどのように行われたか>

<テスト環境でテスト中に問題が再現していたか>

<テスト環境でテスト中に問題が再現しなかった理由>

<テスト環境で障害を再現することができるか>

6. 直接原因

<コンポーネント名称> を <直接原因を引き起こす操作や事象> することで発生しました。

7. 復旧(暫定対策)

💡
本項目は、システムの早期復旧のために実施した対策内容を記載します。

<コンポーネント名称> を <復旧のための操作> することで復旧しました。

8.根本原因

💡
5 Whys 分析をして、根本原因を見つけてから記載します。

<以降の説明を理解するためのアーキテクチャや技術要素に関する補足>

<なぜ直接原因が引き起こされるに至ったか>

9.恒久対策

💡
本項目は、技術的な恒久的対策内容を記載します。

また根本原因を踏まえた、再発防止の対策がある場合はその対策内容も記載します。

10. 学んだこと

💡
振り返りの時に、時間をとって参加者全員で書き込んで振り返ります。

10-1 うまくいったこと

• 箇条書きで記載します。

10-2 うまくいかなかったこと

• 箇条書きで記載します。

10-3 ラッキーだったこと

• 箇条書きで記載します。

11. アクションアイテム

💡
アクションアイテムを実行すれば、根本原因がすべて取り除かれるようにします。
具体的に改善可能な項目にすると良いです。「原因を調査する」「対応を検討する」のようなアイテムではなく、「XXのアラートを設定する」のような具体的なアイテムにしましょう。

アクションアイテムは、プロジェクトで使用しているタスク管理ツールで起票し管理します。

💡
うまくいったことが継続できること、うまくいかなかったことが解決されること、またラッキーだったことがしくみとして取り込まれることも必ず記載します。

12. タイムライン

💡
何が起きたのかが詳細にわかるように、具体的な事象や行動を時系列で記載します。

インシデント対応中は、タイムラインを中心に更新をします。

それによって、他のメンバーがここを見ただけで、現在の状況をある程度理解できるぐらいの粒度で書いてください。

YYYY-MM-DD (all times JST)

• HH ＜OUTAGE BEGINS＞
• HH ＜DETECTION TIME＞
• HH ＜ESCALATION TIME＞
• HH ＜MITIGATION TIME＞
• HH ＜IMPACT ENDS＞
• HH ＜OUTAGE ENDS＞

13. 補足情報

補足情報があれば、こちらに記載します。