トップ > 【実践】Repro のポストモーテム運用【テンプレート付き】

【実践】Repro のポストモーテム運用【テンプレート付き】

Development Division/Platform Team/Sys-infra Unit の今(temama)です。

Repro では障害発生とその対応後にポストモーテムを作成、それに伴ってポストモーテムを記載するポストモーテムミーティングを開催しています。

Repro には、インシデント発生時に対応する開発チームと顧客へ連絡するカスタマーサポートチームの密な連携のためのインシデントテンプレートがあります。これはインシデントの影響時間、機能、影響範囲など連絡の際に必要な情報を穴埋め式で埋めていくもので、障害が復旧して顧客へ連絡するまでが役割です。

記載したインシデント情報をベースに、振り返りとして KPT (Keep/Problem/Try) を行っていましたが、これを SRE 本を参考により良いフォーマットに整えていく働きがポストモーテム文化を根付かせるきっかけとなりました。
最初から現在のフォーマットだったわけではなく、定期的に作成されたポストモーテムを見直し、作成に関わったメンバーからのフィードバックを受けてよりスムーズに進められるよう更新してきました。

ポストモーテムとは

ポストモーテムとは、インシデント発生後にその経緯・影響・対応・根本原因・再発防止策を記録したドキュメントです。Repro では Google の『Site Reliability Engineering』15章の記載を軸にテンプレートを作成、実施しています。
Google では障害発生後のフロー全体を指してポストモーテムと呼んでいますが、Repro ではフローではなく作成した記事自体をポストモーテムとし、作成時に行うミーティングをポストモーテムミーティングと呼んでいます。

ポストモーテムを作成するに当たって大切な原則として、 Blameless（非難しない）があります。

非難なくポストモーテムを書くための前提となるのは、インシデントに関わりを持ったすべての人々が善意の下で、知り得た情報をもって正しい行動をとったものと考えることです。

『SRE サイトリライアビリティエンジニアリング』115章

ポストモーテムに関わる全ての人が Blameless を意識することで、根本原因の特定、再発防止策に注意を向けることができます。

サイトリライアビリティエンジニアリング（SRE 本と呼ばれています）は英語版を無料で読めるので、読んだことのない方は是非気になる章だけでも読んでみることをおすすめします。あるいは Gemini などの AI に記載内容を要約してもらうのも良いと思います。

Postmortem Culture: Learning from Failure | Google SRE

Repro で行っているポストモーテムの流れ

ポストモーテムのフォーマットは PagerDuty の記事を多く引用して利用しています。

PagerDuty: How to Write a Postmortem

事前記入

ポストモーテムには発生した事実の記載と、根本原因を探って恒久対応するための取り組みを決める2つのフェーズがあります。
まずはテンプレートからポストモーテムを作成し、発生した事実を記入します。

  • 発生日
  • 影響範囲: ユーザー/顧客が影響を受けた期間、人数、機能、程度
  • 発生要因: トリガーとなった事象
  • 検出: 対応者が障害に気づいたきっかけ
  • 対応: 障害を回復させた方法
  • タイムライン: インシデントの発生から対応完了までの主なアクションを時系列順で記載
  • 教訓(Lessons Learned): 対応にあたってうまくいったこと、うまくいかなかったこと、幸運だったことを記載
  • 調査結果: もしポストモーテムミーティングまでに技術調査で判明した事実があれば記載

この記入は主にポストモーテム作成のハンドルを握る1名が行いますが、ポストモーテムミーティングの開催前に参加者に内容を確認してもらい、内容に認識の齟齬がないか、各メンバーの視点から追記出来ることを追記してもらいます。

ポストモーテムミーティングの開催

事実の記載が完了したら、日程を決めてポストモーテムミーティングを開催します。Repro では1時間の確保を推奨しています。
参加者は対応担当者、影響したコンポーネントの担当チーム、そして開発部マネージャーです2。
ポストモーテムミーティングでは最初に5分ほど内容について改めて読んでもらう時間を設けてから、以下の内容について話し合っていきます。

  • 根本原因分析: なぜ発生要因から障害に発展してしまったのか、テストの不足や開発中の認識合わせなどまで深堀って考察
  • アクションアイテム: 根本原因を取り除くための方法

