ارزیابی میزان موفقیت عملکرد DevOps با DevOps KPI

The four dimensions of DevOps metrics

مدیریت DevOps با استفاده از معیارهای ارزیابی

امروزه و در عصر DevOps، پیوسته لازم است که شاخص های کلیدی عملکرد (KPI) را ارزیابی کنید تا میزان موفقیت DevOps مشخص شده و امکان تغییرات بیشتر فراهم شود.

DevOps بدون tradeoff

DevOps در اصل از طریق جنبش چابک (Agile Movement) رشد پیدا کرد و در واقع راهکاری برای افزایش سرعت ارائه نرم افزار توسط تیم های توسعه نرم افزار به مشتریان است. در حال حاضر DevOps دربرگیرنده همه بخش های فرایند ارائه نرم افزار است از برنامه ریزی گرفته تا ایمن سازی، نظارت و بروز رسانی اپلیکیشنی که از قبل تولید شده است.

امروزه، DevOps به طور گسترده برای build، تست و ارائه نرم افزار توسط کسب و کارهای مختلف پذیرفته شده است. در این دنیای رقابتی، پرتحرک و همیشه متصل، DevOps شرکت ها را قادر ساخته که از طریق از بین بردن سیلوهای توسعه (Dev) و عملیات (Operation)، با خواسته ی کاربران در مورد تحویل و ارائه سریع همگام شوند.software was a key enabler for the business

این شرایط اهمیت کیفیت نسبت به گذشته را دوچندان کرده است؛ در نتیجه کسب و کارها نمی توانند صرفا برای ارائه سریع نرم افزار به بازار، کیفیت را نادیده بگیرند. با ارائه ی یک اپلیکیشن با عملکرد ضعیف در یک فروشگاه اپلیکیشنی (app store) که کاربران نظرات منفی زیادی در آن درج می کنند، به سرعت می توان شهرت و خوشنامی یک برند را از بین برد. با استفاده از DevOps، بهینه سازی کارها در جهت افزایش سرعت، همزمان با حفظ کیفیت و کاهش خطرها قابل انجام است. Batchهای کوچک، سریع تر ارائه شده و به صورت ذاتی مشکلات مربوط به کیفیت و امنیت را کاهش می دهد.

افزایش سرعت در توسعه نرم افزار به روش سنتی، اغلب اوقات باعث کاهش کیفیت و افزایش آسیب پذیری می شود.   همچنین در روش های سنتی افزایش سرعت، کیفیت و امنیت عاملی برای افزایش هزینه ها محسوب می شود. اما ابتکارات DevOps می تواند واقعا منجر به بهبود در تمام این چهار بُعد شود: سرعت، کیفیت، بهره‌وری و امنیت. کلید کار اتخاذ چارچوبی برای معیارها است که مشخص کند چه جاهایی در حال پیشرفت هستید و چه جاهایی هنوز نیاز به بهبود دارید.

DevOps without trradeoffs

وجود معیارهای ارزیابی ضروری است

اکثر سازمان ها DevOps را به دلیل یک نیاز بیزینسی خاص مثل بهبود زمان بازاریابی، کاهش نقایص یا تراز کردن بهتر ابتکارات IT با استراتژی بیزینسی پیاده سازی می کنند. اما از آنجا که DevOps هیچ فریم ورک رسمی ندارد، روش های زیادی برای ارزیابی موفقیت DevOps وجود ندارد، در حالیکه این ارزیابی حیاتی است. از آنجا که خیلی از سازمان ها DevOps را به صورت تدریجی پیاده سازی می کنند – اول در یک پروژه و بعد آرام آرام آن را در سراسر سازمان گسترش می دهند – چند پروژه اول باید موفقیت آمیز باشند؛ طوریکه بتوانند پشتیبانی انحصاری برای DevOps ایجاد کنند. همانطور که مشتریان ما به ما گفته اند: “هر چیزی که ارزیابی شود، بهبود پیدا می کند.”

"people issues" were the biggest challenge to adopting DevOps

