Postmortem پروژه با کمک AI؛ چه چیزی انسانی می‌ماند؟

پاسخ کوتاه

در workflow پیشنهادی این مقاله، AI می‌تواند logها، گزارش‌ها و تصمیم‌های ثبت‌شده را مرتب کند، یک timeline اولیه بسازد و جاهایی را که شواهد با هم نمی‌خوانند علامت بزند. این‌ها نتیجهٔ ارزیابی عملکرد مدل نیستند؛ متن منظم هم علت ریشه‌ای را ثابت نمی‌کند. تیم باید هر ادعا را به منبع وصل کند، فرضیه‌های رقیب را بسنجد، زمینهٔ تصمیم‌ها را بفهمد و برای اقدام اصلاحی owner و موعد بگذارد. پاسخ‌گویی، قضاوت و یادگیری بدون سرزنش همچنان مسئولیت انسان است.

وقتی پروژه‌ای از مسیر خارج می‌شود یا یک incident به کاربر آسیب می‌زند، وسوسهٔ طبیعی این است که سریع بپرسیم «چه کسی اشتباه کرد؟». این سؤال معمولاً از شواهد جلوتر می‌دود. شاید یک تصمیم اشتباه بوده باشد؛ اما ابزار، محدودیت دسترسی، طراحی فرایند، فشار زمانی، دادهٔ ناقص و راهی که سازمان برای هشدار یا توقف ساخته نیز می‌توانند در نتیجه سهم داشته باشند. اگر بررسی فقط نام یک نفر را پیدا کند و سیستم را دست‌نخورده بگذارد، احتمال تکرار باقی می‌ماند.

در این مقاله، منظور از postmortem، مرور ساختاریافتهٔ یک شکست یا incident مهم در تحویل یا بهره‌برداری از محصول است. این اصطلاح را با گزارش روزانهٔ status یا Sprint Retrospective در چارچوب Scrum یکی نمی‌گیریم: راهنمای Scrum هدف retrospective را برنامه‌ریزی برای بهبود کیفیت و اثربخشی می‌داند و آن را بر بازرسی sprint گذشته بنا می‌کند؛ postmortem این مقاله بر impact، timeline، عوامل رخداد و اقدام‌های incident تمرکز دارد. تیم می‌تواند از اصول یادگیری مشابه برای مرور یک پروژهٔ معمولی هم استفاده کند، اما باید دامنه و هدف را روشن کند.

Postmortem چه چیزی را باید روشن کند؟

یک postmortem مفید دست‌کم چهار سؤال را پاسخ می‌دهد: چه اثری رخ داد، چه زمانی و چگونه متوجه شدیم، چه رویدادها و شرایطی در آن نقش داشتند، و برای کاهش احتمال یا دامنهٔ تکرار چه کاری انجام می‌دهیم؟ «چه کسی بود؟» جای هیچ‌کدام از این چهار سؤال را نمی‌گیرد.

راهنمای رسمی Google SRE برای postmortem، مرور اثر، timeline، trigger، عوامل مشارکت‌کننده و اقدام‌های بعدی را در خدمت یادگیری از failure می‌گذارد. «بدون سرزنش» به معنی حذف مسئولیت یا وانمودکردن به نبود اشتباه نیست؛ یعنی به‌جای داوری دربارهٔ نیت افراد، تصمیم را با اطلاعات و محدودیت‌هایی که همان زمان در دسترس بوده‌اند بررسی کنیم و ببینیم سیستم چه شرایطی برای آن تصمیم ساخته بود.

همین تمایز برای پروژه‌های محصول هم مهم است. اگر scope از کنترل خارج شده، صرفاً نگوییم «تیم خوب برآورد نکرد». بررسی کنیم فرض اولیه بر چه شواهدی بنا شده بود، چه تغییری دیر دیده شد، تصمیم‌ها کجا ثبت شدند و مسیر escalation یا بازنگری چه محدودیتی داشت. تحلیل شخصی نباید جای تحلیل سیستم را بگیرد.

