ایجاد آشوب یا به انتظار آشوب؟

در ابتدا باید بگویم که هدف این مقاله، تشویق به استفاده از مهندسی آشوب (Chaos Engineering) و یا نقد آن نیست و تنها به تعریف مفاهیم آن و همچنین به تجربیاتی که در سحاب به‌دست آورده‌ایم، پرداخته شده است.

یک تعریف روان و دم دستی!

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

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

با توجه به ماهیت سیستم‌های توزیع‌شده، مسائل متعددی باعث افت کیفیت یا قطع شدن سرویس می‌شود؛ از جمله قطعی برق، تأخیر یا قطع شدن شبکه و...

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

به قول خانم Tammy Buttow که یکی از فعالان در حوزهٔ مهندسی آشوب است:

بهتر نیست به‌جای اینکه هر روز نگران این باشیم که برق برود،‌ یک بار خودمان برق را قطع کنیم و ببینیم چه اتفاقی می‌افتد؟

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

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

طبیعیست انجام این آزمایش‌ها بر روی سرویس‌هایی که شامل ۳ یا ۴ سرور است بسیار پرهزینه و بی‌فایده خواهد بود. پیچیدگی چنین پروژه‌هایی آن‌قدر نیست که هزینه/فایدهٔ انجام این کار برایتان به‌صرفه باشد.

اشتباه رایج!

خیلی از افرادی که با کلمهٔ Chaos در حوزهٔ مهندسی نرم‌افزار آشنایی دارند، با من هم‌نظر هستند که از کلمهٔ Chaos Monkey به عنوان یک حوزه در مهندسی نرم‌افزار یاد می‌شود؛ در صورتیکه Chaos Monkey تنها یک ابزار است، نه بیشتر.

داستان برمی‌گردد به سال ۲۰۱۰ میلادی که شرکت Netflix تصمیم می‌گیرد زیرساخت فیزیکی خود را به سرورهای ابری آمازون منتقل کند. برای این کار مهندسان شرکت Netflix ابزار Chaos Monkey را توسعه داده تا مطمئن شوند که در صورت قطع شدن سرورهای آمازون، سرویس Netflix قطع نخواهد شد.

حالا که صحبت از سال ۲۰۱۰ و شروع ماجرای مهندسی آشوب شد، کمی باهم تاریخ‌بازی کنیم:

· سال ۲۰۱۱: مفهوم Simian Army با هدف اضافه کردن عملکردهای بیشتر به ابزار Chaos Monkey و پوشش بیشتری از شیوه‌های تزریق خطا (Failure Injection)، توسعه یافت.

· سال ۲۰۱۲: نت‌فلیکس با رویکرد Fail often ابزار Chaos Monkey را در گیت‌هاب قرار داد.

