ابزار تولید گزارش پستمورتم بدون سرزنش: تبدیل یادداشتهای خام جدول زمانی به گزارش ریشهیابی
Why this prompt matters
Postmortems that name names or stay vague about root cause do double damage: they discourage engineers from reporting incidents honestly next time, and their action items — things like 'be more careful' or 'improve monitoring' — never actually get assigned or completed, so the same failure mode recurs months later. A blameless report with specific, owned action items is the difference between an incident that makes the system stronger and one that just gets filed away.
What we use it for
An on-call engineer has a payments API outage from 2am with only scattered Slack timestamps and half-remembered details, and needs to turn that into a clear, professional postmortem before Monday's leadership review — without spending two hours writing it from scratch or accidentally writing something that reads like it's blaming a specific teammate.
Prompt
Act as a senior site reliability engineer who runs blameless postmortem reviews and has written hundreds of incident reports that engineering leadership actually reads and acts on. Context: Here are my raw incident notes — Slack messages, timestamps, monitoring alerts, and half-formed recollections, not yet organized: [PASTE YOUR RAW INCIDENT NOTES HERE] Additional context: The affected system was [SERVICE OR SYSTEM AFFECTED]. The customer-facing impact was [DESCRIBE IMPACT, OR 'UNKNOWN' IF NOT YET ASSESSED]. The people involved in the response were [ROLES INVOLVED, e.g. on-call engineer, database admin, incident commander — not names]. Task: 1. Reconstruct a precise, chronological timeline from the raw notes, with timestamps where available. Explicitly flag any gap where you had to infer information or where something is missing, using [NEEDS CONFIRMATION]. 2. Identify the root cause. Distinguish clearly between the triggering event (what set the incident off) and the underlying systemic cause (what allowed it to happen or made it possible) — these are usually different and both matter. 3. Identify contributing factors separately from the root cause — things that made the incident worse, slower to detect, or slower to resolve. 4. Write the entire report in a blameless tone: describe what systems and processes did, not what individual people did wrong. Attribute actions to roles or systems, never to named individuals, even if names appear in my raw notes. 5. Generate specific, assignable action items. Each one must include an owner placeholder and be concrete enough that someone could start work on it immediately without further clarification. 6. Include a genuine "what went well" section based on real details in the notes — not generic filler. Constraints: - Never name or imply blame toward a specific individual, even if my notes do. - Never invent timeline details not supported by the notes — flag uncertainty instead of guessing. - Produce no more than 5 action items. Force prioritization rather than a laundry list. - Write the summary section for an audience that includes non-engineering stakeholders, but keep the timeline technically precise for engineers. Output Format: ## Incident Summary [2-3 sentences: what happened, customer impact, duration] ## Timeline [Chronological, timestamped events] ## Root Cause [Triggering event vs. underlying systemic cause, clearly separated] ## Contributing Factors [Bulleted list] ## What Went Well [Bulleted list] ## Action Items [Numbered list, maximum 5, each with Owner: [PLACEHOLDER] and a concrete deliverable]
Result
Incident Summary
A 47-minute outage in the checkout payments API prevented approximately 12% of transaction attempts from completing between 02:14 and 03:01 UTC. Customers saw a generic error on payment submission; no charges were duplicated or lost, but an estimated 340 checkout attempts failed and required customers to retry.
Timeline
02:14 — Payment API error rate begins climbing, first automated alert fires (P2, not yet paged).
02:19 — Error rate crosses 10% threshold, PagerDuty escalates to P1, on-call engineer acknowledges.
02:23 — On-call engineer confirms payment-service pods are returning 503s; connection pool to the primary database appears exhausted. [NEEDS CONFIRMATION: exact connection pool metric value at this time was not recorded in notes.]
02:31 — Database admin joins the incident channel, identifies a long-running analytics query holding connections open on the primary replica used by payment-service.
02:38 — Long-running query manually terminated; connection pool begins recovering.
02:45 — Error rate drops below 5%, but does not fully recover.
02:52 — Incident commander identifies that payment-service's connection pool size was not reset after the spike, requiring a rolling restart.
03:01 — Rolling restart completes, error rate returns to baseline, incident resolved.
Root Cause
Triggering event: A scheduled analytics query against the production database replica ran significantly longer than expected, holding open a large share of available database connections.
Underlying systemic cause: The analytics workload and the payment-service's transactional workload share the same database replica and the same connection pool ceiling, with no isolation or query timeout enforced on the analytics side.
Contributing Factors
- No automated query timeout exists for scheduled analytics jobs, allowing a single query to hold connections indefinitely.
- Payment-service's connection pool did not automatically shed and reset after the underlying resource pressure cleared, requiring a manual rolling restart to fully recover.
- The initial alert at 02:14 was P2 severity and did not page anyone for 5 minutes, delaying the start of active response.
What Went Well
- The database admin correctly diagnosed the connection pool exhaustion and identified the specific offending query within 8 minutes of joining the incident.
- No data integrity issues occurred — no duplicate or lost transactions despite the connection pressure.
Action Items
- Add a hard query timeout (recommend 60 seconds) for all scheduled analytics jobs running against production replicas. Owner: [DATABASE TEAM LEAD]
- Move analytics workloads to a dedicated read replica, isolated from payment-service's connection pool. Owner: [INFRASTRUCTURE LEAD]
- Adjust payment-service's initial alert severity for error-rate anomalies from P2 to P1 to reduce time-to-page. Owner: [ON-CALL ENGINEERING MANAGER]
- Add automatic connection pool health checks that trigger a self-healing restart when pool exhaustion is detected, removing the need for manual intervention. Owner: [PAYMENT-SERVICE TECH LEAD]
اکثر گزارشهای پستمورتم به یکی از دو شیوهی قابلپیشبینی شکست میخورند. یا شبیه گزارشهای سرزنشآمیز هستند — «مهندس کشیک هشدار را نادیده گرفت» — که به مهندسان میآموزد به جای گزارش صادقانه، حوادث را پنهان کنند. یا از نظر فنی دقیقاند، اما اقدامات اصلاحیای تولید میکنند که آنقدر مبهماند که هیچکس هرگز انجامشان نمیدهد: «بهبود مانیتورینگ»، «دقت بیشتر»، «افزودن تستهای بیشتر». شش ماه بعد، همان الگوی شکست دوباره تکرار میشود.
این پرامپت بر پایهی چند تصمیم طراحی مشخص ساخته شده تا از هر دو شکست جلوگیری کند.
چرا علت اصلی و عوامل مشارکتکننده از هم جدا میشوند
بیشتر یادداشتهای حوادث، «آنچه حادثه را آغاز کرد» را با «آنچه آن را ممکن ساخت» درهم میآمیزند. یک کوئری کند یک محرک است. نبود محدودیت زمانی (timeout) برای کوئری، علت سیستمی است که اجازه داد یک کوئری کند به قطعی سرویس تبدیل شود. رفع صرف محرک (حذف همان یک کوئری بد) از تکرار این مشکل جلوگیری نخواهد کرد. این پرامپت مدل را مجبور میکند این دو را بهصراحت از هم جدا کند تا اقدامات اصلاحی حاصل به سیستم بپردازند، نه فقط به نشانهها.
چرا زبان سرزنشآمیز ممنوع است، حتی وقتی یادداشتهای منبع بیطرفانه نیستند
یادداشتهای خام حوادث که در لحظه نوشته میشوند، اغلب واقعاً حاوی اسامی افراد و سرزنش مستقیم هستند — این طبیعی است، نه یک نقص شخصیتی. وظیفهی این پرامپت آن است که این موارد را پیش از آنکه به سندی دائمی تبدیل شوند که مدیران میخوانند و سالها به آن ارجاع میدهند، به زبانی مبتنی بر نقش و سیستم برگرداند. این همان چیزی است که نوشتن صادقانهی یک پستمورتم را از همان ابتدا امن میکند: هیچکس نگران نیست که نامش در سندی بیاید که همهجا بازارسال میشود.
چرا سقف اقدامات اصلاحی اهمیت دارد
فهرست اقدامات اصلاحی بیحد، فهرستی است که هیچکس اجرایش نمیکند. محدود کردن آن به پنج مورد، اولویتبندی واقعی را اجباری میکند — مدل باید تصمیم بگیرد کدام اصلاحات واقعاً به ریشهی اصلی و عوامل مشارکتکننده میپردازند، به جای اینکه گزارش را با هر ایدهی بهبود دور از موضوعی که در جریان حادثه مطرح شده پر کند.
چرا ابهامات علامتگذاری میشوند به جای اینکه نادیده گرفته شوند
گزارش پستمورتمی که با اطمینان دربارهی جزئیاتی صحبت میکند که در واقع هیچکس تأییدشان نکرده، از گزارشی که نسبت به خلأهای خود صادق است بدتر است. علامت [NEEDS CONFIRMATION] مانع از آن میشود که مدل اعداد یا مُهرهای زمانی دقیقنمایی را اختراع کند که در یادداشتهای اصلی وجود نداشتهاند — این الگوی شکست رایجی است که وقتی از AI خواسته میشود ورودی درهموبرهم را حرفهای جلوه دهد، پیش میآید.
یادداشتهای خام حادثهی خود را paste کنید، سه فیلد زمینه را پر کنید، و خروجی، سندی آماده برای بررسی مدیریت خواهد بود — با جدول زمانی، تحلیل واقعی ریشهای، و اقدامات اصلاحیای که میتوان همین امروز روی آنها کار کرد.