takafumi blog

日々の勉強メモ

ポストモーテムとは

基本的にSRE本を自分で実施する際に理解しやすい形にまとめたもの。

前提

この文章はインシデント(障害や緊急対応など)発生時の対応関するポストモーテムに関して記述する。

プロジェクト終了時などその他のタイミングで行うポストモーテムとは異なる。

用語

  • ポストモーテム
    • この文章ないではインシデント時に作成するドキュメントをポストモーテムと呼ぶ
    • ドキュメント作成とそれにまつわるレビューやなど一連の流れ、仕組みを指すときはポストモーテムのプロセスと呼称する
  • インシデント
    • 障害・緊急対応などサービスに何かが起きた時の呼称
  • トイル(SRE本 p51)
    • プロダクションサービスを動作させることに関係する作業で以下のような傾向を持つもの
      • 手作業で繰り返し行われる
      • 自動化することが可能である
      • 戦術的で長期的な価値を持たない
      • 作業量がサービスの成長に比例する

まとめ

目的・文化・準備

プロセス

ポストモーテムのプロセスは以下のようになる

  1. インシデントが発生する
  2. インシデントの対応が完了する
  3. ポストモーテムを書く条件に当てはまるかを判定
  4. 必要な情報を収集する
  5. 原因の分析と対策を検討する
  6. ポストモーテムを書く
  7. レビューを行う
  8. 共有する

参考: https://postmortems.pagerduty.com/what_is/


ポストモーテムの目的

過去のインシデントから学習し、再発の可能性や影響を削減するために行われる。

具体的には以下のような事を目的となる。

  • 根本原因、教訓が十分(具体的・広範囲に)に理解されること
  • 効果的な予防策が確実に導入される事

参考: - https://postmortems.pagerduty.com/what_is/ - SRE本 p175

ポストモーテムの準備

ツールの選定

  • ポストモーテムを書くためには以下の機能を備えているツールが望ましい
    • リアルタイムコラボレーション
    • オープンなコメント/アノテーションシステム
    • メール、チャットによる自動通知
  • 管理システム

参考: SRE本 p177

ポストモーテムの作成

まずポストモーテムを書く前にポストモーテムを作成する必要があるかを判断する

書く場合は

  1. インシデント事態の情報、対応に関する情報収集
  2. インパクトの分析
  3. 根本原因の分析
  4. 対策についてアクションプランを検討
  5. 調査・対策が十分かステークホルダーに確認する

を行い上記を十分に吟味し(もしくは行いながら)、ポストモーテムの作成する。

ポストモーテムは事前に用意したテンプレートに従い記述し、どのようにな書き方がよいポストモーテムかを理解しておく必要がある

いつポストモーテムを作成するか

  • 事前に決めた条件に則り、条件を満たす場合に作成する
    • ユーザー影響あるダウンタイムの発生
    • エンジニアが介入が必要だったとき
    • 解決までの時間
    • データの損失が発生した場合
    • 支払い、請求などお金に関わる問題発生時
    • モニタリングシステム自体の障害
    • など
  • 上記の決まった条件以外で問題となったイベントのステークホルダーは条件に以外で求める事ができる

参考: SRE本 p176~p178

ポストモーテムのテンプレート

例としてポストモーテムには以下のような項目を記述する。

- 担当者
    - ポストモーテム担当者
    - 対応担当者
- 概要
- 原因分析
    - 根本原因(e.g. ○○のバグのため)
    - 発生原因(e.g. △△の操作を行ったため)
- 対応内容
- 対応自体の分析
- 教訓
- 今後のアクションリスト
    - 事後対応内容
    - 現在のステータス
    - 担当者
    - 優先度

よいポストモーテムの書き方

TODO

参考: サイトリライアビリティワークブック―SREの実践方法/10章 ポストモーテムの文化:失敗からの学び

レビュー

レビューが行われていないポストモーテムは適切さを証明できないため、無いも同然と考える必要がある。

実際の流れとしては - チームに下書きを内部共有してレビューを行う - この時、上位の役職者は下書きが完全かを評価する

となる。場合によっては広範囲に意見を求める事もある。

レビューの観点

レビューでは事前にある程度観点を定めておく。

以下は一例

  • 不要な非難が含まれていないか
    • 個人に対する指摘
  • インシデントの主要なデータが収集されているか
  • インパクトの分析が十分か
  • 根本原因の分析が十分か
  • アクションプランは適切か
    • 担当者が決まっているか
    • 優先度が与えられているか
  • 結果はステークホルダーと共有されているか

など

レビューを必ず行う仕組み

レビューが行われなければポストモーテムは無意味といっていい。

必ず行うために、何時、どのように行うかをあらかじめ考えておくとよい。

  • どんなタイミングでレビューをするか
    • 下書きの段階でチーム内や直属の上位者がレビューするのが望ましい
  • レビューされていないポストモーテムが存在しない仕組みづくり
    • レビューMTGを行いポストモーテムを完成させる
      • レビューMTGの議論内容はとりまとめ、ポストモーテムに記載する

参考: SRE本 p178

共有

ポストモーテムを広く共有し、知識や教訓を広い範囲で役立てる事を目標とする。

より広範囲なチーム、内部メーリングリスト、チャットチャンネルなどへ共有する。

ポストモーテム文化の導入

参考: SRE本 p179

非難なく行う

ポストモーテムの記述・レビューなど全てのプロセスを通して、非難なく行うことが重要である - 避難的な雰囲気は問題の隠蔽へつながる - ポストモーテムを頻繁に作成している事を非難しない - ポストモーテムはサービス改善のための提案である - ポストモーテムの作成を称賛する文化を作る事が望ましい

参考: SRE本 P176~P177

継続的な育成と強化

継続にはポストモーテム文化の育成と強化が必要となる。 - 上位管理職の積極的な参加 - 積極的な情報の発信 - よいポストモーテムの選出・定期的な発信 - 公開されたポストモーテム議論の場 - チャットチャンネル、メールグループなど - ポストモーテムの読書会 - 過去の興味深いポストモーテムの振り返り - 新旧を問わず - ディザスターロールプレイング - ポストモーテムに書かれている役割をエンジニアたちが演じ、過去のポストモーテムの再現する

ポストモーテムプロセスのフィードバック

ポストモーテムのプロセス自体に無駄がないかを見直し、改善を行う。 - ポストモーテムは業務の支援となっているか? - トイルが発生しすぎていないか? - ツールは適切か?新しい開発が必要か?

参考: SRE本 p180

将来的な価値を考える

参考: SRE本 P181

準備コストと価値に対する理解

ポストモーテム文化を組織に導入する上での最大の課題は、準備コストよりも価値があるのか?と考える人が多いかもしれないこと。

これを解決するには以下のような対策が考えられる - ワークフローに落とし込む - よいポストモーテムを書くことは評価されるように - ピアボーナスを与える - 上位のリーダーたちの承認と参加を奨励する

理解に関しては - ポストモーテムプロセスのフィードバックを行う - 継続的な育成と強化 - 将来的な価値を考える

などと合わせて考えることが理解を得る助けとなる

参考: SRE本 P179

ポストモーテムの例

SRE本 p507

参考