مهندسی آشوب؛ روشی برای پیش‌بینی اتفاقات غیرمنتظره در کسب‌وکار

مهندسی آشوب چیست؟

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

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

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

مفاهیم پشت مهندسی آشوب

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

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

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

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

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

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

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

مهندسی آشوب شبیه تست استرس است؛ زیرا هدف آن شناسایی و تصحیح مشکلات سیستم یا شبکه است. بر خلاف تست استرس، مهندسی آشوب یک جزء را در یک زمان، آزمایش و تصحیح نمی‌کند.

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

مهندسی آشوب معمولاً به چند مرحله تقسیم می‌‌شود:

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

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

• چیز‌هایی که از آن آگاه هستند و می‌‌فهمند.
• چیز‌هایی که آن‌ها از آن آگاهند، اما کاملاً درک نمی‌کنند.
• چیز‌هایی که می‌‌فهمند، اما از آن آگاه نیستند.
• چیز‌هایی که به­طور کامل از آن‌ها آگاه نیستند و کاملاً درک نمی‌کنند.

تیم‌ها معمولا از سناریو‌های «چه می‌‌شد اگر» استفاده می‌‌کنند که می‌‌تواند باعث ایجاد خطا و خرابی برای ارزیابی عملکرد و یکپارچگی سیستم شود.

اصول پیشرفته­‌ی مهندسی آشوب

«ال پیتر دویچ»، دانشمند کامپیوتر و همکارانش در Sun Microsystems فهرستی از هشت اشتباه محاسبات توزیع شده را تهیه کردند. این‌ها فرضیات نادرستی هستند که برنامه‌نویسان و مهندسان، اغلب در مورد سیستم‌های توزیع شده مطرح می‌‌کنند و نقطه­ی شروع خوبی برای استفاده از مهندسی آشوب برای حل یک مشکل هستند. این موارد عبارتند از:

• شبکه­ قابل اعتماد است.
• تاخیر صفر وجود دارد.
• پهنای باند بی‌نهایت است.
• شبکه­ امن است.
• توپولوژی هرگز تغییر نمی‌کند.
• یک ادمین وجود دارد.
• هزینه­ی حمل و نقل صفر است.
• شبکه همگن است.

هنوز هم شبهاتی در مورد این­که آیا این اشتبا‌هات واقعا وجود دارند، مطرح می‌شود؛ اما مهندسان آشوب همچنان از آن‌ها به عنوان اصول اصلی در درک مشکلات سیستم و شبکه استفاده می‌‌کنند. موضوع اصلی این است که سیستم‌ها و شبکه هرگز کامل یا 100 درصد قابل اعتماد نیستند. به همین دلیل، ما مفهوم «پنج_نُه» را برای سیستم‌ها در دسترس داریم. مفهوم این است که به­جای تلاش برای 100% در دسترس بودن، در حالت بهینه مهندسان می‌‌توانند به کمال 99.999% برسند.

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

بهترین شیوه‌های مهندسی آشوب

مهندسی آشوب پیچیده است. پیروی از روش‌های بهینه می‌‌تواند به جلوگیری از مشکلات ناشی از اشتبا‌هات ذکر شده در بالا کمک کند:

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

نمونه‌هایی از مهندسی آشوب

سیستم توزیع شده‌ای را تصور کنید که می‌‌تواند تعداد معینی از‌ تراکنش‌ها را در ثانیه انجام دهد. از تست مهندسی آشوب می‌‌توان برای یافتن پاسخ این نرم‌افزار هنگام رسیدن به آن حد ‌تراکنش استفاده کرد. آیا عملکرد آسیب می‌‌بیند یا سیستم از کار می‌‌افتد؟

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

یکی از خرابی‌‌های قابل‌توجه سیستم در دنیای واقعی، که نیازمند مهندسی آشوب بود، برای غول سایت‌های فروشگاهی دنیا، یعنی آمازون، اتفاق افتاد. در سال 2015، DynamoDB آمازون، مشکل در دسترس بودن را در یکی از مناطق منطقه‌ای خود تجربه کرد. این نقص باعث شد بیش از 20 سرویس وب آمازون که به DynamoDB متکی بودند در آن منطقه شکست بخورند. سایت‌هایی که از این خدمات استفاده می‌‌کردند از جمله نتفلیکس، برای چندین ساعت از کار افتاده بودند. با این حال، نتفلیکس شکست کمتری را نسبت به سایر سایت‌‌ها تجربه کرد، زیرا یک ابزار مهندسی آشوب به نام Chaos Kong را برای آماده شدن برای چنین سناریویی ایجاد کرده و از آن استفاده کرده بود.

Chaos Kong کل مناطق در دسترس AWS را غیرفعال می‌‌کند، که مراکز داده­ی AWS هستند و به یک منطقه­ی جغرافیایی خدمات می‌‌دهند. استفاده از این ابزار به نتفلیکس توانست کمک کند تا به قطعی‌‌های منطقه‌هایی مانند آنچه که مشکل DynamoDB ایجاد کرد، پاسخ دهد. توانایی این شرکت برای مقابله با خاموشی، اغلب در توضیح اهمیت مهندسی آشوب، ذکر می‌‌شود.

ابزار‌های مهندسی آشوب

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

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

• Chaos Kong (آشوب کنگ): کل مناطق در دسترس AWS را غیرفعال می‌‌کند.
• Chaos Monkey (میمون آشوب): به­طور تصادفی نمونه‌های محیط تولید را غیرفعال می‌‌کند تا باعث خرابی سیستم شود، اما طوری طراحی شده است که تأثیری بر فعالیت مشتری نداشته باشد.
• Chaos Gorilla (گوریل آشوب): مانند Chaos Monkey اما در مقیاس بزرگ­تر.
• Latency (تأخیر): را برای شبیه­سازی قطع و تخریب شبکه معرفی می‌‌کند.

ارتش سیمیان نتفلیکس همچنان به رشد خود ادامه می‌‌دهد زیرا برنامه‌های آشوب­آور بیشتری برای آزمایش قابلیت‌های سرویس پخش ایجاد می‌‌شود. برخی دیگر از ابزار‌های مهندسی آشوب عبارتند از:

• Simoorg: یک برنامه­ی منبع باز که باعث شکست می‌‌شود. لینکدین از این برنامه برای انجام آزمایشات مهندسی آشوب استفاده می‌‌کند.
• Monkey-Ops: یک ابزار منبع باز که در Go پیاده­سازی شده و برای آزمایش و پایان دادن به اجزای تصادفی و پیکربندی‌های استقرار، ساخته شده است.
• Gremlin: یک برنامه­ی مهندسی آشوب که با AWS و Kubernetes کار می‌‌کند و بر بخش‌های خرده­فروشی و مالی تمرکز دارد. 
• شبیه‌ساز تزریق خطا AWS: شامل الگو‌های خطا است که AWS می‌‌تواند به نمونه‌های تولید تزریق کند. پلتفرم دارای افزونگی داخلی و اقدامات حفاظتی است تا از ایجاد مشکلات سیستمی در تست تزریق شکست، جلوگیری کند.