بایگانی‌ها استقرار نرم افزار - سلام دواپس

اکتبر 23, 2018جولای 24, 2020

تاریخچه و داستان دوآپس | DevOps Story and History

چه مشکلی باعث شد رویکرد جدیدی به نام دوآپس(DevOps) مطرح شود؟

سال 2007 میلادی آقای پاتریک دبوآ (Patrick Debois) درگیر پروژه ی جایی دیتاسنتر دولت بلژیک شد و با یک چالش مواجه شد: سیستم ادمین ها و توسعه دهندگان در تعامل با هم به مشکلاتی برمیخوردند که تاثیر منفی در روند اجرای کار داشت.

آگوست 2008 در کنفرانس سالانه چابک که در تورنتو کانادا برگزار شد(Agile 2008 Conference)، آقای اندرو شفر (Andrew Shafer) پیشنهاد نشستی با عنوان زیرساخت چابک (Agile Infrastructure) را می دهد که تقریبا با استفبال هیچکسی مواجه نمی شود به جز یک نفر و آن یک نفر کسی نبود به جز Patrick Debois ! به دلیل استقبال کمی که صورت گرفت، Andrew از برگزاری اون نشست صرف نظر میکنه. بعد از آن Patrick به دنبال Andrew در یک گفتگوی سرپایی راجع به این موضوع صحبت می کنند و گروه Agile System Administration را در google group ایجاد می کنند.

ژون 2009 در کنفرانس O’Reilly Velocity 2009، آقایان John Allspaw و Paul Hammond سخنرانی معروفی تحت عنوان “10 استقرار در روز: نتیجه همکاری توسعه و عملیات در فلیکر” داشتند. پاتریک که از راه دور این کنفرانس را تماشای می کرد، در توییتر ابراز تاسف کرد که نتوانسته به صورت حضوری شرکت کند. Paul Nasrat در پاسخ به این توییت پیشنهاد برگزاری کنفرانس در بلژیک را به Patrick Debois می دهد.

10 Deploys Per Day: Dev and Ops Cooperation at Flickr from John Allspaw

کلمه DevOps برای اولین بار در کجا و توسط چه کسی مطرح شد؟

اکتبر 2009 Patrik به توصیه John عمل کرد و به فکر برگزاری یک کنفرانس در بلژیک افتاد. اول از همه باید یک اسم مناسب برای این کنفرانس انتخال می کرد. سه حرف Development و سه حرف از Operations به اضافه کلمه days چیزی بود که نام این کنفرانس را تشکیل داد “DevOpsDays”. این کنفرانس در 30 اکتبر با مجموعه قابل توجهی از توسعه دهندگان، sys admin ها، متخصصان ابزار و سایر افراد تشکیل شد. بعد از پایان کنفرانس مباحث در توییتر ادامه پیدا کرد. Patrik به هشتگ #DevOps را برای ادامه بحث انتخاب کرد تا خلاصه تر و راحت تر باشد. از آن زمان تا به حال، این جنبش را به نام DevOps (دوآپس) می شناسیم. (در نحوه نوشتن کلمه دوآپس توافق جامعی وجود ندارد و هر سه حالت DevOps و Devops و devops استفاده می شود)

آوریل 2012 Patrik Debois در یک مصاحبه ویدیویی در سال 2012 اذغان کرد که نامگذاری این جنبش به اندازه ای که به نظر می رسد خیلی عمدی نبوده. (به نظر میرسه منظور اینه که خیلی دقیق و فکر شده نیست). در ادامه Patrik میگوید: “من به این دلیل اسم DevOpsDays را در راستای همکاری تیم های توسعه و عملیات انتخاب کردم که اسم “Agile System Administration” طولانی بود و هیچ وقت برنامه ی بزرگی برای دنیایی به نام DevOps وجود نداشته.

