postmortem

振り返り

完了または停止した目標、セッション、変更、インシデントについて、実際の意図、結果、判断の根拠に基づき、明示的な遡及的因果関係の質問に回答します。 中間分析が明示的に求められた場合は、区切りとなる時点と未完了の確認事項を明記してください。結論が示すのはその期間の状況であり、最終結果を確定するものではありません。 関連項目：まだ実行されていない計画がどのように失敗し得るかは事前検討を、完了した変更が受け入れ基準を満たすかどうかは検証を参照してください。

最初の確認：相関か、原因か？

呼び出し元が持ち込んだ主張も含め、因果関係に関するあらゆる主張を仮説として扱ってください。主張を相関から原因へと昇格させるには、次の3つすべてが必要です。

• 明示されたメカニズム：その条件が結果を引き起こした具体的な経路を、読者が対象と照らして確認できる形で示すこと。
• 判別力のある証拠：そのメカニズムが予測し、少なくとも1つの妥当な代替仮説が予測しない観察結果。
• 反実仮想の検証：主張が誤りであれば何が異なっていたはずかを示し、実際に異なっていたことを示す根拠を引用すること。

事後的な修正の原因帰属、つまり「Xを変更したら障害が止まった。したがってXが原因だった」という主張だけでは、これらの要件を何も満たしません。症状が断続的に発生していた可能性や、復旧と変更に共通する未観測の原因があった可能性があるためです。そのような主張は相関として扱い、依然として成り立つ代替仮説を挙げ、判別実験を提案してください。立証されていない原因に基づく推奨は、裏付けのある変更ではなく、その実験として提示します。主張を退ける場合にも、判別力のある証拠、または証拠と矛盾するその主張の予測が必要です。それに満たないものは、相関または不明のままです。

プロンプト

Postmortem last Thursday's release: the deploy needed four attempts and two
rollbacks before it stuck. Using the deploy log, the CI runs and the incident
channel notes, which failures were avoidable and what caused each one?
Answer inline.

重要な制約

• 振り返りは遡及的な因果分析であり、一般的な学びをまとめる場でも、コードの受け入れ判定でもありません。コードの判定を振り返りまで待たせてはならず、両方が求められた場合は、Plan のコードと振り返りを分けるルールに従って、それぞれを別個に扱ってください。 中間分析が求められた場合を除き、結果が判明するまで待ってください。
• 受け入れ検証を再実行したり、既存の判定を変更したり、不足している証拠を捏造したりしてはなりません。既存の verdict.v2 は任意の証拠です。存在しなくても、停止済みまたは未検証の対象は除外されません。
• 以後の対応は呼び出し元が担うため、証拠を書き換えたり、トラッカーの状態を操作したり、残りの計画を変更したり、作業を再開したり、ルールを昇格させたりしてはなりません。
• 分析が空または決定的でなくても問題ありません。妥当な場合は、変更を推奨しないでください。確実性や教訓を捏造してはなりません。

ワークフロー

1. 質問、受け入れられた意図、対象の同一性、実際の結果、利用可能な判断を、正確な ID（コミット、チェック、メッセージ、既存の判定）とともに固定します。不足している証拠は明示したままにします。インシデントの場合、意図は期待されるサービスの動作または SLO、判断はアラートとチェックです。ステップ 2 では、逸脱が起きる前のデプロイ、設定変更、上流イベント、またはシグナルの欠落を探します。
2. 主張が依拠する範囲に限ってタイムラインを再構築し、提供された動作、失敗または停止した作業、プロセスの出力を区別します。修正または停止については、受け入れられた動作から最初に観測可能な逸脱が起きた箇所と、その直前の指示、ツールの結果、または入力不足を特定します。条件が似た成功事例があれば比較し、なければその比較がないことを明記します。呼び出し元が求めた一時停止は、期待される動作です。隠れた作成者の推論は事実ではありません。判断が欠けていることは、PASS でも FAIL でもありません。
3. それぞれの因果関係の主張を、上記の最初のチェックに照らして検証します。必要な検証や互換性対応と、回避可能なやり直しを区別します。レビューが繰り返されたというだけでは、無駄の証明にはなりません。 入力に同じ対象の以前の事後分析が含まれている場合、新たな提案を出す前に、その推奨事項を検討します。提示された作業以降の証拠をもとに、適用済み、一部適用、未適用、または不明を示します。変更が承認済み、保留中、または未承認のいずれだったかを保持します。適用の証拠がないことは、適用に失敗したことを意味しません。対象となる失敗の再発は、観測された場合にのみ報告します。未適用の助言が繰り返されている場合は、単に繰り返すのではなく、既知の障害要因または未解決の疑問を挙げます。未適用であることだけでは、原因、責任、または助言の有効性のいずれも証明されません。
4. 時間やトークンに関する主張では、情報源、期間、単位、含まれるアクターと除外されるアクター、不確実性を明記します。経過時間、並行して行われた作業、集計範囲を区別します。裏付けとなる証拠なしに、合計を無駄、削減額、または金額と同一視しないでください。
5. 以下の出力を返して終了します。提案は実装の許可にはなりません。

出力仕様

• 特に指定がなければ、簡潔なインライン Markdown を使用します。報告書やワークシートは必須ではありません。

  Question: <the causal question>
  Inputs: <intent, outcome and evidence, with exact ids>; missing: <gaps>
  Timeline: <only the events the claims depend on>
  Claims:
  - <claim>: supported | correlation | rejected | unknown
    mechanism / discriminating evidence / counterfactual: <each, cited, or "none">
    alternatives still standing: <rivals the evidence cannot rule out>
  Accounting (if claimed): <source, interval, units, actors, uncertainty>
  Unknowns: <what would settle them>
  Earlier advice (if supplied): <recommendation> - applied | partly applied | not applied | unknown, <evidence>
  Changes (at most three, or "no change"): <change> - <its limit, or the experiment that tests it>
  

• 各変更は、すでに修正済みのコードを再修正するのではなく、通常はステップ 2 で見つかった指示、ツールの結果、または入力不足など、次の実行で直面するものを対象にします。回避可能な見落としの種類に応じて、対策を選びます。

  • 機械的なミス（誤ったパス、コマンドの実行漏れ、禁止された呼び出し）：リンタールール、テスト、フック、または設定ガード。まず、リポジトリのチェックコマンド、フック、CI を確認します。既存のチェックが実行されなかった、または失敗を検出できなかった場合、そのチェックを変更対象とし、重複するものは作りません。コード内にこのようなチェックを設ける箇所がない場合は、フォローアップとしてアーキテクチャを挙げ、問題点を具体的に示します。
  • 判断ミス：標準、ランブックの手順、または指示文のいずれかを 1 つ提案します。これを記述する作業は、別途承認が必要なメモリー作業です。
  • 事実の発見に時間がかかった場合：検索を開始した場所へのポインターを 1 つ示します。事実にアクセスできなかった場合は、ログの記録やアラートなど、次回その事実を確認できる方法を示します。アクセス方法の変更には、呼び出し元の許可が必要です。

• 要求された場合に限り、呼び出し元が指定する保護された非 Git の外部ストレージに YYYY-MM-DD-postmortem-<topic>.md を保存します。保存先の指定がない場合、リポジトリへの保存は許可されません。既存の要求済み証拠は、所有者のポリシーに従って保持します。

• 教訓の編集、サポート、保存先開示のレビューは、いずれも別途承認が必要なメモリー作業です。振り返りの証拠だけで、自らの格上げはできません。