根本原因分析

根本原因分析の手法にはいくつかあります。テンプレートには PagerDuty の『インシデントの分析』に書かれている設問を引用して記載しています。

  • これは単独のインシデントですか、それとも直近よく発生しているものの一部ですか？
  • これは特定のバグや予想された種類の障害だったか、またアーキテクチャ的に予想していなかった問題の種類を明らかにしましたか？
  • 過去にチームがやらないことを選択した作業で、このインシデントに寄与したものはありましたか？
  • 過去に類似または関連するインシデントがあったかどうかを調査します。このインシデントは、システムのより大きな範囲の傾向を示すものですか？
  • サービスの使用を継続的に成長させ拡大するにつれて、この種の問題は悪化/より発生しやすくなりますか？

インシデントの分析 | PagerDuty: How to Write a Postmortem

ただし、これらの設問は全ての障害の原因分析に最適なものではなく、あくまで汎用的なものです。最近は AI に事前記入を済ませたポストモーテムを読ませて、より効果的な原因分析手法を提案してもらうなどの工夫をしています。

アクションアイテム

ここでのポイントは、1時間という限りある時間の中で決めることを絞ることです。
提案されたアクションアイテムについて、「このアクションが本当に根本原因の対応として有効なのか」や、「工数、予算の都合上実施できるのか」については後日調査とすることで、時間内でより多くの視点から対応策を検討できます。
調査の結果アクションを行わなかった場合も、何故そのアクションを見送ったのかを残すことが出来ます。これには ADR (Architecture Decision Record) に似た効果があります。

アクションアイテムの管理

Repro ではタスク管理に ClickUp を利用しています。アクションアイテムは全て ClickUp のタスクとして登録します。
ClickUp にはタスクを複数のリストに登録する機能があります。これを利用して、各チームのタスク管理方針で立てたタスクを開発組織全体のポストモーテムアクションリストにも追加しています。
これにより、開発組織内で簡単にアクションアイテムの進捗について把握できます。そこには調査内容や実行を見送った理由も記載されるため、チーム外からも過去起きたインシデントのその後の対応について詳細に把握が可能です。

最後に、ポストモーテムの記載とミーティング参加者の最後の認識合わせが完了したら、ポストモーテムのフォーマットを整えて開発組織全体へ共有します。これには発生したインシデントと対応の共有と、より多くの開発者によるポストモーテムレビューのフローでもあります。

レビューされていないポストモーテムは、存在しなかったも同然です。 『SRE サイトリライアビリティエンジニアリング』[^sre_book]15章

ポストモーテムのテンプレートは上から順に記載して作成出来る構成にしていますが、読み物として整えるため最後に Tips の削除と、サマリー欄を先頭に移動しています。詳細は付録の実際に利用しているテンプレートをご確認ください。

ポストモーテムの振り返りと改善

年に一度、あるいはもっと早く改善の余地を感じたタイミングでポストモーテムの振り返り会を開催しています。
参加者全員で前回の振り返り会以降に作成されたポストモーテムを読み、ポストモーテムが役に立っているか、作成時に無駄な負担がかかっていないか、より効果的な手法がないかなどについて意見を交換します。その後意見をまとめ、テンプレートを更新し、再び次回の振り返り会まで運用します。

過去の振り返り会で出た意見を一部抜粋します。

  • ポストモーテムミーティングで何を話すのかの共通認識を持ち、議論が意図せず発散しないようにしたい。
  • ポストモーテムの教訓がチームを超えて活かせていない。
  • アクションアイテムが管理されてなくて、実際にやったかどうか分からない。

これらの意見を受けてテンプレートに補足を記載したり、アクションアイテム共有フローを策定するなどポストモーテムの一部を改善しました。

