> For the complete documentation index, see [llms.txt](https://docs.wantedly.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.wantedly.dev/fields/dev-process/post-mortems.md).

# ポストモーテムの取り組み

## TL;DR

* ポストモーテムは、Incident の事例を振り返り、改善のために学んでいく取り組みです。
* Infra と各チームの SRE が中心になって、 ポストモーテムの作成や同期的なレビュー会を毎週行っています。
* <https://github.com/wantedly/post-mortems> (internal) に過去のポストモーテムをまとめています。

## はじめに

ウォンテッドリーでは、日々新しい機能や新しいシステムが追加されています。 そのため、成長と同時に複雑な分散システムになりつつあります。 加えて、外部環境も変化しています。サービスが大きくなるほどにユーザーの行動も多様化し、様々なアクセス元からの危険なリクエストも日々やってくるようになります。

こうした条件の下では、インシデントやサービス障害を未然に防ぐためのコストは、要求する水準に対して指数的に(急激に)大きくなります。 もちろん完璧なサービスを提供できるならそれに越したことはないですが、私たちの目的はプロダクトを通じて社会に影響を与えることであり、完璧なサービスを作ることではありません。かけられるコストには限界がある以上、インシデントが起きうること自体は許容せざるを得ません。

しかし、こういったインシデントから学びを得るための定式化されたプロセスがなければ、同じようなインシデントが無限に繰り返し起こることになります。また野放しのままになってしまえば、インシデントの複雑さは加速度的に増し、あるいは積み重なってシステムの対処ができなくなります。

そのため、インシデントが発生し、対処したあとは、その一部始終から学ぶために振り返りのポストモーテムを書きます。

## ポストモーテムとは？

> ポストモーテムは、インシデントとそのインパクト、その緩和や解消のために行われたアクション、根本原因（群）、インシデントの再発を避けるためのフォローアップのアクションを記録するために書かれるものです。
>
> 抜粋:: Betsy Beyer “SRE サイトリライアビリティエンジニアリング”

ポストモーテムの目的は、インシデントがドキュメント化されること、影響を及ばしたすべての根本原因（群）が十分に理解されること、そして、再発の可能性や影響を削減するための効果的な予防策が確実に導入されるようにすることです。ポストモーテムには次のような事が書かれます。

* 発生したこととその影響範囲
* その緩和や解消のために行われたアクション
* 根本原因
* 再発防止策

ポストモーテムを書くはのは処罰ではなく、会社全体としての学びの機会です。サービスのどの部分をどうすれば改善できるのかを提起し、長期的な成長を鈍化させないプロセスです。

|     -     |  ポストモーテム |    障害報告書   |
| :-------: | :------: | :--------: |
|  想定読者は誰か  |  社内　　　　　 |   ユーザー 　   |
| 何のために書くのか | 失敗から学ぶため | 説明責任を果たすため |

## Post mortems / Incident review での共有

知見として溜まったものを学びの機会として共有するために、週次で Post mortems / Incident review を行い、 作成したポストモーテムの共有と、内容の精査、Next Action の決定などを行っています。

参加メンバーは、Infra Squad のメンバーと、各 Domain の SRE チームのメンバーです。 加えて、その日に扱う予定の post mortems が決まっている場合、それに関係するメンバー (障害発生時に対応してくれたメンバーなど) を呼ぶこともあります。

近頃は incident と言えるような問題が起きていない週も多くなってきたため、開催頻度は低くなりつつあります。

👉 [過去に開催した Post mortems / Incident review](https://github.com/wantedly/post-mortems/labels/Post%20mortem%2FIncident%20Review)

## ポストモーテムの書き方

ウォンテッドリーでは、学びを得て蓄積していけるようなポストモーテムを書いていけるように、 「ポストモーテムを書く会」として同期的にポストモーテムを書く場を設け、そこで書いたポストモーテムをレビューしています。

最近では以下の流れで進めることが多いです。これらの流れについて説明します。

1. インシデント対応を行った関係者の間で、ポストモーテムにするべき学びがあるかどうかを判断する。
2. 一人がポストモーテムの叩き台を作る。
3. 関係者を集めてポストモーテムを書く会を実施する。
4. 書いたポストモーテムを Post mortems / Incident review 会で共有、レビューする。ここでインシデント関係者以外にも学びが共有される。

### 1. ポストモーテム化の判断

インシデントからどのような学びが得られるかについて、関係者の間で話し合います。これには大きく2つの要因が関与します。

* インシデント対応中にすでにある程度のことがわかっていて、それが共有するべき学びに相当する場合。 たとえば、原因となったデプロイが特定されていて、そのデプロイがなぜダメだったのかの目星がすでについている、というような場合です。
* インシデント対応中にはわからなかったことがあり、そこを明らかにすることが今後のインシデント対策に寄与することが期待される場合。たとえば特定のノードが異常状態になったという直接の原因はわかっているが、その根本原因を明らかにしなければ再発するリスクがある場合などです。

インシデントを振り返って、ポストモーテム化するほどの知見がない場合は対応コストとの兼ね合いでポストモーテムを作らないこともあります。ただし、「post-mortem にするほどの学びのない incident」が増えている場合は要注意です。その場合、 incident から学ぶべき上位の学び (組織課題など) がないか点検するべきかもしれません。

### 2. 叩き台の作成

ポストモーテム作成作業のうち、基本的な事実関係の収集などは一人で行ったほうが効率がよく、全員を集める必要がありません。そこで、最近ではインシデントに対応した人のうち誰か一人が叩き台を作ることが多いです。

次の「3. ポストモーテムを書く会の実施」の進め方が執筆の参考になります。

### 3. ポストモーテムを書く会の実施

事前に決めたメンバーで、同期的に Google Docs 上のドキュメントの項目を埋めていく形で進めます。 すでに叩き台がある場合は、それをベースに編集・コメントして内容を改善していきます。 会を進める上では、以下の流れに沿って KPT + Fact を意識して進めると、良いポストモーテムが書きやすいです。

* まず Fact を整理して、参加しているメンバーが当時の状況を把握できている状態にする。
  * Incident の原因、ユーザー影響、復旧要因、タイムラインに関する項目を埋めていく。
* それらから Keep, Problem として、継続していきたい内容、再発防止したい内容、今後改善していきたい内容を洗い出す。
  * テンプレートの Lessons Learned を使うと洗い出しやすいです。
* Problem を改善するための Try を書いていく。
  * TODO, Long-term Action として書いていく。
  * 問題が大きい場合は、以下のように色々な観点で問題を分解すると進めやすいです。
    * 未然に防ぐにはどうなっていると良いか
    * 異常に早期に気付けるにはどうなっていると良いか
    * 気付いた後の対応を早く行えるにはどうなっていると良いか

### 4. 書いたポストモーテムを Post mortems / Incident review 会で共有、レビュー

書いたポストモーテムを共有し、レビューを行います。

Post mortems / Incident review 会は、 Infra Squad + 各 Domain の SRE チームのメンバーが参加しています。参加するには、[ミーティングの Issue (internal)](https://github.com/wantedly/post-mortems/labels/Post%20mortem%2FIncident%20Review) にコメントをしたり、直接相談などしてみてください。 ポストモーテムを書いたチームが、学びを知ってほしい相手を review 会に呼ぶことも可能です。

レビューでは、主に以下の項目が正しく記載されているかをレビューし、必要に応じてその場で修正を行います。

* 内容が非難を避け、建設的であるか？
* 後々のためにインシデントの主要なデータは収集されているか？
* インパクトの分析は完全か？
* 根本原因は十分に深く分析されているか？
* アクションプランは適切で、その結果として行われたバグの修正には適切な優先順位が与えられているか？
* 結果は関係するステークホルダーたちと共有されたか？
* 長期的な解決策が考えられているか？
* アクションプランや長期的な解決策でトイルが増加しないか？

> 「人を修正することはできませんが、システムやプロセスを修正して、複雑なシステムの設計やメンテナンスを行う際に、人々が正しい選択をすることをうまく支援することはできる」 抜粋:: Betsy Beyer “SRE サイトリライアビリティエンジニアリング”

👉 [駄目な例 (internal)](https://github.com/wantedly/post-mortems/issues/4)

## 書いたポストモーテムの活用

書いたポストモーテムについて、TODO は review 会で assign を決めて取り組んでいます。 Long Term Action は、以後のプロジェクトの検討材料として使ったりなどしています。

(Long Term Action の棚卸しなどはもっと行いやすいように、改善などを進めている最中です 💪 <https://github.com/wantedly/post-mortems/issues/84>)

#### 話を聞きに行きたい

* Slack: [#post\_mortem](https://wantedly.slack.com/archives/C027KFZCU5V), [#infra](https://wantedly.slack.com/archives/C010V922570)

#### もっと知りたい

* [失敗から学ぶ - ポストモーテム / Postmotem culture at Wantedly - Speaker Deck](https://speakerdeck.com/munisystem/postmotem-culture-at-wantedly)