شکست‌های سازنده: از پل‌های فروپاشیده تا معماری‌های مقاوم

بخش مقدمه (5 دقیقه)

در دهه ۱۹۴۰، پل تاکوما ناروز در ایالت واشنگتن به دلیل طراحی نادرست آیرودینامیکی و عدم درک صحیح از ارتعاشات ناشی از باد فرو ریخت. این پل که به «Galloping Gertie» معروف بود، تنها چهار ماه پس از افتتاح، بر اثر بادهایی نه‌چندان شدید، به‌طور کامل تخریب شد. شکست این پروژه باعث شد تا جامعه مهندسی به اهمیت تأثیر نیروهای دینامیکی در طراحی سازه‌ها توجه کند و استانداردهای جدیدی برای طراحی پل‌ها و سازه‌های مشابه ایجاد شود. این حادثه نشان داد که شکست‌ها می‌توانند بستری برای یادگیری عمیق و پیشرفت باشند.

تعریف شکست و اهمیت آن در یادگیری و نوآوری

• شکست چیست؟شکست به معنای عدم دستیابی به نتیجه مطلوب یا انحراف از انتظارات است. این مفهوم در حوزه‌های مختلف معانی متفاوتی دارد:

در زندگی شخصی: شکست ممکن است شامل تصمیمات اشتباه، نرسیدن به هدفی مشخص یا روبرو شدن با موانع غیرمنتظره باشد. در مهندسی نرم‌افزار: شکست می‌تواند به معنای از دست رفتن داده‌ها، خرابی یک سرویس، یا کاهش تجربه کاربری باشد.

• چرا شکست ارزشمند است؟هر بار که سیستمی خراب می‌شود یا پروژه‌ای به نتیجه نمی‌رسد، فرصتی فراهم می‌شود تا دلایل آن را بررسی کرده و بهبودهایی ایجاد کنیم. شکست محرک نوآوری است. بسیاری از اختراعات و پیشرفت‌های بزرگ پس از شکست‌های متعدد رخ داده‌اند.مثال: ادیسون و لامپ برق؛ او پس از صدها تلاش ناموفق گفت: "من شکست نخوردم؛ فقط هزار راه را کشف کردم که کار نمی‌کنند." شکست‌ها نشان می‌دهند که روش‌های فعلی کافی نیستند و باید به دنبال راه‌حل‌های بهتر باشیم.

در طول جنگ جهانی دوم، یکی از مسائل حیاتی ارتش‌ها این بود که چگونه دوام و ایمنی هواپیماها را در میدان نبرد افزایش دهند. مهندسان نظامی هواپیماهایی که از مأموریت بازمی‌گشتند را بررسی می‌کردند و نقاطی که آسیب دیده بودند را شناسایی می‌کردند. در نگاه اول، آن‌ها تصمیم گرفتند روی نقاطی که به‌طور مکرر گلوله خورده بودند (مانند بال‌ها یا دم هواپیما) زره‌گذاری کنند.

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

این تحلیل انقلابی بود. به‌جای زره‌گذاری روی نقاط آسیب‌دیده، زره‌ها را روی نقاطی قرار دادند که در ظاهر سالم به نظر می‌رسیدند اما در صورت آسیب، بحرانی بودند. این رویکرد توانست به بهبود طراحی هواپیماها و کاهش تلفات کمک کند.

سوگیری بازماندگی چیست؟

این داستان نمونه‌ای از یک خطای شناختی به نام سوگیری بازماندگی (Survivorship Bias) است.

• این سوگیری زمانی رخ می‌دهد که تمرکز ما فقط بر موارد موفق یا بازمانده است و شکست‌ها یا مواردی که دیده نمی‌شوند را نادیده می‌گیریم.
• نتیجه: درک ناقص و نادرست از دلایل موفقیت یا شکست.

سوگیری بازماندگی در دنیای مهندسی نرم‌افزار

در دنیای مهندسی نرم‌افزار، سوگیری بازماندگی (Survivorship Bias) به‌شدت قابل مشاهده است. بسیاری از افراد و تیم‌ها به جای تحلیل شکست‌ها، تنها بر موفقیت‌ها تمرکز می‌کنند و این موضوع می‌تواند منجر به درک ناقص از دلایل واقعی موفقیت یا شکست شود.

تمرکز بر موفقیت‌ها

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

• کتاب‌ها و الگوهای موفقیت:
  منابعی مانند:Site Reliability Engineering (SRE) by Google:
  این کتاب، اصول مدیریت سیستم‌های مقیاس‌پذیر و قابلیت اطمینان را با ارائه الگوهای موفق توضیح می‌دهد.
  Design Patterns by Erich Gamma et al.:
  این کتاب، پترن‌هایی از طراحی موفق در پروژه‌های نرم‌افزاری را معرفی می‌کند.
  

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

پست‌مرتم‌ها: تمرکز بر شکست‌ها

در مقابل، برخی از شرکت‌های بزرگ فناوری مانند گوگل و نتفلیکس، فرهنگ مستندسازی شکست‌ها و یادگیری از آن‌ها را به شدت جدی گرفته‌اند. این رویکرد، پست‌مرتم‌ها (Postmortems) نامیده می‌شود.

• در پست‌مرتم‌ها چه اتفاقی می‌افتد؟تحلیل دقیق دلایل شکست.
  ارائه شفاف راه‌حل‌هایی برای جلوگیری از تکرار آن.
  مستندسازی فرآیندها برای یادگیری جمعی.
  

مثال‌های عملی: گوگل و نتفلیکس

• گوگل:
  گوگل نه تنها موفقیت‌های خود را مستند می‌کند، بلکه شکست‌ها و دلایل آن‌ها را نیز با جزئیات منتشر می‌کند.
  مثال:قطع سرویسی مانند Gmail یا اختلال در Google Cloud به دقت بررسی و تحلیل می‌شود.
  گزارش‌های پست‌مرتم گوگل نشان می‌دهند که چگونه این حوادث رخ داده‌اند و چه اقداماتی برای بهبود انجام شده است.
  مزیت:
  این شفافیت به تیم‌ها کمک می‌کند از شکست‌ها درس بگیرند و از تکرار آن‌ها جلوگیری کنند.
  
• نتفلیکس:
  نتفلیکس از ابزارهایی مانند Chaos Monkey برای شبیه‌سازی خرابی‌های تصادفی استفاده می‌کند.هدف:
  شناسایی نقاط ضعف سیستم و بهبود مقاومت آن در برابر خرابی‌ها.
  پست‌مرتم‌ها در نتفلیکس:
  مستندسازی دقیق نتایج این شبیه‌سازی‌ها و خرابی‌های واقعی، به تیم‌ها کمک می‌کند سیستم‌هایی مقاوم‌تر و پایدارتر ایجاد کنند.

بخش اول: اهمیت شکست و یادگیری از آن (10 دقیقه)

چرا شکست‌ها ارزشمندند؟

شکست، بخشی جدایی‌ناپذیر از پیشرفت است. در این بخش به این سؤال پاسخ می‌دهیم که چرا شکست‌ها نه‌تنها طبیعی بلکه ضروری‌اند و چگونه می‌توانند به یادگیری و بهبود منجر شوند.

