Postmortem Process

すべての重大インシデント（SEV-2/1）に対し、私たちはポストモーテムを行います。他者を責めることなく、なにがうまくいかずインシデントが引き起こされたのかを正確に把握できる詳細な説明と、将来同じようなインシデントが発生するのを防ぐための手順のリストを設けます。インシデント対応プロセスそのものも、ポストモーテムの対象となります。

ポストモーテムを無視しないこと

インシデント後のポストモーテムを無視する失敗をしないようにしましょう。ポストモーテムなしでは、何がうまくできていてどこに改善の余地があるのか、そしてなによりも次に同じ失敗をすることを回避する方法に気づけません。うまく設計され、他者を責めることにないポストモーテムを行えば、チームは継続的に学び、インフラとインシデント対応プロセスを繰り返し改善することができます。

オーナーの決定#

最初の手順は、ポストモーテムのオーナーを決めることです。オーナーの指名はインシデントコマンダーによって、重大インシデント会議の終わりまたは終了後すみやかに行われます。あなたがポストモーテムのオーナーになる場合は、直接インシデントコマンダーから伝えられます。オーナーはポストモーテムを実行し、ログを調べ、事後調査を管理し、関係者全員へ連絡が行き届く状態にします。フォローアップにはSlackを活用してください。以下に詳細な手順を示します：

オーナーの責務#

ポストモーテムのオーナーとして、あなたは以下のことに責任を持ちます。

ステータスの記述#

私たちのポストモーテムには「ステータス」のフィールドがあり、現在ポストモーテムがプロセスのどの段階にあるのかを示します。以下に、各ステータスの意味と使い方を示します。

ステータス 意味
下書き（Draft） ポストモーテムの内容が現在も作成中であることを示します。
レビュー中（In Review） ポストモーテムの内容が作成済で、ポストモーテムのミーティングでレビューする準備ができています。
レビュー済（Reviewed） ミーティングが終了し、内容がレビューされ同意済の状態です。
もし「対外的なメッセージ」があれば、カスタマーサポートチームがメッセージを受けてステータスページを適切にアップデートします。
クローズ（Closed） ポストモーテムにおいて、これ以上のアクションは必要とされていません。（未完了の問題はJIRAでトラックされている状態です）
「対外的なメッセージ」がなければ、ミーティングが終わりしだい「クローズ」にして構いません。
もし「対外的なメッセージ」がある場合は、サポートチームがメッセージを投稿した後に「クローズ」にアップデートします。

ポストモーテム#

