Postmortems کالبدشکافی DevOps: چرا و چگونه از آنها استفاده کنیم
Postmortems –کالبدشکافی DevOps: چرا و چگونه از آنها استفاده کنیم (+چک لیست)
وقتی اوضاع خراب میشود، که گاهی اوقات هم میشود، مهم است که یک قدم به عقب برداریم و ارزیابی کنیم که چرا و چگونه این اتفاق افتاده است.
در DevOps، هر مشکلی که در فرآیند CI/CD رخ دهد، در اسرع وقت مورد توجه قرار گرفته و برطرف میشود. اطلاعات مورد نیاز از حلقه بازخورد خط لوله CI/CD جمعآوری میشود. این اطلاعات به فرآیند اصلاح وارد میشوند. تجزیه و تحلیل پس از وقوع یک مشکل نقش مهمی در برنامهریزی برای رفع آن دارد. فرهنگ پس از وقوع، تیم توسعه را گرد هم میآورد تا علت را کشف کرده و بر روی یک راهحل احتمالی برای وضعیت تمرکز کنند. طرح کتبی تجزیه و تحلیل پس از وقوع، تأثیر حادثه، اقدامات انجام شده برای حل آن، علت اصلی مشکل، اقدامات انجام شده برای جلوگیری از وقوع چنین حادثهای در آینده و غیره را شرح میدهد. یک تجزیه و تحلیل کامل نه تنها میتواند کیفیت کلی تولید را بهبود بخشد، بلکه استرس و عوامل خطر فرآیند توسعه را نیز کاهش میدهد.
چرا باید بهطور منظم و جدی، بعد از هر اتفاق یا شکست، بررسی و تحلیل انجام بدهیم؟
معمولاً هرگونه تغییر در سیستم ممکن است باعث بیثباتی و عواقب آن شود. خط لوله CI/CD در DevOps، انتشار مکرر در مراحل کوچکتر را ترویج میدهد. این امر از یک سو خطر شکست در یک انتشار خاص را کاهش میدهد، اما از سوی دیگر، تعداد حوادثی را که تیمهای آمادهباش باید به آنها پاسخ دهند، افزایش میدهد.
تیم واکنش به حادثه تلاش میکند تا تأثیر آن را کمّیسازی و کاهش دهد تا سرویس به حالت عادی بازگردد. این دقیقاً همان جایی است که تجزیه و تحلیل پس از حادثه مهم است، مگر اینکه هیچ اقدام اصلاحی یا پیشگیرانهای انجام نشود. در بدترین حالت، حوادث میتوانند با اثر آبشاری چند برابر شوند. در نتیجه، مدت زمانی که یک تیم DevOps صرف پاسخ به حادثه میکند، از زمان واقعی توسعه بیشتر میشود. با گنجاندن فرهنگ پس از حادثه در تیم DevOps میتوان از این وضعیت غیرمنتظره جلوگیری کرد.
چطور یک بررسی پس از حادثه (یا شکست) انجام بدهیم؟
برای جلوگیری از چنین چرخهی سقوطی، تیم شما باید بپذیرد که یادگیری از گذشته برای ساختن آیندهای بهتر ضروری است. این فرایند یادگیری را «کالبدشکافی» (postmortem) مینامند.
هر زمان که یک حادثه یا مشکل باعث شود یک مهندس پشتیبان (on-call engineer) وارد عمل شود، باید یک کالبد شکافی – postmortem انجام شود.
مرحله اول: ثبت شواهد – Registering the Evidence
یک کالبد شکافی معمولی با ثبت شواهد عینی و واقعی آغاز میشود، یعنی چیزهایی که قابل اندازهگیری و بررسی هستند، نه حدس و گمان.
مواردی که باید ثبت شوند:
دلیل شروع حادثه (Trigger):
تأثیر حادثه (Impact):
زمان تشخیص و رفع مشکل (Time to Detect and Mitigate):
مراحلی که برای رفع مشکل طی شد (Steps Taken to Mitigate):
تحلیل ریشهای علت (Root Cause Analysis):
مرحله دوم: تحلیل (The Analysis)
بر اساس شواهد فوق، باید تحلیلی انجام شود. این تحلیل معمولاً توسط عضو تیم آماده به کار که به حادثه پاسخ داده است انجام میشود و ممکن است شامل سایر اعضای تیم باشد که یا به کاهش یا تحلیل علت اصلی کمک کردهاند. فرآیند تحلیل باید به سوالات زیر پاسخ دهد:
علت Trigger
چند هشدار برای حادثه دریافت کردیم؟ آیا علت به موقع بود یا میتوانستیم آن را زودتر ثبت کنیم؟
تأثیر Impact
آیا تأثیر برای شروع یک حادثه در وهله اول کافی بود؟ یا باید عوامل را کالیبره کنیم؟ آیا اقدامات انجام شده برای کاهش تأثیر کافی بود و آیا آنها از این فرآیند پیروی کردند؟ اگر نه، آیا باید در آموزش سرمایهگذاری کنیم یا دستورالعملها را بهبود بخشیم؟ آیا ما موفق شدیم تأثیر را به اندازه کافی سریع کاهش دهیم؟ آیا کاری هست که بتوانیم برای کاهش زمان کاهش انجام دهیم؟
علت Root cause
ریشهای آیا علت ریشهای حل میشود یا باید با آن زندگی کنیم؟ اگر علت ریشهای حل شود، دقیقاً برای حل آن چه کاری باید انجام دهیم؟
مرحله ۳: خلاصه نویسی – Compose a Summary
بر اساس تجزیه و تحلیل، باید خلاصهای تهیه شود که شامل درسهای آموخته شده و وظایف پیگیری ثبت و اولویتبندی شده باشد. وظایف پیگیری معمولاً شامل موارد زیر است:
وظایف تیم مهندسی برای رفع علت ریشهای مشکل
وظایف مهندسان DevOps برای بهبود سیستم نظارت و هشداردهی
وظایف مدیران برای بهبود فرآیندها
۵ نکته برای معرفی فرهنگ کالبد شکافی – Postmortems
معرفی کالبدشکافی برای سازمانی که از نظر تاریخی هیچ گونه کالبدشکافی انجام نداده است، آنقدرها هم که به نظر میرسد آسان نیست. مانند هر فرآیند جدید یا در حال تغییری، معرفی و تداوم تغییر نیاز به زمان و تلاش در تمام سطوح سازمان دارد. با این حال، چند اصل کلیدی وجود دارد که پیروی از آنها تغییر را آسانتر میکند:
۱. حتماً از بازیهای سرزنش و انگشتنما کردن stay away from blame games and finger pointing افراد دوری کنید. این مهمترین نکته برای شروع درست است. اگر تحلیل به جای اینکه تیم را به یادگیری و بهبود سوق دهد، تمرکزش روی مقصر دانستن افراد باشد، این کار آسیبزننده خواهد بود نه مفید.
۲. یک مسئول مخصوص تعیین کنید که مطمئن شود هر پاسخ به حادثه با انجام کالبد شکافی به پایان برسد. این افراد معمولاً از تیمهای DevOps یا کشیک (on-call) هستند و اغلب خودشان رهبران تیم هستند.
۳. همکاری و اشتراکگذاری را تشویق کنید. مستندات کالبدشکافی ها را در جایی مناسب برای یادگیری و اشتراکگذاری مثل ویکیها ثبت کنید. مستندات کالبدشکافی های ماه گذشته را به عنوان مواد آموزشی منظم برای تیم استفاده کنید. امکان همکاری و نظر دادن در طول و بعد از کالبدشکافی را فراهم کنید.
۴. مدیریت را درگیر کنید. حمایت مدیریت باعث آسانتر شدن فرهنگسازی و آموزش در بین مهندسان میشود. برای حفظ درگیری مدیریت، با اهداف مشخص برنامهریزی کنید و پیشرفت را به آنها نشان دهید. مدیرها معمولاً علاقهمند به نمودارهایی هستند که روند رو به رشد را نشان میدهد.
۵. کوچک شروع کنید. اگر سازمان بزرگ است، شروع با چند سرویس و یک تیم کافی است تا نمونهای ساخته شود که سایر تیمها را تشویق کند. موفقیت تیم اولیه معمولاً کافی است تا دیگر تیمها نیز همراه شوند. معرفی تغییر بدون داشتن یک نمونه مثبت داخلی بسیار سختتر است.
Postmortem Checklist
ما چک لیستی از سوالاتی که باید از خودتان بپرسید تا بتوانید DevOps خود را به بهترین شکل ممکن انجام دهید، آماده کردهایم.
تشخیص Detection
تأثیر Impact
- تأثیر روی کاربران نهایی Impact on end users
- تأثیر روی بهرهوری Impact on productivity
- تأثیر روی زیرساخت Impact on infrastructure
کاهش اثر / رفع مشکل Mitigation
- زمان صرف شده برای رفع مشکل Time to mitigation
- گام اول برای رفع مشکل Mitigation step #1
- گام دوم برای رفع مشکل Mitigation step #2
تحلیل علت ریشهای Root cause analysis
درسهای آموخته شده Lessons learned
پیگیریها Follow-ups
- کار #۱ (تشخیص / رفع / فرآیند) Task #1 (detect/mitigate/process)
- کار #۲ (تشخیص / رفع / فرآیند) Task #2 (detect/mitigate/process)
- کار #۳ (تشخیص / رفع / فرآیند) Task #3 (detect/mitigate/process)
