Chaos Engineering چیست؟
با توجه به گستردگی سرویس‌های آنلاین توزیع‌شده از یکسو و همچنین وابستگی کاربران و حتی سایر کسب‌وکارهای کوچک‌تر به این دست سرویس‌ها از سوی دیگر، شاهد ظهور معماری میکروسرویس و زیرساخت‌های توزیع‌شدهٔ ابری در فضای وب بوده‌ایم اما در عین حال پیچیدگی مدیریت این قبیل سرویس‌ها نیز به مراتب بیشتر از گذشته شده است که در چنین فضایی از دسترس خارج شدن وب‌سایت کسب‌وکارهای بزرگ آنلاین هزینه‌های گزافی را به آن‌ها تحمیل خواهد کرد و مسلماً Cost of Downtime به عنوان یکی از شاخص‌های کلیدی عملکرد محسوب خواهد شد و اینجا است که اهمیت Chaos Engineering دوچندان خواهد شد.
Chaos Engineering به مجموعه تمهیداتی گفته می‌شود که تیم‌های مهندسی توسعهٔ نرم‌افزار را قادر می‌سازد تا نرم‌افزار را در محیط واقعی یا اصطلاحاً Production Environment زیر بار فشارهای مختلفی قرار دهند تا در نهایت دریابند که سرویس مذکور تا چه حد تحمل شرایط غیرمنتظره را دارا است و بدین ترتیب کسب‌وکارهای آنلاین می‌توانند قبل از آنکه با آن شرایط غیرمنتظره روبه‌رو شوند، خود را برای برون‌رفت و پایدار نگاه داشتن سرویس آماده سازند (می‌توان برای این مفهوم به معادل‌هایی همچون «مهندسی آشوب» یا «مهندسی هرج‌ومرج» اشاره کرد اما با توجه به اینکه هرگونه معادل‌سازی آن‌طور که باید و شاید حق مطلب را ادا نمی‌کند و اصالت این مفهوم را کم‌رنگ می‌سازد، در ادامهٔ این مقاله Chaos Engineering را به اختصار CE می‌نامیم و از معادل‌های فارسی استفاده نخواهیم کرد.)
در حقیقت، CE کمک می‌کند تا مشکلات مرتبط با سرویس آنلاین‌مان را قبل از آنکه به دَون‌تایم منجر شوند شناسایی کرده و آن‌ها را مرتفع سازیم. به تعبیری دیگر، CE این امکان را در اختیار تیم‌های مهندسی می‌گذارد تا «آنچه را فکر می‌کنند ممکن است اتفاق بیفتد» را با «آنچه واقعاً در عمل رخ خواهد داد» مقایسه کرده و خود را برای چنین شرایطی آماده سازند که برای این منظور مهندسین عمداً برای همان سرویسی که مشتریان واقعی در حال استفاده از آن هستند مشکل/مشکلاتی ایجاد کرده و از نتایج به دست آمده درس می‌گیرند که به چه شکل می‌توانند سیستم را در چنین شرایطی مقاوم سازند.
آشنایی با تاریخچهٔ CE
وقتی صحبت از CE می‌شود، نیاز است تا با اصطلاح دیگری تحت عنوان Resiliency نیز آشنا شویم که معادلی همچون «انعطاف‌پذیری» می‌توان برایش در نظر گرفت. به طور کلی، در صنعت توسعهٔ نرم‌افزار Resiliency به این نکته اشاره دارد که یک اپلیکیشن می‌باید از این توانایی برخوردار باشد تا در صورت بروز هر گونه نقص، چالش یا مشکلی بتواند تا حد ممکن از عملکرد عادی خود برخوردار باشد که این‌گونه مشکلات را می‌توان در سه دستهٔ مشکلات زیرساختی همچون مشکل در سرورها، مشکلات شبکه‌ای همچون کمبود پهنای‌باند و همچنین مشکلات نرم‌افزاری مانند کدنویسی غیراصولی دسته‌بندی کرد و نیاز به توضیح نیست که هر چه‌قدر کسب‌وکاری گسترده‌تر باشد، به همان میزان اهمیت CE در آن بیشتر است که از جملهٔ این کسب‌وکارهای گسترده می‌توان به Netflix اشاره کرد.
زمانی که شرکت نت‌فلیکس در سال 2010 به سمت کلود مهاجرت کرده و شروع به استفاده از AWS آمازون نمود، اعضای تیم مهندسی این شرکت به خصوص علی بصیری، بنیان‌گذار تیم مهندسی Chaos Engineering در کمپانی نت‌فلیکس، به فکر تست Resiliency سرورهای خود افتادند تا در نهایت بتوانند ببینند که اگر دقیقاً در همان محیطی که مشتریان نت‌فلیکس از این سرویس استفاده می‌کنند مشکلی رخ دهد باید انتظار چه پیامدهایی را داشته باشند که در همین راستا مهندسین این شرکت در سال 2011 ابزار Chaos Monkey را طراحی کردند که به صورت تصادفی سرورهای نت‌فلیکس را از دسترس خارج می‌کرد تا ببینند مشتریان این شرکت با چه شرایطی روبه‌رو می‌شوند (شاید در ظاهر چنین کاری غیرمنطقی به نظر برسد اما در عمل اتخاذ چنین سیاستی مهندسین این شرکت را قادر ساخت تا Resiliency را بدون آنکه تأثیری منفی بر تجربهٔ کاربری مشتریان این شرکت داشته باشد تا حد ممکن افزایش دهند.)
در سال بعد (2011) این شرکت مجموعه ابزارهای تست Simian Army را ابداع نمود که این امکان را در اختیار توسعه‌دهندگان و تیم دوآپس این شرکت می‌گذاشت تا انواع و اقسام تست‌های مرتبط با بار (استرس) روی سرورهای این شرکت را پیاده‌سازی کنند و در سال 2012 نت‌فلیکس ابزار Chaos Monkey را به صورت اپن‌سورس عرضه کرد تا دیگر شرکت‌ها نیز بتوانند از آن استفاده کنند که برای آشنایی بیشتر با این ابزار، می‌توانید به مقالهٔ Chaos Monkey: ابزاری اپن‌سورس جهت تست نرم‌افزار مراجعه نمایید. در سال 2014 نیز در این شرکت سِمَتی تحت عنوان Chaos Engineer ابداع شد که چنین کسی وظیفهٔ کار با این ابزارها و حصول اطمینان از نهایت Uptime سرویس‌های این شرکت را داشت.
سایر منابع آموزشی در ارتباط با CE
برای کسب اطلاعات بیشتر در رابطه با CE منابع مختلفی در دسترس است که از آن جمله می‌توان به موارد زیر اشاره کرد:
- Chaos Conf کنفرانسی است که مهندسین CE دور هم جمع شده تا به تبادل اطلاعات بپردازند.
- Awesome Chaos Engineering ریپازیتوری‌ای در گیت‌هاب است که در آن منابع مرتبط مختلفی در ارتباط با CE یافت می‌شود.
- Chaos Engineering کتابی است که یکی از نویسندگان آن علی بصیری، مهندس نرم‌افزار ارشد در نت‌فلیکس، می‌باشد که دربرگیرندهٔ اطلاعات جامعی در این رابطه می‌باشد.
- Intro to Chaos Engineering یک ویدیوی آموزشی در یوتیوب است که در آن یکی از مهندسین SRE به معرفی CE می‌پردازد.
در این ارتباط نیاز است تا با مفهوم دیگری تحت عنوان Site Reliability Engineering یا به اختصار SRE نیز آشنا شویم که برای این منظور می‌توانید به مقالات زیر مراجعه نمایید:
- SRE: آشنایی با مقولهٔ مهندسی ضریب اطمینان و اهمیت در کمپانی گوگل
- تفاوت بین DevOps و SRE در چیست؟
- SLI | SLA | SLO: مفاهیم مرتبط با SRE که باید با آن‌ها آشنا بود
به طور کلی، چنانچه کسب‌وکار آنلاینی داشته باشیم که در لحظه هزاران کاربر از آن استفاده می‌کنند، اطمینان حاصل کردن از Uptime سرویس‌مان یک باید است و اینجا است که Chaos Engineering می‌تواند در هرچه کمتر کردن ریسک‌های مربوطه کمک کند.
