با توجه به گستردگی سرویس‌های آنلاین توزیع‌شده از یکسو و همچنین وابستگی کاربران و حتی سایر کسب‌وکارهای کوچک‌تر به این دست سرویس‌ها از سوی دیگر، شاهد ظهور معماری میکروسرویس و زیرساخت‌های توزیع‌شدهٔ ابری در فضای وب بوده‌ایم اما در عین حال پیچیدگی مدیریت این قبیل سرویس‌ها نیز به مراتب بیشتر از گذشته شده است که در چنین فضایی از دسترس خارج شدن وبسایت کسب‌وکارهای بزرگ آنلاین هزینه‌های گزافی را به آن‌ها تحمیل خواهد کرد و مسلماً 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 پیاده‌سازی کنند می‌باید تست‌هایی برنامه‌ریزی‌شده، منظم و کاربردی طراحی کنند تا پس از اِعمال آن‌ها بتوان فهمید که سرویس مذکور در چنین شرایطی چه عملکردی از خود نشان خواهد داد که در همین راستا، مهندسین این حوزه ابتدا به ساکن یک فرضیه می‌نویسند مبنی بر اینکه سیستم در صورت وقوع شرایطی خاص چه رفتاری از خود باید نشان دهد سپس در کوچک‌ترین مقیاس ممکن دست به پیاده‌سازی آن تست می‌زنند و در نهایت تأثیرات از دسترس خارج شدن سرویس را در تک‌تک مراحل پیاده‌سازی تست اندازه‌گیری می‌کنند تا ببینند سیستم در چه بخش‌هایی از این آزمون سربلند بیرون آمده و در کدام بخش‌ها شکست خورده است. با این تفاسیر، پس از تست‌هایی از این دست، تیم توسعهٔ نرمافزار با عکس‌العمل واقعی سیستم در شرایط بی‌ثبات آشنا خواهد شد.
در حقیقت، پس از انجام چنین تست‌هایی، یا سیستم زیر فشار سربلند بیرون می‌آید یا مشکلی ایجاد می‌شود که در هر دور صورت کار به درستی انجام شده است؛ در واقع، اگر هیچ‌گونه دَون‌تایمی صورت نگیرد، مهندسین از کارکرد دقیق سرویس‌شان مطمئن می‌شوند اما در صورت ایجاد مشکل، می‌فهمند که نقصی وجود دارد و باید موضوع ریشه‌یابی شده و دیباگ گردد.
چه شرکت‌هایی از CE بهره می‌گیرند؟
به طور کلی، شرکت‌های بزرگ ارائه‌دهندهٔ خدمات PaaS ،IaaS و SaaS که میلیون‌ها کاربر از سراسر دنیا دارند چاره‌ای جز به‌کارگیریِ CE ندارند که از آن جمله می‌توان به گوگل، مایکروسافت، فیسبوک، آمازون، نت‌فلیکس و دیگر شرکت‌های مطرح اشاره کرد مضاف بر اینکه سایر بیزینس‌ها همچون بانک‌ها و شرکت‌های هواپیمایی نیز از مزایای این نوع مهندسی بهره می‌گیرند. همان‌طور که از طریق واکسن آنفولانزا ما عمداً مقداری تعیین‌شده مواد مضر وارد بدن خود می‌سازیم تا سیستم ایمنی خود را برای مبارزه با این ویروس آماده و مقاوم سازیم، شرکت‌های فوق‌الذکر نیز CE را به منزلهٔ ابزاری تلقی می‌کنند که عملکردی همچون واکسن آنفولانزا داشته با این تفاوت که سیستم‌های کامپیوتری را برای هرگونه نقطه ضعفی ایمن می‌سازند.
ارتباط سیستم‌های توزیع‌شده با CE
اساساً سیستم‌های به اصطلاح Distributed با سیستم‌های سنتی Monolithic تفاوت‌هایی ساختاری دارند و با توجه به همین تفاوت معماری، پیش‌بینی رفتار سیستم‌های توزیع‌شده پیچیده‌تر است (برای آشنایی بیشتر با این دو نوع معماری، می‌توانید به مقالهٔ Microservice چیست؟ مراجعه نمایید.) در این رابطه، یکسری باورهای نادرست در مورد سیستم‌های توزیع‌شده وجود دارد که نقش بسزایی در هرچه گمراه‌تر شدن توسعه‌دهندگان دارند که از جملهٔ مهم‌ترین آن‌ها می‌توان به موارد زیر اشاره کرد:
- شبکه همواره قابل‌اعتماد و امن است.
- تأخیر (Latency) در شبکه برابر با صفر است.
- پهنای‌باند نامحدود است.
- توپولوژی شبکه هرگز تغییر نمی‌کند.
در همین راستا و جهت آشنایی بیشتر با این دست سیستم‌ها، می‌توانید به پادکست مصاحبه با امیرحسین پی‌براه: فوق‌دکترای بیگ دیتا و متخصص سیستم‌های توزیع‌شده مراجعه نمایید.
CE چه مزایایی برای کسب‌وکارها خواهد داشت؟
کسب‌وکارهای بزرگ آنلاین با بالا بردن سطح Resiliency زیرساخت خود می‌توانند این تضمین را ایجاد کنند که تحت بار زیاد روی سرورهای‌شان متحمل ضررهای کلان مالی نخواهند شد مضاف بر اینکه فشار روانی روی تیم مهندسی ایشان نیز به مراتب کمتر خواهد شد و در نهایت برند بهتری از خود در ذهن مشتریان ایجاد خواهند کرد. در عین حال، CE برای سایر ذی‌نفعان همچون کاربران عادی و یا کسب‌وکارهای B2B نیز حائز اهمیت است چرا که می‌توانند تجربهٔ استفاده از سرویس به اصطلاح Third-party باثبات‌تری را داشته باشند.
درآمدی بر ترتیب اجرای تست‌های CE
مشکلاتی که پس از زیر بار قرار گرفتن نرمافزار ممکن است رخ دهند را می‌توان در چهار دسته کلی تقسیم‌بندی کرد که عبارتند از:
- Known Knowns: مشکلاتی که نسبت به آن‌ها آگاه هستیم و درک‌شان می‌کنیم.
- Known Unknowns: مشکلاتی که نسبت به آن‌ها آگاه هستیم اما درک‌شان نمی‌کنیم.
- Unknown Knowns: مشکلاتی که نسبت به آن‌ها آگاه نیستیم اما درک‌شان می‌کنیم.
- Unknown Unknowns: مشکلاتی که نه نسبت به آن‌ها آگاه هستیم و نه درک‌شان می‌کنیم.
چنانچه بخواهیم به شکل بصری دسته‌بندی فوق را مشاهده کنیم خواهیم داشت:
برای درک بهتر این موضوع، فرض کنیم یک مجموعه دیتابیسی حاوی ده‌ها سرور MySQL داریم که در هر سرور چندین Shard وجود دارد (Shard نوعی پارتیشن‌بندی دیتابیس است که از آن طریق دیتابیس‌های حجیم به بخش‌های کوچک‌تر، سریع‌تر و قابل‌مدیریت‌تری تقسیم‌بندی می‌شوند.) در ناحیهٔ جغرافیایی خاصی یک دیتابیس اصلی داریم که حاوی اصطلاحاً دو Replica است (برای اینکه دیتابیس به صورت توزیع‌شده در نواحی جغرافیایی مختلفی پخش گردد تا کاربران به صورت بهینه‌تر بتوانند به نزدیک‌ترین سرور به خود متصل گردند و یا اگر یکی از سرورها از دسترس خارج بود کاربر بتواند بلافاصله به سرور دیگری متصل گردد، چندین نسخه از یک دیتابیس واحد ایجاد می‌گردد که به هر کدام از آن‌ها یک Replica گفته می‌شود.) در چنین شرایطی اگر CE را اِعمال کنیم، با شرایط زیر روبه‌رو خواهیم شد:
- Known Knowns: می‌دانیم وقتی رپلیکا از دسترس خارج شود مسلماً از Cluster حذف خواهد شد مضاف بر اینکه می‌دانیم که یک رپلیکا جایگزین به آن اضافه خواهد شد (به مجموع دیتابیس‌ها اصطلاحاً Cluster گفته می‌شود.)
- Known Unknowns: با مشاهدهٔ لاگ‌های نرمافزار می‌دانیم که دیتابیس کلون خواهد شد اما هرگز نمی‌دانیم متوسط زمانی که به طول خواهد انجامید تا پس از رخداد مشکل کلون به کلاستر اضافه گردد چه‌قدر است.
- Unknown Knowns: چنانچه در آنِ واحد دو رپلیکا را از یک کِلاستر حذف کنیم، نمی‌دانیم که به طور میانگین چه‌قدر طول خواهد کشید تا دیتای مربوطه کپی شود اما در عین حال می‌دانیم که در ناحیهٔ جغرافیایی دیگری دو رپلیکا داریم که زیر بار خواهند رفت.
- Unknown Unknowns: دقیقاً نمی‌دانیم اگر در یک ناحیهٔ جغرافیایی خاص کلاستر از دسترس خارج شود چه اتفاقی خواهد افتاد مضاف بر اینکه نمی‌دانیم آیا سرور جایگزین در ناحیه‌ای دیگر به درستی عمل خواهد کرد یا خیر زیرا اساساً چنین سناریویی هرگز اتفاق نیفتاده است.
سایر منابع آموزشی در ارتباط با 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 می‌تواند در هرچه کمتر کردن ریسک‌های مربوطه کمک کند.
