Step by Step

以下は、概要レベルでのポストモーテム実施のステップです。各ステップの実施方法の詳細を以下に示します。

1. インシデントの新しいポストモーテムを作成する。
2. 「インシデントポストモーテムミーティング」共有カレンダーに、必須および任意の参加者のために、必要な時間枠内でポストモーテムミーティングをスケジュールする。
3. ステータス/影響の重要な変化と、対応者が取った主要なアクションをインシデントタイムラインに記入する。
   • タイムラインの各項目について、データの出所となるメトリクスまたはサードパーティのページを含める。
4. インシデントを分析する。
   • 表面的な原因と根本的な原因を特定する。
   • 技術とプロセスの両方を考慮する。
5. フォローアップアクションのチケットを作成する。
6. 外部向けメッセージを作成する。
7. レビューを依頼する。
8. ポストモーテムミーティングに参加する。
9. ポストモーテムを共有する。

オーナーの責任#

重大なインシデント対応の終了時、またはその直後に、インシデントコマンダーは対応者の一人をポストモーテムのオーナーとして選出します。選出されたオーナーはインシデントコマンダーから直接通知を受けます。ポストモーテムの作成は最終的には共同作業となりますが、単一のオーナーを選出することで確実に完了させることができます。

ポストモーテムのオーナーは以下の責任を負います：

• 共有カレンダーにポストモーテムミーティングをスケジュールし、関連する人々を招待する（Sev-1の場合は3日以内、Sev-2の場合は5営業日以内にスケジュールする必要があります）。
• インシデントを調査し、調査に必要な他のチームのメンバーを招集する。
• ページに必要なすべてのコンテンツが更新されていることを確認する。含めるべき内容についてはテンプレートを参照してください。
• フォローアップチケットを作成する（オーナーはチケットの作成のみ責任を負い、解決までのフォローアップは責任外です）。
• 会議前に適切な関係者とポストモーテムの内容をレビューし、ポストモーテムミーティングでトピックを進行する（インシデントコマンダーが会議を「運営」し、議論を軌道に乗せますが、あなたが最も多く話すことになるでしょう）。
• ポストモーテムの結果を社内に伝える。

ポストモーテムのオーナーはポストモーテム文書を作成し、関連するすべての情報を更新します。

管理#

1. 文書を作成する。
2. すべての対応者を追加する。
3. 会議をスケジュールする。

まだインシデントコマンダーが実施していない場合、ポストモーテムオーナーの最初のステップは、インシデントのための新しい空のポストモーテムを作成することです。Slackの履歴を確認して対応者を特定し、彼らにポストモーテムの作成を手伝ってもらえるようにページに追加します。インシデントコマンダー書記官も足しましょう。インシデント対応のレコーディングへのリンクを追加します。

次に、インシデントの複雑さに応じて30分から1時間のポストモーテムミーティングをスケジュールします。プロセスの最初に会議をスケジュールすることで、SLA内にポストモーテムが完了することを確保します。会議はSev-1の場合は3暦日以内、Sev-2の場合は5営業日以内にスケジュールする必要があります。すべての参加者にとって最適な時間を見つけることを心配する必要はありません。優先事項はこの時間枠内にスケジュールすることであり、参加者はそれに応じてスケジュールを調整する必要があります。PagerDutyでは、すべてのポストモーテムミーティングを「インシデントポストモーテムミーティング」共有カレンダーにスケジュールし、組織全体で関心のある人々が簡単に見つけられるようにしています。

ポストモーテムミーティングには以下の人々を招待します：

• 必須
  • インシデントコマンダー。
  • インシデントコマンダーをシャドーイングしていた担当者（いた場合）。
  • インシデントに関与したサービスオーナー。
  • インシデントに関与した主要なエンジニア/対応者。
  • 影響を受けたシステムのエンジニアリングマネージャー。
  • 影響を受けたシステムのプロダクトマネージャー。
• 任意
  • カスタマーリエゾン（Sev-1インシデントの場合のみ）。

PagerDutyのポストモーテムには、ポストモーテムが現在プロセスのどの段階にあるかを示す「ステータス」フィールドがあります。以下は、値の説明と使用方法です。