شکست در زندگی: آموختن تاب‌آوری و پایداری

شکست در زندگی فردی می‌تواند فرصتی برای رشد و تاب‌آوری باشد:

• آگاهی از محدودیت‌ها: شکست‌ها به ما نشان می‌دهند که در چه زمینه‌هایی باید خود را تقویت کنیم.
• کاهش ترس از ناشناخته‌ها: وقتی شکست را تجربه کنیم و متوجه شویم که پایان دنیا نیست، اعتمادبه‌نفس بیشتری برای مواجهه با چالش‌های جدید پیدا می‌کنیم.
• افزایش تاب‌آوری (Resilience): ذهن و روان انسان با هر شکست مقاوم‌تر می‌شود.

مثال:
دانش‌آموزی که بارها در آزمون ورودی شکست می‌خورد، با شناسایی نقاط ضعف خود و کار کردن روی آن‌ها می‌تواند در نهایت موفق شود.

شکست در مهندسی نرم‌افزار: منبع قابلیت اعتماد

در دنیای نرم‌افزار، شکست‌ها ابزار مهمی برای شناسایی نقاط ضعف سیستم‌ها هستند:

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

چرخه عیب، خطا، و شکست (Fault → Error → Failure)

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

1. Fault (عیب):
   عیب، یک نقص یا مشکل در طراحی یا اجرای سیستم است. این مشکل می‌تواند سخت‌افزاری یا نرم‌افزاری باشد و لزوماً همیشه منجر به خطا نمی‌شود.مثال: طراحی نادرست آیرودینامیکی در پل Tacoma Narrows.
   
2. Error (خطا):
   خطا زمانی رخ می‌دهد که عیب در شرایط خاصی باعث شود سیستم رفتار نامطلوبی داشته باشد. خطا نشان‌دهنده اثری است که عیب در عملکرد سیستم ایجاد می‌کند.مثال: نوسانات شدید ناشی از باد که در پل Tacoma Narrows رخ داد.
   
3. Failure (شکست):
   شکست زمانی رخ می‌دهد که خطا به گونه‌ای پیشرفت کند که سیستم دیگر نتواند وظیفه خود را انجام دهد و عملکرد آن برای کاربران غیرقابل‌قبول شود.مثال: فروپاشی کامل پل Tacoma Narrows.
   

این چرخه نشان می‌دهد که چگونه یک عیب کوچک می‌تواند به فاجعه‌ای بزرگ تبدیل شود.

در هنگام شکست چه کار نکنیم!

شکست اگر تحلیل نشود، تنها منجر به تکرار اشتباهات خواهد شد.

• فرار از مسئولیت:
  افراد یا تیم‌هایی که شکست را گردن نمی‌گیرند، نمی‌توانند پیشرفت کنند.
• نادیده گرفتن دلایل:
  بدون تحلیل دقیق، همان اشتباه دوباره رخ می‌دهد.
• پنهان‌کاری:
  اگر شکست‌ها به اشتراک گذاشته نشوند، هیچ‌کس از آن‌ها یاد نخواهد گرفت.
  

چگونه شکست‌ها ما را بهتر می‌کنند؟

1. شناسایی نقاط ضعف

شکست‌ها نقاط ضعف سیستم را آشکار می‌کنند.

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

2. توسعه سیستم‌های مقاوم‌تر

شکست‌ها می‌توانند به طراحی سیستم‌هایی منجر شوند که مقاوم‌تر (Resilient) هستند.
این سیستم‌ها نه‌تنها خرابی‌ها را تحمل می‌کنند، بلکه قادر به بازیابی سریع هستند.

مهندسی آشوب (Chaos Engineering): ابزار Chaos Monkey

نتفلیکس پیشگام استفاده از مهندسی آشوب است. آن‌ها با طراحی ابزار Chaos Monkey توانستند سیستم‌های خود را مقاوم‌تر کنند.

• Chaos Monkey چیست؟
  Chaos Monkey ابزاری است که به‌صورت تصادفی بخش‌هایی از سیستم را از کار می‌اندازد تا نقاط ضعف شناسایی شوند.هدف: اطمینان از اینکه سیستم می‌تواند حتی در صورت خرابی بخشی از آن، عملکرد خود را حفظ کند.
  
  نحوه کار:Chaos Monkey به‌صورت تصادفی سرورها یا سرویس‌ها را غیرفعال می‌کند.
  تیم‌های مهندسی بررسی می‌کنند که آیا این خرابی‌ها بر عملکرد کلی سیستم تأثیر گذاشته است یا خیر.
  مشکلات شناسایی‌شده اصلاح می‌شوند تا سیستم مقاوم‌تر شود.
  
• نتایج استفاده از Chaos Monkey:شناسایی و رفع وابستگی‌های غیرضروری.
  بهبود تحمل خرابی (Fault Tolerance).
  افزایش سرعت بازیابی سیستم در شرایط بحرانی.

پیاده‌سازی مهندسی آشوب (Chaos Engineering) و استفاده از ایده‌های Chaos Monkey به ابزارهای پیشرفته نیاز ندارد و می‌تواند در ساده‌ترین شکل خود نیز پیاده‌سازی شود. با این حال، انتخاب ابزارها و روش‌ها بستگی به پیچیدگی سیستم شما دارد. در ادامه، توضیح می‌دهم که چگونه می‌توانید به صورت ساده شروع کنید و سپس به ابزارهای پیشرفته‌تر بپردازم.

چگونه ساده شروع کنیم؟

برای شروع، نیازی به ابزار خاصی ندارید. می‌توانید به‌صورت دستی یا با نوشتن اسکریپت‌های ساده، آزمایش‌های مهندسی آشوب را اجرا کنید:

1. انتخاب آزمایش:
   یک بخش کوچک از سیستم خود را انتخاب کنید که می‌خواهید مقاومت آن را آزمایش کنید (مثلاً سرور پایگاه داده، یک سرویس API، یا یک ماژول خاص).
2. شبیه‌سازی خرابی‌ها:
   به‌صورت دستی یکی از سناریوهای زیر را اجرا کنید:خاموش کردن یک سرور: موقتاً یک سرور را خاموش کنید و بررسی کنید که آیا سیستم همچنان به درستی کار می‌کند.
   قطع اتصال شبکه: با تنظیم قوانین فایروال یا قطع شبکه یک سرور، سناریوی قطعی ارتباط را شبیه‌سازی کنید.
   مصرف منابع زیاد: یک اسکریپت ساده بنویسید که CPU یا حافظه سرور را بیش از حد مصرف کند و ببینید که سیستم چگونه واکنش نشان می‌دهد.
   از ابزارهایی مانند tc در لینوکس می‌توانید برای ایجاد تأخیر یا اختلال در شبکه استفاده کنید.
   
3. مشاهده و ثبت نتایج:بررسی کنید که سیستم چگونه به این خرابی‌ها واکنش نشان می‌دهد. آیا سیستم قادر به بازیابی است؟ آیا کاربران متوجه خرابی شدند؟ داده‌ها از دست رفتند؟
   

Bulkheads و Circuit Breakers: تقویت مقاومت در برابر خرابی