وجود معیارهایی که نشان دهنده موفقیت آمیز بودن یک آزمایش باشند، می تواند به غلبه بر مقاومت های داخلی در برابر پذیرش DevOps کمک کند. یکی از نظرسنجی های شرکت Gartner از مدیران مشاغل2 و  بخش IT مشخص کرد که “people issue” (موارد مربوط به افراد) بزرگترین چالشی است که سازمان ها در پذیرش DevOps با آن روبرو هستند و 43 درصد پاسخ دهندگان مقاومت در برابر تغیرات را بزرگترین مانع دانسته اند. از آنجا که DevOps نیاز به تحول فرهنگی و تغییرات فرایند و فناوری دارد، وجود پشتیبانی و حمایت انحصاری از آن ضروری است.

بعلاوه، DevOps به عنوان یک سیر تکاملی شناخته شده است که نیاز به بهبود مستمر (Continuous Improvement) دارد. اما اگر نتایج را ارزیابی نکنید، متوجه نمی شوید که DevOps را چطور درون سازمانتان تکامل دهید.

ارزیابی در مسیر تکامل DevOps بسیار ضروری و حیاتی است. اما چطور می توان موفقیت DevOps را ارزیابی کرد؟ چه چیزی باعث عملکرد فوق العاده‌ی یک سازمان می شود؟ کدام شاخص های کلیدی عملکرد (KPI) این قابلیت را دارند که مشخص کنند چه چیزی برای شما خوب کار می کند و چه چیزی خیر – و اطلاعاتی برای توضیح علت (علت کار نکردن بعضی روش ها) فراهم کنند؟ چه چیزهایی را ارزیابی می کنید، چطور آن ها را ارزیابی می کنید و این اعداد دقیقا چه چیزی را نشان می دهند؟

این مقاله یازده شاخص کلیدی عملکرد را مشخص کرده که فنداسیون لازم برای معیارهای DevOps را ایجاد می کنند، رشته ای که همگام با تکامل روش های DevOps بیشتر و بیشتر درون شرکت هایی در انواع مختلف تنیده می شود. این یازده شاخص را در پست بعدی معرفی و بررسی خواهیم کرد.

DevOps metrics are essential

معیارهای ارزیابی DevOps در چهار بعد

برای تعیین بهترین شاخص های کلیدی عملکرد (KPI) جهت ارزیابی DevOps، شرکت Hewlett Packard Enterprise Software Services (به اختصار HPE) در ابتدا بزرگترین چالش های ارائه نرم افزار را که مشتریان گزارش شده بود را بررسی کرده است:

  1. کند بودن زمان عرضه به بازار  | Slow time to market
  2. ایجاد تجربیات ضعیف برای کاربران | Poor user experience
  3. هزینه های بالا | High cost
  4. پیش پینی پذیری ضعیف  | Poor predictability
  5. آسیب پذیری و ریسک  | Vulnerabilities and risk

هر یک از این چالش ها به تنهایی می تواند موانعی برای یک شرکت در جهت برآورده کردن خواسته های کاربران ایجاد کند. هر یک از این چالش ها به تنهایی، در توانایی یک شرکت برای برآورده سازی تقاضاهای کاربران مانع ایجاد می کند. اما تقریبا هر شرکتی حداقل با سه یا چهار مورد از این چالش ها روبرو می شود و خیلی از شرکت ها با تمام این پنج چالش روبرو می شوند. جای تعجب نیست که خیلی از تیم های نرم افزاری اطلاع ندارند که کجا یا چطور شروع به اصلاح مشکلاتشان کنند.

شرکت HPE ریشه این مشکلات را چهار حوزه متفاوت می داند:

  1. سرعت | Velocity
  2. کیفیت | Quality
  3. بهره‌وری | Productivity
  4. امنیت | Security

DevOps می تواند تمام این چهار مورد را بدون از دست رفتن هیچکدام برآورده کند. موفقیت در هر یک از این چهار حوزه می تواند زمان عرضه به بازار، تجربیات کاربر، هزینه، پیش بینی پذیری و امنیت را کاملاً بهبود ببخشد.

شرکت HPE، رهبری تعریف معیارهایی که شرکت های امروزی باید ارزیابی و نظارت کنند را بر عهده گرفته است. بعضی از بزرگترین مشتریان DevOps در حال حاضر این فریم ورک را قبول و پیاده سازی کرده‌اند.