AI در workflow پیشنهادی کجا می‌تواند کمک کند؟

در workflow پیشنهادی، اولین کاربرد کم‌ریسک می‌تواند آماده‌سازی شواهد باشد: جمع‌کردن رخدادهای ثبت‌شده از منبع‌های مجاز، یکسان‌کردن قالب زمان، خلاصه‌کردن متن‌های طولانی و گروه‌بندی گزارش‌هایی که به یک بازه یا مؤلفه مربوط‌اند. اگر چند ساعت log، issue، change، پیام on-call و تصمیم ثبت‌شده وجود داشته باشد، مدل می‌تواند پیش‌نویسی برای شروع بررسی فراهم کند؛ این کار باید با نمونهٔ منبع‌ها و دسترسی محدود ارزیابی شود.

کار پیشنهادی دوم، ساخت timeline اولیه است. مدل ممکن است برای هر رویداد زمان، شرح و منبع احتمالی پیشنهاد کند و موردهای بدون timestamp، شکاف زمانی یا تعارض بین دو رکورد را علامت بزند. خروجی باید به رکورد قابل‌دسترسی برگردد؛ جمله‌ای که فقط در خلاصهٔ مدل وجود دارد، مدرک نیست. اگر سیستم نتواند برای یک نکته منبع را نشان دهد، آن نکته باید به‌صورت پرسش باز بماند یا حذف شود.

در همین workflow می‌توان از مدل خواست چند فرضیهٔ رقیب بسازد. مثلاً افت کیفیت ممکن است با تغییر داده، rollout یک نسخه، افزایش بار یا تغییر رفتار کاربر هم‌زمان شده باشد. کنار هم گذاشتن این گزینه‌ها شاید برای بررسی تیم مفید باشد، اما هم‌زمانی علت را ثابت نمی‌کند و این توانایی هم باید روی دادهٔ مجاز و نمونه‌های واقعی همان تیم سنجیده شود. اینجا کار انسان شروع می‌شود: شواهد لازم برای تمایز فرضیه‌ها را پیدا کند، توضیح‌های ناسازگار را کنار بگذارد و بخش‌هایی را که هنوز معلوم نیست صریح نگه دارد.

آنچه GitHub اعلام کرده است

در اعلامیهٔ ۱ اکتبر ۲۰۲۶، GitHub نمونه‌ای از Dynamic workflowهای Copilot را توضیح داد که در بررسی incident، log و telemetry را جمع می‌کند، تحلیل چند سیستم را هماهنگ می‌کند و یافته‌ها را در یک timeline و گزارش جمع‌بندی می‌کند. خود GitHub این قابلیت را public preview معرفی کرده است.

اعلامیهٔ دیگری از همان روز، computer use را در public preview برای Copilot CLI و اپ GitHub Copilot در macOS و Windows توصیف می‌کند.

برداشت تحریریه و محدودیت شواهد

این مثال محصولی نشان می‌دهد GitHub چطور یک workflow از این جنس را معرفی می‌کند؛ اما به‌تنهایی دقت تحلیل، کاهش زمان پاسخ یا بهبود نتیجهٔ یک تیم را اثبات نمی‌کند. وقتی agent می‌تواند از طریق رابط گرافیکی کار کند، مرز دسترسی و ثبت اقدام اهمیت بیشتری پیدا می‌کند: باید روشن باشد کدام محیط مجاز است، پیش از چه عملی تأیید لازم است و چطور می‌توان اقدام را متوقف یا بعداً بازبینی کرد. پیشنهاد این مقاله برای جداسازی مجوز خواندن از مجوز تغییر و تعریف checkpoint انسانی، یک کنترل طراحی است؛ نه نتیجه‌ای که از اعلامیهٔ فروشنده به دست آمده باشد.

از transcript مدل، واقعیت نسازیم