1. Bulkheads (اتاقک‌های عایق):این مفهوم از طراحی کشتی‌ها گرفته شده است.
   در کشتی‌ها، Bulkheadها دیواره‌هایی هستند که بخش‌های مختلف کشتی را جدا می‌کنند. این دیواره‌ها تضمین می‌کنند که اگر یک بخش دچار خرابی شود (مثلاً آب وارد آن شود)، سایر بخش‌ها سالم بمانند.
   در نرم‌افزار:
   Bulkheads به معنای جداسازی سرویس‌هاست، به‌طوری‌که خرابی یک سرویس باعث خرابی سرویس‌های دیگر نشود.
   مثال:
   در نتفلیکس، سرویس‌های جداگانه‌ای برای پخش ویدئو، مدیریت کاربر، و توصیه محتوا وجود دارد. اگر سرویس توصیه‌گر خراب شود، پخش ویدئو همچنان ادامه خواهد داشت.
   

1. Circuit Breakers (قطع‌کننده‌ها):این مفهوم از فیوزهای برق الهام گرفته شده است. فیوزها زمانی که جریان برق بیش از حد زیاد شود، مدار را قطع می‌کنند تا از آسیب‌دیدگی بیشتر جلوگیری کنند.
   در نرم‌افزار:
   Circuit Breakers از فرستادن درخواست‌های بیشتر به یک سرویس در حال خرابی جلوگیری می‌کنند.
   مثال:
   اگر یک سرویس زیرنویس در نتفلیکس کند یا غیرفعال شود، Circuit Breaker موقتاً درخواست‌ها به آن سرویس را متوقف می‌کند تا از تأثیر منفی روی سایر بخش‌ها جلوگیری شود.
   

بخش دوم: یادگیری از شکست در مهندسی نرم‌افزار (15 دقیقه)

فرهنگ مستندسازی شکست‌ها: یادگیری از پست‌مورتِم‌ها

یکی از عناصر کلیدی در یادگیری از شکست‌ها، مستندسازی دقیق و شفاف دلایل و پیامدهای آن‌هاست. پست‌مورتِم‌ها (Postmortems) به تیم‌ها اجازه می‌دهند تا شکست‌ها را تحلیل کنند و از تکرار آن‌ها جلوگیری کنند.

پست‌مورتِم چیست؟

پست‌مورتِم گزارشی است که پس از وقوع یک شکست یا حادثه تهیه می‌شود و شامل موارد زیر است:

• شرح حادثه: چه اتفاقی افتاد؟
• دلایل اصلی شکست: چرا این اتفاق رخ داد؟
• پیامدها: این شکست چه تأثیری بر سیستم یا کاربران داشت؟
• اقدامات اصلاحی: چه کارهایی برای رفع این مشکل و جلوگیری از تکرار آن انجام خواهد شد؟

اهمیت شفافیت در پست‌مورتِم‌ها

• فرهنگ بدون سرزنش (Blameless Culture):
  هدف پست‌مورتِم، یافتن راه‌حل است، نه سرزنش افراد. شرکت‌هایی مثل گوگل و فیسبوک تأکید می‌کنند که در این فرآیند هیچ‌کس نباید احساس ترس از سرزنش داشته باشد.
• تشویق به یادگیری جمعی:
  با مستندسازی شکست‌ها، تیم‌ها می‌توانند به‌جای پنهان کردن اشتباهات، از آن‌ها برای بهبود سیستم استفاده کنند.

متدولوژی DERP در فیسبوک

DERP یک روش چهار مرحله‌ای است که فیسبوک برای تحلیل و رفع مشکلات از آن استفاده می‌کند:

1. Detection (تشخیص):چگونه مشکل شناسایی شد؟
   مثلاً از طریق هشدارهای سیستم، داشبوردها، یا گزارش‌های کاربران.
   
2. Escalation (تصاعد):آیا افراد مناسب به‌سرعت درگیر شدند؟
   می‌توان این فرآیند را خودکار کرد تا زمان واکنش کاهش یابد.
   
3. Remediation (اصلاح):چه اقداماتی برای رفع مشکل انجام شد؟
   آیا این اقدامات قابل خودکارسازی هستند؟
   
4. Prevention (پیشگیری):چگونه می‌توان از وقوع دوباره این مشکل جلوگیری کرد؟
   آیا می‌توان راه‌حلی برای کاهش اثرات خرابی (مثل کاهش زمان خرابی یا تأثیر آن) پیاده‌سازی کرد؟

مثال: فیسبوک و بازبینی حادثه‌ها

فیسبوک از پست‌مورتِم‌ها به‌طور گسترده برای یادگیری از مشکلات استفاده می‌کند:

• مثال حادثه:
  در یک مورد، یکی از سرویس‌های فیسبوک به دلیل یک تغییر سریع در تنظیمات دچار خرابی شد. تیم مهندسی با تحلیل پست‌مورتِم، موارد زیر را شناسایی کرد:نبود یک مکانیسم اعتبارسنجی برای تنظیمات جدید.
  تأخیر در شناسایی مشکل به دلیل نبود نظارت کافی.
  اقدامات اصلاحی:
  تیم مهندسی ابزارهایی را توسعه داد تا تغییرات پیش از اعمال، به‌صورت خودکار اعتبارسنجی شوند.
  

اهمیت نرخ استاندارد شکست

در مهندسی نرم‌افزار، شکست‌ها نباید به صفر برسند. یک نرخ بسیار کم شکست می‌تواند نشان‌دهنده عدم ریسک‌پذیری و نوآوری باشد.

چرا نرخ پایین شکست می‌تواند مشکل‌ساز باشد؟

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

داستان اختلال بزرگ AWS در سال 2011: نقطه عطفی در زیرساخت‌های ابری

در آوریل 2011، یکی از بزرگ‌ترین اختلالات در تاریخ زیرساخت‌های ابری رخ داد؛ اختلالی که تأثیر عمیقی بر معماری و فرآیندهای AWS گذاشت و درس‌های مهمی را به همراه داشت. این حادثه که به اختلال در Amazon EC2 و Amazon RDS در منطقه شرقی ایالات متحده شناخته می‌شود، داستانی پر از پیچیدگی‌های فنی، چالش‌های بحرانی، و اصلاحات گسترده است.

آغاز ماجرا: تغییر پیکربندی شبکه

همه چیز از یک تغییر معمولی در پیکربندی شبکه آغاز شد. در ساعت 12:47 بامداد روز 21 آوریل، تیم AWS تغییراتی را برای ارتقاء ظرفیت شبکه اصلی در یکی از زون‌های دسترسی (Availability Zone) در منطقه شرقی ایالات متحده اعمال کرد. این تغییر به اشتباه باعث شد که ترافیک شبکه به یک شبکه پشتیبان با ظرفیت کمتر منتقل شود.

• پیامد: این تغییر به طور غیرمنتظره باعث شد که تعداد زیادی از نودهای Amazon EBS (Elastic Block Store) در زون مذکور از یکدیگر جدا شوند. این اتفاق باعث شد که این نودها نتوانند داده‌ها را به‌درستی بازنویسی (re-mirror) کنند و وارد یک طوفان بازنویسی (re-mirroring storm) شوند.