سال 2013 موسسه Puppet Labs اولین نظرسنجی وضعیت دوآپس (State of DevOps) را برگزار کرد تا یک ارزیابی ای از روند رشد و عملکرد این حوزه به دست بیاید.

تاریخچه دوآپس به روایت تصویر

رشد دوآپس در سال های اخیر به روایت تصویر

ممنون که ما را دنبال می کنید.

ژانویه 27, 2018مارس 31, 2020

یازده شاخص کلیدی عملکرد دواپس | 11 DevOps KPI

شاخص های کلیدی عملکردی دواپس یا DevOps KPI که قبلا به چهار دسته سرعت، کیفیت، بهره وری و امنیت تقسیم کردیم را چطور ارزیابی می‌کنید؟ در این مطلب یازده شاخص کلیدی عملکرد، اصول و پایه های لازم برای ارزیابی موفقیت DevOps را معرفی و بررسی کرده ایم.

شاخص های سرعت دواپس | DevOps Velocity KPI

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

1. فرکانس استقرار | Frequency of deployment

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

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

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

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

قبلا دو مطلب در رابطه با استقرار نرم افزار منتشر کردیم که خواندن آن خالی از لطف نیست :

2. سرعت استقرار | Speed of deployment

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

دلیل اهمیت: در روش های سنتی، سیستم های شرکتی اتصال تنگاتنگی دارند(tightly coupled هستند)؛ هر زمان چیزی مستقر می شود، ممکن است در نهایت نیاز به استقرار مجدد کل اپلیکیشن باشد. یک دهه پیش، این امر قابل قبول بود – می توانستید از کار افتادگی پنج ساعته‌ی ویندوز را برای نیمه شب زمانبندی کنید، بدون این که این از کار افتادگی تاثیر منفی برای بیزینس داشته باشد. اما مشاغل امروزه جهانی هستند – مثلاً وقتی در امریکا نیمه شب است، در آسیا روز است – و اکثر شرکت ها در همه اوقات مشتریانی دارند که بیدار هستند. بنابراین سریع بودن استقرار امری حیاتی است.

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

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

3. سرعت تایید بیلد ها | Speed of build verification (QA)

مفهوم: کل زمان حرکت یک محصول در چرخه QA

دلیل اهمیت: اکثر اوقات QA تبدیل به یک تنگنا می شود. ارزیابی زمان سپری شده برای یک محصول تولیدی در QA اطلاعات کلیدی درباره اینکه با چه سرعت و فرکانسی می توانید یک محصول یا سرویس ارائه دهید، در اختیارتان قرار می دهد. وقتی مقدار این سنجه بالا باشد، متوجه می شوید که می توانید فرکانس را بدون اینکه QA تبدیل به تنگنا شود، افزایش دهید. اگر این مقدار پایین باشد، نشان می دهد که نیاز به پیاده سازی تکنیک هایی مثل اتوماسیون تست در خط لوله‌ی انتشار محصول دارید (release pipeline).

4. فرکانس تایید بیلد ها | Frequency of build verification (QA)

مفهوم: تعداد تولیداتی که یک تیم QA می تواند در یک دوره خاص به مصرف برساند.

دلیل اهمیت: افزایش تعداد تولیداتی که QA می تواند به صورت مثبت مورد مصرف قرار دهد تاثیر مثبتی بر زمانبندی انتشار دارد. ممکن است سرعت استقرار بالا باشد، اما بدون ادغام مستمر (Continuous Integration) باید تولیدات را به صورت دستی مدیریت کنید که این کار باعث کند شدن خط لوله انتشار (DevOps Pipeline) می شود. به طور مشابه، بدون Continuous Testing، حین فرایند تست زمان هدر می رود. نتیجه این است که تیم QA نمی تواند حداکثر تعداد تولیدات را در هر چرخه به مصرف برساند و پوشش تست – همچنین اطمینان از حرکت به مرحله بعد – دچار مشکل است.

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

شاخص های کیفیت دواپس | DevOps Quality KPI

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

