اصول مهندسی آشوب

آخرین به روز رسانی در ژوين ۲۰۲۳

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

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

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

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

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

آشوب در عمل

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

  1. با تعریف «وضعیت ثابت» به عنوان یک خروجی قابل اندازه‌گیری سیستم که رفتار طبیعی را نشان می‌دهد، شروع کنید.
  2. فرض کنید که این وضعیت ثابت هم در گروه کنترل و هم در گروه تجربی ادامه خواهد داشت.
  3. متغیرهایی را معرفی کنید که رویدادهای واقعی مانند خرابی سرورها، خرابی درایوها، قطع شدن ارتباط شبکه و غیره را بازتاب می‌دهند.
  4. با جستجوی تفاوتی در وضعیت ثابت بین گروه کنترل و گروه تجربی، فرضیه را رد یا تایید کنید.

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

اصول پیشرفته

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

یک فرضیه در مورد رفتار حالت پایدار بسازید

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

رویدادهای دنیای واقعی را تغییر دهید

متغیرهای آشوب رویدادهای دنیای واقعی را منعکس می کنند. رویدادها را بر اساس تأثیر احتمالی یا فرکانس تخمینی اولویت بندی کنید. رویدادهایی را در نظر بگیرید که مربوط به خرابی‌های سخت‌افزاری مانند از بین رفتن سرورها، خرابی‌های نرم‌افزاری مانند پاسخ‌های نادرست، و رویدادهای بدون شکست مانند افزایش ترافیک یا یک رویداد مقیاس‌پذیری هستند. هر رویدادی که بتواند حالت پایدار را مختل کند، یک متغیر بالقوه در آزمایش آشوب است.

اجرای آزمایش در محیط عملیاتی

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

آزمایش ها را برای اجرای مداوم به صورت خودکار انجام دهید

انجام آزمایشات به صورت دستی کار فشرده و در نهایت ناپایدار است. آزمایش ها را خودکار کنید و آنها را به طور مداوم اجرا کنید. Chaos Engineering اتوماسیون را در سیستم ایجاد می کند تا هم Orchestration و هم تجزیه و تحلیل را هدایت کند.

شعاع انفجار را به حداقل برسانید

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

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

به بحث جاری اصول هرج و مرج و کاربرد آنها در بپیوندید [جامعه آشوب].