طوفان بازنویسی: بحران عمیق‌تر می‌شود

در سیستم EBS، هنگامی که یک نود اتصال به نود دیگر را از دست می‌دهد، باید به سرعت نود جدیدی برای کپی داده‌ها پیدا کند. اما در این حادثه، تعداد نودهایی که نیاز به بازنویسی داشتند، بسیار زیاد بود و ظرفیت آزاد موجود در سیستم به سرعت تمام شد. این مسئله باعث شد:

• حلقه‌های بی‌پایان جستجو: نودها بدون نتیجه به جستجوی ظرفیت خالی ادامه دادند.
• افزایش بار کنترل: حجم بالای درخواست‌ها باعث شد که کنترل‌پنل EBS (EBS Control Plane) تحت فشار شدید قرار گیرد و دیگر نتواند به درخواست‌های جدید پاسخ دهد.
• اختلال منطقه‌ای: تأثیر این اختلال از زون آسیب‌دیده به دیگر زون‌های منطقه گسترش یافت و کاربران با تأخیرها و خطاهای شدید مواجه شدند.

پیامدها: تأثیر بر EC2 و RDS

• Amazon EC2: حدود 13٪ از حجم‌های ذخیره‌سازی در زون آسیب‌دیده در وضعیت "گیرکرده" (stuck) قرار گرفتند و کاربران نمی‌توانستند از آن‌ها استفاده کنند.
• Amazon RDS: 45٪ از پایگاه‌های داده تک‌زون (single-AZ) تحت تأثیر قرار گرفتند. در برخی موارد، خرابی‌های شبکه حتی پایگاه‌های داده چندزون (multi-AZ) را نیز مختل کرد.

اقدامات AWS برای بازیابی

تیم AWS تلاش کرد تا سیستم را به حالت پایدار بازگرداند:

1. افزایش ظرفیت: سرورهای جدید به زون اضافه شدند تا بازنویسی داده‌ها امکان‌پذیر شود.
2. ایزوله‌سازی زون آسیب‌دیده: ارتباط بین زون آسیب‌دیده و کنترل‌پنل EBS قطع شد تا از تأثیر بیشتر جلوگیری شود.
3. بازیابی دستی: تیم AWS مجبور شد فرآیندهای دستی را برای بازگرداندن داده‌ها از نسخه‌های پشتیبان (snapshots) انجام دهد.

تا 24 آوریل، بیشتر حجم‌های ذخیره‌سازی بازیابی شدند. با این حال، 0.07٪ از حجم‌ها به دلیل خرابی‌های سخت‌افزاری قابل بازیابی نبودند.

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

AWS این حادثه را به عنوان فرصتی برای بهبود زیرساخت‌های خود در نظر گرفت. در گزارش پست‌مورتِم، این شرکت اقدامات زیر را اعلام کرد:

1. افزایش ظرفیت اضافی: برای جلوگیری از طوفان‌های بازنویسی در آینده، ظرفیت بیشتری در زون‌ها ذخیره شد.
2. تغییر در منطق بازنویسی: نودها به جای جستجوی بی‌پایان، از روش‌های بازگشت تدریجی (exponential backoff) استفاده خواهند کرد.
3. بهبود جداسازی زون‌ها: سیستم کنترل‌پنل به گونه‌ای بهبود یافت که اختلال در یک زون بر زون‌های دیگر تأثیر نگذارد.
4. ارتقاء ابزارهای ارتباط با مشتری: AWS ابزارهای جدیدی را برای نمایش وضعیت منابع مشتریان و اطلاع‌رسانی بهتر توسعه داد.

پست‌مورتِم (Postmortem): ریشه‌شناسی و مفهوم
ریشه کلمه:

• کلمه Postmortem از لاتین آمده است و به معنای "پس از مرگ" است:Post: به معنای "بعد از".
  Mortem: به معنای "مرگ".
  
• در ابتدا این کلمه برای توصیف بررسی‌های پزشکی پس از مرگ یک فرد به‌کار می‌رفت تا علت مرگ شناسایی شود.

کاربرد اولیه:

• در پزشکی قانونی، پست‌مورتِم به معنای بررسی دقیق برای یافتن علت مرگ است. این بررسی شامل تحلیل اعضای داخلی، شرایط بدن، و هرگونه شواهدی است که به کشف علت مرگ کمک می‌کند.

چرا پست‌مورتِم مهم است؟

• شفاف‌سازی دلایل شکست و اجتناب از سرزنش افراد.
• ایجاد فرهنگ یادگیری در تیم‌ها.
• کمک به بهبود فرآیندها و طراحی‌ها.

ساختار یک پست‌مورتِم استاندارد:

1. خلاصه حادثه:چه اتفاقی افتاد و چه خدماتی تحت تأثیر قرار گرفتند؟
   مدت زمان خرابی چقدر بود؟
   
2. جدول زمانی (Timeline):رویدادها و اقدامات انجام شده در طول حادثه، به ترتیب زمانی.
   
3. دلایل اصلی (Root Causes):چه عواملی باعث خرابی یا حادثه شدند؟
   
4. درس‌های آموخته‌شده (Lessons Learned):تیم چه چیزهایی را از این حادثه یاد گرفت؟
   
5. اقدامات اصلاحی (Corrective Actions):چه تغییراتی انجام خواهد شد تا از تکرار این حادثه جلوگیری شود؟

چرا گاهی اوقات تیم‌ها از پست‌مورتِم اجتناب می‌کنند؟

دلایل رایج تأخیر یا اجتناب از پست‌مورتِم:

1. فرهنگ سرزنش:تیم‌ها ممکن است احساس کنند که افراد مقصر شناخته خواهند شد، در نتیجه تمایلی به انجام پست‌مورتِم ندارند.
   
2. اولویت‌دهی به رفع فوری مشکل:گاهی تیم‌ها به جای تحلیل دقیق حادثه، تنها به رفع سریع مشکل فکر می‌کنند.
   
3. نبود زمان کافی:در سازمان‌هایی که فشار زیادی برای تحویل سریع دارند، ممکن است پست‌مورتِم به تعویق بیفتد.
   

چرا تأخیر مضر است؟

• با گذشت زمان، اطلاعات و جزئیات حادثه فراموش می‌شوند.
• درس‌های مهمی که می‌توان از حادثه آموخت، از دست می‌روند.
• مشکلات اصلی ممکن است دوباره تکرار شوند.

بخش سوم: مدیریت شکست‌ها (20 دقیقه)

در این بخش، به روش‌ها و الگوهای مدیریت شکست‌ها می‌پردازیم. این موضوع شامل پیشگیری از شکست‌ها، مدیریت خرابی‌های غیرمنتظره، و کشف خطاهاست.

1. پیشگیری از شکست‌ها

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

1.1. Quarantine (ایزوله کردن بخش‌های آسیب‌دیده)

• تعریف:
  بخش‌های معیوب یا آسیب‌دیده سیستم شناسایی و ایزوله می‌شوند تا خرابی به سایر بخش‌ها سرایت نکند.
• مثال:
  در یک سیستم توزیع‌شده، اگر یکی از سرورها رفتار غیرعادی داشته باشد، درخواست‌ها به آن سرور متوقف و به سرورهای دیگر هدایت می‌شوند. این کار شبیه به جداسازی یک بخش بیمار در بیمارستان است.