タイムラインの作成#

まずタイムラインに焦点を当てます。インシデント中に起きた事実を文書化します。何をすべきだったか、何をすべきでなかったか、インシデントの原因は何かといった評価は避けてください。ここで事実のみを提示することで、非難を避け、より深い分析をしやすくします。またインシデントは、対応者が気づいて対応を開始する前に始まっていた可能性があることに注意してください。タイムラインにはステータス/影響の重要な変化と対応者が取った主要なアクションを含めます。後知恵バイアスを避けるため、タイムラインはインシデント発生前の時点から始め、解決から逆算するのではなく、時系列に沿って進めてください。

Slackのインシデントログを確認して、対応中に行われた重要な決定やアクションを見つけます。後から考えると知っておきたかったけれども、インシデント中には知らなかった情報も含めましょう。このような追加情報は、影響を受けたサービスに関連するモニタリング、ログ、デプロイを確認すると見つけることができます。モニタリングについては分析の段階で精査しますが、まずはインシデントに関連する重要なイベントをタイムラインに追加し、インシデントのステータスと影響の変化も含めてください。

タイムラインの各項目について、データの出所となるメトリクスまたはサードパーティのページを特定します。これにより各ポイントが明確に説明され、意見ではなく事実に基づいていることが保証されます。これはモニタリンググラフへのリンク、ログ検索、Xのポスト、その他タイムラインで説明しようとしているデータポイントを示すものであれば何でも構いません。

影響の文書化#

影響はいくつかの観点から説明する必要があります：

• 影響が発生していた期間はどれくらいですか？言い換えれば、ユーザー/顧客が影響を受けた時間の長さはどれくらいですか？
  • 影響の長さは対応作業の長さとは異なる場合があることに注意してください。影響は、問題が検出されてインシデント対応が開始される前にすでに始まっていた可能性があります。
• 何人の顧客が影響を受けましたか？
  • サポートは、影響を受けたすべての顧客のリストを必要とする場合があり、個別に連絡を取ることがあります。
• 何人の顧客がインシデントについてサポートに連絡しましたか？
• どの機能がどの程度影響を受けましたか？
  • 製品に特化したビジネスメトリクスで影響を定量化します。PagerDutyの場合、これにはイベント送信、処理の遅延、通知配信の遅延などが含まれます。

インシデントの分析#

インシデント中に何が起きたかを理解したら、さらに時間をさかのぼってインシデントにつながった要因を探します。テクノロジーは、継続的に変化する関係のネットワーク（組織的、人的、技術的）を伴う複雑なシステムです。

リチャード・クック博士の論文「How Complex Systems Fail」によれば、複雑なシステムは障害から強く防御されている一方、一見無害な問題が独自に組み合わさった結果、壊滅的な障害を引き起こします。さらに、明白な障害には複数の欠陥が必要なため、「根本原因」を特定することは根本的に間違っています。複雑なシステムの大きな障害には単一の根本原因はなく、障害が可能になる環境を作り出す複数の要因の組み合わせがあります。ポストモーテムオーナーのインシデント分析の目標は根本原因を特定することではなく、この障害を引き起こした可能性のある複数の要因を理解することです。

クックはまた、「根本原因」を見つける努力はシステムの理解を反映するものではなく、むしろ発生した出来事に対して特定の局所的な力を非難する文化的な必要性を反映していると述べています。非難がないことは効果的なポストモーテムにとって不可欠です。個人の行動が根本原因と見なされるべきでは決してありません。効果的な分析では、人間の行動よりも深いところまで掘り下げを行います。誰かのミスが障害に寄与した場合、分析においては個人への非難を避けるためにこれを匿名化する意味があります。どのチームメンバーも同じミスを犯す可能性があると仮定しましょう。クックによれば、「あらゆる実務担当者の行動は実のところギャンブルであり、不確実な結果に直面しながら行われる行為です。」