5. نرخ موفقیت استقرار | Deployment success rate

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

دلیل اهمیت: نرخ موفقیت بالا هنگام استقرار در سرورهای غیرتولیدی، دلالت بر کیفیت بالا در مراحل قبلی دارد. نرخ موفقیت پایین حاکی از ضعف کیفی کدنویسی است. در خیلی از شرکت ها، ممکن است System Integration Test و QA نرخ موفقیت بالایی داشته باشند ولی در عین حال در محیط پیش عملیات (Staging) موفق نباشند. این معیار می تواند به شما کمک کند تا مشکلات موجود در مرحله استقرار را هدف گرفته و از بین ببرید. نرخ موفقیت باید به مرور زمان افزایش پیدا کند.

در سازمان هایی که عملکرد خیلی خوبی دارند، مقدار این معیار باید به دلیل حذف مشکلات در پیش عملیات (Staging) – یا بهتر از آن، پیشگیری از این مشکلات – بالا باشد. اما خیلی از سازمان ها در این حوزه دچار چالش هستند و باید انتشارها (یا نسخه ها) را به عقب برگردانند. پایین بودن نرخ موفقیت بعد از یک فاز پیمایش موفق می تواند نشان دهنده چندین مشکل باشد:

فقدان سازگاری بین محیط های مختلف | Lack of consistency across environments
فقدان مدیریت مناسب داده های تست | Lack of good test data management
پوشش و کیفیت پایین تست | Low testing quality and coverage

6. میزان حوادث/نقایص | Incident/defect volumes

مفهوم: تعداد حوادث و نقایص گزارش شده در یک نسخه خاص از یک محصول یا سرویس در محیط عملیاتی

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

کیفیت نیازمندی ها | Quality of the requirements
کیفیت توسعه | Quality of development
کیفیت تست از جمله قابلیت مدیریت داده های تست | Quality of testing, including test data management capability
سطح همکاری بین استقرار، QA و عملیات (مثلاً اشتباه در درک نیازمندی ها) | Level of collaboration between development, QA, and operations

7. نرخ پوشش نیازمندی ها | Requirements coverage ratio

مفهوم: درصد قابلیت ردیابی (traceability) بین نیازمندی ها و تست ها (منظور امکان ارتباط دادن این دو به هم است).

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

وقتی که نیازمندی ها و test case ها با هم هماهنگی داشته باشند، تغییر در نیازمندی ها منجر به قابلیت مشاهده موارد متناظر در پوشش test case می شود. بروز رسانی هر یک از test case به نیازمندی ربط پیدا می کند. وجود ارتباط، تاثیر مثبت و مستقیمی بر کیفیت نرم افزار دارد. بالا بودن میزان این ارتباط نشان دهنده افزایش کیفیت نرم افزار؛ تناقض و ناسازگاری کمتر بین تحلیل گران، توسعه دهندگان و تیم QA؛ و بهره وری بالاتر است.

شاخص های بهره وری دواپس | DevOps Productivity KPI

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

8. میزان استفاده از ویژگی‌ها | Feature usage

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

دلیل اهمیت: DevOps یک چرخه بازخوردی است (feedback loop) که شامل بیزنس، توسعه، تست، عملیات و کاربران می شود. پایین بودن میزان استفاده از ویژگی‌ها به این معناست که بخش فناوری اطلاعات (IT) مشغول توسعه ویژگی ها و امکاناتی است که یا مورد تقاضا نیستند (بازخورد ضعیف از سوی بیزنس به بخش توسعه)، یا مورد نیاز نیستند (بازخورد ضعیف از طرف کاربران به بیزنس) یا به صورت ضعیف ساخته شده اند (مشکل در بازخورد از سوی بخش IT). هزینه ویژگی ها و امکاناتی که مورد استفاده قرار نمی گیرند، می تواند بسیار زیاد باشد، بنابراین مهم است که علت این امر شناسایی شود. بالا بودن تعداد ویژگی هایی که در یک محصول خاص استفاده نشده اند نشان دهنده منفی بودن میزان اثربخشی مدیریت و توسعه نیازمندی ها است.