• مزایا:کاهش تأثیر خرابی.
  ایجاد فرصت برای بازیابی بخش معیوب.
  
• چالش‌ها:تشخیص دقیق بخش آسیب‌دیده.
  جلوگیری از اشتباه در ایزوله کردن بخش سالم.
  

1.2. Checkpointing (ذخیره‌سازی حالت سالم)

• تعریف:
  در این روش، سیستم به صورت دوره‌ای وضعیت سالم خود را ذخیره می‌کند تا در صورت بروز خطا، به آخرین وضعیت سالم بازگردد.
• مثال:در پایگاه داده‌ها، لاگ‌های تراکنش به عنوان Checkpoint ذخیره می‌شوند تا در صورت خرابی بتوان داده‌ها را بازیابی کرد.
  در محاسبات طولانی‌مدت، وضعیت پردازش ذخیره می‌شود تا در صورت خرابی، پردازش از همان نقطه ادامه یابد.
  
• مزایا:کاهش زمان بازیابی.
  حفظ پایداری داده‌ها.
  
• چالش‌ها:نیاز به فضای ذخیره‌سازی کافی.
  احتمال از دست رفتن داده‌های اخیر.
  

1.3. Failover (انتقال به واحد جایگزین) برای پیشگیری

• تعریف:
  Failover در اینجا به‌عنوان یک استراتژی از پیش طراحی‌شده برای انتقال وظایف یک بخش معیوب به واحد جایگزین به کار می‌رود. این طراحی به گونه‌ای است که خرابی‌های پیش‌بینی‌شده تأثیری بر کاربران نداشته باشند.
• مثال:در سرورهای وب، یک سرور غیرفعال (Passive) به محض خرابی سرور اصلی (Active)، به‌طور خودکار وارد عمل می‌شود.
  در سیستم‌های مخابراتی، تماس‌های تلفنی به طور خودکار به خطوط دیگر منتقل می‌شوند.
  
• مزایا:کاهش زمان خرابی.
  اطمینان از دسترس‌پذیری مداوم.
  
• چالش‌ها:هزینه بالا برای نگهداری واحدهای جایگزین.
  پیچیدگی در هماهنگی بین واحد اصلی و جایگزین.
  

الگوریتم‌های پیشرفته مدیریت صف: CoDel و Adaptive LIFO

در سیستم‌های پیچیده و سرویس‌های تحت فشار، مدیریت مؤثر صف‌های درخواست نقش مهمی در پیشگیری از شکست‌ها و کاهش تأخیر ایفا می‌کند. دو الگوریتم CoDel (Controlled Delay) و Adaptive LIFO (Last-In-First-Out) از ابزارهای پیشرفته‌ای هستند که برای این هدف استفاده می‌شوند.

1. الگوریتم CoDel (Controlled Delay)

تعریف:

CoDel یک الگوریتم مدیریت صف است که برای کنترل تأخیر در سیستم‌های با صف‌های طولانی طراحی شده است. این الگوریتم درخواست‌هایی که زمان زیادی در صف باقی مانده‌اند را به‌طور خودکار حذف می‌کند تا از انباشته شدن درخواست‌های بی‌فایده جلوگیری شود.

چرا CoDel؟

• بسیاری از شکست‌ها در سیستم‌ها به دلیل وجود صف‌های طولانی از درخواست‌ها رخ می‌دهند. این صف‌ها معمولاً به دلیل ظرفیت محدود منابع یا افزایش ترافیک ورودی ایجاد می‌شوند.
• صف‌های طولانی می‌توانند باعث ایجاد "Bufferbloat" شوند، جایی که درخواست‌های قدیمی‌تر همچنان پردازش می‌شوند در حالی که کاربران منتظر درخواست‌های جدیدتر هستند.

نحوه کار CoDel:

1. CoDel به زمان انتظار هر درخواست در صف توجه می‌کند، نه به تعداد درخواست‌ها.
2. اگر یک درخواست بیش از زمان مشخصی (Threshold) در صف باقی بماند، CoDel آن را حذف می‌کند.
3. به این ترتیب، فقط درخواست‌هایی پردازش می‌شوند که به موقع قابل رسیدگی هستند.

مثال عملی:

• سیستم‌های وب:
  فرض کنید یک سرور وب درخواست‌های کاربران را در صف نگه می‌دارد. اگر درخواست‌ها به دلیل بار سنگین دیر پردازش شوند، کاربر ممکن است صفحه را ببندد. CoDel درخواست‌های قدیمی را حذف می‌کند تا سرور به درخواست‌های جدیدتر پاسخ دهد.
• شبکه‌ها:
  در روترها و سوئیچ‌ها، CoDel می‌تواند از انباشته شدن بسته‌های قدیمی جلوگیری کرده و تأخیر شبکه را کاهش دهد.

مزایا:

• جلوگیری از انباشته شدن درخواست‌های غیرضروری.
• کاهش تأخیر در پاسخ‌گویی به درخواست‌ها.
• ساده و قابل‌اعتماد برای سیستم‌های شلوغ.

چالش‌ها:

• تنظیم صحیح زمان Threshold ممکن است برای هر سیستم متفاوت باشد.
• حذف درخواست‌ها ممکن است در برخی سیستم‌ها (مانند تراکنش‌های مالی) قابل‌قبول نباشد.

2. الگوریتم Adaptive LIFO (Last-In-First-Out)

تعریف:

Adaptive LIFO الگوریتمی است که در شرایط عادی صف‌ها را به صورت FIFO (First-In-First-Out) مدیریت می‌کند، اما هنگام شلوغی و افزایش فشار، به حالت LIFO تغییر می‌کند. در این حالت، درخواست‌های جدیدتر اول پردازش می‌شوند.

چرا Adaptive LIFO؟

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

نحوه کار Adaptive LIFO:

1. حالت عادی (FIFO):
   درخواست‌ها به ترتیب ورود پردازش می‌شوند.
2. حالت شلوغی (LIFO):
   اگر صف بیش از حد طولانی شود یا زمان انتظار زیاد شود، درخواست‌های جدیدتر اول پردازش می‌شوند.
3. این تغییر به صورت پویا و بر اساس شرایط سیستم انجام می‌شود.

مثال عملی:

• سرورهای درخواست‌های آنی:
  در سرورهای بازی‌های آنلاین، درخواست‌های جدیدتر (مانند حرکات کاربر) اولویت بیشتری دارند. Adaptive LIFO به سرور کمک می‌کند تا درخواست‌های جدید را سریع‌تر پردازش کند.
• سرورهای وب:
  در یک سایت خبری، کاربران ممکن است درخواست‌های جدیدتری برای مشاهده مطالب ارسال کنند. در زمان اوج ترافیک، Adaptive LIFO به سرور کمک می‌کند به درخواست‌های جدیدتر پاسخ دهد.

مزایا:

• بهبود تجربه کاربر در شرایط شلوغی.
• کاهش زمان انتظار برای درخواست‌های جدیدتر.
• انعطاف‌پذیری در مدیریت شرایط متغیر.

چالش‌ها:

