أنشئ تقرير ما بعد الحادث خالٍ من اللوم من جدول زمني خام للحادثة
Why this prompt matters
Post-mortems that skip the root cause / contributing factors distinction produce action items that fix symptoms, not systems. Teams that consistently write shallow post-mortems repeat the same incident categories — different service, same missing circuit breaker, same absent alert. The blameless framing is also not optional: post-mortem cultures where engineers feel implicitly blamed for outages produce teams that under-report near-misses, which means preventable P0s go undetected until they actually happen.
What we use it for
Your team resolved a P0 outage two hours ago. The on-call engineer has a Slack thread, a PagerDuty timeline, and some runbook notes — but nothing structured. You need a complete post-mortem document ready for the engineering all-hands tomorrow morning, and you have thirty minutes.
Prompt
Act as a senior site reliability engineer with extensive experience writing blameless post-mortems for high-traffic systems.
Context:
The following incident has been resolved. You have been given a raw timeline of events, the contributing factors identified during the retrospective, and the remediation steps the team took.
Incident details:
- Service affected: [SERVICE NAME, e.g., "Payment API", "User Authentication Service"]
- Severity: [P0/P1/P2]
- Duration: [START TIME] to [END TIME] ([TOTAL DURATION])
- Customer impact: [DESCRIBE IMPACT, e.g., "100% of checkout requests failed for 47 minutes"]
- Raw timeline / notes: [PASTE YOUR INCIDENT NOTES, SLACK THREAD, OR RUNBOOK ENTRIES HERE]
Task:
Write a complete, professional blameless post-mortem document following Google's SRE post-mortem culture principles. The document must identify system failures and process gaps — never individual blame.
Constraints:
- Use blameless language throughout. Say "the deployment pipeline did not have a gate for X" not "the engineer forgot to check X"
- Distinguish between root cause (the fundamental system or process failure) and contributing factors (conditions that allowed the root cause to have impact)
- Action items must be specific, ownable, and measurable — not vague ("improve monitoring")
- Do not pad the timeline. Only include events that affected the incident trajectory
- If the raw notes contain blame language, neutralize it in the post-mortem
Output Format:
**Incident Post-Mortem: [INCIDENT TITLE]**
**Date:** [DATE] **Severity:** [P0/P1/P2] **Duration:** [X hours Y minutes] **Status:** Resolved
**Executive Summary**
[2-3 sentences: what failed, for how long, customer impact, and status]
**Timeline** (all times in [TIMEZONE])
[Chronological bullet list: time → what happened / who detected it / what action was taken]
**Root Cause**
[Single paragraph identifying the fundamental system or process failure. No blame language.]
**Contributing Factors**
[Bulleted list: each factor that allowed the root cause to cause impact]
**Impact**
[Quantified: % of users affected, requests failed, revenue exposure if known, SLA breach if applicable]
**What Went Well**
[Honest assessment: detection speed, communication, rollback success, etc.]
**What Went Poorly**
[Honest, blameless assessment: slow escalation paths, missing runbooks, unclear ownership, etc.]
**Action Items**
| Priority | Action | Owner Role | Due |
|---|---|---|---|
| P0 | [Specific action] | [Role, not name] | [DATE] |
**Lessons Learned**
[2-3 sentences: the systemic lesson this incident teaches, framed for future decision-making]Result
**Incident Post-Mortem: Payment API Outage — Connection Pool Exhaustion** **Date:** 2026-05-14 **Severity:** P0 **Duration:** 1 hour 23 minutes **Status:** Resolved
**Executive Summary** A deployment of Payment API v4.17.2 introduced a database query that did not release connections under timeout conditions, exhausting the PostgreSQL connection pool within 34 minutes of deploy. Checkout requests failed for 100% of users between 14:02 and 15:25 UTC. No payment data was lost; all in-flight transactions were rolled back cleanly by PostgreSQL.
**Timeline** (all times UTC) - 13:31 — Payment API v4.17.2 deployed to production via automated pipeline. Health checks passed. - 13:58 — First spike in payment_api_p99_latency (180ms → 2.4s). Alert fires to on-call channel. - 14:02 — db_pool_available_connections hits zero. Checkout endpoint returns 503 for all requests. - 14:09 — On-call engineer identifies connection pool exhaustion in Datadog. Escalates to database team. - 14:17 — Database team identifies new query in v4.17.2 as source of leaked connections. Initiates rollback. - 14:31 — Rollback to v4.17.1 begins after second-engineer sign-off. - 14:37 — Rollback complete. Connection pool begins recovering. - 15:25 — All metrics return to baseline. Incident resolved.
**Root Cause** The new getPaymentMethodDetails() query introduced in v4.17.2 opened a database transaction but did not include a timeout handler for the network I/O path. Under elevated latency from the payment provider API (which was experiencing independent slowdowns), the transaction blocked indefinitely without releasing its connection back to the pool. With no connection limit per query type and no circuit breaker on the I/O path, the pool exhausted completely within 34 minutes of the deploy.
**Contributing Factors** - The CI pipeline had no static analysis check for connection lifecycle management in database queries - The staging environment uses a connection pool 10× smaller than production, masking this failure mode at staging load - The rollback approval process requires a second engineer sign-off with no defined fast-path escalation, adding 14 minutes to recovery time - No alert existed for connection pool availability below 20%; the first alert fired only after the pool was already fully exhausted
**Impact** - 100% of checkout requests failed for 83 minutes - ~14,200 failed checkout attempts (at pre-incident rate of 171/min) - No SLA breach (threshold: 120 minutes for P0 incidents) - No payment data loss; all in-flight transactions rolled back cleanly
**What Went Well** - Latency alerting fired within 27 minutes of deploy — well within the team's 30-minute detection target - Database team identified the specific query responsible within 8 minutes of escalation - The rollback itself executed in 6 minutes with no secondary failures or data inconsistencies
**What Went Poorly** - The rollback approval gate added 14 minutes with no fast-path for P0 incidents during peak hours - No connection pool headroom alert meant the service transitioned from 100% available to 0% with no intermediate warning - The PR review checklist does not include connection lifecycle verification for database query changes
**Action Items** | Priority | Action | Owner Role | Due | |---|---|---|---| | P0 | Add alert for db_pool_available_connections below 30% | On-Call Infrastructure | 2026-05-21 | | P0 | Define P0 fast-path rollback approval (max 5 min, auto-escalate) | Engineering Manager | 2026-05-21 | | P1 | Add CI linting rule for unguarded database transactions | Backend Platform | 2026-05-28 | | P1 | Scale staging connection pool to 1:3 ratio of production | Database Reliability | 2026-06-04 | | P2 | Add timeout handler to all payment provider I/O paths | Payments Team | 2026-06-11 |
**Lessons Learned** Connection lifecycle management requires both explicit code review verification and automated tooling — relying on developer attention alone is insufficient at current deployment frequency. The contributing factors identified here (missing alerts, undersized staging, slow rollback gates) are systemic patterns worth auditing across all critical services, not just the payment stack.
مراجعات ما بعد الحادث التي تُكتب تحت ضغط الوقت — أو بعد أيام من زوال الأدرينالين — غالباً ما تكون سطحية. تفتقد العوامل المساهمة، وتتجاوز الأنماط النظامية التي جعلت الحادثة ممكنة، أو تُسند اللوم بصمت عبر اختيار الكلمات. هذا الـ Prompt يفرض الهيكل الذي يجعل مراجعات ما بعد الحادث مفيدة فعلاً: لغة خالية من اللوم، فصل السبب الجذري عن العوامل المساهمة، وعناصر عمل محددة بما يكفي لإغلاقها.
الـ Prompt
انسخ النص كاملاً. استبدل كل حقل بين قوسين بتفاصيل حادثتك الفعلية قبل تشغيله.
تصرف كمهندس موثوقية مواقع أولي (Senior SRE) لديه خبرة واسعة في كتابة مراجعات ما بعد الحادث الخالية من اللوم للأنظمة ذات الحركة العالية.
السياق:
تم حل الحادثة التالية. حصلت على جدول زمني خام للأحداث، والعوامل المساهمة التي تم تحديدها أثناء المراجعة اللاحقة، وخطوات المعالجة التي قام بها الفريق.
تفاصيل الحادثة:
- الخدمة المتأثرة: [اسم الخدمة، مثلاً "واجهة الدفع API"، "خدمة مصادقة المستخدم"]
- الخطورة: [P0/P1/P2]
- المدة: [وقت البداية] إلى [وقت النهاية] ([المدة الإجمالية])
- أثر العميل: [وصف الأثر، مثلاً "فشلت 100% من طلبات الدفع لمدة 47 دقيقة"]
- الجدول الزمني/الملاحظات الخام: [الصق ملاحظات الحادثة، سلسلة Slack، أو إدخالات Runbook هنا]
المهمة:
اكتب مستند مراجعة ما بعد الحادثة احترافيًا كاملاً خالٍ من اللوم باتباع مبادئ ثقافة مراجعة ما بعد الحادثة من Google SRE. يجب أن يحدد المستند فشل النظام وثغرات العملية — وليس إلقاء اللوم على فرد.
القيود:
- استخدم لغة خالية من اللوم في كل مكان. قل "لم تحتوِ خطوة النشر على بوابة لـ X" وليس "نسي المهندس التحقق من X"
- ميّز بين السبب الجذري (فشل النظام أو العملية الأساسي) والعوامل المساهمة (الظروف التي سمحت للسبب الجذري بأن يُحدث أثرًا)
- يجب أن تكون عناصر العمل محددة وقابلة للامتلاك وقياسية — وليست غامضة ("تحسين المراقبة")
- لا تزيد الجدول الزمني. أدرج فقط الأحداث التي أثرت على مسار الحادثة
- إذا كانت الملاحظات الخام تحتوي على لغة لوم، قم بتحييدها في المراجعة
تنسيق المخرجات:
**مراجعة ما بعد الحادثة: [عنوان الحادثة]**
**التاريخ:** [التاريخ] **الخطورة:** [P0/P1/P2] **المدة:** [X ساعة Y دقيقة] **الحالة:** تم الحل
**الملخص التنفيذي**
[2-3 جمل: ما الذي فشل، لمدة كم، أثر العميل، والحالة]
**الجدول الزمني** (جميع الأوقات بـ [المنطقة الزمنية])
[قائمة نقطية زمنية: الوقت ← ما حدث / من اكتشفه / ما الإجراء المتخذ]
**السبب الجذري**
[فقرة واحدة تحدد فشل النظام أو العملية الأساسي. لا توجد لغة لوم.]
**العوامل المساهمة**
[قائمة نقطية: كل عامل سمح للسبب الجذري بأن يُحدث أثرًا]
**الأثر**
[مُقدَّر: نسبة المستخدمين المتأثرين، الطلبات الفاشلة، التعرض للعائدات إن أمكن، خرق اتفاقية مستوى الخدمة إن وُجد]
**ما سار بشكل جيد**
[تقييم صادق: سرعة الاكتشاف، التواصل، نجاح التراجع، إلخ.]
**ما سار بشكل سيء**
[تقييم صادق خالٍ من اللوم: مسارات تصعيد بطيئة، غياب Runbook، ملكية غير واضحة، إلخ.]
**عناصر العمل**
| الأولوية | الإجراء | صاحب الدور | تاريخ الاستحقاق |
|---|---|---|---|
| P0 | [إجراء محدد] | [دور، وليس اسم] | [التاريخ] |
**الدروس المستفادة**
[2-3 جمل: الدرس النظامي الذي تعلمه هذه الحادثة، مصاغ لاتخاذ القرارات المستقبلية]لماذا كل قسم موجود
التمييز بين السبب الجذري والعوامل المساهمة هو أهم قرار هيكلي في هذا الـ Prompt. بدونه، تكتب الفرق "قاعدة البيانات سقطت" كسبب جذري وتعتبر المهمة منتهية. الـ Prompt يفرض عليك التعمق: ما هي خاصية النظام التي جعلت "سقوط قاعدة البيانات" ممكنًا؟ هل لم يكن هناك قاطع دارة (Circuit Breaker)؟ لا إنذار لمجموعة الاتصالات (Connection Pool)؟ بيئة اختبارية أصغر حجمًا أخفت الفشل؟ هذه هي العوامل المساهمة — وهي ما تُصلحه فعلاً.
اللغة الخالية من اللوم هي قيد وليس تفضيلًا أسلوبيًا. الـ Prompt يوجه النموذج صراحة لتحييد لغة اللوم إذا ظهرت في الملاحظات الخام التي تلصقها. هذا مهم لأن سلاسل Slack الخام وقنوات الحوادث مليئة بعبارات مثل "دفع جون الكود دون مراجعة الـ Runbook" — والتي، عند إعادة صياغتها نظاميًا، تصبح "لم تحتوِ قائمة التحقق للنشر على خطوة مراجعة إلزامية للـ Runbook لنوع الخدمة هذا." الإصلاح هو نفسه، لكن إحدى الصيغتين تبني ثقافة يبلغ فيها المهندسون عن الحوادث الوشيكة (near-misses) والأخرى لا تفعل.
جدول عناصر العمل منسق بـ "الدور" (وليس الاسم) و"تاريخ الاستحقاق" عمدًا. مراجعات ما بعد الحادث التي تسند عناصر العمل لأفراد بأسمائهم تفشل عندما يغادر ذلك الشخص الفريق. الإسناد إلى دور يجعل العنصر دائمًا عبر التغييرات التنظيمية. تواريخ الاستحقاق تفرض الأولوية؛ بدونها، تبقى عناصر P1 في قائمة الانتظار لأشهر.
مثال على المخرجات
إليك المخرجات التي ينتجها هذا الـ Prompt عند إعطائه حادثة استنزاف مجموعة اتصالات (Connection Pool Exhaustion) كمدخل:
مراجعة ما بعد الحادثة: انقطاع واجهة الدفع — استنزاف مجموعة الاتصالات
التاريخ: 2026-05-14 الخطورة: P0 المدة: ساعة و23 دقيقة الحالة: تم الحل
الملخص التنفيذي
نشر الإصدار v4.17.2 من واجهة الدفع أدخل استعلام قاعدة بيانات لم يحرر الاتصالات تحت ظروف انتهاء المهلة (Timeout)، مما استنزف مجموعة اتصالات PostgreSQL بالكامل خلال 34 دقيقة من النشر. فشلت طلبات الدفع لـ 100% من المستخدمين بين الساعة 14:02 و15:25 UTC. لم تُفقد أي بيانات دفع؛ تم التراجع عن جميع المعاملات الجارية بشكل نظيف.
السبب الجذري
الاستعلام الجديد getPaymentMethodDetails() فتح معاملة قاعدة بيانات لكنه لم يتضمن معالج مهلة (Timeout Handler) لمسار الإدخال/الإخراج الشبكي. تحت زمن استجابة مرتفع من واجهة مزود الدفع، كانت المعاملة تتعطل إلى أجل غير مسمى دون تحرير اتصالها. مع عدم وجود حد للاتصالات لكل نوع استعلام وعدم وجود قاطع دارة (Circuit Breaker)، استُنزفت المجموعة بالكامل خلال 34 دقيقة.
العوامل المساهمة
- لم تحتوِ خطوة CI على فحص تحليل ثابت لإدارة دورة حياة الاتصالات في استعلامات قاعدة البيانات
- تستخدم البيئة الاختبارية مجموعة اتصالات أصغر بـ 10 مرات من الإنتاج، مما منع ظهور نمط الفشل هذا في اختبارات الحمل على نطاق البيئة الاختبارية
- تطلبت عملية الموافقة على التراجع توقيع مهندس ثانٍ، مما أضاف 14 دقيقة لوقت الاسترداد دون تعريف مسار تصعيد في حال عدم توفر المُعتمِد
- لم يوجد إنذار لتوفر مجموعة الاتصالات أقل من 20% — أول إنذار انطلق فقط بعد استنزاف المجموعة بالكامل
عناصر العمل (مقتطف)
- P0: إضافة إنذار هامش مجموعة الاتصالات عند 30% متبقية — البنية التحتية المناوبة (On-Call Infrastructure) — 2026-05-21
- P0: تحديد موافقة المسار السريع للتراجع لحوادث P0 (بحد أقصى 5 دقائق) — مدير الهندسة (Engineering Manager) — 2026-05-21
- P1: إضافة قاعدة تدقيق (Linting Rule) إلى CI للمعاملات غير المحمية في قاعدة البيانات — منصة الواجهة الخلفية (Backend Platform) — 2026-05-28
الحصول على أقصى استفادة من الـ Prompt
جودة المخرجات تتناسب طرديًا مع جودة المدخلات الخام. سلسلة Slack تحتوي على طوابع زمنية وتفاصيل تقنية ستنتج جدولًا زمنيًا أدق من ملخص فقري. إذا كانت ملاحظات الحادثة ضعيفة، أضف تمريرة ثانية: بعد المخرجات الأولية، تابع بـ "الآن دقق عناصر العمل — هل أي منها غامض أو غير قابل للامتلاك؟ إذا كان الأمر كذلك، أعد كتابتها لتكون محددة." سيقوم النموذج بتضييقها.
بالنسبة لأنواع الحوادث المتكررة (انقطاعات النشر، مشاكل قواعد البيانات، أعطال واجهات الطرف الثالث)، يمكنك بناء مكتبة من مراجعات ما بعد الحادثة السابقة واطلب من النموذج مقارنة الجديدة: "إليك ثلاث مراجعات سابقة من خدمة الدفع لدينا. ما العوامل المساهمة التي تظهر في هذه الحادثة الجديدة والتي ظهرت أيضًا في السابقة؟" هذا يكشف أنماطًا نظامية تفوتها المراجعات الفردية.
Claude Opus 4.7 ينتج أكثر إعادة صياغة خالية من اللوم دقة — فهو يكتشف بمهارة لغة اللوم الخفيفة التي قد يتركها GPT-4o أحيانًا. للحوادث المباشرة ذات الملاحظات الخام النظيفة، يكفي Claude Sonnet 4.6 أو GPT-4o بسرعة وكفاءة.