برای هر خط گزارش، یکی از سه برچسب ساده را نگه دارید:

این برچسب‌ها را به واژه‌های مبهمی مثل «احتمالاً ریشهٔ مشکل» تبدیل نکنید. یک گزارش خوب اجازه می‌دهد خواننده ببیند کدام جمله مشاهده است و کدام برداشت. AI ممکن است زبان را روان کند و ناخواسته مرز این دو را محو کند؛ بازبین باید این مرز را دوباره برقرار کند.

یک نمونهٔ واقعی در Google SRE Workbook این مسئله را ملموس می‌کند. در جریان decommission یک rack، مرحله‌ای از automation پس از failure دوباره اجرا شد. در مسیر retry، یک API فهرست خالی را مانند «بدون filter» تفسیر کرد؛ در نتیجه دامنهٔ عملیات از فهرست خالی به همهٔ ماشین‌های واجدشرایط گسترش یافت. منبع، ترکیب رفتار API، نبود idempotency و کنترل‌های ناکافی را توضیح می‌دهد و گزارش می‌کند که اقدام‌های بعدی به کم‌کردن دامنهٔ یک incident مشابه کمک کردند. این case study دربارهٔ AI نیست و دلیلی هم نمی‌دهد که AI حتماً این رخداد را پیشگیری می‌کرد. ارزشش برای این بحث آن است که مرور خوب از سرزنش فردی عبور می‌کند و تغییرهای مشخص در interface و safeguard را پیدا می‌کند.

• ثبت‌شده: مستقیماً در log، issue، پیام یا سند مشخص دیده می‌شود و همان منبع در دسترس reviewer است.
• فرضیه: توضیحی است که با بخشی از شواهد جور درمی‌آید، اما هنوز آزمون کافی نشده است.
• نامعلوم: داده نداریم، رکوردها تعارض دارند یا کسی هنوز آن را بررسی نکرده است.

یک workflow امن و قابل‌بازبینی بسازیم

این workflow هفت گام دارد: از تعیین دامنه و جمع‌آوری مجاز داده شروع می‌شود، به timeline و بررسی فرضیه‌ها می‌رسد و با اقدام‌های دارای owner و مرور گزارش پایان می‌گیرد.

۱. trigger و دامنه را مشخص کنید

قبل از جمع‌آوری داده، بگویید چه رخدادی را مرور می‌کنید و چرا. impact برای چه کاربرانی بود؟ از چه زمانی تا چه زمانی؟ چه محصول، تیم یا مسیر کاری در دامنه است؟ اگر پروژه فقط از برآورد عقب افتاده، شاید یک retrospective هدفمند کافی باشد. اگر داده حذف شده، دسترسی بیش از حد داده شده یا کاربر از دسترس سرویس خارج شده، incident review رسمی‌تر لازم است.

۲. دادهٔ لازم را با مجوز جمع کنید

فهرست sourceهای مجاز، صاحب داده و افراد مجاز به دیدن خروجی را ثبت کنید. logهای تولید می‌توانند token، ایمیل، محتوای مشتری یا اطلاعات امنیتی داشته باشند. تا جای ممکن داده را در منبع اصلی نگه دارید و به مدل فقط بخش لازم و مجاز را بدهید. در خروجی عمومی، شناسهٔ کاربر یا جزئیات محرمانه را بازنشر نکنید. اگر نمی‌توانید provenance و permission یک منبع را توضیح دهید، آن را وارد prompt یا گزارش نکنید.

اگر Agent چند ابزار را فراخوانی می‌کند، مجوز خواندن را از مجوز تغییر جدا کنید. جمع‌آوری incident evidence معمولاً نباید به معنی اجازهٔ تغییر production، بستن issue یا ارسال پیام به کاربر باشد. actionهای حساس باید مجوز محدود، checkpoint انسانی و سابقهٔ قابل‌ردیابی داشته باشند.