• ممکن است درخواست‌های قدیمی به طور کامل پردازش نشوند.
• نیاز به تنظیم حساسیت الگوریتم بر اساس بار سیستم.

ترکیب CoDel و Adaptive LIFO

این دو الگوریتم می‌توانند با هم ترکیب شوند تا بهترین نتایج را در مدیریت صف‌ها ایجاد کنند:

• CoDel:
  صف را از انباشته شدن درخواست‌های قدیمی پاک می‌کند.
• Adaptive LIFO:
  درخواست‌های جدیدتر را در اولویت قرار می‌دهد.

مثال عملی ترکیب:

• در یک سیستم میکروسرویس با تعداد زیادی درخواست، CoDel از انباشته شدن درخواست‌های قدیمی جلوگیری می‌کند و Adaptive LIFO تضمین می‌کند که درخواست‌های جدیدتر سریع‌تر پردازش شوند.

جمع‌بندی و کاربرد:

• CoDel:
  مناسب برای سیستم‌هایی که تأخیر در پاسخ‌دهی به درخواست‌ها باید حداقل باشد.
• Adaptive LIFO:
  مناسب برای سیستم‌هایی که درخواست‌های جدیدتر اهمیت بیشتری دارند.
• ترکیب:
  مناسب برای سیستم‌هایی با ترافیک بالا و اولویت متغیر درخواست‌ها (مانند سیستم‌های مالی، بازی‌های آنلاین، یا سیستم‌های وب با ترافیک زیاد).

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

2. مدیریت خرابی‌های غیرمنتظره

مدیریت خرابی‌های غیرمنتظره به مجموعه‌ای از ابزارها و تکنیک‌ها اشاره دارد که برای واکنش سریع به شرایط پیش‌بینی‌نشده طراحی شده‌اند. در این بخش، روش‌هایی ارائه می‌شوند که در زمان وقوع خرابی‌های غیرمنتظره، سیستم بتواند به کار خود ادامه دهد.

2.1. Failover برای مدیریت خرابی

• تعریف:
  Failover در اینجا به عنوان یک مکانیزم اضطراری برای انتقال وظایف به واحد جایگزین در شرایط خرابی غیرمنتظره استفاده می‌شود.
• مثال عملی:
  در دیتابیس‌های توزیع‌شده مانند PostgreSQL، اگر سرور اصلی به طور غیرمنتظره دچار مشکل شود، Failover به سرور ثانویه انجام می‌شود.
• مزایا:کاهش زمان واکنش به خرابی.
  حفظ عملکرد سیستم حتی در شرایط بحرانی.
  
• چالش‌ها:نیاز به تشخیص سریع خرابی.
  جلوگیری از وقوع Failover اشتباه.
  

2.2. Circuit Breakers

• تعریف:
  Circuit Breakers از ارسال درخواست به سرویس‌های معیوب جلوگیری می‌کنند تا از گسترش خرابی در سیستم جلوگیری شود.
• مثال عملی:
  در سیستم‌های میکروسرویس، اگر یک سرویس نتواند به سرویس دیگر پاسخ دهد، Circuit Breaker مسیر درخواست‌ها را قطع می‌کند.
• مزایا:کاهش بار روی سرویس معیوب.
  جلوگیری از گسترش شکست.
  
• چالش‌ها:تشخیص زمان مناسب برای باز کردن مجدد Circuit.
  احتمال کاهش عملکرد سیستم در زمان فعال بودن Circuit Breaker.
  

2.3. Bulkheads

• تعریف:
  این الگو سرویس‌ها را از یکدیگر ایزوله می‌کند تا خرابی یک سرویس به کل سیستم منتقل نشود. ایده اصلی این الگو از طراحی کشتی‌ها گرفته شده است، جایی که Bulkheads قسمت‌های مختلف کشتی را از هم جدا می‌کند تا نشت آب به کل کشتی منتقل نشود.
• مثال عملی:
  در سیستم‌های ابری، اگر یکی از میکروسرویس‌ها دچار مشکل شود، Bulkheads اطمینان می‌دهد که سایر سرویس‌ها همچنان به درستی کار می‌کنند.
• مزایا:بهبود پایداری سیستم.
  کاهش تأثیر خرابی.
  
• چالش‌ها:طراحی پیچیده.
  هزینه بالای پیاده‌سازی.
  

حرکت نتفلیکس از High Availability به Resilience

1. تفاوت High Availability و Resilience

در ابتدا، باید تفاوت این دو مفهوم را توضیح دهیم:

• High Availability (دسترس‌پذیری بالا):این مفهوم به طراحی سیستمی اشاره دارد که بیشترین زمان ممکن در دسترس باشد.
  معمولاً از افزونگی (Redundancy) استفاده می‌کند، یعنی سیستم چندین کپی از منابع حیاتی خود دارد.
  برای مثال: اگر یک سرور خراب شود، سرور دیگری بلافاصله جایگزین می‌شود.
  
• Resilience (انعطاف‌پذیری):Resilience به معنی توانایی سیستم برای تحمل و بازیابی از خرابی‌هاست.
  به جای اجتناب کامل از خرابی، این رویکرد فرض می‌کند که خرابی اجتناب‌ناپذیر است و سیستم باید طوری طراحی شود که در هنگام خرابی بتواند همچنان به ارائه سرویس ادامه دهد یا به سرعت بازیابی شود.
  

مثال تفاوت:

تصور کنید یک فروشگاه آنلاین دارید:

• در High Availability، اگر سرور اصلی شما خراب شود، بلافاصله سرور پشتیبان جایگزین آن می‌شود.
• در Resilience، فرض می‌شود که ممکن است چند سرور همزمان دچار مشکل شوند. بنابراین، طراحی سیستم به گونه‌ای انجام می‌شود که سرویس‌های حیاتی (مثل پردازش سفارش‌ها) همچنان به کار خود ادامه دهند حتی اگر بخشی از سیستم غیرفعال باشد.

2. مشکل اولیه نتفلیکس:

در سال 2008، نتفلیکس با یک خرابی گسترده دیتاسنتر مواجه شد. این خرابی باعث شد:

• سرویس پخش ویدئوی نتفلیکس به طور کامل برای چند ساعت از دسترس خارج شود.
• کاربران نتفلیکس نتوانند به محتوا دسترسی پیدا کنند، که منجر به نارضایتی گسترده شد.
• زیرساخت فعلی نتفلیکس (High Availability در دیتاسنترهای اختصاصی) نتوانست این خرابی را مدیریت کند، زیرا طراحی آن برای پیشگیری از خرابی بود، نه تحمل خرابی.

3. راه‌حل: حرکت به سمت Resilience

نتفلیکس پس از این حادثه تصمیم گرفت زیرساخت خود را بازطراحی کند و به جای High Availability، Resilience را در اولویت قرار دهد. این تصمیم شامل چندین تغییر کلیدی بود:

3.1. انتقال به زیرساخت ابری (AWS)

• نتفلیکس زیرساخت خود را از دیتاسنترهای اختصاصی به سرویس ابری AWS منتقل کرد.
• مزایا:توانایی توزیع داده‌ها و سرویس‌ها در چندین منطقه جغرافیایی.
  کاهش وابستگی به یک مکان فیزیکی خاص.
  افزایش مقیاس‌پذیری.
  

