JavadAgha
JavadAgha
خواندن ۴ دقیقه·۶ ماه پیش

استراتژی‌های استقرار

استقرار(Deploying) یا ارتقاء(upgrading) سرویس‌ها فرآیندی حساس است. در این پست، ما استراتژی‌های کاهش خطر را بررسی می‌کنیم.

دیاگرام های زیر استراتژی‌های رایج را نشان می‌دهد.

استقرار چندسرویسی (multi-service deployment)
استقرار چندسرویسی (multi-service deployment)

استقرار چندسرویسی

در این مدل، تغییرات جدید به طور همزمان در چندین سرویس مستقر می‌شوند. این رویکرد آسان برای پیاده‌سازی است. اما از آنجا که همه سرویس‌ها همزمان ارتقا می‌یابند، مدیریت و تست وابستگی‌ها (test dependencies)دشوار است. همچنین، بازگشت ایمن(rollback safely) به حالت قبلی نیز دشوار است.


 (Blue-Green Deployment)تقرار آبی-سبز
(Blue-Green Deployment)تقرار آبی-سبز


استقرار آبی-سبز

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


(Canary Deployment)تقرار کاناری
(Canary Deployment)تقرار کاناری


استقرار کاناری

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


آزمایش A/B
آزمایش A/B


آزمایش A/B

در آزمایش A/B، نسخه‌های مختلفی از سرویس‌ها به طور همزمان در production اجرا می‌شوند. هر نسخه یک «آزمایش» را برای زیرمجموعه‌ای از کاربران اجرا می‌کند. آزمایش A/B یک روش کم هزینه برای آزمایش ویژگی‌های جدید در تولید است. ما باید فرآیند استقرار را کنترل کنیم تا در صورتی که برخی ویژگی‌ها به طور تصادفی به کاربران فرستاده شوند، اقدام کنیم.


مشکلات مربوط به استقرار در production ؟

خرابی های مربوط به استقرار می توانند به دلایل مختلفی رخ دهند، از جمله:

۱. تغییرات ناسازگار: استقرار تغییراتی که با معماری موجود سیستم یا وابستگی ها ناسازگار هستند می تواند منجر به شکست های غیرمنتظره و خرابی شود.

۲. مشکلات مقیاس پذیری: استقرار به‌روزرسانی هایی که به درستی با افزایش ترافیک یا بار کار برخورد نمی‌کنند می تواند منجر به مشکلات عملکردی و خرابی شود.

۳. خطاهای پیکربندی: اشتباهات در پیکربندی های مخصوص محیط (مانند رشته‌های اتصال پایگاه داده، کلیدهای API و غیره) می تواند منجر به شکست های بحرانی در طول استقرار شود.

۴. آزمایش ناکافی: آزمایش ناکافی فرآیند استقرار و تغییرات جدید می تواند منجر به مشکلات غیرمنتظره در محیط تولید شود.

۵. شکست بازگشت: مشکلات با فرآیند بازگشت می تواند دشوار باشد که به یک وضعیت پایدار برگردید، که منجر به خرابی های طولانی مدت می شود.

۶. شکست زیرساخت: مشکلات با زیرساخت زیربنایی (مانند خدمات ابری، شبکه و غیره) می تواند بر فرآیند استقرار تأثیر گذاشته و منجر به خرابی شود.


راهبردهای استقرار خاصی که ذکر کردید (چندخدمتی، کناری، آبی-سبز، آزمایش A/B) طراحی شده‌اند تا خطر خرابی های مربوط به استقرار را با استقرار تدریجی تغییرات و ارائه راهی برای بازگشت سریع اگر مشکلاتی تشخیص داده شوند، کاهش دهند. با این حال، حتی با این راهبردها، خرابی ها همچنان ممکن است رخ دهند اگر به درستی پیاده‌سازی نشوند یا اگر مشکلات زیربنایی در سیستم وجود داشته باشند.


بهترین راه برای پیشگیری و کاهش خرابی های مربوط به استقرار، داشتن یک خط لوله استقرار قوی و به خوبی آزمایش شده، سیستم های نظارت و هشدار دقیق و یک برنامه پاسخ به حوادث واضح است.


چند نکته اضافی برای پیشگیری و کاهش خرابی های مربوط به استقرار:

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

۲. استقرار تدریجی: استقرار تغییرات به صورت تدریجی و مرحله ای (مانند استقرارهای کاناری یا آبی-سبز) به شما امکان می دهد تا برای مشکلات پایش کنید و در صورت لزوم به سرعت بازگردید، به جای یک استقرار یکپارچه.

۳. نظارت و هشدار: داشتن نظارت قوی برای ردیابی شاخص های کلیدی و شناسایی سریع هرگونه ناهنجاری می تواند به شناسایی مشکلات به محض بروز آنها کمک کند و واکنش سریع را ممکن سازد.

۴. بازگشت خودکار: خودکارسازی فرآیند بازگشت به طوری که بتواند به سرعت و قابل اعتماد اجرا شود، برای کاهش زمان توقف در طول یک حادثه حیاتی است.

۵. برنامه ریزی پاسخ به حوادث: توسعه روش های واضح پاسخ به حوادث، با نقش ها و مسئولیت های مشخص، می تواند به تیم ها در پاسخ دهی کارآمد و موثر در زمان بروز خرابی ها کمک کند.

۶. بررسی پس از حادثه و بهبود مداوم: تجزیه و تحلیل دقیق علل ریشه ای حوادث گذشته و پیاده سازی بهبودهای فرآیندی می تواند به پیشگیری از بروز مشکلات مشابه در آینده کمک کند.



مقیاس پذیریاستقرارdevopsطراحی سیستم های نرم افزاریdeploy
کنجکاو در مباحث مهندسی نرم افزار
شاید از این پست‌ها خوشتان بیاید