効果

社内のメンバーからポストモーテムの効果について、振り返り会やアンケートの結果から一部紹介します。

  • 根本原因の話ができており、ポストモーテム参加していなくても教訓を得られる機会になっている。
  • 同じような障害の対処をする際に、どこを確認するとよさそうかを後からでも把握できるようになった。
  • 他チームのポストモーテムから、観点やマインドの面で自チームに役立てられることはあるかを考えられるようになった。

ポストモーテムが効果的な活動であるという理解を得られているのは SRE の Enabling 活動の一区切りだと考えています。
前のめりに取り組んでくれている開発メンバーにはとても感謝しています。

展望

ポストモーテムミーティング内で行う根本原因分析の手法について、まだまだ改善の余地があると感じています。AI の力も借りつつ、限られた時間を効果的に使えるよう様々な手法を試していきたいと思っています。
また、記載してレビューを通ったポストモーテムを資料として生かす方向性も検討しています。新しいメンバーがオンコールに入る際、あるいは社内の障害対応フローの確認のためのディザスタロールプレイ3を行う際のシナリオとしての活用を考えています。

WE'RE HIRING!!

Repro では SRE を推進し、より信頼できるプロダクト及び基盤を構築する仲間を募集しています！
Repro 株式会社 - 求人一覧

付録: 実際に利用しているテンプレート

Repro では esa.io を利用しているため、esa 用のテンプレートになっています。

## 作成日
<!-- 
ポストモーテムミーティング実施日を記入
-->

 YYYY-MM-DD


## 作者

<!-- 
参加したメンバーをチーム別に記入してください
control + i で esa アイコンが挿入できます
-->

- [team] :member_icon:

## サマリ

> [!IMPORTANT]
> 下部のサマリ欄の記載が完了したらここに移動する

## インパクト