سرعت (Velocity) : نرخ ارائه تغییرات نرم افزاری توسط یک سازمان را ارزیابی می کند.
کیفیت (Quality) : ارزیابی می کند که تغییرات نرم افزاری ارائه شده چقدر نیازهای کسب و کار را برآورده و در جهت رضایت عمل می کنند.
بهره وری (Productivity) : ظرفیت و کارایی یک سازمان در تحویل تغییرات نرم افزاری را ارزیابی می کند.
امنیت (Security) : آسیب پذیری هایی که هنگام تحویل تغییرات نرم افزاری نمایان می شوند را ارزیابی می کند.

سرعت، کیفیت، بهره وری و امنیت به یکدیگر وابسته اند. بهبود یک حوزه منجر به بهبود در سه حوزه دیگر می شود بدون این که نیازی به tradeoff باشد.

The four dimensions of DevOps metrics

velocity iconچرا اندازه گیری و ارزیابی سرعت مهم است؟

مهم ترین ویژگی DevOps سرعت است. DevOps به عنوان راهی برای عرضه سریع امکانات جدید توسط توسعه دهندگان در پاسخ به تقاضای کاربران برای محتوای سریع تر و بهتر، ایجاد شده است. و با توجه به اینکه سرعت، امری نسبی است –احتمالا همیشه می خواهید که سریع تر و سریع تر از قبل باشید– بیشتر تیم های توسعه دهنده فراموش می کنند که به دنبال چه هدفی هستند.

با اندازه گیری و ارزیابی سرعت متوجه می شوید که آیا در حال افزایش سرعت هستید یا کاهش آن و یا اینکه در یک الگوی خاص گرفتار شده اید. همچنین می توانید به بیزینس کمک کنید که به طور واضح‌تری میزان پاسخگویی بخش IT را مشخص کند.

سرعت زیاد در تحویل نرم افزار، علاوه بر ایجاد مزیت رقابتی برای شرکت، نحوه تعامل کسب و کار با بخش IT را هم بهبود می بخشد.

quality iconچرا اندازه گیری و ارزیابی کیفیت مهم است؟

طبق نظرسنجی ای1 که شرکت Forrester Consulting از تصمیم گیرندگان IT امریکایی و اروپایی انجام داده است، 78 درصد از پاسخ دهندگان بهبود کیفیت را یکی از خواسته های اصلی گروه های بیزینسی اعلام کرده اند.

با DevOps نیازی به قربانی کردن کیفیت برای رسیدن به سرعت بیشتر نیست. برای افزایش سرعت می توانید ارائه نرم افزار را به واحدهای کوچکتری تقسیم کنید، به طوریکه در واقع تعدادی micro service با وابستگی حداقلی یا بدون هیچ وابستگی ارائه خواهید کرد. unitهای کوچکتر یعنی تحویل سریع تر به همراه کیفیت بالاتر و ریسک کمتر.

بعلاوه DevOps از طریق ایجاد فرهنگی برتر و ابزارهایی برای پشتیبانی از آن، کیفیت را وارد تمامی مراحل زنجیره ارائه نرم افزار می کند.
از نظر فرهنگی، DevOps بر مسئولیت های مشترک، انتظار کیفیت از توسعه دهندگان، تست کنندگان، اعضای تیم امنیت و عملیات و همه افراد بین آن ها تاکید دارد. از نظر تکنیکی، DevOps مستلزم حداکثر میزان ممکن اتوماسیون برای سرعت بخشیدن به فرایندها و کاهش خطاهای انسانی است. و استفاده از یک رویکرد Shift-left در تست، امنیت و مانیتورینگ به بهبود کیفیت کمک می کند.

shift left testing رویکردی در تست نرم افزار یا سیستم است که بر انجام تست در مراحل اولیه چرخه حیات تاکید دارد (moved left on project timeline). این نیمه اول قاعده کلی تست نرم افزار است: “تست زودتر و پر تکرار” (Test Early and Often)

کیفیت چیزی نیست که قابل حدس زدن باشد. بلکه باید آن را توسط معیارهای خاص تعریف و بر این اساس بر آن نظارت کرد.

productivity iconچرا اندازه گیری و ارزیابی بهره وری مهم است؟

