یک incident رخ می‌ده. سیستم چند دقیقه یا چند ساعت down می‌شه. تیم جمع می‌شه، مشکل رو حل می‌کنه، سرویس برمی‌گرده. حالا چی؟
خیلی از تیم‌ها همین‌جا متوقف می‌شن. مشکل حل شده، پس بریم سراغ کار بعدی. اما این دقیقاً همون جایی‌ست که بیشترین یادگیری از دست می‌ره.
Postmortem چیست و چرا مهم است
Postmortem یک سند مکتوبه که بعد از هر incident قابل‌توجه نوشته می‌شه و به این سوالات جواب می‌ده:
- دقیقاً چه اتفاقی افتاد؟ (timeline دقیق)
- چرا اتفاق افتاد؟ (root cause)
- چطور کشف شد؟ (توسط مانیتورینگ یا کاربر؟)
- چطور حل شد؟
- چه چیزی رو باید تغییر بدیم تا دوباره اتفاق نیفته یا سریع‌تر کشف بشه؟
اما یک postmortem خوب فقط یک گزارش فنی نیست — یک ابزار فرهنگی‌ست.
چرا کلمه‌ی «Blameless» این‌قدر مهم است
وقتی یک incident رخ می‌ده، غریزه‌ی طبیعی تیم‌ها اینه که بپرسن «کی این کار رو کرد؟». این سوال به نظر منطقی میاد، ولی نتیجه‌ی واقعیش مخرب است:
- مهندسی که مسئول یک اشتباه بوده، دفعه‌ی بعد اطلاعات رو پنهان می‌کنه یا کمتر ریسک می‌کنه (که یعنی نوآوری کمتر)
- تمرکز از «چطور سیستم اجازه داد این اتفاق بیفته» به «کی مقصره» منحرف می‌شه
- تیم به‌جای رفع مشکل ریشه‌ای (که معمولاً سیستمیه، نه فردی)، فقط یک نفر رو سرزنش می‌کنه و فردا همون مشکل به شکل دیگه‌ای برمی‌گرده
فرهنگ Blameless Postmortem این فرض رو می‌گیره: هیچ مهندسی عمداً سیستم رو خراب نمی‌کنه. اگه یک نفر یه دستور اشتباه زد، سوال درست این نیست که «چرا اشتباه کردی» بلکه اینه: «چرا سیستم ما اجازه داد یک اشتباه انسانی این‌قدر آسیب بزنه؟» و «چطور می‌تونیم safety net بسازیم که دفعه‌ی بعد جلوی این اشتباه رو بگیره؟»
قالب عملی یک Postmortem خوب
۱. خلاصه‌ی اجرایی (Executive Summary)
دو تا سه جمله که می‌گه چه اتفاقی افتاد، چقدر طول کشید، و چه کسانی/چه بخشی تحت تاثیر قرار گرفتن. این بخش برای کسایی نوشته می‌شه که وقت خوندن کل سند رو ندارن.
۲. Timeline دقیق
هر رویداد مهم با زمان دقیق (بر اساس timestamp لاگ‌ها و مانیتورینگ، نه حافظه): - چه زمانی مشکل شروع شد - چه زمانی کشف شد (و توسط چی — آلارم خودکار یا گزارش کاربر؟) - چه زمانی تیم واکنش نشون داد - چه زمانی مشکل رفع شد
فاصله‌ی بین «شروع مشکل» و «کشف مشکل» یکی از مهم‌ترین معیارهاییه که باید بهبود بدید — این دقیقاً همون چیزیه که observability خوب حلش می‌کنه.
۳. Root Cause Analysis
نه سطحی («سرور crash کرد») بلکه عمیق («سرور به خاطر memory leak در فلان بخش کد که تحت بار بالا رخ می‌ده crash کرد، و چون آلارم memory usage تنظیم نشده بود، تا زمان crash کامل کشف نشد»). تکنیک «۵ چرا» (پرسیدن مداوم «چرا» تا رسیدن به علت ریشه‌ای) اینجا خیلی کاربردیه.
۴. Action Items مشخص و قابل پیگیری
هر postmortem باید به چند اقدام مشخص ختم بشه، هر کدوم با: - یک مسئول مشخص - یک تاریخ هدف - یک تعریف واضح از «انجام شد»
اقدامات نباید کلی باشن («مانیتورینگ رو بهتر کنیم») بلکه باید مشخص باشن («آلارم memory usage با آستانه‌ی ۸۰٪ روی سرویس X تنظیم بشه»).
۵. چیزهایی که خوب پیش رفت
این بخش رو خیلی از تیم‌ها فراموش می‌کنن. اگه مانیتورینگ زود مشکل رو تشخیص داد، یا runbook مشخص باعث سرعت واکنش شد، این‌ها رو هم مستند کنید — چون این‌ها الگوهایی هستن که باید تکرارشون کنید.
چطور فرهنگش رو بسازیم
داشتن یک قالب کافی نیست. فرهنگ Blameless با چند اقدام عملی ساخته می‌شه:
- رهبری باید الگو باشه: اگه یک مدیر یا لید تیم توی جلسه‌ی postmortem شروع کنه به سرزنش، کل فرهنگ فرو می‌ریزه. باید صریح گفته بشه که هدف یادگیریه، نه مجازات.
- همه‌ی postmortemها باید در دسترس کل تیم باشن: پنهان کردن گزارش‌ها فقط این پیام رو می‌ده که چیزی برای شرم وجود داره.
- حتی near-miss ها رو مستند کنید: مشکلاتی که نزدیک بود به incident واقعی تبدیل بشن ولی نشدن، معمولاً ارزان‌ترین منبع یادگیری هستن.
نتیجه‌ی یک فرهنگ سالم Postmortem
تیم‌هایی که این فرهنگ رو جدی می‌گیرن معمولاً این‌ها رو تجربه می‌کنن:
- کاهش تکرار همون نوع incident در بلندمدت
- کاهش زمان کشف مشکلات مشابه در آینده (چون الگوها مستند شدن)
- افزایش اعتماد تیم به گزارش دادن مشکلات کوچک، قبل از اینکه به بحران بزرگ تبدیل بشن
جمع‌بندی
Postmortem بدون سرزنش، مستندسازی نیست — یک سرمایه‌گذاریه. هر incident که درست تحلیل بشه، سیستم و تیم شما رو یک پله مقاوم‌تر می‌کنه. تیمی که از هر شکست یاد می‌گیره، در بلندمدت خیلی کمتر شکست می‌خوره.
اگه تیم شما هنوز runbook یا فرآیند مشخصی برای incident response نداره، این دقیقاً یکی از چیزهاییه که تیم Dropp Tempo توی مدل on-call و پشتیبانی‌مون برای مشتری‌ها پیاده می‌کنه — از تشخیص سریع تا مستندسازی که واقعاً استفاده می‌شه.