3.2. توسعه ابزار Chaos Monkey

• Chaos Monkey چیست؟یک ابزار که به طور تصادفی بخشی از زیرساخت را غیرفعال می‌کند (مثلاً خاموش کردن سرورها یا قطع ارتباط سرویس‌ها).
  هدف: شناسایی نقاط ضعف در سیستم پیش از اینکه در شرایط واقعی باعث خرابی شوند.
  
• مثال:
  Chaos Monkey ممکن است یک سرور خاص را خاموش کند. اگر سیستم به درستی طراحی شده باشد، سایر سرورها باید بدون وقفه به ارائه سرویس ادامه دهند.

3.3. استفاده از Bulkheads

• Bulkheads چیست؟ایده‌ای که از کشتی‌ها الهام گرفته شده است: در کشتی‌ها، بخش‌هایی به صورت مجزا طراحی می‌شوند تا در صورت نشت آب، فقط همان بخش آسیب ببیند و کل کشتی غرق نشود.
  در نرم‌افزار، Bulkheads بخش‌های مختلف سیستم را از یکدیگر جدا می‌کند.
  
  مثال عملی:سرویس جستجوی نتفلیکس و سرویس پخش ویدئو جداگانه طراحی شده‌اند. اگر یکی از آن‌ها دچار مشکل شود، دیگری همچنان به کار خود ادامه می‌دهد.
  

3.4. پیاده‌سازی Circuit Breakers

• Circuit Breakers چیست؟ایده‌ای مشابه فیوزهای الکتریکی: اگر یک بخش از سیستم دچار مشکل شود، Circuit Breaker جریان درخواست‌ها به آن بخش را قطع می‌کند تا خرابی گسترش پیدا نکند.
  مثال عملی:
  اگر یک سرویس پشتیبان در نتفلیکس (مثلاً سرویس زیرنویس) دچار مشکل شود، Circuit Breaker درخواست‌های مربوط به زیرنویس را متوقف می‌کند تا سرویس‌های دیگر تحت تأثیر قرار نگیرند.
  

4. نتیجه حرکت به Resilience

بهبود تجربه کاربری

• پس از پیاده‌سازی این تغییرات، حتی در صورت خرابی یک منطقه جغرافیایی یا دیتاسنتر، سرویس نتفلیکس همچنان در دسترس است.

کاهش Downtime

• طراحی Resilient باعث شد قطعی‌های چند ساعته گذشته به چند دقیقه کاهش یابد.

آمادگی برای آینده

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

5. چرا حرکت از High Availability به Resilience منطقی است؟

• High Availability برای جلوگیری از خرابی طراحی شده است، اما...خرابی همیشه قابل پیش‌بینی یا اجتناب نیست.
  در مواقع خرابی گسترده، سیستم‌های High Availability ممکن است ناتوان باشند.
  
• Resilience برای تحمل خرابی طراحی شده است.به جای تلاش برای جلوگیری از هر خرابی، Resilience خرابی را به عنوان یک حقیقت اجتناب‌ناپذیر می‌پذیرد.
  سیستم‌های Resilient قادرند حتی در شرایط خرابی به کار خود ادامه دهند.
  

جمع‌بندی: درس از نتفلیکس

حرکت نتفلیکس از High Availability به Resilience یک نمونه عالی از چگونگی طراحی سیستم‌هایی است که نه تنها در برابر خرابی مقاوم هستند، بلکه از خرابی‌ها یاد می‌گیرند و قوی‌تر می‌شوند.

3. کشف خطاها

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

3.1. Heartbeat (سیگنال ضربان)

• تعریف:
  سیگنال‌های دوره‌ای ارسال‌شده از یک ماژول به سیستم نظارتی برای تأیید صحت عملکرد.
• مثال:
  سرورهای کلاستر با ارسال سیگنال‌های Heartbeat نشان می‌دهند که همچنان فعال هستند.
• چالش‌ها:احتمال ایجاد False Positive در شرایط قطع موقت شبکه.
  نیاز به تنظیم دقیق بازه‌های زمانی ارسال سیگنال.
  

3.2. Watchdog (تایمر نگهبان)

• تعریف:
  تایمری که اگر توسط فرآیند در حال نظارت ریست نشود، خرابی را تشخیص می‌دهد.
• مثال:
  در سیستم‌های تعبیه‌شده (Embedded Systems)، Watchdog می‌تواند فرآیندهای معیوب را ری‌استارت کند.
• چالش‌ها:نیاز به تنظیم دقیق تایمر برای جلوگیری از شناسایی خطاهای اشتباه.
  

3.3. Voting (رأی‌گیری)

• تعریف:
  مقایسه خروجی چند ماژول برای شناسایی خطا در یک ماژول معیوب.
• مثال:
  در سیستم‌های هوافضا، خروجی سه کامپیوتر کنترل پرواز با هم مقایسه می‌شود و خروجی ناسازگار به‌عنوان خطا شناسایی می‌شود.
• چالش‌ها:هزینه بالا برای نگهداری ماژول‌های اضافی.
  زمان بیشتر برای تصمیم‌گیری در سیستم‌های بزرگ.
  

پیچیدگی معماری:

• در معماری‌های ساده‌تر یا برای سرویس‌های تک‌نفره (single instance)، استفاده از Watchdog منطقی‌تر است.نیازی به مانیتور مرکزی یا سیستم‌های پیچیده Load Balancer نیست.
  واکنش به خرابی سریع و خودکار است.
  
• Heartbeat معمولاً در سیستم‌های پیچیده‌تر و توزیع‌شده استفاده می‌شود، جایی که چندین نود یا سرویس با هم کار می‌کنند.مانیتور مرکزی وظیفه تصمیم‌گیری و مدیریت خرابی را بر عهده دارد (مثلاً انتقال ترافیک از یک سرویس معیوب به سرویس دیگر).

Watchdog مستقیماً وظیفه بازیابی سرویس را بر عهده دارد.

Heartbeat فقط به یک مانیتور مرکزی اطلاع می‌دهد که سرویس مشکل دارد، و سیستم دیگری باید وارد عمل شود (مثلاً یک load balancer که نود معیوب را از کلاستر خارج کند).

بخش چهارم: اشتباهات رایج پس از شکست (5 دقیقه)

رفتارهای اشتباه پس از شکست

1. سرزنش کردن (Blaming Others or Yourself):اشتباه چیست؟
   سرزنش کردن دیگران یا خودتان پس از شکست نه تنها مشکل را حل نمی‌کند، بلکه باعث از دست دادن فرصت یادگیری و کاهش روحیه تیم می‌شود.
   مثال:
   تصور کنید تیمی پس از شکست پروژه، به جای تحلیل دلایل واقعی، تقصیر را به گردن یک فرد خاص بیندازد. این رویکرد به جای تقویت همکاری، باعث ایجاد جو منفی و کاهش اعتماد در تیم می‌شود.
   جایگزین:
   تمرکز بر پیدا کردن دلایل اصلی شکست و تحلیل آن به جای متهم کردن افراد. شعار "مشکل را مقصر بدانیم، نه فرد را" در این زمینه مفید است.
   