ポストモーテムオーナーは、影響を受けたサービスのモニタリングを調査することから分析を始めるべきです。インシデントが始まった時点とその前に、突然のスパイクやフラットラインがなかったか異常を探します。データがどのように収集されたかを他の人が確認できるように、データを検索するために使用したコマンドやクエリ、グラフ画像、モニタリングツールからのリンクをこの分析と一緒にまとめてください。このサービスや動作に対するモニタリングがない場合は、モニタリングの構築をこのポストモーテムのアクションアイテムとしてしましょう。以下のアクションアイテムの作成で詳しく説明します。

インシデントの原因を特定するもう一つの有効な戦略は、本番以外の環境でインシデントを再現することです。現象の切り分けを行えるように変数を変更して実験を行います。入力の一部を変更または削除した場合も、まだインシデントは発生しますか？

このレベルまで分析を行うと、インシデントの表面的な原因が明らかになります。次に、このような事象が発生しうる形でシステムが設計された背景を尋ねます。なぜ、当時それらの設計判断が最良の決定だと思われたのでしょうか？これらの質問に答えていくと、根本原因を明らかにするのにつながります。

以下は、ポストモーテムオーナーが特定の問題の種類を特定するのに役立つ質問です：

• これは単独のインシデントですか、それとも直近よく発生しているものの一部ですか？
• これは特定のバグや予想された種類の障害だったか、またアーキテクチャ的に予想していなかった問題の種類を明らかにしましたか？
• 過去にチームがやらないことを選択した作業で、このインシデントに寄与したものはありましたか？
• 過去に類似または関連するインシデントがあったかどうかを調査します。このインシデントは、システムのより大きな範囲の傾向を示すものですか？
• サービスの使用を継続的に成長させ拡大するにつれて、この種の問題は悪化/より発生しやすくなりますか？

根本原因ではないかもしれませんが、分析においてはプロセスも考慮してください。人々が協力し、コミュニケーションを取り、作業をレビューする方法がインシデントに寄与しましたか？これはまた、インシデント対応プロセスを評価し改善する機会でもあります。インシデント中の対応プロセスで何がうまくいき、何がうまくいかなかったかを考えてみてください。

ポストモーテムに調査結果の要約を書きます。チームは会議での議論を通じてさらなる学びを見つけ、追加の原因を特定するかもしれませんが、オーナーは生産的な議論を確保するために可能な限り事前作業と文書化を行ういましょう。

質問項目#

以下は、深い分析を促進するためのリストです。非難を避け、学習を促進するために、「誰が」や「なぜ」ではなく、「どのように」「何が」という質問をしてください。

フォローアップアクション#

インシデントの原因を特定した後、これが再び起こらないようにするために何をする必要があるかを考えます。分析に基づいて、この特定のインシデントではなく、この種の問題の発生を減らすための提案もあるかもしれません。

同じインシデントや類似のインシデントが再び発生する可能性を完全に排除することは不可能（または努力に値しない）かもしれないので、将来のインシデントの検出と軽減をどのように改善できるかも考慮してください。この種の問題に対してはより良いモニタリングとアラートが必要で、将来より迅速にチームが対応できるようにする必要がありますか？この種のインシデントが再び発生した場合、チームはどのように重大度や対応時間を抑えることができますか？インシデント対応プロセスを改善するためのアクションも特定することを忘れないでください。Slackのインシデント履歴を確認して、インシデント中に提起されたすべてのToDoアイテムを見つけ、これらもチケットとして文書化されていることを確認してください。（この段階では、チケットを作成するだけです。ポストモーテムミーティングの前にタスクを完了させる必要はありません。）

提案されたすべてのフォローアップアクションのチケットをタスク管理ツールで作成します。すべてのチケットに重大度レベルと日付タグを付けて、チケットシステムで簡単に見つけて報告できるようにします。チームのプロダクトオーナーが他の作業と比較してタスクの優先順位を付けるのに十分な情報があり、最終的な担当者がタスクを完了するのに十分な情報を得られるよう、チケットにできるだけ多くのコンテキストと提案された方向性を提供してください。

;login: マガジンの記事「Postmortem Action Items: Plan the Work and Work the Plan」で、John Lunney・Sue Lueder・Betsy Beyerは、Googleがポストモーテムのアクションアイテムを迅速かつ簡単に完了させるためにどのように書いているかを説明しています。彼らはすべてのアクションアイテムを実行可能、具体的、かつ範囲が限定されたものとして書くことを勧めています。

