|
| 1 | +# Incident Postmortem Playbook |
| 2 | + |
| 3 | +This document describes when YieldVault writes postmortems, how action items are |
| 4 | +tracked, and the publication workflow for finalized reports. |
| 5 | + |
| 6 | +--- |
| 7 | + |
| 8 | +## 1. When to write a postmortem |
| 9 | + |
| 10 | +Write a postmortem for any of the following: |
| 11 | + |
| 12 | +| Trigger | Examples | |
| 13 | +|---------|----------| |
| 14 | +| **Severity 1–2 incidents** | Full outage, data loss risk, contract pause | |
| 15 | +| **DR events** | Database restore, RPC failover, backend redeploy under pressure | |
| 16 | +| **Security incidents** | Key compromise, unauthorized access, exploit attempt | |
| 17 | +| **Contract upgrades with issues** | Failed upgrade, rollback, unexpected state | |
| 18 | + |
| 19 | +Lower-severity incidents may use a shortened report at the Incident Commander's |
| 20 | +discretion, but must still capture root cause and action items. |
| 21 | + |
| 22 | +--- |
| 23 | + |
| 24 | +## 2. Timeline |
| 25 | + |
| 26 | +| Phase | Deadline | Deliverable | |
| 27 | +|-------|----------|-------------| |
| 28 | +| During incident | Real-time | [Incident Report Template](./runbooks/templates/incident-report.md) | |
| 29 | +| Post-incident | Within 48 hours | Postmortem draft | |
| 30 | +| Publication | Within 5 business days | Published report in `docs/incidents/` | |
| 31 | + |
| 32 | +These deadlines align with the [Quick Reference](./runbooks/QUICK_REFERENCE.md) |
| 33 | +post-mortem checklist and [Incident Response Runbooks](./runbooks/README.md). |
| 34 | + |
| 35 | +--- |
| 36 | + |
| 37 | +## 3. Roles |
| 38 | + |
| 39 | +| Role | Responsibility | |
| 40 | +|------|----------------| |
| 41 | +| **Incident Commander** | Owns timeline accuracy and severity classification | |
| 42 | +| **Author** | Drafts postmortem from incident report and logs | |
| 43 | +| **Reviewer** | DevOps or Security lead validates technical accuracy | |
| 44 | +| **Release engineer** | Ensures security-sensitive details follow disclosure rules | |
| 45 | + |
| 46 | +--- |
| 47 | + |
| 48 | +## 4. Creation flow |
| 49 | + |
| 50 | +1. **Start from template** — Copy |
| 51 | + [`docs/runbooks/templates/post-mortem.md`](./runbooks/templates/post-mortem.md). |
| 52 | +2. **Optional draft location** — Save work-in-progress to |
| 53 | + `docs/incidents/drafts/INCIDENT-XXX-slug.md` (not indexed until published). |
| 54 | +3. **Gather inputs**: |
| 55 | + - Live [incident report](./runbooks/templates/incident-report.md) |
| 56 | + - Grafana / PagerDuty timelines |
| 57 | + - Backend diagnostics bundle (`/api/diagnostics/bundle`) |
| 58 | + - Relevant runbook steps exercised |
| 59 | +4. **Complete all sections** — Summary, impact metrics, timeline, root cause, |
| 60 | + action items table, lessons learned. |
| 61 | + |
| 62 | +--- |
| 63 | + |
| 64 | +## 5. Action-item tracking |
| 65 | + |
| 66 | +Every postmortem must include an **Action Items** table with: |
| 67 | + |
| 68 | +| Column | Required | |
| 69 | +|--------|----------| |
| 70 | +| ID | Yes (`AI-001`, `AI-002`, …) | |
| 71 | +| Action | Yes | |
| 72 | +| Owner | Yes | |
| 73 | +| Priority | Yes (P0/P1/P2) | |
| 74 | +| Due Date | Yes | |
| 75 | +| Tracking Issue | Yes — link to GitHub issue | |
| 76 | +| Status | Yes (Open / In Progress / Done) | |
| 77 | + |
| 78 | +**Workflow:** |
| 79 | + |
| 80 | +1. File each action item as a GitHub issue referencing the incident ID. |
| 81 | +2. Link the issue number in the postmortem table. |
| 82 | +3. Review open action items in the quarterly runbook review |
| 83 | + ([runbooks README](./runbooks/README.md) §Continuous Improvement). |
| 84 | + |
| 85 | +--- |
| 86 | + |
| 87 | +## 6. Review and redaction |
| 88 | + |
| 89 | +Before publication: |
| 90 | + |
| 91 | +- [ ] Incident Commander and Reviewer sign off on timeline and severity |
| 92 | +- [ ] Remove credentials, PII, and unreleased vulnerability details |
| 93 | +- [ ] For **security incidents**, follow the 48-hour minimum disclosure window |
| 94 | + described in [Release Notes Playbook](./release-notes-playbook.md) §8 |
| 95 | +- [ ] Confirm customer-facing language is approved if published externally |
| 96 | + |
| 97 | +--- |
| 98 | + |
| 99 | +## 7. Publication flow |
| 100 | + |
| 101 | +1. **Open a PR** adding the finalized report to `docs/incidents/` using the |
| 102 | + naming convention: `YYYY-MM-DD-INCIDENT-XXX-short-slug.md` |
| 103 | +2. **Set `Status: Published`** in the report header (drafts must not remain in |
| 104 | + `docs/incidents/` root) |
| 105 | +3. **Update the index** in [`docs/incidents/README.md`](./incidents/README.md) |
| 106 | +4. **Link action items** — Ensure every `AI-xxx` row has a merged or open GitHub |
| 107 | + issue |
| 108 | +5. **Update runbooks** if new failure modes were discovered |
| 109 | +6. **Announce** in `#yieldvault-incidents`; update status page if user-facing |
| 110 | +7. **Merge PR** after reviewer approval |
| 111 | + |
| 112 | +CI validates postmortem structure via `scripts/validate-postmortem.sh`. Install the |
| 113 | +workflow from [`docs/ci/postmortem-docs.workflow.yml`](./ci/postmortem-docs.workflow.yml) |
| 114 | +into `.github/workflows/` to enable automated PR checks. |
| 115 | + |
| 116 | +--- |
| 117 | + |
| 118 | +## 8. DR test reports |
| 119 | + |
| 120 | +Disaster recovery exercises that surface runbook gaps should file a |
| 121 | +[DR Test Report](./runbooks/templates/dr-test-report.md). Significant findings |
| 122 | +warrant a full postmortem using the same publication flow. |
| 123 | + |
| 124 | +--- |
| 125 | + |
| 126 | +## 9. Runbook feedback loop |
| 127 | + |
| 128 | +After each published postmortem: |
| 129 | + |
| 130 | +1. Identify runbook sections that were unclear or missing |
| 131 | +2. Open a follow-up PR updating the relevant runbook under `docs/runbooks/` |
| 132 | +3. Record the change in the postmortem's **Runbook Updates Required** section |
| 133 | + |
| 134 | +--- |
| 135 | + |
| 136 | +**Last Updated:** June 26, 2026 |
| 137 | +**Maintained By:** DevOps Team |
| 138 | +**Issue:** [#769](https://github.com/Junirezz/YieldVault-RWA/issues/769) |
0 commit comments