9. میانگین زمان لازم برای بازیابی سرویس | Mean time to restore service (MTTRS)

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

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

بعلاوه، MTTRS می تواند مشخص کننده مشکلاتی در سازمان باشد از جمله:

وضعیت سلامت چرخه بازخورد بین بیزنس، بخش های توسعه، QA، عملیات و کاربران نهایی.
سطح چابکی شرکت و این که شرکت با چه سرعتی می تواند به تغییرات ایجاد شده توسط یک فرد، فرایند و تکنولوژی‌های آینده واکنش نشان دهد.
بهره وری و اثربخشی کلی

The health of the feedback loop between the business, development, QA, operations, and end users
The level of enterprise agility and how quickly the enterprise can react to changes from a people, process, and technology perspective
Overall productivity and effectiveness

شاخص های امنیت دواپس | DevOps Security KPI

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

10. میزان قبول شدن تست امنیت | Security test pass rate

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

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

11. نرخ تشخیص اسکن کدها | Code scanning detection rate

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

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

تحلیل مناسب اعداد و ارقام

DevOps این قابلیت را دارد که زنجیره ارائه نرم افزار را به ماشینی با تفکر ناب، سریع و به شدت موثر تبدیل کند تا آنچه کاربران تقاضا دارند را عرضه کند. این تبدیل اهمیت بسیار زیادی دارد. طبق یکی از نظر سنجی های شرکت Forrester Consulting که در سال 2015 انجام شده، 64 درصد از پاسخ دهندگان بر این باورند که نرم افزار یکی از عوامل کلیدی توانمندساز مشاغل است و موفقیت مشاغل بستگی به اپلیکیشن هایی با کیفیت بالا دارد که مناسب با مدل های بیزنسی مدرن باشد.

DevOps has the potential to transform the software delivery chain into a lean, fast, highly effective machine that delivers what users want.

شرکت نرم افزاری HPE با کمک داده های حجیم معیارهایی را از منابع مختلف در سیستم های IT مختلف جمع آوری کرده است تا این 11 شاخص کلیدی عملکرد و موارد دیگر را تولید کند. ابتکار شرکت نرم افزاری HPE دیدگاهی واحد از معیارهای DevOps فراهم می کند که به شما برای بدست آوردن اطلاعات و بینش هایی درباره مسیر حرکت DevOps کمک می کند؛ به طوری که می توانید به شیوه ای موثر و کارآمد تبدیل و تحول DevOps را مدیریت کنید.

مسیرهای آتی برای شاخص های کلیدی عملکرد DevOps

وقتی که شروع به استفاده از شاخص های کلیدی عملکرد برای ارزیابی موفقیت DevOps کردید، راه های زیادی برای گسترش داشبورد معیارهای دواپس و متناسب کردن آن با سایر سطوح سازمان خواهید داشت. برای گسترش معیارهای DevOps به سمت بالا و حوزه بیزنس، داشبورد KPIی DevOps را می توان به صورت یک داشبورد مخصوص مدیر ارشد فناوری اطلاعات درآورد که دیدگاهی سطح بالا از تشکیلات IT و همچنین میزان پیشرفت در فعالیت های عمده فراهم کند. (DevOps Dashboard)

یکی از شاخص های کلیدی عملکرد که در حال حاضر مشاغل علاقه زیادی به آن دارند، میزان استفاده از ویژگی ها است اما می توانید در کنار آن، زمان چرخه را هم نظارت کنید که نشان می دهد تولید یک ویژگی خواسته شده و استقرار آن در یک محصول چقدر زمان می برد. البته شاخص های کلیدی عملکرد از نوعِ اقتصادی نیز همیشه برای مشاغل متناسب و مهم هستند – که یکی دیگر از راه های گسترش داشبورد را تشکیل می دهند.

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

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

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

