ポストモーテムの取り組み
- ポストモーテムは、Incident の事例を振り返り、改善のために学んでいく取り組みです。
- Infra と各チームの SRE が中心になって、 ポストモーテムの作成や同期的なレビュー会を毎週行っています。
- https://github.com/wantedly/post-mortems (internal) に過去のポストモーテムをまとめています。
Wantedly では、日々新しい機能や新しいシステムが追加されています。 そのため、成長と同時に複雑な分散システムになりつつあります。
インシデントやサービス障害は、増幅する規模感と変化の速度から避けがたいです。 インシデントが発生した場合は、基本的にその場で原因対策し安定運用に戻します。
しかし、こういったインシデントから学びを得るための定式化されたプロセスがなければ、同じようなインシデントが無限に繰り返し起こることになります。また野放しのままになってしまえば、インシデントの複雑さは加速度的に増し、あるいは積み重なってシステムの対処ができなくなります。
そのため、失敗から学ぶために振り返りのポストモーテムを書きます。
ポストモーテムは、インシデントとそのインパクト、その緩和や解消のために行われたアクション、根本原因（群）、インシデントの再発を避けるためのフォローアップのアクションを記録するために書かれるものです。抜粋:: Betsy Beyer “SRE サイトリライアビリティエンジニアリング”
ポストモーテムの目的は、インシデントがドキュメント化されること、影響を及ばしたすべての根本原因（群）が十分に理解されること、そして、再発の可能性や影響を削減するための効果的な予防策が確実に導入されるようにすることです。ポストモーテムには次のような事が書かれます。
- 発生したこととその影響範囲
- その緩和や解消のために行われたアクション
- 根本原因
- 再発防止策
ポストモーテムを書くはのは処罰ではなく、会社全体としての学びの機会です。サービスのどの部分をどうすれば改善できるのかを提起し、長期的な成長を鈍化させないプロセスです。
- | ポストモーテム | 障害報告書 |
|---|---|---|
想定読者は誰か | 社内 | ユーザー |
何のために書くのか | 失敗から学ぶため | 説明責任を果たすため |
知見として溜まったものを学びの機会として共有するために、毎週 Post mortems / Incident review を行い、 作成したポストモーテムの共有と、内容の精査、Next Action の決定などを行っています。この場で Incident の共有や、ポストモーテムを書く提案も行っています。
参加メンバーは、Infra Squad のメンバーと、各 Domain の SRE チームの メンバーです。毎週水曜日 15:00 ~ 15:30 に実施しています。
Wantedly では、学びを得て蓄積していけるようなポストモーテムを書いていけるように、 「ポストモーテムを書く会」として同期的にポストモーテムを書く場を設け、そこで書いたポストモーテムをレビューしています。
最近では以下の流れで進めることが多いです。これらの流れについて説明します。
- 1.ポストモーテムを書きたいものを Post mortems / Incident review 会で提案
- 2.ポストモーテムを書く会に向けて準備
- 3.ポストモーテムを書く会の実施
- 4.書いたポストモーテムを Post mortems / Incident review 会で共有、レビュー
最近発生した Incident やオペレーションなど、振り返って学びを得るためにポストモーテムを書きたいものを Post mortems / Incident review 会で提案します。 そこで、「ポストモーテムを書く会」のメンバーを決めます。メンバーは、進行役として Infra Squad のメンバー1人以上 + Incident やオペレーションに関わったメンバー、参加したいメンバーにします。
メンバーを決めたら、進行役の Infra メンバーが、書く会の予定の設定をします。
Post mortems / Incident review 会は、 Infra Squad + 各 Domain の SRE チームのメンバーが参加しています。参加するには、ミーティングの Issue (internal) にコメントをしたり、直接相談などしてみてください。
「ポストモーテムを書く会」がスムーズに行えるように、事前に以下の準備を行います。
- 進行役の Infra メンバーがテンプレートを使ってドキュメントを作成する。
- その issue に「ポストモーテムを書く会」用の Google Docs のテンプレートがあるので、予めテンプレートからドキュメントを作っておきます。
- Incident やオペレーションに関与したメンバーが、それのサマリを用意しておきます。
- サマリを用意しておくと、ポストモーテムを書く際の事実確認がスムーズに行えます。
- Incident の場合は wantedly/infrastructure の incident issue template (internal) に、サマリのテンプレートがあるので、それを利用すると便利です。
事前に決めたメンバーで、同期的に Google Docs 上のドキュメントの項目を埋めていく形で進めます。 会を進める上では、以下の流れに沿って KPT + Fact を意識して進めると、良いポストモーテムが書きやすいです。
- まず Fact を整理して、参加 しているメンバーが当時の状況を把握できている状態にする。
- Incident の原因、ユーザー影響、復旧要因、タイムラインに関する項目を埋めていく。
- それらから Keep, Problem として、継続していきたい内容、再発防止したい内容、今後改善していきたい内容を洗い出す。
- テンプレートの Lessons Learned を使うと洗い出しやすいです。
- Problem を改善するための Try を書いていく。
- TODO, Long-term Action として書いていく。
- 問題が大きい場合は、以下のように色々な観点で問題を分解すると進めやすいです。
- 未然に防ぐにはどうなっていると良いか
- 異常に早期に気付けるにはどうなっていると良いか
- 気付いた後の対応を早く行えるにはどうなっていると良いか
書いたポストモーテムを共有し、レビューを行います。 レビューでは、主に以下の項目が正しく記載されているかをレビューし、必要に応じてその場で修正を行います。
- 内容が非難を避け、建設的であるか？
- 後々のためにインシデントの主要なデータは収集されているか？
- インパクトの分析は完全か？
- 根本原因は十分に深く分析されているか？
- アクションプランは適切で、その結果として行われたバグの修正には適切な優先順位が与えられているか？
- 結果は関係するステークホルダーたちと共有されたか？
- 長期的な解決策が考えられているか？
- アクションプランや長期的な解決策でトイルが増加しないか？
「人を修正することはできませんが、システムやプロセスを修正して、複雑なシステムの設計やメンテナンスを行う際に、人々が正しい選択をすることをうまく支援することはできる」 抜粋:: Betsy Beyer “SRE サイトリライアビリティエンジニアリング”
書 いたポストモーテムについて、TODO は review 会で assign を決めて取り組んでいます。 Long Term Action は、以後のプロジェクトの検討材料として使ったりなどしています。
(Long Term Action の棚卸しなどはもっと行いやすいように、改善などを進めている最中です 💪 https://github.com/wantedly/post-mortems/issues/84)
最終更新 1yr ago