۳. timeline را از روی شواهد بسازید

برای هر رخداد زمان، توضیح کوتاه، منبع و سطح اطمینان را بیاورید. منطقهٔ زمانی را یکسان کنید و زمان دریافت داده را با زمان وقوع رویداد اشتباه نگیرید. اگر دو منبع دربارهٔ ترتیب رویدادها اختلاف دارند، هر دو را ثبت کنید تا صاحب incident آن را بررسی کند؛ مدل نباید بی‌صدا یکی را انتخاب کند.

۴. trigger را از عوامل مشارکت‌کننده جدا کنید

Trigger رویدادی است که آغاز یا آشکارشدن مسئله را نزدیک کرده؛ contributing factor شرطی است که اثر را ممکن یا شدیدتر کرده است. برای مثال، یک deploy می‌تواند trigger باشد، اما نبود canary، پیچیدگی rollback، دادهٔ قدیمی یا alert دیرهنگام در دامنه و مدت اثر سهم داشته باشند. یک زنجیرهٔ علت واحد ممکن است تصویر بیش‌ازحد ساده بسازد؛ چند عامل هم‌زمان را بررسی کنید.

۵. فرضیه‌ها را با reviewer انسانی بسنجید

از مدل بخواهید برای هر فرضیه «شاهد موافق، شاهد مخالف، دادهٔ مفقود و راه آزمون» را جدا کند. بعد کسی که به منبع‌ها دسترسی دارد آن‌ها را بررسی کند. اگر evidence کافی نداریم، نتیجهٔ صحیح «هنوز نمی‌دانیم» است. اعتمادبه‌نفس یا لحن قطعی مدل، عدم‌قطعیت داده را از بین نمی‌برد.

۶. اقدام‌ها را سیستمی و قابل‌پیگیری کنید

عبارت‌هایی مثل «دقت بیشتر شود» یا «تیم آموزش ببیند» به‌تنهایی برنامهٔ اصلاح نیستند. هر اقدام باید تغییر مشخص، owner، اولویت، موعد یا trigger بازبینی و روش سنجش داشته باشد. آموزش ممکن است لازم باشد، اما جای تغییر interface ناامن، guardrail ناقص یا alert بی‌اثر را نمی‌گیرد. اگر اقدام قرار است فقط رفتار انسان را جبران کند، بپرسید چه کنترل سیستمی می‌تواند خطا را سخت‌تر یا دامنهٔ آن را کوچک‌تر کند.

۷. گزارش را مرور و با دسترسی مناسب نگهداری کنید

گزارش را کسی که در رخداد نقش داشته و کسی که برای اقدام‌های بعدی پاسخ‌گوست بخوانند. کامل‌بودن impact، قابل‌دفاع‌بودن timeline، عمق عوامل، کیفیت اقدام‌ها، حذف اطلاعات حساس و امکان فهم گزارش برای تیم‌های مرتبط را بررسی کنید. انتشار داخلی هم نیازمند رعایت اصل دسترسی به حداقل اطلاعات لازم است.

نقش AI را بر اساس اختیارش نام‌گذاری کنیم

در بخش AI گزارش، بنویسید مدل چه نقشی داشت؛ سه سطح را مترادف نکنید:

هرچه اختیار بیشتر شود، کنترل و evidence هم بیشتر لازم می‌شود. «انسان در حلقه است» جملهٔ کافی نیست؛ مشخص کنید انسان دقیقاً کدام خروجی را، پیش از چه اقدام برگشت‌ناپذیری و با دسترسی به چه منبعی تأیید می‌کند.

• اتوماسیون: قالب‌بندی، تبدیل timestamp، deduplication یا انتقال رکوردهای مشخص؛ خروجی باید با نمونهٔ منبع قابل‌مقایسه باشد.
• تقویت تحلیل: پیشنهاد timeline، خوشه‌بندی رخدادها یا ساخت فرضیه؛ انسان منبع را باز می‌کند و نتیجه را تأیید یا رد می‌کند.
• Agent اجرایی: چند گام و ابزار را خودش اجرا می‌کند؛ دسترسی، tool call، دادهٔ ورودی، توقف، تأیید و بازپخش باید ثبت‌پذیر باشند.

