مهندسی آشوب نظم و ترتیبی برای آزمایش یک سیستم با این هدف است که اطمینانی از ظرفیت سیستم برای مقاومت در برابر شرایط متزلزل در شرایط بهرهبرداری به دست آید.
مهندسی آشوب نظم و ترتیبی برای آزمایش یک سیستم با این هدف است که اطمینانی از ظرفیت سیستم برای مقاومت در برابر شرایط متزلزل در شرایط بهرهبرداری به دست آید.
پیشرفتهایی در سیستمهای نرمافزاری توزیعشده ( Distributed Systems ) در مقیاس بزرگ به دست آمده که زمین بازی را برای مهندسی نرمافزار تغییر داده است. به عنوان یک صنعت ما به سرعت اقداماتی را که باعث افزایش انعطافپذیری توسعه و سرعت پیادهسازی شوند را میپذیریم. یک سوال فورا مطرح میشود: ما تا چه حدی میتوانیم به سیستمهای پیچیدهای که به بهرهبرداری میرسانیم اطمینان داشته باشیم؟
حتی هنگامی که تمامی سرویسهای یک سیستم توزیعشده به درستی کار میکنند، تعاملات بین این سرویسها میتوانند منجر به نتایجی غیرقابل پیشبینی شوند. نتایج غیرقابل پیشبینی، همراه با وقایع نادر اما مخرب دنیای واقعی ، که بر این محیطهای بهرهبرداری اثر میگذارند، این سیستمها را به طور ذاتی آشوبی میکنند.
ما نیاز داریم که این ضعفها را قبل از اینکه در رفتارهای ناهنجاری در ابعاد سیستم نمایان شوند، شناسایی کنیم. ضعفهای سیستمی میتوانند شکلهای مختلفی داشته باشند؛ تنظیمات بازگشتی ( Fallback ) در زمانی که یک سرویس در دسترس نیست؛ سیلی از تلاشهای مجدد در اثر وقفههای زمانی نامناسب؛ از کارافتادگی هنگامی که یک وابستگی پایین دست ( Downstream Dependency ) ترافیک بیش از حدی دریافت میکند؛ خرابیهای آبشاری هنگامی که یک نقطه دچار نقص میشود؛ و سایر موارد. ما باید مهمترین نقاط ضعف را به طور فعالانه، قبل از اینکه بر مشتریان ما در بهرهبرداری اثر بگذارند، بهبود ببخشیم. باید آشوب ذاتی این سیستمها را مدیریت کنیم، از انعطافپذیری و سرعت فزاینده بهرهبرداری کنیم و به استقرارهایی ( Deployment ) که در محیط بهرهبرداری انجام میدهیم، با وجود پیچیدگیای که دارند، اطمینان داشته باشیم.
یک رویکرد تجربی و مبتنی بر سیستم، به آشفتگی در سیستمهای توزیعشده در مقیاس میپردازد و در توانایی آن سیستمها برای مقاومت در برابر شرایط واقعی اعتمادسازی میکند. ما رفتار یک سیستم توزیعشده را با مشاهده آن در طی یک آزمایش کنترل شده میآموزیم. ما این را «مهندسی آشوب» می نامیم.
برای پرداختن به عدم قطعیت سیستم های توزیع شده در مقیاس، مهندسی آشوب را می توان به عنوان تسهیلکننده آزمایشها برای کشف نقاط ضعف سیستمی در نظر گرفت. این آزمایشها این ۴ مرحله را دنبال میکنند.
۱. با تعریف «وضعیت پایدار» ( Steady State ) به عنوان برخی از خروجیهای قابل اندازهگیری یک سیستم که رفتار عادی را نشان میدهند، شروع کنید.
۲. فرض کنید که این حالت پایدار هم در گروه کنترل و هم در گروه آزمایش ادامه خواهد داشت.
۳. متغیرهایی را معرفی کنید که منعکس کننده رویدادهای دنیای واقعی هستند مانند خرابی سرورها، هارد دیسک هایی که عملکرد نادرست دارند، اتصالات شبکه قطع شده و …
۴. سعی کنید با جستجوی تفاوت در حالت پایدار بین گروه کنترل و گروه آزمایش، فرض خود را رد کنید.
هرچه برهم زدن وضعیت پایدار سختتر باشد، اعتماد بیشتری به رفتار سیستم داریم. اگر نقطه ضعفی کشف شود، اکنون هدفی برای بهبود قبل از اینکه رفتار در سیستم به طور کلی نمایان شود، داریم.
اصول زیر یک کاربرد ایدهآل از مهندسی آشوب را توصیف میکند که برای فرآیندهای آزمایشی که در بالا توضیح داده شد، اعمال میشود. حد مرزی که این اصول تا آن دنبال میشوند به شدت با اطمینانی که میتوانیم در یک سیستم توزیعشده در مقیاس داشته باشیم، مرتبط است.
یک فرضیه بر پایه رفتار وضعیت پایدار بسازید
به جای ویژگیهای داخلی سیستم، بر خروجی قابل اندازهگیری یک سیستم تمرکز کنید. اندازهگیری آن خروجی در یک دوره زمانی کوتاه، نشاندهنده وضعیت پایدار سیستم است. توان عملیاتی کلی سیستم، نرخ خطا، میزان تاخیر و … همگی میتوانند معیارهای مشترک نشاندهنده رفتار حالت پایدار باشند. با تمرکز بر الگوهای رفتار سیستمی در طول آزمایشات، به جای تلاش برای تایید نحوه کارکرد سیستم، آشوب تأیید میکند که سیستم کار میکند.
رویدادهای دنیای واقعی را تغییر دهید
متغیرهای آشوب، رویدادهای دنیای واقعی را منعکس میکنند. رویدادها را بر اساس تأثیر احتمالی یا فرکانس تخمینی آنها اولویتبندی کنید. رویدادهایی را در نظر بگیرید که مربوط به خرابیهای سختافزاری مانند از بین رفتن سرورها، خرابیهای نرمافزاری مانند پاسخهای نادرست، و رویدادهای بدون شکست مانند افزایش ترافیک یا یک رویداد مقیاسپذیری هستند. هر رویدادی که بتواند حالت پایدار را مختل کند، یک متغیر بالقوه در آزمایش مهندسی آشوب است.
در محیط بهرهبرداری آزمایش کنید
سیستم ها بسته به محیط و الگوهای ترافیک رفتار متفاوتی دارند. از آنجایی که رفتار استفاده میتواند در هر زمان تغییر کند، نمونهبرداری از ترافیک واقعی تنها راه برای گرفتن مطمئن مسیر درخواست ( Request Path ) است. برای تضمین اعتبار روشی که سیستم در آن اعمال میشود و ارتباط آن با سیستم فعلی مستقرشده، مهندسی آشوب قویاً ترجیح میدهد مستقیماً روی ترافیک در محیط بهرهبرداری آزمایش کند.
آزمایش ها را برای اجرای مداوم به صورت خودکار انجام دهید
انجام آزمایشات به صورت دستی کار فشرده و در نهایت ناپایدار است. آزمایشها را خودکار کنید و آنها را به طور مداوم اجرا کنید. مهندسی آشوب، اتوماسیون را در سیستم ایجاد میکند تا هم ارکستراسیون و هماهنگی و هم تجزیه و تحلیل را هدایت کند.
شعاع انفجار را به حداقل برسانید
آزمایش در تولید این پتانسیل را دارد که باعث مشکلات غیر ضروری برای مشتری شود. در حالی که باید برای برخی از اثرات منفی کوتاهمدت در نظر گرفته شود، این مسئولیت و تعهد مهندس آشوب است که اطمینان حاصل کند که پیامدهای آزمایشها به حداقل میرسد و مهار میشود.
مهندسی آشوب یک روش قدرتمند است که در حال حاضر نحوه طراحی و مهندسی نرمافزار را در برخی از عملیاتهای با مقیاس بزرگ در جهان تغییر میدهد. در جایی که سایر روشها به سرعت و انعطافپذیری میپردازند، مهندسی آشوب به طور خاص با عدم قطعیت سیستمیک در این سیستمهای توزیعشده مقابله میکند. اصول هرج و مرج اطمینان را برای نوآوری سریع در مقیاسهای عظیم فراهم میکند و به مشتریان تجربه های با کیفیتی را که شایسته آنهاست ارائه میدهد.
("Hello World!") شریف رضوانی هستم، با افتخار یکی از اعضای تیم Front-End پایدار سامانه، مشتاق یادگیری تکنولوژیهای جدید و رویارویی با چالشهای تازه. تلاش میکنم که به قولی Zero Downtime باشم!
دیدگاه شما