همه ی هدف و تمرکز DevOps این است که به سازمان های فناوری اطلاعات کمک کند تا ارزش بیشتری برای بیزینس ایجاد کند. اما در صورتیکه تلاش های شما بخوبی با بیزینس هماهنگ نشده باشد، هر چقدر هم سریع بتوانید نرم افزارهایی با کیفیت عرضه کنید، این امر (ایجاد ارزش برای بیزینس) میسر نمی شود.

در صورتیکه DevOps درست اعمال شود، سازمان ها شاهد افزایش سرعت و کیفیت بدون افزایش هزینه ها خواهند بود. در حقیقت با کوتاه کردن چرخه ها، شما شاهد افزایش ارزش های کسب و کاری خواهید بود. ارزیابی و نظارت بر معیارهای بهره وری، یک چرخه‌ی بازخورد (feedback loop) برای بخش IT ایجاد می کند. بدین ترتیب تمرکز خود را بر ایجاد ویژگی هایی که مورد استفاده کاربران است می گذارید و در نتیجه اتلاف منابع کمتر صورت می گیرد و و ارزش بیزینسی افزایش می یابد.

security iconچرا اندازه گیری و ارزیابی امنیت مهم است؟

سرعت اهمیت زیادی در DevOps دارد اما در دنیای امروزی، اهمیت امنیت هم به همین اندازه زیاد است. تیم ها باید اطمینان داشته باشند که حین عملیات، باعث آسیب پذیر شدن سیستم نمی شوند.

افزودن ویژگی های جدیدی که باعث ایجاد آسیب پذیری های جدیدی در سیستم شود یا آسیب پذیری ها و نقاط نفوذ قبلی را مشخص کند، مطمئنا باعث نارضایتی مشتریان خواهد شد. بعلاوه ایجاد آسیب پذیری در سیستم باعث می شود که تیم ها مجبور شوند بیشتر وقتشان را صرف اصلاح این آسیب پذیری ها و نقاط ضعف کنند.

امنیت هم مثل کیفیت به رویکردهای تست  shift-left نیاز دارد که با استفاده از این رویکرد مشخص کردن زود هنگام آسیب پذیری ها با هزینه های کمتر (هم از نظر زمانی هم از نظر هزینه های مالی) قابل انجام است. وقتی که تست shift-left را انجام دهید، تست امنیت در ابتدای چرخه توسعه انجام می شود. ارزیابی زود هنگام آسیب پذیری های امنیتی این اطمینان را ایجاد می کند که تولیدات قبل از این که به مرحله بعدی خط انتشار وارد شوند، پایدار و باثبات می شوند.

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

در مطلب بعد یازده شاخص کلیدی عملکرد DevOps را معرفی و بررسی خواهیم کرد.

برگرفته از “Hewlett Packard Enterprise, “Measuring DevOps success
سایر منابع :

1Source: Forrester Consulting, “Application Delivery Speed Drives Success: How Mastering DevOps Enables Speed With Quality and Low Cost”
23Source: Gartner, “Survey Analysis: DevOps Adoption Survey Results,” September 2015

Share Button

استراتژی پیشرفته استقرار نرم افزار | Advanced Software Deployment Strategy

Software Deployment Strategy Adv.

در این مطلب قصد دارم به استراتژی های پیشرفته ی استقرار نرم افزار که در Continuous Deployment و DevOps کاربرد فراوانی دارند، بپردازم. در پست قبلی به تعریف استراتژی و استراتژی استقرار نرم افزار پرداختیم، همچنین دو تا از استراتژی های پایه استقرار نرم افزار (Recreate Deployment و Rolling Deployment) را معرفی و بررسی کردیم.

Blue-Green Deployment Strategy

Blue-Green Deployment یکی دیگر از استراتژی های استقرار است که به طور خلاصه شامل نگه داشتن همزمان دو نسخه از سرویس در محیط عملیاتی می شود که ریسک انتشار را به شدت کم می کند. نسخه قبلی (Blue) و نسخه ای که جدیدا منتشر شده و در دسترس قرار گرفته (Green). این روش معمولا از یک load balancer برای هدایت ترافیک به نسخه ی green می شود. اگر Monitoring یک رخداد (Incident) را شناسایی کرد، ترافیک به طور اتوماتیک به نسخه ی قبلی یعنی blue هدایت خواهد شد.

هدف Blue-Green Deployment ، حذف DownTime و کاهش ریسک های ناشی از Deployment وامکان Rollback بسیار سریع است.