• 実行可能： 各アクションアイテムを動詞で始まる文として表現します。アクションは有用な結果をもたらすようにします。
• 具体的： 各アクションアイテムの範囲をできるだけ狭く定義し、範囲内と範囲外を明確にします。
• 範囲が限定的： 各アクションアイテムを、オープンエンドまたは継続的なタスクではなく、いつ終了したかを示すように表現します。

出典: ;login: Spring 2017 Vol. 42, No. 1.

チケットを作成する前に議論が必要なフォローアップアクションの提案がある場合は、これらの項目をポストモーテムミーティングの議題に追加するメモを作成しましょう。場合によってはチームの検証や明確化が必要な提案かもしれません。会議でこれらの項目を議論すると、どのように進めるのが最善かを決定するのに役立つでしょう。

あまりにも多くのチケットを作成しないように注意してください。P0/P1のタスク、つまり絶対に対処すべきタスクのみを作成しましょう。ここにはいくらかトレードオフが発生することがありますが、それは問題ありません。ときには、インシデントの再発を減らす可能性のあるアクションを実行するために必要な労力に対して、ROIが見合わないケースもあります。その場合も、その決定をポストモーテムに文書化しておく価値があります。チームがアクションを実行しないことを選択した理由を理解するのは、やったことが役に立たなかったのではないかという無力感を避けるのにも役立つでしょう。

チケットを作成する人自身がそれを完了する責任を負うわけではないことに注意しましょう。チケットは影響を受けたサービスを所有するチームのプロジェクトでオープンされます。フォローアップアクションの責任を負うすべてのチームの代表者を少なくとも1人、ポストモーテムミーティングに招待します。

対外メッセージの作成#

対外メッセージの目的は、技術や組織に関する独自情報を明かすことなく、何が起こったのか、それに対して何をしているのかについて顧客に十分な情報を提供することで信頼を築くことです。内部分析の一部は主に内部の読者に利益をもたらすもので、外部のポストモーテムに含める必要はありません。

外部ポストモーテムは、内部ポストモーテムに使用される情報を要約し、整理したものです。外部ポストモーテムには以下の3つのセクションが含まれます：

1. 要約： インシデントの期間と観測可能な顧客への影響を要約した2〜3文。
2. 何が起きたか：
   • 原因の要約。
   • インシデント中の顧客向け影響の要約。
   • インシデント中の緩和努力の要約。
3. これに対して何をしているか： アクションアイテムの要約。

ヒント：本当に完全な停止でない限り、「停止（outage）」という言葉を使用することは避けてください。代わりに「インシデント」または「サービス低下」という言葉を使用してください。顧客は一般的に「停止」を見て最悪の事態を想定します。

この時点で、外部ポストモーテムはまだ送信または公開すべきではないドラフトであることに注意してください。送信前にポストモーテムミーティングでレビューする必要があります。

ポストモーテムレビュー#

PagerDutyでは、スタイルと内容に関するポストモーテムのレビューに活用できる経験豊富なポストモーテム作成者のコミュニティがあります。これにより、会議中の無駄な時間を減らせます。会議がスケジュールされる少なくとも24時間前に、Slackへポストモーテムへのリンクを投稿してフィードバックを受け取ります。

以下は、私たちが主に確認する事柄です：

• 十分な詳細を提供していますか？
• 何が間違っていたかを指摘するだけでなく、問題の根本的な原因を掘り下げていますか？
• 「何が起きたか？」と「どう修正するか」を分けていますか？
• 提案されたアクションアイテムは意味がありますか？十分に範囲が限定されていますか？
• ポストモーテムは適切に書かれ、理解可能ですか？
• 対外メッセージは顧客の共感を得られそうな内容ですか、それとも反感を引き起こす可能性がありますか？

ポストモーテムのレビューは誤字脱字を細かく指摘することではありません（ただし、対外メッセージにスペルや文法エラーがないことを確認してください）。重要なのは、ポストモーテムから最大の利益を得るために、ポストモーテムに価値ある変更を加えるための建設的なフィードバックを提供することです。