https://virgool.io/feed/@azibom software engineer @ Cafe Bazaar fa 2026-04-22 17:28:50 https://files.virgool.io/upload/users/109297/avatar/0iUVzR.jpeg?height=120&width=120 https://virgool.io/@azibom https://virgool.io/@azibom/%D8%B4%DA%A9%D8%B3%D8%AA-%D9%87%D8%A7%DB%8C-%D8%B3%D8%A7%D8%B2%D9%86%D8%AF%D9%87-%D8%A7%D8%B2-%D9%BE%D9%84-%D9%87%D8%A7%DB%8C-%D9%81%D8%B1%D9%88%D9%BE%D8%A7%D8%B4%DB%8C%D8%AF%D9%87-%D8%AA%D8%A7-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%87%D8%A7%DB%8C-%D9%85%D9%82%D8%A7%D9%88%D9%85-xwlai8gxou9u بخش مقدمه (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)این چرخه، مفهومی کلیدی در تحلیل شکست‌هاست و به ما کمک می‌کند تا بفهمیم چرا یک سیستم از کار می‌افتد.Fault (عیب):عیب، یک نقص یا مشکل در طراحی یا اجرای سیستم است. این مشکل می‌تواند سخت‌افزاری یا نرم‌افزاری باشد و لزوماً همیشه منجر به خطا نمی‌شود.مثال: طراحی نادرست آیرودینامیکی در پل Tacoma Narrows.Error (خطا):خطا زمانی رخ می‌دهد که عیب در شرایط خاصی باعث شود سیستم رفتار نامطلوبی داشته باشد. خطا نشان‌دهنده اثری است که عیب در عملکرد سیستم ایجاد می‌کند.مثال: نوسانات شدید ناشی از باد که در پل Tacoma Narrows رخ داد.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 به ابزارهای پیشرفته نیاز ندارد و می‌تواند در ساده‌ترین شکل خود نیز پیاده‌سازی شود. با این حال، انتخاب ابزارها و روش‌ها بستگی به پیچیدگی سیستم شما دارد. در ادامه، توضیح می‌دهم که چگونه می‌توانید به صورت ساده شروع کنید و سپس به ابزارهای پیشرفته‌تر بپردازم.چگونه ساده شروع کنیم؟برای شروع، نیازی به ابزار خاصی ندارید. می‌توانید به‌صورت دستی یا با نوشتن اسکریپت‌های ساده، آزمایش‌های مهندسی آشوب را اجرا کنید:انتخاب آزمایش:یک بخش کوچک از سیستم خود را انتخاب کنید که می‌خواهید مقاومت آن را آزمایش کنید (مثلاً سرور پایگاه داده، یک سرویس API، یا یک ماژول خاص).شبیه‌سازی خرابی‌ها:به‌صورت دستی یکی از سناریوهای زیر را اجرا کنید:خاموش کردن یک سرور: موقتاً یک سرور را خاموش کنید و بررسی کنید که آیا سیستم همچنان به درستی کار می‌کند.قطع اتصال شبکه: با تنظیم قوانین فایروال یا قطع شبکه یک سرور، سناریوی قطعی ارتباط را شبیه‌سازی کنید.مصرف منابع زیاد: یک اسکریپت ساده بنویسید که CPU یا حافظه سرور را بیش از حد مصرف کند و ببینید که سیستم چگونه واکنش نشان می‌دهد.از ابزارهایی مانند tc در لینوکس می‌توانید برای ایجاد تأخیر یا اختلال در شبکه استفاده کنید.مشاهده و ثبت نتایج:بررسی کنید که سیستم چگونه به این خرابی‌ها واکنش نشان می‌دهد. آیا سیستم قادر به بازیابی است؟ آیا کاربران متوجه خرابی شدند؟ داده‌ها از دست رفتند؟Bulkheads و Circuit Breakers: تقویت مقاومت در برابر خرابیBulkheads (اتاقک‌های عایق):این مفهوم از طراحی کشتی‌ها گرفته شده است.در کشتی‌ها، Bulkheadها دیواره‌هایی هستند که بخش‌های مختلف کشتی را جدا می‌کنند. این دیواره‌ها تضمین می‌کنند که اگر یک بخش دچار خرابی شود (مثلاً آب وارد آن شود)، سایر بخش‌ها سالم بمانند.در نرم‌افزار:Bulkheads به معنای جداسازی سرویس‌هاست، به‌طوری‌که خرابی یک سرویس باعث خرابی سرویس‌های دیگر نشود.مثال:در نتفلیکس، سرویس‌های جداگانه‌ای برای پخش ویدئو، مدیریت کاربر، و توصیه محتوا وجود دارد. اگر سرویس توصیه‌گر خراب شود، پخش ویدئو همچنان ادامه خواهد داشت.Circuit Breakers (قطع‌کننده‌ها):این مفهوم از فیوزهای برق الهام گرفته شده است. فیوزها زمانی که جریان برق بیش از حد زیاد شود، مدار را قطع می‌کنند تا از آسیب‌دیدگی بیشتر جلوگیری کنند.در نرم‌افزار:Circuit Breakers از فرستادن درخواست‌های بیشتر به یک سرویس در حال خرابی جلوگیری می‌کنند.مثال:اگر یک سرویس زیرنویس در نتفلیکس کند یا غیرفعال شود، Circuit Breaker موقتاً درخواست‌ها به آن سرویس را متوقف می‌کند تا از تأثیر منفی روی سایر بخش‌ها جلوگیری شود.بخش دوم: یادگیری از شکست در مهندسی نرم‌افزار (15 دقیقه)فرهنگ مستندسازی شکست‌ها: یادگیری از پست‌مورتِم‌هایکی از عناصر کلیدی در یادگیری از شکست‌ها، مستندسازی دقیق و شفاف دلایل و پیامدهای آن‌هاست. پست‌مورتِم‌ها (Postmortems) به تیم‌ها اجازه می‌دهند تا شکست‌ها را تحلیل کنند و از تکرار آن‌ها جلوگیری کنند.پست‌مورتِم چیست؟پست‌مورتِم گزارشی است که پس از وقوع یک شکست یا حادثه تهیه می‌شود و شامل موارد زیر است:شرح حادثه: چه اتفاقی افتاد؟دلایل اصلی شکست: چرا این اتفاق رخ داد؟پیامدها: این شکست چه تأثیری بر سیستم یا کاربران داشت؟اقدامات اصلاحی: چه کارهایی برای رفع این مشکل و جلوگیری از تکرار آن انجام خواهد شد؟اهمیت شفافیت در پست‌مورتِم‌هافرهنگ بدون سرزنش (Blameless Culture):هدف پست‌مورتِم، یافتن راه‌حل است، نه سرزنش افراد. شرکت‌هایی مثل گوگل و فیسبوک تأکید می‌کنند که در این فرآیند هیچ‌کس نباید احساس ترس از سرزنش داشته باشد.تشویق به یادگیری جمعی:با مستندسازی شکست‌ها، تیم‌ها می‌توانند به‌جای پنهان کردن اشتباهات، از آن‌ها برای بهبود سیستم استفاده کنند.متدولوژی DERP در فیسبوکDERP یک روش چهار مرحله‌ای است که فیسبوک برای تحلیل و رفع مشکلات از آن استفاده می‌کند:Detection (تشخیص):چگونه مشکل شناسایی شد؟مثلاً از طریق هشدارهای سیستم، داشبوردها، یا گزارش‌های کاربران.Escalation (تصاعد):آیا افراد مناسب به‌سرعت درگیر شدند؟می‌توان این فرآیند را خودکار کرد تا زمان واکنش کاهش یابد.Remediation (اصلاح):چه اقداماتی برای رفع مشکل انجام شد؟آیا این اقدامات قابل خودکارسازی هستند؟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 و RDSAmazon EC2: حدود 13٪ از حجم‌های ذخیره‌سازی در زون آسیب‌دیده در وضعیت "گیرکرده" (stuck) قرار گرفتند و کاربران نمی‌توانستند از آن‌ها استفاده کنند.Amazon RDS: 45٪ از پایگاه‌های داده تک‌زون (single-AZ) تحت تأثیر قرار گرفتند. در برخی موارد، خرابی‌های شبکه حتی پایگاه‌های داده چندزون (multi-AZ) را نیز مختل کرد.اقدامات AWS برای بازیابیتیم AWS تلاش کرد تا سیستم را به حالت پایدار بازگرداند:افزایش ظرفیت: سرورهای جدید به زون اضافه شدند تا بازنویسی داده‌ها امکان‌پذیر شود.ایزوله‌سازی زون آسیب‌دیده: ارتباط بین زون آسیب‌دیده و کنترل‌پنل EBS قطع شد تا از تأثیر بیشتر جلوگیری شود.بازیابی دستی: تیم AWS مجبور شد فرآیندهای دستی را برای بازگرداندن داده‌ها از نسخه‌های پشتیبان (snapshots) انجام دهد.تا 24 آوریل، بیشتر حجم‌های ذخیره‌سازی بازیابی شدند. با این حال، 0.07٪ از حجم‌ها به دلیل خرابی‌های سخت‌افزاری قابل بازیابی نبودند.درس‌هایی که آموخته شدAWS این حادثه را به عنوان فرصتی برای بهبود زیرساخت‌های خود در نظر گرفت. در گزارش پست‌مورتِم، این شرکت اقدامات زیر را اعلام کرد:افزایش ظرفیت اضافی: برای جلوگیری از طوفان‌های بازنویسی در آینده، ظرفیت بیشتری در زون‌ها ذخیره شد.تغییر در منطق بازنویسی: نودها به جای جستجوی بی‌پایان، از روش‌های بازگشت تدریجی (exponential backoff) استفاده خواهند کرد.بهبود جداسازی زون‌ها: سیستم کنترل‌پنل به گونه‌ای بهبود یافت که اختلال در یک زون بر زون‌های دیگر تأثیر نگذارد.ارتقاء ابزارهای ارتباط با مشتری: AWS ابزارهای جدیدی را برای نمایش وضعیت منابع مشتریان و اطلاع‌رسانی بهتر توسعه داد.پست‌مورتِم (Postmortem): ریشه‌شناسی و مفهومریشه کلمه:کلمه Postmortem از لاتین آمده است و به معنای "پس از مرگ" است:Post: به معنای "بعد از".Mortem: به معنای "مرگ".در ابتدا این کلمه برای توصیف بررسی‌های پزشکی پس از مرگ یک فرد به‌کار می‌رفت تا علت مرگ شناسایی شود.کاربرد اولیه:در پزشکی قانونی، پست‌مورتِم به معنای بررسی دقیق برای یافتن علت مرگ است. این بررسی شامل تحلیل اعضای داخلی، شرایط بدن، و هرگونه شواهدی است که به کشف علت مرگ کمک می‌کند.چرا پست‌مورتِم مهم است؟شفاف‌سازی دلایل شکست و اجتناب از سرزنش افراد.ایجاد فرهنگ یادگیری در تیم‌ها.کمک به بهبود فرآیندها و طراحی‌ها.ساختار یک پست‌مورتِم استاندارد:خلاصه حادثه:چه اتفاقی افتاد و چه خدماتی تحت تأثیر قرار گرفتند؟مدت زمان خرابی چقدر بود؟جدول زمانی (Timeline):رویدادها و اقدامات انجام شده در طول حادثه، به ترتیب زمانی.دلایل اصلی (Root Causes):چه عواملی باعث خرابی یا حادثه شدند؟درس‌های آموخته‌شده (Lessons Learned):تیم چه چیزهایی را از این حادثه یاد گرفت؟اقدامات اصلاحی (Corrective Actions):چه تغییراتی انجام خواهد شد تا از تکرار این حادثه جلوگیری شود؟چرا گاهی اوقات تیم‌ها از پست‌مورتِم اجتناب می‌کنند؟دلایل رایج تأخیر یا اجتناب از پست‌مورتِم:فرهنگ سرزنش:تیم‌ها ممکن است احساس کنند که افراد مقصر شناخته خواهند شد، در نتیجه تمایلی به انجام پست‌مورتِم ندارند.اولویت‌دهی به رفع فوری مشکل:گاهی تیم‌ها به جای تحلیل دقیق حادثه، تنها به رفع سریع مشکل فکر می‌کنند.نبود زمان کافی:در سازمان‌هایی که فشار زیادی برای تحویل سریع دارند، ممکن است پست‌مورتِم به تعویق بیفتد.چرا تأخیر مضر است؟با گذشت زمان، اطلاعات و جزئیات حادثه فراموش می‌شوند.درس‌های مهمی که می‌توان از حادثه آموخت، از دست می‌روند.مشکلات اصلی ممکن است دوباره تکرار شوند.بخش سوم: مدیریت شکست‌ها (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:CoDel به زمان انتظار هر درخواست در صف توجه می‌کند، نه به تعداد درخواست‌ها.اگر یک درخواست بیش از زمان مشخصی (Threshold) در صف باقی بماند، CoDel آن را حذف می‌کند.به این ترتیب، فقط درخواست‌هایی پردازش می‌شوند که به موقع قابل رسیدگی هستند.مثال عملی:سیستم‌های وب:فرض کنید یک سرور وب درخواست‌های کاربران را در صف نگه می‌دارد. اگر درخواست‌ها به دلیل بار سنگین دیر پردازش شوند، کاربر ممکن است صفحه را ببندد. CoDel درخواست‌های قدیمی را حذف می‌کند تا سرور به درخواست‌های جدیدتر پاسخ دهد.شبکه‌ها:در روترها و سوئیچ‌ها، CoDel می‌تواند از انباشته شدن بسته‌های قدیمی جلوگیری کرده و تأخیر شبکه را کاهش دهد.مزایا:جلوگیری از انباشته شدن درخواست‌های غیرضروری.کاهش تأخیر در پاسخ‌گویی به درخواست‌ها.ساده و قابل‌اعتماد برای سیستم‌های شلوغ.چالش‌ها:تنظیم صحیح زمان Threshold ممکن است برای هر سیستم متفاوت باشد.حذف درخواست‌ها ممکن است در برخی سیستم‌ها (مانند تراکنش‌های مالی) قابل‌قبول نباشد.2. الگوریتم Adaptive LIFO (Last-In-First-Out)تعریف:Adaptive LIFO الگوریتمی است که در شرایط عادی صف‌ها را به صورت FIFO (First-In-First-Out) مدیریت می‌کند، اما هنگام شلوغی و افزایش فشار، به حالت LIFO تغییر می‌کند. در این حالت، درخواست‌های جدیدتر اول پردازش می‌شوند.چرا Adaptive LIFO؟در بسیاری از سیستم‌ها، درخواست‌های جدیدتر معمولاً اهمیت بیشتری دارند.در شرایط شلوغی، احتمال بی‌فایده بودن درخواست‌های قدیمی بیشتر است، زیرا کاربران ممکن است عملیات خود را لغو کرده باشند.نحوه کار Adaptive LIFO:حالت عادی (FIFO):درخواست‌ها به ترتیب ورود پردازش می‌شوند.حالت شلوغی (LIFO):اگر صف بیش از حد طولانی شود یا زمان انتظار زیاد شود، درخواست‌های جدیدتر اول پردازش می‌شوند.این تغییر به صورت پویا و بر اساس شرایط سیستم انجام می‌شود.مثال عملی:سرورهای درخواست‌های آنی:در سرورهای بازی‌های آنلاین، درخواست‌های جدیدتر (مانند حرکات کاربر) اولویت بیشتری دارند. 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 به Resilience1. تفاوت 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 MonkeyChaos Monkey چیست؟یک ابزار که به طور تصادفی بخشی از زیرساخت را غیرفعال می‌کند (مثلاً خاموش کردن سرورها یا قطع ارتباط سرویس‌ها).هدف: شناسایی نقاط ضعف در سیستم پیش از اینکه در شرایط واقعی باعث خرابی شوند.مثال:Chaos Monkey ممکن است یک سرور خاص را خاموش کند. اگر سیستم به درستی طراحی شده باشد، سایر سرورها باید بدون وقفه به ارائه سرویس ادامه دهند.3.3. استفاده از BulkheadsBulkheads چیست؟ایده‌ای که از کشتی‌ها الهام گرفته شده است: در کشتی‌ها، بخش‌هایی به صورت مجزا طراحی می‌شوند تا در صورت نشت آب، فقط همان بخش آسیب ببیند و کل کشتی غرق نشود.در نرم‌افزار، Bulkheads بخش‌های مختلف سیستم را از یکدیگر جدا می‌کند.مثال عملی:سرویس جستجوی نتفلیکس و سرویس پخش ویدئو جداگانه طراحی شده‌اند. اگر یکی از آن‌ها دچار مشکل شود، دیگری همچنان به کار خود ادامه می‌دهد.3.4. پیاده‌سازی Circuit BreakersCircuit 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 دقیقه)رفتارهای اشتباه پس از شکستسرزنش کردن (Blaming Others or Yourself):اشتباه چیست؟سرزنش کردن دیگران یا خودتان پس از شکست نه تنها مشکل را حل نمی‌کند، بلکه باعث از دست دادن فرصت یادگیری و کاهش روحیه تیم می‌شود.مثال:تصور کنید تیمی پس از شکست پروژه، به جای تحلیل دلایل واقعی، تقصیر را به گردن یک فرد خاص بیندازد. این رویکرد به جای تقویت همکاری، باعث ایجاد جو منفی و کاهش اعتماد در تیم می‌شود.جایگزین:تمرکز بر پیدا کردن دلایل اصلی شکست و تحلیل آن به جای متهم کردن افراد. شعار "مشکل را مقصر بدانیم، نه فرد را" در این زمینه مفید است.پنهان کردن شکست (Hiding Failures):اشتباه چیست؟پنهان کردن شکست باعث می‌شود که دیگران نتوانند از آن درس بگیرند یا در اصلاح آن مشارکت کنند. این رفتار در بلندمدت مشکلات را بزرگ‌تر می‌کند.مثال:در یک شرکت نرم‌افزاری، تیم توسعه ممکن است یک باگ جدی را پنهان کند تا مسئولیت آن را به عهده نگیرد. این کار ممکن است منجر به آسیب‌های بزرگ‌تر مانند از دست رفتن داده‌ها یا نارضایتی مشتریان شود.جایگزین:شفافیت در ارائه جزئیات شکست، مانند تهیه گزارش‌های پست‌مورتِم که دلایل شکست و راه‌حل‌ها را مستند می‌کند.توقف تلاش (Giving Up):اشتباه چیست؟شکست ممکن است انگیزه افراد را کاهش دهد و برخی را به توقف تلاش وادار کند. این رویکرد باعث می‌شود فرصت‌های بعدی از دست بروند.مثال:یک استارتاپ که اولین محصولش در بازار شکست خورده، ممکن است کاملاً فعالیت خود را متوقف کند. در حالی که می‌توانست از شکست یاد بگیرد و محصولی بهتر عرضه کند.جایگزین:تحلیل شکست، اصلاح مسیر، و ادامه تلاش با یادگیری از اشتباهات قبلی.نادیده گرفتن بازخوردها (Ignoring Feedback):اشتباه چیست؟بازخوردها معمولاً شامل اطلاعات ارزشمندی برای اصلاح اشتباهات هستند. نادیده گرفتن این بازخوردها به معنای از دست دادن فرصت یادگیری است.مثال:تیمی که بازخورد مشتریان درباره رابط کاربری نرم‌افزار را نادیده می‌گیرد، ممکن است محصولی با تجربه کاربری ضعیف ارائه دهد و باز هم شکست بخورد.جایگزین:گوش دادن فعال به بازخوردها و استفاده از آن‌ها برای بهبود فرآیندها و محصولات.مسئولیت‌گریزی (Avoiding Responsibility):اشتباه چیست؟انکار نقش خود در شکست یا انداختن تقصیر به گردن عوامل خارجی، مانع از یادگیری می‌شود.مثال:مدیر پروژه‌ای که شکست را فقط به دلیل کمبود بودجه یا مشکلات تیمی می‌داند، ممکن است به اشتباهات مدیریتی خود توجه نکند.جایگزین:پذیرش مسئولیت و شناسایی نقاط قابل بهبود در عملکرد خود.رویکرد جایگزین: چگونه از شکست‌ها یاد بگیریم؟شفافیت (Transparency):چه باید کرد؟اطلاعات مربوط به شکست را به‌صورت شفاف با تیم یا سازمان به اشتراک بگذارید.چرا؟شفافیت باعث ایجاد اعتماد و فراهم کردن محیطی برای یادگیری جمعی می‌شود.مثال:انتشار گزارش‌های پست‌مورتِم توسط شرکت‌هایی مثل گوگل و آمازون که در آن دلایل شکست و راه‌حل‌ها به طور دقیق تحلیل می‌شود.تحلیل دقیق (In-Depth Analysis):چه باید کرد؟با استفاده از ابزارها و روش‌هایی مانند روش پنج چرا (∗5Whys∗*5 Whys*∗5Whys∗)، دلایل اصلی شکست را شناسایی کنید.چرا؟تحلیل دقیق کمک می‌کند تا از تکرار اشتباهات جلوگیری شود.مثال:شرکت فیسبوک از متدولوژی DERP (تشخیص، تصاعد، اصلاح، پیشگیری) برای تحلیل و مستندسازی شکست‌ها استفاده می‌کند.یادگیری از بازخوردها (Learning from Feedback):چه باید کرد؟بازخوردهای همکاران، مشتریان، و ذینفعان را به‌طور جدی بررسی کنید.چرا؟بازخوردها می‌توانند نقاط کور سیستم یا فرآیند را آشکار کنند.مثال:تیم‌های نرم‌افزاری از بازخوردهای کاربران برای شناسایی باگ‌ها و مشکلات تجربه کاربری استفاده می‌کنند.پیشگیری و بهبود (Prevention and Improvement):چه باید کرد؟اقدامات پیشگیرانه برای کاهش احتمال تکرار شکست‌ها طراحی کنید.چرا؟شکست‌ها زمانی ارزشمند هستند که منجر به تغییرات مثبت شوند.مثال:نتفلیکس با پیاده‌سازی Chaos Engineering از نقاط ضعف سیستم خود پیش از وقوع شکست مطلع می‌شود.نتیجه‌گیری و بحث پایانی (5 دقیقه)جمع‌بندینقش شکست در رشد شخصی و سازمانی:شکست به‌عنوان یک فرصت:شکست، برخلاف باور رایج، پایان راه نیست بلکه یک فرصت برای یادگیری و بازنگری است. همان‌طور که مهندسان فیسبوک و نتفلیکس نشان داده‌اند، تحلیل دقیق شکست‌ها می‌تواند به پیشرفت‌های بزرگ منجر شود.مثال: شکست بزرگ دیتاسنتر نتفلیکس در سال 2008 نه تنها باعث بهبود سرویس‌دهی این شرکت شد، بلکه مفهومی جدید به نام Chaos Engineering را به دنیای فناوری معرفی کرد.شکست در زندگی شخصی:در زندگی روزمره نیز، شکست‌ها می‌توانند درس‌های ارزشمندی درباره نقاط ضعف، محدودیت‌ها، و راه‌های بهبود به ما بیاموزند. افرادی که از شکست‌های خود درس می‌گیرند، در بلندمدت موفق‌تر هستند.استفاده از شکست برای نوآوری و بهبود مستمر:تحلیل و مستندسازی شکست‌ها:سازمان‌هایی که شکست‌های خود را مستند می‌کنند، مانند آمازون و فیسبوک، از این شکست‌ها به‌عنوان پایه‌ای برای طراحی سیستم‌های بهتر و نوآورانه استفاده می‌کنند.مثال: پست‌مورتِم آمازون پس از اختلال EC2 در سال 2011 منجر به توسعه الگوریتم‌های جدید برای مدیریت ظرفیت و جلوگیری از طوفان بازنویسی (Re-mirroring Storm) شد.ایجاد فرهنگ یادگیری:تیم‌ها و سازمان‌هایی که شکست را به‌عنوان بخشی از مسیر یادگیری می‌پذیرند، معمولاً خلاق‌تر و نوآورتر عمل می‌کنند."موفقیت محصول پذیرش شکست و تبدیل آن به یک درس سازنده است. به‌جای فرار از شکست، آن را در آغوش بگیرید." azibom azibom Wed, 20 Nov 2024 18:10:59 +0330 https://virgool.io/@azibom/%D8%A7%D8%B2-%D8%AA%D8%AD%D9%84%DB%8C%D9%84-%D8%B3%D8%B1%DB%8C-%D9%87%D8%A7%DB%8C-%D8%B2%D9%85%D8%A7%D9%86%DB%8C-%D8%AA%D8%A7-%D9%BE%DB%8C%D8%B4-%D8%A8%DB%8C%D9%86%DB%8C-%D9%82%DB%8C%D9%85%D8%AA-%DA%A9%D8%B1%DB%8C%D9%BE%D8%AA%D9%88-%D8%A8%D8%AE%D8%B4-%D8%A7%D9%88%D9%84-j8dvkojo1pom تعریف سری زمانی به این شکله که مجموعه ای از داده ها که بر اساس زمان مرتب شده باشند، حالا این داده ها میتونن قیمت بیت کوین باشن یا فروش سالانه ی یک شرکت!اگه بخوایم عوامل تاثیر گذار بر روی سری های زمانی رو نام ببریم میتونیم به چهار مورد اشاره کنیم. روندتغییرات فصلیتغییرات دوره ایتغییرات نامنظم منظور از روند،‌ تغییرات دراز مدت در میانگین سری زمانی هست؛ تغییرات فصلی به تغییراتی میگیم که با دوره تناوب های کوچک تری رخ میدن؛ حرکت نوسانی در بازه های بزرگتر نسبت به تغییرات فصلی رو تغییرات دوره ای میگیم؛ در اخر هم در هر سری زمانی ممکن است عامل تصادفی وجود داشته باشه که غیر قابل پیش بینی بوده و به طریقی نامنظم رفتار میکنه که به اون تغییرات نامنظم میگیم.روش های محاسبه ی روند روش میانگین متحرکبرای پیدا کردن مقدار میانگین متحرک از مرتبه ی N در یک روز کافی است میانگین N روز قبل رو محاسبه کنیم.برای مثال : import yfinance as yfimport matplotlib.pyplot as pltdata = yf.download('BTC-USD', start=&quot2021-01-01&quot)data['SMA30'] = data['Close'].rolling(100).mean()plt.figure(figsize=(15, 10))data['Close'].plot()data['SMA30'].plot()plt.ylabel('Close')plt.xlabel(None)plt.savefig(&quotmygraph.png&quot)۲. روش نصف کردن داده هاخیلی ساده میتونیم داده ها رو به دو قسمت تقسیم کنیم و میانگین هر کدوم رو بگیریم و به هم وصل کنیم!۳. روش کمترین مربعاتدر این روش به دنبال یافتن منحنی ای هستیم که حاصل جمع توان دوم های اختلاف مقادیر اون از داده های اصلی کمترین باشهimport yfinance as yfimport matplotlib.pyplot as pltimport numpy as npfrom sklearn.linear_model import LinearRegressiondata = yf.download('BTC-USD', start=&quot2021-01-01&quot)lm = LinearRegression()y = data['Close'].valuesx = range(len(data['Close']))x = np.array(x).reshape(-1, 1)lm = lm.fit(x,y)data['Trend'] = lm.predict(x)plt.figure(figsize=(15, 10))data['Close'].plot()data['Trend'].plot()plt.ylabel('Close')plt.xlabel(None)plt.savefig(&quotmygraph.png&quot)ادامه دارد ... azibom azibom Mon, 20 Feb 2023 21:45:02 +0330 https://virgool.io/CodeLovers/%D8%A2%DB%8C%D8%A7-%D9%85%DB%8C%D8%B4%D9%87-%DA%A9%D8%AF-%D9%87%D8%A7%DB%8C-php-%D8%B1%D9%88-%DA%A9%D8%A7%D9%85%D9%BE%D8%A7%DB%8C%D9%84-%DA%A9%D8%B1%D8%AF-qsgctvgjdv24 اگه خیلی مختصر و کوتاه بخوایم جواب بدیم باید بگیم خیرولی راه هایی وجود داره که بشه یجورایی این کارو انجام داد و اونم استفاده از یک Bytecode Caching Engine هستش. حالا قضیه چیه ، اسکریپت های php برای اجرا در زمان runtime ابتدا به bytecode کامپایل میشن و در هر بار اجرای یک script این تبدیل زمان بره. خب حالا میشه اومد و این bytecode هارو کش کرد و با این کار سرعت اجرای کد هارو خیلی بالاتر برد.معرفی یک Bytecode Caching Engine بیاید نگاهی به OpCacheهمون طور که احتمالا حدس زدید : OPcache یک موتور کش است که در PHP تعبیه شده است. وقتی فعال شود ، به طور چشمگیری عملکرد وب سایت هایی را که از PHP استفاده می کنند افزایش می دهد. برای فعال کردنش هم وارد php.ini بشید و خط زیر رو به انتهای فایل اضافه کنید‍‍‍‍‍opcache.enable=1‍‍‍و بعدش هم میتونید اون رو تنظیم کنیدopcache.revalidate_freq=60opcache.validate_timestamps=1opcache.max_accelerated_files=4000opcache.memory_consumption=200اینجا هم یکم درباره ی اینکه هر کدوم چیکار میکنه مینویسمopcache.revalidate_freq: How often to check script timestamps for updates, in seconds. 0 will result in OPcache checking for updates on every request.opcache.validate_timestamps: If enabled, OPcache will check for updated scripts every opcache.revalidate_freq seconds.opcache.max_accelerated_files: The maximum number of keys (and therefore scripts) in the OPcache hash table.opcache.memory_consumption: The size of the shared memory storage used by OPcache, in megabytes.و اگر بخوام مثال بالا رو توضیح بدم باید بگم که ما با opcache.validate_timestamps=1 گفتیم که به opcache.revalidate_freq=5 توجه کن یعنی هر ۶۰ ثانیه یک بار بیا و اپدیت کن کش رو در صورت نیاز , با opcache.max_accelerated_files=4000 داریم میگیم که نهایتا ۴۰۰۰ تا فایل php رو میتونی کش کنی bytecode شون رو و با opcache.memory_consumption=200 میگیم که نهایتا ۲۰۰ مگ از فضا رو میتونه استفاده کنههمین و اینکهامیدوارم که این مطلب مفید واقع شده باشه ... azibom azibom Tue, 25 May 2021 16:35:09 +0430 https://virgool.io/@azibom/%D8%B0%D9%87%D9%86-%D9%85%D8%A7-%DA%86%D8%AC%D9%88%D8%B1%DB%8C-%DB%8C%D8%A7%D8%AF-%D9%85%DB%8C%DA%AF%DB%8C%D8%B1%D9%87-gbatduubggn1 امروز داشتم به این فکر میکردم که ما چجوری یه مهارت جدید رو یاد میگیریم، در واقع چه اتفاقی توی مغز میوفته واقعا.خب شاید بپرسین خب این مزیتش چیه، جوابی که من براش دارم اینه :خیلی از ادما تو زندگیشون دنبال پیشرفتن، پیشرفت کردن همیشه با تغییر کردن همراهه، تغییر کردن هم نتیجه ی اگاهی و یادگیریه، پس اگر بفهمیم مغز چجوری یاد میگیره میتونیم سریعتر و بهتر یاد بگیریم و با سرعت بیشتری تو بعد های مختلف زندگیمون پیشرفت کنیم.اینا قسمت هایی از چیزایی هستش که خوندم این جا هم داره سوال رو عوض میکنه که به نظرم کار قشنگیهخب الان میخوایم ببینیم که مغز با چه روش هایی یاد میگیره، اولیش اینه که مغز میاد و تعداد خیلی زیادی سیناپس تولید میکنه و بعد بعضی از اون ها ور به صورت انتخابی برمیداره و بقیه رو حذف میکنه، مثل مجسمه ساز هایی که از دل سنگ مجسمه درست میکنن.روش بعدی هم اضافه و تولید کردن سیناپس هایی هستش که میخواد.یه چیزی که میشه دید اینه که تو مرحله ی اول که کلی سیناپس تولید میشه و حذف میشه انگار یجورایی مغز داره مقدار دهی اولیه میشه و داره یه مدل برای خودش میسازه متناسب با شرایط، مدلی که به عنوان یک بیس اصلی تو سال های بعد زندگی براش عمل میکنه و اونو دوباره اپدیت میکنه، ولی پایه احتمالا همون بمونه خب پارت یک تموم شد، یه نکته ی مهم این که این مطالب رو من از روی چند جای مختلف خوندم و یکمم چیزایی که به نظرم درست بود رو بهش اضافه کردم :)همینموفق باشید azibom azibom Tue, 23 Jun 2020 13:35:58 +0430 https://virgool.io/Technofa/blockchain-oalli6dniopn زمانی که من دبیرستان بودم همیشه صحبت های زیادی درباره‌ی بینکوین و بلاکچین وجود داشت.اوایل فکر میکردم که تکنولوژی ای عادیه ولی کمی بعد متوجه اهمیت این تکنولوژی شدم و سعی کردم بیشتر درکش کنم و بفهمم که بلاکچین چیه و چرا شگفت انگیزه. بلاکچین یک دفترچه‌ی عمومی از معاملات است و از دو بخش تشکیل شده : یک شبکه ی peer-to-peer و یک پایگاه داده ی غیرمتمرکز توزیع شده.یک بلاک مجموعه ای از داده هاست و دارای چهار ویژگی اصلی استزمان ایجاد بلاکاین که هر بلاک در چند جا ذخیره میشودهیچ مرجع مرکزی وجود نداردهر بلاک به گونه ثبت میشود که انگار روی سنگ ثبت شده ... :)بلاک ها با زنجیر به هم متصل میشوند و هر بلاک اشاره به بلاک قبلی میکندحالا یکم عمیق تر موضوع رو بررسی میکنیم.فرض کنید من میخوام به بهترین دوستم دریا یه دستبند بفروشم. ما هم دیگرو میبینیم و من دستبند رو به دریا میدم و ۱۰ هزار تومن میگیرم.حالا دریا یه دستبند داره و هرکاری بخواد میتونه با اون بکنه و من هم دیگه دستبند ندارم و به جای اون ۱۰ هزار تومن پول دارم. این یک مثال ساده از یک معامله ی فیزیکی است. در این جا به هیچ شخص سومی نیاز نداریم که به معامله نظارت کنه یا اون رو تایید کنه.حالا تصور کنید که چی میشه اگر من بخوام یک دستبند دیجیتال به دریا بفروشم. دریا از کجا باید بفهمه که من این دستبند رو در یک زمان به صد نفر دیگه نفروختم. دستبند باید ردیابی شود اگر من از یک دفترچه‌ی دیجیتال استفاده کنم نیاز به یک شخص سومی به نام امین دارم تا مراقب باشه من در دفترچه دست نبرم.همچنین داشتن امین به عنوان حسابدار برای من هزینه دارد و این به معنیه که دستبندهای من گرونتر شده. و خب ... به نظر می رسد این یک وضعیت باخت-باخت است.خب حالا راه حل چیه ؟این بار به جای این که من دفترچه ی دیجیتال رو به امین بدم اون رو با همه به اشتراک میذارم. این عالیه چون دیگه کسی نمیتونه اون رو چند بار بفروشه یا بگه دستبند برای منه چون دفترچه ها در رایانه های بقیه از دفترچه های دستکاری شده در رایانه کلاهبردار پشتیبانی نمیکنند و هر چه تعداد دفترچه ها بیشتر باشد امکان تقلب هم کمتر میشود.این مثال یکی از مزیت های بلاکچین را نشان میدهد که ما میتوانیم معاملات رو بر اساس یک روش قابل اعتماد ذخیره کنیم. بلاکچین همیشگی است و اطلاعات بعد از ارسال تغییر نخواهد کرد. علاوه بر این ، قابل استناد است زیرا در اختیار همه است ، نه تحت کنترل یک نهاد واحد و این موضوع همچنین باعث میشه سیستم انعطاف بیشتری در برابر مشکلات داشته باشه. بلاکچین مزایای بسیاری دارد اما فقط برخی از اون ها در این مقاله مطرح شد.امیدوارم مقاله باشه براتون مفید :))))اگر هم کاری با من داشتید میتونید بهم بگید. اینم اینستا و تلگرام و توییتر بنده =)منبع azibom azibom Sat, 21 Dec 2019 22:28:32 +0330