“تشکیلات IT باید این امر را به رسمیت بشناسند که DevOps قابلیت تحول و تغییر را دارد و بر این اساس باید در جنبه های فردی و فرایندی تلاش هایشان سرمایه گذاری زمانی و پولی کنند. مدیران IT نباید بیش از حد بر فناوری تاکید کنند و در نتیجه حوزه های دیگر را تحت تاثیرات منفی قرار دهند.”

منبع : “Hewlett Packard Enterprise, “Measuring DevOps success

جولای 23, 2017مارس 31, 2020

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

در این مطلب قصد دارم به استراتژی های پیشرفته ی استقرار نرم افزار که در 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% ترافیک عملیاتی به محیط آبی که نسخه ی قدیمی در آن نصب شده هدایت می شود و نسخه ی جدید در محیط آبی نصب و راه اندازی می شود.
مرحله دوم: بعد از راه اندازی کامل نسخه ی جدید در محیط آبی، 100% ترافیک عملیاتی به محیط آبی هدایت می شود.

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

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

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

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

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 استفاده کنیم ؟

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

جولای 10, 2017مارس 31, 2020

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

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

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

استراتژی چیست ؟ | What is Strategy ?
دیپلویمنت چیست ؟ | What is Deployment ?
استقرار نرم افزار | Software Deployment
استراتژی استقرار نرم افزار چیست ؟ | What is Software Deployment Strategy ?
اهداف استراتژی های استقرار نرم افزار کدامند ؟
معایب استقرار به روش های قدیمی چیست ؟
رانش پیکربندی چیست ؟ | What is Configuratoin Drift ؟
Immutable Server چیست ؟
استراتژی های پایه استقرار نرم افزار
- Recreate Deployment Strategy
  - چه موقع از Recreate Deployment استفاده کنیم ؟
- Rolling Deployment Strategy
  - چه موقع از Rolling Deployment استفاده کنیم ؟

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

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

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

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

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

همانطور که از تعاریف مشخص است، استراتژی برنامه ای با جزئیات دقیق و کاملا قابل پیش بینی نیست. تاکید یک استراتژی خوب بر آن است که در برخی از توانایی های رقابتی خاص پیشرفت حاصل شود. برای دستیابی و رسیدن به اهداف یک استراتژی، نیاز است برنامه هایی (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 به سرور و اعمال یک سری تنظیمات و پیکربندی به صورت دستی و غیر اتوماتیک در آن بود. با گذشت زمان و تکامل اپلیکیشن ها و همچنین اپلیکیشن-سرورها، روش های استقرار و انتشار نرم افزار هم کامل تر و متنوع تر شدند. با این وجود هنوز بسیاری از تولید کنندگان نرم افزار، از روش های قدیمی و منسوخ شده برای استقرار استفاده می کنند که معایب زیادی به همراه دارد.

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

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

به حداقل رساندن DownTime یا به صفر رساندن آن
کاهش ریسک ناشی از استقرار
کاهش ریسک عملیاتی کردن نسخه ی جدید
شناسایی سریع مشکلات نسخه ی جدید بعد از عملیاتی شدن
سرعت بخشیدن به امکان 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 Deployment Strategy
  - چه موقع از Recreate Deployment استفاده کنیم ؟
- Rolling Deployment Strategy
  - چه موقع از Rolling Deployment استفاده کنیم ؟
استراتژی های پیشرفته استقرار نرم افزار (در پست بعدی معرفی و بررسی خواهند شد)
- Canary Deployment Strategy
- Blue-Green Deployment Strategy
- Dark Launch Strategy
- A/B Deployment Strategy

Recreate Strategy | Recreate Deployment

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

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

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

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

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

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

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

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

Rolling Strategy | Rolling Deployment

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

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

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

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

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

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

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

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

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

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

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

جمع بندی

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

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