زمانی که یک سرویس آنلاین ناگهان از دسترس خارج میشود یا برنامه ای هنگام ثبت سفارش هنگ میکند. معمولا تیم فنی این موقعیت ها را "شرایط غیرمنتظره" لحاظ میکنند. اما در سیستمهای مدرن، تعداد حالتهای خرابی آنقدر زیاد است که هیچ تست سنتی ای نمیتواند همه آن ها را پیش از وقوع پیشبینی و شبیهسازی کند.
اینجاست که Chaos Engineering یا مهندسی آشوب به عنوان روشی برای تست تابآوری سیستم در برابر خرابیهای غیرمنتظره مطرح میشود.
در تست های سنتی از قبل میدانیم چه خطایی میخواهد شبیهسازی شود. مثلا اگر دیتابیس پاسخ ندهد چه میشود؟ اما در دنیای واقعی خرابی ها به شکل های عجیب و غیرقابل پیشبینی ظاهر میشوند. شبکه ناگهان کند شده یا سرور بدون هشدار از کار میافتد. Chaos Engineering میگوید به جای پیشبینی همه حالت ها، خرابی را عمدا به وجود بیاور و ببین سیستم چطور رفتار میکند.
برای مثال شرکت نتفلیکس یک ابزار به نام Chaos Monkey ساخته که این ابزار به طور تصادفی سرویسهای داخلی را خاموش میکند. هدفش این است ببین آیا سیستم بدون دخالت انسان میتواند خودش را بازیابی کند یا خیر. اگر با خاموشی یک سیستم کل سیستم از کار بیفتد این نقص معماری است و باید برطرف شود.
فرآیند مهندسی آشوب چهار مرحله دارد:
مرحله اول: فرضیه
فرض میکنیم اگر یک سرویس از کار بیفتد، سیستم همچنان ادامه میدهد.
مرحله دوم: تزریق خطا
به صورت کنترل شده و با تاثیر محدود خطا ایجاد میکنیم
مرحله سوم: مشاهده
رفتار سیستم را میبینیم. آیا واقعا تاب آورد؟
مرحله چهارم: بهبود
اگر سیستم تاب نیاورد و مشکل داشت، نقص را پیدا کرده و رفع میکنیم.
مهندسی آشوب در سیستمهایی که اکثر حالت های خرابی آن را از قبل میشناسیم کارایی کمی دارد. همچنین اگر در سیستمهای حساس که کاربران آن حتی برای قطعی هیچ تحملی ندارند هم این روش استفاده شود( مثل سیستم های بیمارستان یا سیستم های فضایی) باید خیلی محتاط بود.
Chaos Engineering به ما یادآوری میکند خرابی حتمی است و به جای امیدواری که خطایی رخ ندهد بهتر است سیستم را برای روزهای بد آماده کنیم و نقاط ضعف پنهان شده در سیستم را زودتر از موعد پیدا کنیم.
منابع:
Chaos Mesh Docs
Netflix Chaos Monkey
Principles of Chaos Engineering