ポストモーテムのオーナーとして指名されたら、文書の作成を開始し、関連情報を更新していく必要があります。

  1. （もしインシデントコマンダーがまだ実施していなければ）対象インシデント向けに新しいポストモーテムを作成します。

  2. ポストモーテムのミーティングを、SEV-1の場合は3日以内に、SEV-2の場合は5営業日以内に設定します。カレンダー上の話ですから、スケジュール設定はポストモーテムを書き終わる前にやっておきましょう。

    • 共有カレンダー「インシデントポストモーテムミーティング（Incident Postmortem Meetings）」上にミーティングを作成しましょう。

  3. 持っている情報すべてをページに書き出し始めましょう。

    • まずはタイムラインに注力しましょう。
      • タイムラインには、ステータスや影響における重要な変化、そして対応者によって行われた重要なアクションを含めましょう。
    • Slackの履歴に目を通して対応者を特定し、ページに追加します。
      • リストの中で、インシデントコマンダーと書記官を明らかにしましょう。

  4. ポストモーテムへさらに詳細な情報を記載しましょう。

    • タイムラインにおける各項目において、指標を特定するか、データの発生元であるサードパーティのページを明記しましょう。実際にはDatadogへのグラフ、SumoLogicの検索、Xのポストなどといったものが考えられます。タイムライン上で描こうとしているデータポイントを示すものであれば、なんでも構いません。
    • インシデント会議のレコーディングへのリンクを追加します。

  5. インシデントの分析を行いましょう。

    • インシデントに関するあらゆる情報を収集しましょう。何がインシデントを引き起こし、どのくらいの顧客が影響を受けたかといった情報です。
      • データを調べるために実行したコマンドやクエリがページに記載され、どうやってデータが集められたのか他の人たちが見られるようにします。
    • 顧客への影響を把握しましょう。（一般的にはイベントの送信、処理の遅れ、通知の遅延などです）
    • インシデント発生の根底にあった原因を特定しましょう。なにが起きたのかに加えて なぜ 起きたのかが大切です。

  6. 顧客向けに送信される対外メッセージを書きましょう。これは送信前にポストモーテムミーティング中にレビューされます。

    • 本当に全面停止が発生していないかぎり「機能停止（outage）」という言葉の使用は避け、「インシデント（incident）」または「サービス低下（service degradation）」を使いましょう。顧客は「機能停止」を目にすると最悪のケースを想定します。
    • 以前のポストモーテムの例を参照し、どのようなものを送信すべきかを見てみましょう。

  7. ポストモーテムへのリンクをSlackに投稿し、文体や内容を内部関係者にレビューしてもらいます。ミーティング予定の24時間前にできるとよいでしょう。

    • 経験あるポストモーテムの執筆者は、ポストモーテムの詳細レベルや内容についてフィードバックしてくれるでしょう。これにより、ミーティング中の時間の無駄を防ぐことができます。

  8. ポストモーテムミーティングに参加します。（詳しくは下のセクションを参照してください）

  9. フォローアップアクション用のJIRAチケットを作成します。（または、チケットを作成する前に方向性を決定する必要がある場合は、ディスカッションのトピックを書き出しましょう）

    • Slackの履歴を見て、TODO項目になりそうなものを特定します。
    • すべてのチケットに重大度レベルと日付のタグを付与します。
    • あらゆるアクションはインシデントの再発を減らす可能性があるものです。
      • ある程度のトレードオフがあるかもしれませんが、構いません。その労力にROIが見合わない場合もあります。
    • インシデント対応をよりよいものにするであろうアクションを特定します。
    • チケットを作りすぎないように注意してください。通常、私たちが作成対象とするのは、確実に取り組む必要があるP0やP1のもののみです。

  10. インシデントから学べるよう、内部でのコミュニケーションを取ります。

    • 結果と重要な学びを記述して内部の関係者向けにメールします。
    • ポストモーテムへのリンクを記載しましょう。

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

ミーティングは通常15分から30分くらいで、ポストモーテムプロセスを締めくくる意図で行われます。なにが起きたのか、もっと上手くできる余地のあったことはなにか、そして必要なフォローアップアクションを議論する必要があります。事実や分析、推奨されるアクションに齟齬がないかを洗い出し、信頼性の問題を引き起こしている問題に対するより広範な認識を得ることが目的です。

ポストモーテムミーティングには、以下の人たちを招待しましょう。

インシデントコマンダーはミーティングを進行し、議論の焦点がブレることなく軌道に乗るようにします。ただし、ポストモーテムのレポートを説明するため、大部分の話はポストモーテムのオーナーがすることになるでしょう。

一般的なアジェンダは以下のようなものです。

  1. タイムラインを総括し、全員が合意のうえ同じ認識を持っていることを確認します。
  2. 重要なポイントや、通常と異なるような項目をまとめます。
  3. 問題をどのように発見できたかを議論します。
    • 問題は canary で顕在化しましたか？
    • テストや、負荷テスト環境で発見できた可能性のあるものですか？
  4. 顧客影響を議論します。顧客からのコメントがあれば、それも含めましょう。
  5. 作成されたアクションアイテムをレビューし、それが適切か、あるいは他のアクションも必要かを議論します。

実例#

以下に、他社が実施しているポストモーテムを実施している実例を挙げます：

参考情報#