ポストモーテムプロセス

全ての重大インシデント (SEV-2/SEV-1) では、ポストモーテムによるフォローアップが必要です。 誰も責めず、何が問題でインシデントを引き起こしたか、今後に再発を防止するために何ができるかを詳細に記述します。 インシデント対応プロセス自身も含める必要があります。

オーナーの指名#

最初のステップはポストモーテムのオーナーを指名することです。 これはインシデントコマンダーが、重大インシデントの通話の終わり、または直後に指名します。 オーナーはポストモーテムを記録し、ログを精査し、追加調査を管理し、全ての関係者に情報を提供する責務があります。 詳しい手順は次で説明します。

オーナーの責務#

ポストモーテムのオーナーになると次のような責務があります。

• ポストモーテムのミーティングを（共有カレンダーに）設定し、関係者を招待します（SEV-1の場合は3営業日以内、SEV-2の場合は5営業日以内が望ましいです）。
• インシデントの調査をして、他のチームから調査の助けになりそうな人を選びます。
• 必要な内容をまとめてページを更新します。
• 追加調査用のJIRAチケットを作成しします（あなたの責務はチケットを作成することで、追加調査することではありません）。
• ミーティングの前に、関係者とポストモーテムのレビューをします。
• ポストモーテムのミーティングで、議題について説明します（インシデントコマンダーがミーティングを進行するが、実際はあなたがほとんど喋ります）。
• ポストモーテムの結果を内部に伝えます。

ステータス#

私たちのポストモーテムには「ステータス」フィールドがあります。 このフィールドの使い方は以下のとおりです。

Status	Description
Draft	ポストモーテムの内容をまだ書いてる段階です。
In Review	ポストモーテムの内容が書き終わり、レビュー可能な状態です。
Reviewed	ミーティングが終了し、内容がレビューされて確認できました。 もし外部への告知が必要な場合は、ステータスページを更新するようカスタマーサポートに連絡します。
Closed	ポストモーテムに関する新たな作業はありません（まだ解決してない問題はJIRAによって追跡します）。 もし外部への告知がない場合は、ミーティング終了後このステータスをスキップできます。 もし外部への告知が必要な場合は、サポートチームが告知を出したあとに、サポートチームがステータスを更新します。

ポストモーテム#

ポストモーテムのオーナーに指名されたときは、ポストモーテムの作成と関連情報を更新しましょう。

1. （もしインシデントコマンダーがまだ作って無ければ）ポストモーテムを作成します。

2. SEV-1の場合は3営業日以内に、SEV-2の場合は5営業日以内に、ポストモーテムのミーティングを設定します。 ポストモーテムを書き始める前にミーティングを設定したほうが良いです。

   • 共有カレンダーに「インシデントポストモーテムミーティング」を追加します。

3. 持っている全ての情報を記入します。

   • タイムラインに主眼を置いて書くべきです。
     • タイムラインには、重要なステータスや影響の変化や、応答者によって行われた主要なアクションを記入すべきです。
   • Slackの履歴をさかのぼり、誰が対応したかを記入します。
     • インシデントコマンダーと記録係もリストに入れます。

4. より詳細な情報をポストモーテムに記入します。

   • タイムラインのそれぞれの項目では、データのもととなるメトリクスやサードパーティのページを特定します。 これはDataDog上のグラフや、SumoLogicの検索結果、ツイートなどへのリンクです。 タイムラインで説明しようとしているデータなら何でも構いません。
   • インシデントの通話録音へのリンクを追加します。

5. インシデントの解析を行います。

   • 全てのインシデントに関するデータを収集します。 なにが原因で、どれくらいの顧客に影響があったか、などです。
     • どうやってデータを収集したかを他の人がわかるように、全てのコマンドやクエリを残します。
   • インシデントの根本原因を特定します（なにが起こって なぜ 発生したのか）。

6. 顧客に送られる告知メッセージを書きます。これは顧客に送る前に、ポストモーテムのミーティングで確認します。

   • 本当にサービスが停止している場合を除いて、「停止（outage）」という言葉を使わないでください。 代わりに「インシデント」または「サービス劣化」などの用語を使ってください。 顧客は「停止」という言葉を見ると、最悪の事態を想定します。
   • 過去のポストモーテムから、どのような文章を送るべきか確認できます。

7. 内部関係者でポストモーテムの内容やスタイルをレビューするためにSlackにリンクを送ります。 これは設定したミーティングの24時間より前を目指すべきです。

   • 経験豊富なポストモーテム執筆者が、どれくらい詳細に書くかや、ポストモーテムの内容についてレビューしてくれます。 これでミーティング中の無駄な時間を回避します。

8. ポストモーテムのミーティングに出席します（詳細は後述します）。

9. 追加調査のためのJIRAチケットを作成します（あるいはチケットを作成前に方針を決めたい場合は、議論のためのメモを書き留めておきます）。

   • Slackの履歴を遡り、全てのTODOを拾い上げます。
   • 全てのチケットに、緊急度のレベルと日付タグを付与します。
   • インシデント再発を減らすための全てのアクション。
     • （これはトレードオフですが、それでも構わないです。ときには費やす労力が結果に見合わないこともあります）。
   • インシデント対応プロセスを良くするためのアクションを特定します。
   • チケットをあまり作りすぎないようにしましょう。絶対に対応すべきP0/P1のチケットのみを作成します。

10. インシデントから何を学んだかを社内に報告します。

    • 関係するステークホルダーに、結果と主に何を学んだかをメールします。
    • ポストモーテムへのリンクを含めます。

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

このミーティングは通常15-30分で、ポストモーテム手順のまとめのために実施します。 何が発生して、どうすればよかったか、必要な追加調査について話し合います。 このミーティングの目的は、事実や解析、推奨事項に関する認識をあわせ、信頼性に関する問題が発生していることを広く認知してもらいます。

ポストモーテムのミーティングには、以下の人たちを招待すべきです。

• 常に参加
  • インシデントコマンダー
  • インシデントコマンダーの補佐（いれば）
  • インシデントに関するサービスオーナー
  • インシデントに関わった主要なエンジニアや対応者
  • 影響のあったシステムのエンジニアリングマネージャー
  • 影響のあったシステムのプロダクトマネージャー
• 任意参加
  • 顧客連絡（SEV-1のみ）

インシデントコマンダーが会議を進行して議題が逸れないようにします。 しかしオーナーがポストモーテムを通してほとんど喋ることになります。

ミーティングの主な議題は以下のとおりです

1. タイムラインの要約と確認。
2. 重要な点と変わった点の要約。
3. 問題をどうすれば気づくことができたかの議論。
   • カナリアでは発見できなかったか？
   • テストや、ロードテストの環境で発見できなかったか？
4. 顧客への影響について議論。顧客からのコメントなどは無かったか。
5. 作成されたアクションの各項目をレビューし、適切かどうか、追加でやるべきかどうかを議論。

例#

他社のポストモーテムの例をいくつか列挙します

• Stripe
• LastPass
• AWS
• Twilio
• Heroku
• Netflix
• GOV.UK Rail Accident Investigation
• A List of Post-mortems!

参考文献#

• Advanced PostMortem Fu and Human Error 101 (Velocity 2011)
• Blame. Language. Sharing.