ヌーラボ
ポストモーテムについて
インシデントが発生した場合、問題を修正し、サービスは通常運用に戻る。
インシデントから学びを得るための定式化したプロセスがなければ、インシデント無限に繰り返される。
野放しにした場合、インシデントの複雑になり、積み重なってシステムや運用担当者を圧迫し、最終的にはユーザに影響が及ぶ。
そのためポストモーテムは重要である。
ポストモーテムを書くことの目的は、インシデントがドキュメント化されること。
影響を及ぼしたすべての根本原因が十分に理解されること、そしてとりわけ、再発の可能性や影響を削減するための効果的な予防策が確実に導入されるようにすること。
ポストモーテムは、望ましからざる重大なイベントが生じた後に求められます。
ポストモーテムは処罰ではなく、会社全体としての学びの機会である。
ポストモーテムのプロセスは、時間や労力という観点で本来的にコストがかかることなので、ポストモーテムを書くべきかどうかは慎重に判断します。
- ユーザーに影響が及んだダウンタイムやデグレーションが一定の閾値を超えた場合
- 種類の如何を問わず、データの損失が生じた場合
- オンコールエンジニアの介入が必要だった場合（リリースのロールバック、トラフィックのルート調整など）
- 解決までの時間が一定の閾値を超えた場合
- モニタリングの障害（これは通常、人手でインシデントが発見されることになります）
ポストモーテムの条件はインシデントが生じる前に定義しておき、ポストモーテムが必要かを誰もが理解できるようにしておくことが重要
客観的な条件をいれることでステークホルダーにポストモーテムが求めやすくなる
ポストモーテムで批判を行わないことは、SREの文化における信条
避難なくポストモーテムを書くための前提となるのは、インシデントに関わりをもったすべての人が善意の下で、知り得た情報をもって正しい行動をとったものと考えることです。
そうでなければ、問題が表にでてこなくなる。すべての「ミス」はシステムを強化する機会と見なす。
ポストモーテムはサービスのどの部分をどうすれば改善できるのかを問題提起するもの
ポストモーテムを共有する上で大事なこと
- リアルタイムコラボレーション
- オープンなコメント/アノテーションシステム
- メールによる通知
ポストモーテムを書くことには、正式なレビューと好評も含まれる。
具体的には以下のようなレビューを行う。
- 後々のためにインシデントの主要なデータは収集されたか？
- インパクトの分析は完全か？
- 根本原因は十分に深く分析されているか？
- アクションプランは適切で、その結果として行われたバグの修正には適切な優先順位が与えられているか？
- 結果は関係するステークホルダーたちと共有されたか？
関係者全員が、ポストモーテムのドキュメントをそのアクションアイテムに満足したら、そのポストモーテムを過去のインシデントについてのチームや組織のレポジトリに追加します、透明性の高い共有をすれば、他社がそのポストモーテムを見つけ、そこから学ぶことが用意になる。
ポストモーテムの文化を組織に導入することは簡単なことではない。
そのため継続的な育成と強化が必要になる。
非難のないポストモーテムは、理想的にはエンジニアが自発的に生み出すものであるべきです。
ポストモーテムを育む精神の下で、SREはシステムのインフラストラクチャについて学んだことを広める活動を積極的に作り出すこが大事。
- 今月のポストモーテム
- Google+ のポストモーテムグループ
- ポストモーテム読書会
- 不運の輪（過去のポストモーテムの再現をする）
ポストモーテムを組織に導入する上での最も大きな課題は、準備にかかるコストほどの価値があるのか疑問に思う人がいるかもしれないことです。
- ポストモーテムをワークフローに落とし込む。試行錯誤にいくつかのポストモーテムがうまくできあがれば、その結果を証明しやすくなり、ポストモーテムを行う条件を特定しやすくなる
- 効果的なポストモーテムを書くことは報われることであり、称賛されることであるようにする。これには、すでに述べたようなソーシャルな方法を通じて公的に行うことも、個人やチームのパフォーマンス管理を通じて行うことも含まれます。
- 上位のリーダーたちの承認と参加を奨励する。ポストモーテムの価値が高いことにについては、Larry Page までが語っている。
ポストモーテムの文化を育むための継続的な投資によって、サービスの障害は減り、ユーザー体験を改善できる。
プロダクトは違ったとしても、最悪の事態から学ぶという共通の目標に向けて、誰もがポストモーテムを作成している。