جلسه پست‌مرتم چیست؟

در ادامه قسمت قبل، در این نوشته، فصل Postmortem Culture: Learning from Failure را خلاصه و بررسی می‌کنیم.

هزینۀ خطا/شکست، یادگیری است!

در شرکت‌ها یا سازمان‌ها ممکن است به دلایل مختلف، خطاها و شکست‌هایی رخ بدهد.

اما نکتۀ مهم، چگونگی مواجه شدن با این خطاهاست. اینکه آن‌ها را درست کنیم و رهایشان کنیم یا اینکه هر چه می‌توانیم از آن‌ها یاد بگیریم تا جلوی دوباره رخ دادنشان یا حتی رخ دادن خطاهای دیگر را بگیریم.

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

نکتۀ مهم این است که این جلسه‌ها به‌عنوان یک فرهنگ در گوگل به blame-free postmortem culture معروف است. یعنی کسی حق ندارد دیگران را سرزنش کند یا فرد خاصی را به‌عنوان مسبب خطا نشان دهد؛ بلکه همه به‌دنبال روال غلطی هستند که باعث این اتفاق شده است تا آن را درست کرده، از تکرار مجدد آن جلوگیری کنند.

اینجا دو جمله از یک فرد دخیل با سیستم را می‌نویسم و با هم مقایسه می‌کنم:

• این سیستم بک‌اند واقعاً افتضاح است! در چند هفتۀ گذشته بارها پایین آمده است و اگر اوضاع این‌‌گونه پیش برود، خودم آن را از اول می‌نویسم...
• در چند هفتۀ اخیر، چند بار سیستم بک‌اند پایین آمده است. شاید بازنویسی این سیستم کمک کند که از این اتفاق‌ها جلوگیری شود. اگر این کار را بکنیم، on-callهای بعدی نیز خوش‌حال خواهند بود. :)

تفاوت دو جملۀ بالا کاملاً ملموس است. مشخص است که هرکدام چه جو منفی و مثبتی را ایجاد می‌کند. اصلاً اینکه این جلسات blame-free باشند، خودش چالش است و به تمرین بسیار نیاز دارد.

ابتدا کمی جزئی‌تر می‌گوییم که چه زمانی incident رخ داده است؟

از اتفاق‌های زیر به‌عنوان incident یاد می‌شود:

• هر اتفاقی که کاربر احساسش کند!‌ چه پایین آمدن سیستم و چه تجاوز کردن یک متریک مانند latency از یک مقدار معین؛
• اگر داده‌ای از دست برود؛
• اگر کسی که on-call است، مجبور شود مداخله کند؛
• یک زمان خاص که برخی آستانه‌ها رد شده باشند؛
• کشف حادثۀ دستی (یعنی خطای مانیتورینگ).

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

خود گوگل فرهنگ‌های جذابی برای این جلسات پست‌مرتم دارد:

• انتخاب پست‌مرتم ماه و تقدیر از آن؛
• گروه‌های پست‌مرتم‌خوانی که بحث‌های مربوط به این جلسات در آنجا رخ می‌دهد.

در ادامه، به ساختار و مناسک جلسه‌های پست‌مرتم می‌پردازیم:

یک Template از داکیومنت را با هم بررسی می‌کنیم:

ـ تاریخ وقوع؛

ـ نویسندگان؛

ـ وضعیت فعلی: وضعیتی که سرویس در حال حاضر در آن قرار دارد؛

ـ خلاصۀ حادثه؛

ـ تأثیر حادثۀ مزبور: مثلاً n کاربر نتوانستند از ما سرویس بگیرند؛

ـ دلایل ریشه‌ای: چه چیزهایی باعث این حادثه شد. نکتۀ مهم این است که این دلایل باید قابلیت ایجاد مجدد را داشته باشند؛

ـ چگونگی اطلاع: مثلا سرویس Alerting بالا رفتن Latency را هشدار داد و مهندس on-call وارد عمل شد؛

ـ ابعاد حادثه: اینکه حادثه در چه حدی بزرگ یا کوچک بوده است؛

ـ کارهایی که باید انجام شود: برای اینکه این حادثه یا حوادث مشابه آن دیگر تکرار نشود، چه کسی چه کاری را انجام دهد (کارهای مختلف به افراد مختلف اساین می‌شوند).

ـ درس‌هایی که آموختیم:

در این قسمت باید به این سؤالات جواب داده شود:

ـ نقاط قوتمان کجا بود؟

ـ کجا ضعف داشتیم؟

ـ کجا خوش‌شانس بودیم؟

و در نهایت، یک تایم‌لاین با تاریخ و ساعت از کل اتفاق شرح داده می‌شود.

شاید این جلسات در بسیاری از سازمان‌ها نه به‌عنوان پست‌مرتم، بلکه با عنوان‌های دیگر برگزار شوند.

ـ حالا سؤال این است که آیا همۀ این مناسک باید انجام شوند؟

به قول یکی از دوستان، بودن همین کارهای مشخص، باعث نظم و پیگیری بیشتر این جلسه‌ها می‌شود و در نهایت هم، تأثیر آن‌ها را بیشتر می‌کند.

برای تجربه بیشتر، می‌توان نمونه جلسات پروژ‌ه‌های متن‌باز دنیا را بررسی کرد. مانند این مثال از پروژه گیت‌لب:

https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/4113

خب، این بخش هم تمام شد و در بخش بعدی به سراغ فصل Monitoring Distributed Systems می‌رویم ان‌شاءالله.