2. پنهان کردن شکست (Hiding Failures):اشتباه چیست؟
   پنهان کردن شکست باعث می‌شود که دیگران نتوانند از آن درس بگیرند یا در اصلاح آن مشارکت کنند. این رفتار در بلندمدت مشکلات را بزرگ‌تر می‌کند.
   مثال:
   در یک شرکت نرم‌افزاری، تیم توسعه ممکن است یک باگ جدی را پنهان کند تا مسئولیت آن را به عهده نگیرد. این کار ممکن است منجر به آسیب‌های بزرگ‌تر مانند از دست رفتن داده‌ها یا نارضایتی مشتریان شود.
   جایگزین:
   شفافیت در ارائه جزئیات شکست، مانند تهیه گزارش‌های پست‌مورتِم که دلایل شکست و راه‌حل‌ها را مستند می‌کند.
   
3. توقف تلاش (Giving Up):اشتباه چیست؟
   شکست ممکن است انگیزه افراد را کاهش دهد و برخی را به توقف تلاش وادار کند. این رویکرد باعث می‌شود فرصت‌های بعدی از دست بروند.
   مثال:
   یک استارتاپ که اولین محصولش در بازار شکست خورده، ممکن است کاملاً فعالیت خود را متوقف کند. در حالی که می‌توانست از شکست یاد بگیرد و محصولی بهتر عرضه کند.
   جایگزین:
   تحلیل شکست، اصلاح مسیر، و ادامه تلاش با یادگیری از اشتباهات قبلی.
   
4. نادیده گرفتن بازخوردها (Ignoring Feedback):اشتباه چیست؟
   بازخوردها معمولاً شامل اطلاعات ارزشمندی برای اصلاح اشتباهات هستند. نادیده گرفتن این بازخوردها به معنای از دست دادن فرصت یادگیری است.
   مثال:
   تیمی که بازخورد مشتریان درباره رابط کاربری نرم‌افزار را نادیده می‌گیرد، ممکن است محصولی با تجربه کاربری ضعیف ارائه دهد و باز هم شکست بخورد.
   جایگزین:
   گوش دادن فعال به بازخوردها و استفاده از آن‌ها برای بهبود فرآیندها و محصولات.
   
5. مسئولیت‌گریزی (Avoiding Responsibility):اشتباه چیست؟
   انکار نقش خود در شکست یا انداختن تقصیر به گردن عوامل خارجی، مانع از یادگیری می‌شود.
   مثال:
   مدیر پروژه‌ای که شکست را فقط به دلیل کمبود بودجه یا مشکلات تیمی می‌داند، ممکن است به اشتباهات مدیریتی خود توجه نکند.
   جایگزین:
   پذیرش مسئولیت و شناسایی نقاط قابل بهبود در عملکرد خود.
   

رویکرد جایگزین: چگونه از شکست‌ها یاد بگیریم؟

1. شفافیت (Transparency):چه باید کرد؟
   اطلاعات مربوط به شکست را به‌صورت شفاف با تیم یا سازمان به اشتراک بگذارید.
   چرا؟
   شفافیت باعث ایجاد اعتماد و فراهم کردن محیطی برای یادگیری جمعی می‌شود.
   مثال:
   انتشار گزارش‌های پست‌مورتِم توسط شرکت‌هایی مثل گوگل و آمازون که در آن دلایل شکست و راه‌حل‌ها به طور دقیق تحلیل می‌شود.
   
2. تحلیل دقیق (In-Depth Analysis):چه باید کرد؟
   با استفاده از ابزارها و روش‌هایی مانند روش پنج چرا (∗5Whys∗*5 Whys*∗5Whys∗)، دلایل اصلی شکست را شناسایی کنید.
   چرا؟
   تحلیل دقیق کمک می‌کند تا از تکرار اشتباهات جلوگیری شود.
   مثال:
   شرکت فیسبوک از متدولوژی DERP (تشخیص، تصاعد، اصلاح، پیشگیری) برای تحلیل و مستندسازی شکست‌ها استفاده می‌کند.
   
3. یادگیری از بازخوردها (Learning from Feedback):چه باید کرد؟
   بازخوردهای همکاران، مشتریان، و ذینفعان را به‌طور جدی بررسی کنید.
   چرا؟
   بازخوردها می‌توانند نقاط کور سیستم یا فرآیند را آشکار کنند.
   مثال:
   تیم‌های نرم‌افزاری از بازخوردهای کاربران برای شناسایی باگ‌ها و مشکلات تجربه کاربری استفاده می‌کنند.
   
4. پیشگیری و بهبود (Prevention and Improvement):چه باید کرد؟
   اقدامات پیشگیرانه برای کاهش احتمال تکرار شکست‌ها طراحی کنید.
   چرا؟
   شکست‌ها زمانی ارزشمند هستند که منجر به تغییرات مثبت شوند.
   مثال:
   نتفلیکس با پیاده‌سازی Chaos Engineering از نقاط ضعف سیستم خود پیش از وقوع شکست مطلع می‌شود.
   

نتیجه‌گیری و بحث پایانی (5 دقیقه)

جمع‌بندی

1. نقش شکست در رشد شخصی و سازمانی:
   شکست به‌عنوان یک فرصت:
   شکست، برخلاف باور رایج، پایان راه نیست بلکه یک فرصت برای یادگیری و بازنگری است. همان‌طور که مهندسان فیسبوک و نتفلیکس نشان داده‌اند، تحلیل دقیق شکست‌ها می‌تواند به پیشرفت‌های بزرگ منجر شود.مثال: شکست بزرگ دیتاسنتر نتفلیکس در سال 2008 نه تنها باعث بهبود سرویس‌دهی این شرکت شد، بلکه مفهومی جدید به نام Chaos Engineering را به دنیای فناوری معرفی کرد.
   شکست در زندگی شخصی:
   در زندگی روزمره نیز، شکست‌ها می‌توانند درس‌های ارزشمندی درباره نقاط ضعف، محدودیت‌ها، و راه‌های بهبود به ما بیاموزند. افرادی که از شکست‌های خود درس می‌گیرند، در بلندمدت موفق‌تر هستند.
   
2. استفاده از شکست برای نوآوری و بهبود مستمر:
   تحلیل و مستندسازی شکست‌ها:
   سازمان‌هایی که شکست‌های خود را مستند می‌کنند، مانند آمازون و فیسبوک، از این شکست‌ها به‌عنوان پایه‌ای برای طراحی سیستم‌های بهتر و نوآورانه استفاده می‌کنند.مثال: پست‌مورتِم آمازون پس از اختلال EC2 در سال 2011 منجر به توسعه الگوریتم‌های جدید برای مدیریت ظرفیت و جلوگیری از طوفان بازنویسی (Re-mirroring Storm) شد.
   ایجاد فرهنگ یادگیری:
   تیم‌ها و سازمان‌هایی که شکست را به‌عنوان بخشی از مسیر یادگیری می‌پذیرند، معمولاً خلاق‌تر و نوآورتر عمل می‌کنند.

"موفقیت محصول پذیرش شکست و تبدیل آن به یک درس سازنده است. به‌جای فرار از شکست، آن را در آغوش بگیرید."