استراتژی های برخط کردن سیستم

در حقیقت عنوان ترجمه Deployment Strategies است که فکر کردم این ترجمه بهتر باشد.قضیه از این قرار است که شما یک سیستم جدید یا یک قابلیت جدید یا نسخه بروزرسانی شده از یک سیستم و/یا یک قابلیت که اکنون زیربار است را می خواهید جایگرین نسخه قبلی کنید، در این فرآیند باید هزینه و ریسک ناشی از اشتباهات و موارد حساب نشده حداقل باشد و تا حد امکان سیستم downtime نداشته باشد.در بسیاری از محیط ها و ابزارهای DevOps مثل OpenShift و کوبرنتیس و ... هم همین عناوین و ادبیات را در سرفصل Deployment مشاهده می کنید و لازم است درک صحیحی از این مفاهیم داشته باشید.شش استراتژی متداول و معروف برای اینکار وجود دارند :روش Recreate : به این روش Basic Deployment هم می گویند، به این صورت است که نسخه A را خاموش کرده و نسخه B را آنلاین می کنیم.مزایای این روش سرعت و سادگی و نو شدن کل سیستم در یک مرحله است. همچنین نیازی به منابع مضاعف برای آنلاین نگه داشتن هر دو نسخه نیست.معایب آن این است که زمان و محیطی برای تست نسخه جدید در محیط production نیست و درصورت بروز مشکل زیربار عملیات در محیط واقعی کاربران تحت تاثیر قرار می گیرند، همچنین بین خارج شدن نسخه قدیم از دسترسی تا آنلاین شدن نسخه جدید ممکن است وقفه ای وجود داشته باشد. از سوی دیگر اگر نسخه قدیم از مدار و زیرساخت خارج شده باشد بارگذاری و آنلاین کردن مجدد آن ممکن زمانبر بوده و در این فاصله درخواست ها قابل پاسخگویی نباشند.روش A/B testing :این روش عمدتاً در آزمایش و سنجش عملکرد نسخه های جدید و سنجش بازخوردهای کاربران و صحت و بازدهی سیستم استفاده می شود و به اینصورت است که بخش مشخصی از کاربران براساس ruleهای تعریف شده به نسخه های جدید هدایت شوند (مثلاً deviceهای متفاوت، موقعیت جغرافیایی متفاوت، گروه کاربری متفاوت و ...) و شرایط و پاسخ گویی نسخه های جدید نسبت به این کاربران سنجیده شود.دقت بفرمایید ممکن است یک نسخه برای 2 دسته کاربری که شرایط متفاوت دارند نیز تست شود. یعنی هم نسخه هم دسته کاربری متغییر هستند.مزایای آن این است که میتوان روی اینکه چه کاربرانی چه نسخه ای را می بینند و بازخورد آن کنترل و سنجش داشت و نسخه های مختلف را همزمان در محیط production تست کرد.معایب آن این است که این روش در حقیقت یک روش تحقیقاتی برای آزمایش و سنجش است و برای کار واقعی با تعدد نسخ و محیط ها مواجه خواهیم شد که فرآیند deployment مستر پیچیده تر و پرریسک تر می کند ، همچنین ممکن است در توزیع ترافیک کاربران و سنجش بازخورد آن ها و سیستم پیچیدگی های فنی وجود داشته باشد.روش Shadow :در این روش نسخه قدیم و جدید همزمان آنلاین هستند، یک کپی از ترافیک جاری نسخه قدیم روی نسخه جدید ارسال می شود تا صحت و بازدهی آن تست شود. دقت بفرمایید نسخه قدیم آنلاین و فعال است و معمولاً کل عملیات نیز توسط همان نسخه قدیم انجام می شود، در اینجا مقصود تست شبیه سازی شده نسخه جدید با ترافیک و شرایط production بوسیله یک کپی زنده از شرایط نسخه قدیمی جاری است.مزیت این روش امکان تست نسخه جدید در محیط و شرایط production و قابلیت پیگیری خطاهای بوجود آمده بدون اثر گذاری روی کاربران و ترافیک زنده است. همچنین پس از کسب اطمینان می توان ترافیک را بصورت مستقیم روی نسخه جدید ارسال کرد و نسخه قدیمی را خاموش نمود.عیب آن نیاز به منابع مضاعف برای آنلاین کردن 2سیستم و پیچیدگی فنی پیاده سازی برای انتقال یک کپی از ترافیک نسخه قدیم به جدید و گرفتن بازخوردی که دیگر الزاماً بازخورد یک کاربر زنده واقعی نیست است.روش Canary :در این روش ما میزان آنلاین شدن و زیربار رفتن سیستم جدید را براساس فازهای تعیین شده افزایش می دهیم. یعنی مثلاً در ابتدا 1% ترافیک و عملیات روی نسخه جدید است، اگر ok بود ، 10% ، اگر ok بود 30% و همینطور تا 100% قضیه ادامه پیدا می کند.به این روش phased rollout و incremental rollout هم می گویند.مزیت آن کاهش ریسک و downtime و تست تدریجی نسخه جدید است.عیب آن طولانی بودن زمان برخط کردن کامل سیستم جدید و پیچیدگی ها عملیاتی برای تقسیم ترافیک و سخت بودن تست های تعیین و کنترل شده بخصوص درباره بازخوردهای کاربران است.روش Dark launching :لازم بذکر است این مورد بیشتر در سرفصل تست نرم افزار و قابلیت و Continuous Delivery دسته بندی می شود و استراتژی system deployment نیست. اما برای آشنایی و با توجه به مرتبط بودن و استفاده زیاد فکر کردم ذکر آن اینجا مفید باشد. برای مطالعه بیشتر درباره Automated testing اینجا را ببینید.این روش حالتی از روش shadow و A/B Testing و canary برای برخط کردن یک قابلیت جدید روی سیستم موجود است و بیشتر برای قابلیت های جدید بکار می رود. یعنی معمولاً وقتی نسخه قبلی نبوده و یک چیز جدید می خواهد به یک سیستم اضافه شود به این روش تست می کنند. در این روش قابلیت جدید روی backend فعال می شود یا به اصطلاح predeploy می شود، سپس برای دسته تعیین شده ای از کاربران روی frontend فعال می شود تا عملکرد آن در محیط production تست شود و اگر جواب آزمایش و سنجش ها مثبت بود، قابلیت جدید برای همه کاربران فعال خواهد شد. روش Ramped :این روش به rolling-update هم معروف است و عموماً در محیط های کانتینری و ارکستراسیون ها استفاده می شود. در این روش نسخه جدید نود به نود جایگزین نسخه قدیمی می شود.ریسک پایین و سادگی نسبی فرآیند پیاده سازی و انتقال از مزایای این روش هستند.معایب آن نداشتن کنترل روی ترافیک و نداشتن فضای آزمایش و سنجش تعیین شده و امکان پیچیدگی در roll back است.روش Blue/Green :در این روش نسخه جدید بصورت کامل در کنار نسخه قدیمی آنلاین می شود و در شرایط staging قرار می گیرد. سپس روی نسخه کامل جدید تست صحت و بازدهی در محیط و زیرساخت واقعی انجام می شود و درصورت صحت، ترافیک از روی نسخه قبلی به نسخه جدید منتقل می گردد.تفاوت آن با shadow این است که در مرحله تست بجای یک کپی از ترافیک واقعی، معمولاً با automated testها و آزمایش های شبیه سازی شده تست انجام می شود. مزیت این روش که بسیار متداول هم هست سادگی تست و انتقال ، سادگی بازگشت به شرایط قبل فقط با تغییر مسیر ترافیک و زیر بار واقعی بودن یک نسخه در آن واحد است.عیب آن نیاز به منابع مضاعف در محیط واقعی برای آنلاین بودن همزمان نسخه قدیم و جدید و امکان ایجاد مشکلاتی زیربار واقعی و کامل که در تست های روتین کشف نشده اند است.این هفت مورد مهمترین روش های اصلی برای آنلاین کردن یک سیستم کامل جدید یا قابلیت جدید هستند که البته ممکن است بسته به نیاز و شرایط با تغییرات یا بصورت ترکیبی استفاده شوند یا اساساً روشی اختصاصی برای سناریوی شما نیاز باشد که با ایده گرفتن از اینها باید طراحی کنید.