روش انجام Blue-Green Deployment: در این روش علاوه بر محیط عملیاتی (سبز)، یک محیط کاملا مشابه اما جداگانه وجود دارد(آبی). نسخه ی قدیم اپلیکیشن در محیط سبز نصب شده و 100% از ترافیک عملیاتی به این محیط هدایت می شود. نسخه ی جدید اپلیکیشن روی محیط آبی نصب، راه اندازی و تست می شود، سپس در یک لحظه 100% از ترافیک عملیاتی به محیط آبی هدایت می شود. در این روش در هر زمان تنها یکی از نسخه ها عملیاتی است و نسخه ی دیگر غیر فعال است.

امکان Rollback در این روش بسیار سریع خواهد بود. همچنین قبل از عملیاتی شدن نسخه ی جدید برای کاربران، این فرصت ایجاد می شود تا از عملکرد صحیح اپلیکیشن و استقرار آن مطمئن شویم. بدین ترتیب ریسک حاصل از دیپلویمنت و نسخه ی جدید به شدت کم خواهد شد.

مثال: شکل زیر نشان دهنده ی این استراتژی به صورت کلی است.
مرحله اول: 100% ترافیک عملیاتی به محیط آبی که نسخه ی قدیمی در آن نصب شده هدایت می شود و نسخه ی جدید در محیط آبی نصب و راه اندازی می شود.Blue Green Deployment Strategy 01
مرحله دوم: بعد از راه اندازی کامل نسخه ی جدید در محیط آبی، 100% ترافیک عملیاتی به محیط آبی هدایت می شود.Blue Green Deployment Strategy 02


استراتژی قناری | Canary Deployment Strategy

انتخاب این نام از داستان “قناری در معدن زغال سنگ” گرفته شده است. در گذشته معدنچیان با خود یک قناری در قفس به معدن می بردند، در چنین شرایطی اگر میزان گازهای سمی (متان یا مونو اکسید کربن) در معدن به حدی برسد که برای انسان خطر جدی ایجاد کند، قناری جان خود را از دست می داد و بدین ترتیب معدن چیان از وجود گازهای سمی باخبر می شدند.

روش انجام Canary Deployment: در استراتژی استقرار به روش قناری، نسخه ی جدید اپلیکیشن روی تعداد کمی از نودهای عملیاتی منتشر می شود و درصد کمی از ترافیک عملیاتی به نسخه ی جدید هدایت می شود. در این روش دو نسخه قدیم و جدید به طور همزمان عملیاتی هستند. نسخه ی جدید، نقش یک قناری را بازی می کند تا بدون اینکه ریسکی متوجه اکثریت کاربران شود، متوجه شویم که وضعیت در عملیات چطور خواهد بود (از نظر integration با سایر اپلیکیشن ها، CPU، Mamory، disk Usage و …). در صورت رضایت بخش بودن می توان سایر نود ها را هم به روزرسانی کرد، در غیر اینصورت می توان تصمیم به fail کردن استقرار یا Rollback گرفت.

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

canary-deployment-strategy

 


Dark Launch Strategy

Dark launching فرایندی است که در آن Featureهای جدید نرم افزار به نحوی تدریجی یا مخفیانه ریلیز می شود و در یک زمان مشخص، یا برای گروه های کاربری مشخصی، فعال و قابل استفاده می شود. با این روش می توان بازخورد بخشی از کاربران را دریافت کرد و در محیط عملیاتی بدون اینکه اکثر کاربران تحت تاثیر قرار گیرند، Performance Test انجام داد. با این روش دیگر نیازی نیست که انتشار Feature های تکمیل شده به دلیل یک یا چند Feature تکمیل نشده به تعویق بیافتد و می توان کدهای تکمیل نشده را (با در نظر گرفتن ملاحظاتی) بدون تاثیر در عملکرد کلی اپلیکیشن منتشر کرد.

روش انجام Dark Launch Strategy: این کار با به کارگیری یک تکنیک در توسعه نرم افزار به نام Feature Flag یا Feature Toggle انجام می شود. در این تکنیک، پیکربندی هایی برای هر Feature یا مجموعه ای از آن ها افزوده می شود، همچنین تکه کدهایی در ابتدای هر ویژگی استفاده می شود که با توجه به پیکربندی، آن ویژگی را در زمان خاصی، یا برای گروهی از کاربران فعال می کند.

