مهندسی آشوب

مقدمه

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

مهندسی آشوب[1]

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

این ترکیب اولین بار در شرکت نت فلیکس بکار گرفته شد[2]بدین صورت که بطور عمدی نقصی در یکی از مولفه های مشخص سیستم عملیاتی ایجاد میشود و اثرات آن و حالتهای قابل بازیابی را مورد سنجش و بررسی قرار میدهند. در واقع هدف اصلی مهندسی آشوب این است که قبل از آنکه خرابی و قطعی سراغ یک سیستم بیاید، پیش بینیها و تدابیر لازم جهت کاهش وقوع و به حداقل رساندن اثرات آن اتخاذ گردد.

همانطور که میدانید جلوگیری کامل از وقوع حوادث در محیطهای توزیع شده و در کل محیطهایی که مولفه های آن به یکدیگر وابسته هستند(نظیر معماریهای مایکروسرویس) تقریبا غیر ممکن است. هر چقدر در طراحی مولفه ها دقت لازم را بخرج دهید در نهایت ممکن است از یک مولفه شخص ثالث دچار خطا و قطعی شوید. با مراحلی که مهندسی آشوب پیشنهاد میکند اولا افراد قبل و حین خرابی آمادگیهای لازم را کسب میکنند و همچنین مهمترین مولفه های کیفیت سرویس -که [3]SLA و SLO [4]هستند- بطور کامل در بوته آزمایش قرار میگیرند.

مراحل اجرای مانورهای مهندسی آشوب

برای داشتن یک تجربه خوب از آشوب اثربخش لازم است 3 گام زیر به ترتیب اجرا شود:

گام نخست: آماده سازی

در مهندسی آشوب، تیمهای SRE[5] و تیمهای عملیات لازم است فعالیتهای زیر را انجام دهند:

• تعریف و شناسایی متریکها و معیارهای حالت پایدار سرویس که وضعیت سلامت کلی سیستم را نشان میدهد
• فرضیه های baseline متعددی که علیه هر یک از حالتهای پایدار سرویس (که در بالا مشخص شده است) وجود دارد را استخراج کنید. (به بیان دیگر برای هریک از متریکهاbaseline مشخصی استخراج و برای نقض آنها فرضیه هایی تعریف کنید)
• فهرستی از تمامی سناریوهای شناخته شده خرابی را به همراه روشهای برطرف سازی آنها تهیه کنید
• تمامی کدها و ابزارهای موجود را شناسایی و تاحد امکان فرایندهای خودکار سازی را آماده کنید.
• برای آنکه گستره وسیعی از مشکلات و مسائل دنیای واقعی را تحت پوشش قرار دهید لازم است فهرست کاملی از آزمونها را تهیه و تنظیم کنید.

گام دوم: تشکیل اتاق جنگ و برگزاری مانورهای تمرینی

یکی از فعالیتهایی که لازم است در مهندسی آشوب پیاده سازی کنید ایجاد یک محیط عملیاتی مضاعف و اضافی است -که ما آن را محیط ثانوی نامگذاری میکنیم- تا بتوانید تمامی مانورهای خرابی را در آن هدایت کنید. این محیط نه تنها باید از نظر پیکربندی زیرساخت همانند محیط عملیاتی واقعی باشد بلکه ویژگیهایی نظیر ترافیک ورودی و بارعملیاتی آن نیز باید مشابه باشد. برای آنکه مانورهای موفقی داشته باشید لازم است تا حد ممکن فرایندهای خود را بطور خودکار انجام دهید.

اهداف زیر باید در مانور آشوب محیط ثانوی محقق گردد:

• برنامه ریزی و ایجاد جریان کار جهت برگزاری مانور
• شناخت عمیق و دقیق سیستمها توسط مهندسان آشوب
• یکپارچه سازی ابزارها و فرایندهای بازیابی خودکار
• کاهش اثرات آشوب با برطرف کردن سریع مشکلات بوجود آمده
• رد و تایید برخی از فرضیه هایی که در مرحله قبل مطرح شده است

گام سوم: مانور آشوب در محیط اصلی

در این مرحله باید با استفاده از ابزارهای خودکار سازی مانور آشوب را در محیط عملیاتی اصلی هدایت کنید. همواره در نظر داشته باشید که این اختلالها نباید از آستانه مجاز SLOتعدی کند و همواره باید مراقب SLA خود باشید.

در هنگام مانور موارد زیر را در نظر بگیرید:

• کارشناسان و متخصصان هریک از سرویسها لازم است دردسترس و گوش به زنگ باشند.
• جریان کار را دنبال کنید و گزارشهایی از انحراف معیار حالت پایدار، اقدامات مرتبط با تعمیر خرابیها و بازگشت به آن را از قبل آماده داشته باشید.
• متریکهایی که SLOسرویسها را تهدید میکند را اعتبار سنجی و نظارت کنید؛ هرگاه که از آستانه SLO رد شدید مانور را متوقف نمایید و بعد از یافتن راه حلی برای آن مجدد آنرا از سربگیرید.
• با استفاده از ابزارهای خودکارسازی هنگامی که مانور را متوقف میکنید موارد قبل را پاکسازی کنید و مطمئن شوید هیچ پردازشی از قبل نمانده یا در حالت zombie قرار نگرفته باشد.
• همواره تجارب آموخته شده از مانورها را مستند کنید و سعی کنید تا حد امکان آنها را در ابزارهای خودکارسازی بروز نگهدارید.

نکات پایانی

• مهندسی آشوب فرایندی است که معمولا بطور رایج توسط تیمهای SRE برنامه ریزی و اجرا میگردد و همانطور که میدانید اصل لازم در پیاده سازی SREنگرش خودکارسازی است. بنابراین پیش از برنامه ریزی برای اجرای مانورهای آشوب زیرساختهای خودکارسازی را بشکل دقیق و کارامدی توسعه دهید.
• لازم است مانورهای آشوب را برای هر مدل از سرویس و معماری نرم افزار که پارامترهای SLO و SLA در آن مهم و همواره اندازه گیری میشود اجرا کنید.
• در پیاده سازی راهکارهای مانیتورینگ عملکرد سرویسها بیشترین کوشش را بخرج دهید تا شواهد را بتوانید بدقت ثبت و نتایج درستی برداشت کنید.
• سعی کنید مانورها را در پایدارترین شرایط سرویسدهی ممکن برنامه ریزی کنید تا نتایج بهتری حاصل شود.
• همواره بعد از هر مانور نتایج را جمع بندی، مستند و به تمامی تیمهای عملیاتی ارائه دهید تا از خروجی آن همه گروهها بهره­مند شوند.

در نهایت مهندسی آشوب وظیفه دارد پارامترهای کیفیت سرویسدهی را به چالش بکشد تا در نهایت سرویسی مطمئن و با کیفیت تحویل کاربران نهایی شود. همواره باید سعی کنید از نتایج آن برای بهبود SLI[6]ها و ROI[7]ها بهره برداری کنید.

[1] این واژه ترجمه عبارت Chaos engineering است.

[2] البته منظور از اولین بار در دنیای فناوری اطلاعات است چرا که پیشتر در علم ریاضیات شاخه ای تحت عنوان نظریه آشوب وجود دارد که به بررسی سیستم‌های پیچیده‌ای می‌پردازد که در خروجی آن‌ها با اعمال تغییرات کوچک (و ظاهراً قابل اغماض) تغییراتِ بزرگی حاصل می‌شود.

[3] Service Level Agreement

[4] Service Level Objectives

[5] Site Reliability Engineering

[6] Service Level Indicators

[7] Return Of Investments