> [!TIP] 
> インシデントによるインパクトを書いてください。
> 
> - 影響が発生していた期間はどれくらいですか？言い換えれば、ユーザー/顧客が影響を受けた時間の長さはどれくらいですか？
> - 何人の顧客が影響を受けましたか？
>   - 何人の顧客がインシデントについてサポートに連絡しましたか？
> - どの機能がどの程度影響を受けましたか？
>   - 製品に特化したビジネスメトリクスで影響を定量化します。
>   - リクエスト数、消費したエラーバジェットの値など
> 
> 参考: [PagerDuty: 影響の文書化](https://postmortems.pagerduty.co.jp/how_to_write/writing/#_4)

## 発生要因 (Trigger)

> [!TIP]
> 存在していた根本原因が、何を起因にインシデントに発展したのかについて記載をします。
> > e.g. デプロイ、リクエストの集中、オペレーションミス、エッジケースのリクエストなど

## 検出

> [!TIP]
> インシデントをどう検出したか書いてください。
> > e.g.  DataDog アラート、問い合わせ、不審なエラーログ通知から調査した結果発覚など

## 対応

> [!TIP]
> インシデントに対してどのように対応し、顧客への影響を止めたか書いてください。
> > e.g.
> > - 暫定対応: ロールバックを行い、正常動作するリビジョンへ巻き戻した
> > - 緩和: プロセスを停止し、不整合のあるデータを増やさないようにした

## タイムライン

> [!TIP]
> インシデントに関するイベントについてタイムラインを書いてください。
> 
> - 事実に焦点を当てて記載しましょう。
> - インシデントは、インシデント対応者が認識する前から始まっていた可能性があることに注意しましょう。
> - タイムラインには、状況や影響の重要な変化、対応者による主要な行動を含めましょう。
> - インシデント前の時点から始めて、時系列に沿って書くようにしましょう。
> - タイムラインの各項目について、出典となるメトリックやページのリンクを貼り付けましょう。
> - 意見ではなく、事実に基づいていることを示しましょう。
> 
> 参考: [PagerDuty: タイムラインの作成](https://postmortems.pagerduty.co.jp/how_to_write/writing/#_3)

YYYY-MM-DD  (UTC+09:00)

- [HH:MM] [イベント概要]
    - 補足情報、Slack や PagerDuty、Datadog 等への URL のリンクがあれば書く

### 障害メトリクス

> [!TIP]
> タイムラインに記載した時間から算出してください
> 中間プロセスがない場合はスキップして、MTTR が算出できるように記載してください
> タイムラインと以下の記入項目を AI に渡して算出させると便利です
> 
> MTTRやMTBFなどの数値定義参考
> https://www.splunk.com/ja_jp/data-insider/what-is-mean-time-to-repair.html

- 問題発生から検知：
- 検知から連絡：
- 連絡から着手：
- 着手から復旧（暫定対応）：
- 問題発生から復旧までの時間の合計（MTTR）：

## 教訓 (Lessons Learned)

> [!TIP]
> 発生したインシデントの対応にあたり、以下の3つについて事実ベースで記載してください。
> 
> - うまくいったこと：事前に用意した対応・対策がうまく機能したもの
> - うまくいかなかったこと：事前に用意した対応・対策がうまく機能しなかったもの
> - 幸運だったこと：用意不足や考慮外だったが、緩和や解消に役立ったもの
> 
> :information_source: 教訓はアラート設定や対応フロー等が機能したかの振り返りで、アクションアイテムの発案に役立ちます。原因分析に紐づけすぎないように留意してください。

### うまくいったこと

- ...

### うまくいかなかったこと

- ...

### 幸運だったこと

- ...

## 根本原因 (Root Cause)

### 調査結果

> [!TIP]
> 事前記入：調査したものは事前に記入
> - 発生要因は何を引き起こしたのか

ここまで事前記入
---

### 原因分析

> [!TIP]
> ポストモーテムミーティングで深堀りする
> 
> - これは単独のインシデントですか、それとも直近よく発生しているものの一部ですか？
> - これは特定のバグや予想された種類の障害だったか、またアーキテクチャ的に予想していなかった問題の種類を明らかにしましたか？
> - 過去にチームがやらないことを選択した作業で、このインシデントに寄与したものはありましたか？
> - 過去に類似または関連するインシデントがあったかどうかを調査します。このインシデントは、システムのより大きな範囲の傾向を示すものですか？
> - サービスの使用を継続的に成長させ拡大するにつれて、この種の問題は悪化/より発生しやすくなりますか？
>
> 参考: [PagerDuty: インシデントの分析](https://postmortems.pagerduty.co.jp/how_to_write/writing/#_5)

## アクションアイテム

> [!TIP]
> 対策タスクを書いてください。
>  Clickupにカードを作り担当者とDue Date、Add To Another List `Dev > Division > Post-mortem Actions` を設定しましょう。
> 
> ポストモーテム一覧リストに作成したタスクが見えるようになっていることを確認してください。

アクション内容 | 担当チーム | ClickUp (必須) | 補足事項
--- | --- | --- | ---
 | | |

## サマリ

> [!TIP]
> インシデントについて、対応時にその場に居なかった人にもわかるように簡潔にまとめてください。
> サマリは記載完了後、記事の上部にあるサマリ欄に移動させてください。

- どの期間に、どの機能に、何がおきたのか、どんな影響が発生したのか
- 原因
- 対応

## 参考情報・関連情報

- ...

## ポストモーテムについての補足事項

> [!TIP]
> このポストモーテムについて、感想や改善案、プラスデルタを書いてください。
  1. O'Reilly 著『SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム』↩
  2. 可能な限りマネージャーが参加可能な時間を探しますが、忙しい立場の人を1時間連続で時間を確保するのは難しいものです。見つからないときは任意参加者として Google Calendar で招待するようにしています。↩
  3. 障害発生時のコミュニケーションや対応内容、チェック項目、ドキュメントなどを確認しながら行う障害対応ロールプレイ。TRPG みたいなものだと思っています。↩

© About Repro Tech Blog