Google، Facebook، و بسیاری از غول های فناوری اطلاعات برای ریلیز تدریجی و تست ویژگی های جدید توسط گروه کوچکی از کاربرانشان، از Dark Launching استفاده می کنند. بدین ترتیب قبل از ریلیز عمومی، این فرصت را پیدا می کنند تا میزان علاقه ی کاربران را شناسایی کنند و همچنین تاثیر تغییرات جدید را روی کارایی کل سیستم اندازه گیری کنند. ابزاری که Facebook برای این کار استفاده می کند، “Gatekeeper” نام دارد.


A/B Deployment Strategy

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

یک مثال پیچیده تر شامل یک proxy یا load-balancer تخصصی که ترافیک را بر اساس کاربران یا اپلیکیشن ها بین شاخه های A و B تقسیم می کند. تمامی تستر ها به شاخه B هدایت می شوند و سایر کاربران به شاخه A.

A/B Deployment می تواند به عنوان A/B Testing در نظر گرفته شود، اگر چه یک استقرار A/B نشان دهنده چندین نسخه از کد و پیکربندی است، در صورتی که A/B Testing اعلب از یک کد با چک های خاص برنامه تشکیل شده است.

چه موقع از A/B Deployment استفاده کنیم ؟

  • زمانی که لازم می خواهیم چند نسخه از اپلیکیشن و کانفیگ را به طور همزمان تست کنیم اما اولویت بندی مشخصی برای نسخه ها نداریم.
  • زمانی که می خواهیم اپلیکیشن را با کانفیگ های مختلف برای مناطق مختلف اجرا کنیم.


Share Button

استراتژی استقرار نرم افزار | Software Deployment Strategy

Software Deployment Strategy

در این مطلب به ابتدا به تعریف استراتژی (Strategy)، استقرار نرم افزار (Software Deployment) اشاره شده و در ادامه دو تا از استراتژی های پایه استقرار نرم افزار معرفی و بررسی شده است.

در این صفحه به مطالب زیر می پردازیم :

 

در مطلب بعدی موارد زیر معرفی و بررسی خواهند شد

  • استراتژی های پیشرفته استقرار نرم افزار
    • Canary Deployment Strategy
    • Blue-Green Deployment Strategy
    • Dark Launch Strategy
    • A/B Deployment Strategy

استراتژی چیست ؟ | What is Strategy ?

تعاریف مختلفی از استراتژی وجود دارد اما به نظرم سه تعریف زیر در کنار هم دید خوبی از مفهوم استراتژی به ما می دهد.

  1. استراتژی یعنی یک برنامه کلان برای رسیدن به یک یا چند هدف در شرایط غیر قطعی (ویکی پدیا)
  2. استراتژی داشتن یعنی اینکه وقتی مجموعه ی تصمیم هایمان دیده می شود، بتوان الگوی خاصی را در آن ها مشاهده کرد. (هنری مینتزبرگ)
  3. استراتژی یعنی کاری که دیگران انجام می دهند را با منابع کمتر (کاراتر) انجام دهیم و کارهایی انجام دهیم که هیچ کس غیر از ما انجام نمی دهد. (مایکل پورتر)

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

دیپلویمنت چیست ؟ | What is Deployment ?

دیپلویمنت یعنی گسترش دادن، استفاده، یا سازماندهی برای رسیدن آگاهانه به یک هدف. (Merrian Webster – Definition of Deploy)

استقرار نرم افزار چیست ؟ | What is Software Deployment ?

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

(در ادامه ی این متن، از واژه ی “استقرار” به جای “Software Deployment” یا “استقرار نرم افزار” استفاده شده است.)

استراتژی استقرار نرم افزار چیست ؟ | What is Software Deployment Strategy ؟

Software Deployment Strategy یا استراتژی استقرار نرم افزار، یک استراتژی در جهت گسترش، استفاده، و یا سازماندهی، برای استقرار به صورت آگاهانه است. به عبارت ساده تر فرایندی است که نحوه ی استقرار و پیکربندی اپلیکیشن و سرورها را مشخص می کند. هر اپلیکیشن یا سرور برای استقرار، نیازمندی ها و ملاحظات متفاوتی دارد که برای انجام آن باید از یک استراتژی مناسب استفاده کرد. از جمله این نیازمندی ها می توان به دسترس پذیری اپلیکیشن، مدت زمان استقرار و بسیاری موارد دیگر اشاره کرد.

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