موفقیت را با یادگیری بسنجیم، نه با سرعت نوشتن

زمان تولید پیش‌نویس می‌تواند یک metric عملیاتی باشد، ولی نشان نمی‌دهد گزارش درست است یا incident تکرار نمی‌شود. کنار آن چند نشانه را بررسی کنید: چند ادعای timeline به source وصل‌اند؛ چند ادعا در بازبینی حذف یا اصلاح شدند؛ چند مورد نامعلوم صریح ثبت شد؛ اقدام‌ها owner و موعد دارند؛ و آیا اقدام‌های تکمیل‌شده واقعاً failure mode را کاهش دادند؟

این metricها را برای قضاوت دربارهٔ عملکرد فردها به کار نبرید. هدف اندازه‌گیری کیفیت فرایند یادگیری و کنترل سیستمی است. اگر مدل سریع‌تر گزارش بنویسد اما reviewer مجبور شود شواهد بیشتری را اصلاح کند، صرفه‌جویی واقعی روشن نیست. اگر action item بسته شد، باز هم باید بعداً بررسی کنید آیا safeguard کار می‌کند یا incident مشابه با شکل دیگری برمی‌گردد.

قالب کوتاه برای شروع فردا

برای اولین postmortem assisted-by-AI، این هفت بخش کافی است:

با یک رخداد کوچک شروع کنید، نه کل تاریخچهٔ سازمان. دادهٔ کم اما قابل‌ردیابی از transcript حجیم و بی‌مرز ارزشمندتر است. یک postmortem خوب قرار نیست روایت بی‌نقصی از گذشته بسازد؛ باید تصمیم بعدی را امن‌تر و تغییر سیستمی را قابل‌پیگیری‌تر کند.

• خلاصه و impact: چه چیزی برای چه کسی تغییر کرد؟
• بازه و دامنه: چه زمان و چه سیستم‌هایی بررسی می‌شوند؟
• Timeline: رخداد، timestamp، منبع و سطح اطمینان.
• Trigger و عوامل: چه چیزی شروع کرد و چه شرایطی دامنه یا مدت را تغییر داد؟
• فرضیه‌ها و مجهول‌ها: چه توضیح‌هایی آزموده شدند و چه چیزی هنوز روشن نیست؟
• اقدام‌ها: تغییر، owner، موعد/trigger، اولویت و روش بازبینی.
• AI provenance: ابزارها، منابع مجاز، کارهای خودکار، تغییرهای انسانی و محدودیت‌های خروجی.

نکات کلیدی

• AI می‌تواند evidence را مرتب کند و فرضیه بسازد؛ خروجی آن به‌خودی‌خود شاهد یا root cause نیست.
• postmortem incident را با status report و retrospective معمولی یکی نگیریم.
• برای هر واقعیت منبع، هر فرضیه شاهد و هر اقدام owner و پیگیری مشخص داشته باشیم.
• یادگیری بدون سرزنش، بررسی عوامل سیستمی است؛ به معنی حذف پاسخ‌گویی یا ریسک نیست.
• زمان تولید draft را کنار کیفیت evidence و اجرای اقدام‌ها بسنجیم.
• دسترسی Agent به log، ابزار و محیط دسکتاپ باید محدود و قابل‌بررسی باشد.

قدم بعدی

اگر در حال واردکردن AI به یک فرایند عملیاتی هستید، ابتدا دامنهٔ اختیار، منبع داده، نقطهٔ تأیید و مسیر rollback را بنویسید. برای طراحی یا بازبینی این فرایندها می‌توانید مسیر ارتقای AI حکیم را ببینید.