· سال ۲۰۱۴: برای اولین بار، سِمَت Chaos Engineer (مهندس آشوب) در شرکت نت‌فلیکس تعریف شد. تعریف این سمت شغلی باعث شد که ابزاری به نام (Failure Injection Testing (FIT به‌وجود بیاید. هدف از این کار داشتن کنترل بیشتر و کمتر کردن حالات تصادفی در اجرای تست‌ها بود.

· سال ۲۰۱۶: شرکت‌های دیگری مانند Gremlin تاسیس شد که مدیران اصلی این شرکت‌ها اغلب از شرکت نت‌فلیکس بودند.

· سال ۲۰۱۸: شرکت گرملین کنفرانس بزرگی را با نام Chaos Conf را طراحی کرد.

· سال ۲۰۲۰: شرکت آمازون، مهندسی آشوب را به صورت رسمی به (WAF (Well-Architected Framework خود اضافه کرد.

با یک نگاه کلی به این تاریخچه، می‌توان به اهمیت این حوزه در بحث مهندسی نرم‌افزار در سال‌های اخیر پی برد؛ اما وقتی نام شرکت‌هایی را که در حال حاضر، در حال بهره‌برداری از این حوزهٔ مهندسی هستند، می‌بینیم، بیش از پیش به نفوذ مهندسی آشوب در حوزهٔ مهندسی نرم‌افزار پی می‌بریم. نام شرکت‌هایی که در ادامه آمده است، می‌تواند پشتوانهٔ خوبی برای اعتبار این حوزه باشد. شرکت‌هایی همچون:

نت‌فلیکس، لینکداین، فیس‌بوک، گوگل، مایکروسافت و آمازون

خب که چه!؟

سؤال خوبیست. ما در سحاب سرویس‌های داده‌محور ارائه می‌کنیم. پس برای مدیریت این داده‌ها نیاز به سیستم توزیع‌شده با تکنولوژی‌های بیگ‌دیتایی داریم. محیط اجرا آن‌قدر پویا و در حال تغییر است که نمی‌توانیم برای تغییرات روی محیط اجرا، به‌ صورت مکرر به مشتری،درخواست Downtime بدهیم؛ یا این که آن‌قدر برق رفتن تبدیل به امری عادی شده که تصمیم گرفتیم برای یک بار هم که شده خودمان برق را قطع کنیم ببینیم چه می‌شود. به همین دلیل کمربندمان را محکم کردیم و زدیم به دل تحقیق و توسعه دربارهٔ این حوزه.

پیش از اجرا...

ابزار موجود را دیدیم، پیش‌نیازها را بررسی کردیم، سامانهٔ مانیتورینگمان را قابل اتکاتر کرده و از همه مهم‌تر برای مسئلهٔ Disaster Recovery کارهای خوبی انجام دادیم و به محض این که شرایط را برای اجرای این نوع از تست‌ها آماده دیدیم، به همراه تیم‌هایDevOps، SRE، Change management، Development و...، به‌ خط شدیم که برنامهٔ عملیات (Action plan) را استخراج کنیم.

پس از استخراج برنامهٔ عمليات، شعاع انفجار (Blast Radius) را هماهنگ کردیم. در تحقیقاتی که انجام شد، بِه‌‌روش‌هایی (Best Practices) که در حوزهٔ مهندسی آشوب وجود داشت، دلالت بر کمینه کردن شعاع انفجار در ابتدای انجام آزمون‌ها داشت. ما هم خومان را از این قاعده مستثنی نکردیم و تا توانستیم با صبر و حوصله، اما با اطمینان خاطر، نقشهٔ اجرا را چیدیم.

داخل پرانتز بگوییم که، مهندسى آشوب در سطوح زیر قابل انجام است:

· در سطح زیرساخت سخت‌افزاری

· در سطح شبکه

· در سطح نرم‌افزار

اینکه چه مواردی را در نقشهٔ اجرا لیست کردیم در ادامه می‌بینیم:

۱- لیست سرویس‌هایی که باید مورد آزمون قرار می‌گرفتند را کشف کردیم.

۲- لیست ماشین‌ها را به همراه آدرس آی پی آنها پر کردیم.

۳- سرویس‌ها را بر اساس مخاطرات و دامنهٔ اثرشان مرتب کردیم.

۴- درخواست تغییر (RFC) را آماده کردیم و ...

اجرا...

ما تصمیم گرفتیم برای شروع به سراغ اجرای آزمون در سطح شبکه برویم. چگونه؟

به این صورت که ابزاری که نوشتیم، به صورت خودکار شبکهٔ ماشین(ها)ی هدف را مختل می‌کند (این اختلال قابل کانفیگ است و می‌تواندشامل Packet Loss یا Delay و یا حتی قطعی کامل شبکه باشد). پس از اختلال در شبکه و در بازه‌ای که برای اختلال در کانفیگ در نظر گرفتیم، آزمون اصلی شروع می‌شود و از طریق سامانهٔ مانیتورینگ بررسی می‌کنیم که اوضاع سرویس به چه شکل است. نکتهٔ مهم این است که با این که دامنهٔ اثر را در ابتدا بسیار کوچک در نظر گرفتیم، اما تیم‌های پشتیبانی و مدیریت سانحه On-call بودند. بعد از آن که اجرای آزمون به اتمام رسید، ابزار، باز هم به‌ صورت خودکار، وضعیت شبکه را به حالت پایدار (Steady State) برمی‌گرداند.

متخصصان توصیه می‌کنند چنین مانورهایی در ابتدا در محیط آزمایشگاه صورت بگیرد.

پس از اجرا...

راستش را بخواهید از همین تکرارها در محیط آزمایشگاه، درس‌ها و نکات زیادی کشف می‌شود. مثلا اینکه هرچقدر که تلاش کنیم، بازهم معماری محیط اجرا با معماری محیط آزمایشگاه کاملا یکی نخواهد شد؛ اما با اجرای این آزمون‌ها (Chaos Engineering) تا حد بسیار زیادی دو محیط را به هم نزدیک خواهید کرد. نکتهٔ دیگر این است که تکنولوژی‌هایی مثل hadoop و kafka و HBase کاملا وابسته به کانفیگ هستند. از کجا می‌دانید که کانفیگی که برای این تکنولوژی‌ها انجام داده‌اید، HA بودن سرویس را تضمین می‌کند؟ آیا فرضیه‌ای (Hypothesis) وجود دارد که برای آن، راه حل اثبات وجود داشته باشد؟

سامانهٔ مانیتورینگ ما در طول اجرای آزمونی که بر روی تکنولوژی HBase اجرا کردیم، خطایی داد که در نگاه اول اصلا مشخص نبود به چه دلیل است؛ اما بعد از بررسی متوجه شدیم که گره HMaster خودکشی کرده است. چرا؟ در آن لحظه نمی‌دانیم! فقط می‌دانیم که با اختلالی که در شبکه ایجاد کرده بودیم، این اتفاق افتاد. اینجا بود که به ابزاری که آماده کرده بودیم بیش از پیش افتخار کردیم؛ چرا که با ۱ تیر چند نشان زده بودیم: سامانهٔ مانیتورینگ را ارزیابی کردیم، ابزار ایجاد آشوب را امتحان کردیم و نیز متوجه شدیم که سرویس HBaseمان چقدر دسترس‌پذیر است.

تکلیف سرویس‌های وابسته چیست؟!

ما در برنامهٔ عملیاتمان برخی از سرویس‌های وابسته را لیست نکرده بودیم؛ اما در زمان اجرای آزمون‌ها، متوجه شدیم که با از کار افتادن برخی سرویس‌ها، تعدادی از سرویس‌های دیگر هم دچار اشکال می‌شوند. (بازهم دلیلی دیگر برای اجرای آزمون‌ها در آزمایشگاه)

یکی از بزرگترین دستاوردهای ما این بود که با انجام این آزمون‌ها، توانستیم با پشتوانهٔ علمی، به مشتری‌هایمان بگوییم که مؤلفه‌های محیط اجرا کاملا دسترس‌پذیر (Highly Available) هستند.

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

حرف آخر

آشوب را ایجاد کنید و نگذارید که آشوب، شما را ایجاد کند. (شوخی!)

اما اگر می‌خواهید مثل ما در سحاب، مؤلفه‌های در حال اجرا را در همان محیط اصلی (محیط Production) و بدون گرفتن Downtime از مشتری، مورد ارزیابی قرار دهید، هر چقدر که می‌توانید آزمون خودکار نوشته، انتشار و استقرار نسخه‌ها را کاملا خودکار کرده و جملهٔ Fail Fast Fail Often را در واقعیت بالفعل کنید.

همچنین شاید بد نباشد که مراحل اجرای ارزیابی‌های مهندسی آشوب را به‌صورت زیر بنویسیم:

پیش از اجرا

• برنامه‌ریزی برای Disaster Recovery
• داشتن سامانهٔ مانیتورینگ قابل اتکا
• تهیهٔ نقشه‌ٔ اجرا (Action Plan)

اجرا

• آماده کردن آزمون‌های کاملا خودکار جهت تزریق خطا در محیط اجرا (Production)
• نگهداری حالت Steady State برای برگشتن به این حالت، بعد از اتمام ارزیابی
• کمینه کردن شعاع انفجار (Blast Radius)
• اجرای ارزیابی در محیط آزمایشگاه
• اجرای ارزیابی در محیط اجرا

پس از اجرا

• بررسی نتایج به‌دست آمده در سامانهٔ مانیتورینگ

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

متشکرم!