اهداف استراتژی های استقرار نرم افزار کدامند ؟

از جمله اهدافی که استراتژی های استقرار به دنبال دستیابی به آن ها هستند، می توان به این موارد اشاره کرد:

  1. به حداقل رساندن DownTime یا به صفر رساندن آن
  2. کاهش ریسک ناشی از استقرار
  3. کاهش ریسک عملیاتی کردن نسخه ی جدید
  4. شناسایی سریع مشکلات نسخه ی جدید بعد از عملیاتی شدن
  5. سرعت بخشیدن به امکان Rollback به نسخه ی قبلی

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

استفاده از روش های استقرار قدیمی و غیر اتوماتیک در نگهداری سرور ها و استفاده از آن ها برای مدت زمان طولانی (چندین ماه یا چند سال) باعث مشکلات زیادی می شود. حتی اگر شما تمامی patch ها و update ها را به درستی روی سرور و اپلیکیشن نصب کرده باشید، بعد از مدتی با یک سرور حساس و شکننده با پیکربندی منحصر به فرد مواجه خواهید شد که نمی توانید آن را تعویض کنید یا سروری مشابه آن ایجاد کنید. (به چنین سروهایی در اصطلاح “Snowflake Servers” می گویند). دلایل مختلفی وجود دارد که نیاز می شود یک سرور جدید راه اندازی کنید، از جمله تغییر دیتاسنتر، اضافه کردن سرورهای fail-over، اضافه کردن سرور برای مقیاس پذیری بیشتر، مشکلات امنیتی و … که در چنین شرایطی امکان آن وجود نخواهد داشت یا با ریسک بسیار بالا و صرف زمان زیادی همراه خواهد بود.

رانش پیکربندی چیست ؟ | What is Configuratoin Drift ؟

از اصطلاح Configuration Drift یا “رانش پیکربندی” مواقعی استفاده می شود که تغییرات پیکربندی به صورت موردی، با توجه کم و بدون مستند سازی روی سرورها اعمال می شود عملا سرور را به یک سرور منحصر به فرد تبدیل می کند که محدودیت ها و مشکلاتی را به همراه خود دارد.

برخی از این مشکلات که در بالا اشاره شد، با به کار گیری ابزارهای مدیریت پیکربندی نظیر Chef و Puppet و Ansible برطرف می شوند. اگر پیکربندی ها با استفاده از این ابزارها انجام شود، از پدیده ی Configuration Drift جلوگیری می شود. اما نکته ی مهم این است که در این روش تنها پیکربندی هایی که صراحتا از طریق ابزار اعمال شده انجام خواهد شد و اگر مواردی خارج از آن به محیط یا سرور اعمال شود، ابزار مطلع نمی شود.

Immutable Server چیست ؟

استراتژی ای وجود دارد که در آن به صورت دوره ای سرورها را حذف مب کنند و یک سرور جدید به جای آن ایجاد می کنند و با استفاده از ابزارهایی که در بالا معرفی شد، به صورت اتوماتیک، پیکربندی می کنند. این کار باعث جلوگیری از Configuration Drift می شود. با این روش، با هر تغییر در پیکربندی، بلافاصله قادر به راه اندازی یک سرور جدید خواهیم بود. این استراتژی با نام Immutable Server شناخته می شود از رانش پیکربندی و Snowflake Server ها جلوگیری می کند. از این استراتژی می توان در کنار  Recreate Deployment Strategy که در ادامه توضیح خواهم داد استفاده کرد.

انواع استراتژی استقرار نرم افزار | Deployment Strategies

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

Recreate Strategy | Recreate Deployment

استراتژی Recreate Deployment یکی از استراتژی های پایه استقرار نرم افزار می باشد. روش انجام این استراتژی دقیقا شبیه به زمانی است که یک اپلیکیشن برای اولین بار نصب و راه اندازی می شود. همه چیز مرحله به مرحله و از ابتدا باید انجام شود. همچنین نیازی نیست که کدهای جدید و قدیم در کنار هم کار کنند.

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

چه موقع از Recreate Deployment استفاده کنیم ؟

  • زمانی که قبل از راه اندازی نسخه ی جدید، نیاز است یک مهاجرت ( Migration ) در سطح دیتا یا سرور انجام شود
  • زمانی که نیازی نیست تا نسخه های جدید و قدیم اپلیکیشن به طور همزمان با هم کار کنند
  • زمانی که از یک RWO volume ای استفاده می کنید که قابلیت به اشتراک گذاری بین چند نسخه را ندارد [openshift.org]

مثال: در شکل زیر مراحل انجام این روش برای محیطی با سه نود نمایش داده شده است.

مرحله اول: قبل از شروع کار، ترافیک به سرور که نسخه ی قدیمی اپلیکیشن را دارد، هدایت می شود.

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

مرحله سوم: همه ی نودها به روزرسانی شده اند و به مدار باز میگردند.

 

Recreate Deployment Strategy

 


Rolling Strategy | Rolling Deployment

Rolling Deployment یکی دیگر از استراتژی های پایه استقرار نرم افزار است و هدف آن به حداقل رساندن یا حذف DownTime و کم کردن ریسک های وابسته به استقرار می باشد. Rolling Deployment برای محیط هایی عملیاتی که نیاز است به روزرسانی در آن ها بدون DownTime انجام شود، مناسب است. این استراتژی معمولا در محیط هایی با تعداد نود(سرور)های زیاد به کار گرفته می شود و برخلاف برخی دیگر از استراتژی ها نیاز به منابع اضافه ندارد و با استفاده از سرورها و منابع جاری قابل اجرا است.

روش انجام Rolling Deployment : در این روش یکی از (یک گروه از) نودها از دسترس خارج شده و نسخه ی جدید اپلیکیشن با نسخه ی قبلی جایگزین می شود، سپس ترافیک عملیات به آن هدایت می شود و نوبت به نود بعدی می رسد. این کار تا به روزرسانی همه ی نود ها ادامه می یابد.

مثال: در شکل زیر مراحل انجام این استراتژی برای محیطی با سه نود (سرور) نشان داده شده است. این مثال یک محیطی با عملیاتی است که ترافیک ورودی توسط یک Router یا Load-Balancer به سرورهای مشابه هدایت می شوند.

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

rolling deployment strategy 0

مرحله اول: یکی از نود ها از مدار خارج می شود و از آن پس ترافیک عملیاتی به سمت آن هدایت نمی شود. در همین حین نودی که از مدار خارج شده، به روزرسانی می شود.
rolling deployment strategy 1

مرحله دوم: نودی که به روزرسانی شده به مدار باز میگردد و نود دیگری از مدار خارج و به روزرسانی می شود.
rolling deployment strategy 2

مرحله سوم: مرحله دوم برای تمامی نودهای باقیمانده (در اینجا یک نود) تکرار می شود.

rolling deployment strategy 3

مرحله چهارم: در این مرحله تمامی نودها به مدار بازگشته و ترافیک به آن ها هدایت می شود.

rolling deployment strategy 4

چه موقع از Rolling Deployment استفاده کنیم ؟

  • زمانی که میخواهیم در حین استقرار یا به روزرسانی اپلیکیشن، DownTime نداشته باشیم
  • زمانی که اپلیکیشن می تواند به طور همزمان با نسخه ی جدید و قدیم کار کند

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


جمع بندی

در این مطلب راجع به مفهوم استراتژی و استراتژی های استقرار نرم افزار صحبت کردیم، در ادامه به برخی از اهداف و چالش ها در این زمینه اشاره کردیم و دو تا از استراتژی های پایه استقرار نرم افزار به نام های Recreate و Rolling را با ذکر مثال شرح دادیم. همچنین مواقعی که می توان از این استراتژی ها استفاده کرد را شمردیم.

امیدوارم این مطب مورد استفاده شما دوستان واقع شده باشه. در مطلب بعدی که سعی میکنم کمتر از یک هفته دیگه منتشر کنم، استراتژی های پیشرفته ی استقرار نرم افزار که در Continuous Deployment و DevOps کاربرد دارند را بررسی خواهم کرد.

Share Button
Show Buttons
Hide Buttons