دوآپس (devops) و ۱۱ مزیت آن

فرهنگ سازمانی

تکنولوژی‌های جدید علاوه بر توسعه‌ی عملکرد نرم افزارها، بر روی فرهنگ‌های سازمانی نیز تأثیرگذار هستند. تغییراتی که دوآپس یا DevOps ایجاد می‌کند ترکیبی از هردو تغییرات فرهنگ و فناوری‌های جدید است. ایده‌ی DevOps اصلاح فضای کار برای همکاری، بحث و به اشتراک گذاشتن تجربیات است.

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

تاریخچه دواپس

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

طبق رویکردی که باعث مطرح شدنِ دوآپس شد، می‌توان مؤسس آن را آقای Patrick Debois دانست. پاتریک که از هر منظری علاقه‌مند به یادگیری IT بود، در سال 2007 میلادی بر روی پروژه‌ی دیتاسنتر دولت بلژیک مشغول به کار شد. مسئولیت تست و آزمایش آن با پاتریک بود.  یکی از چالش‌هایی که در طی این پروژه با آن برخورد کرد، مشکلات و ناهماهنگی بین دو تیم عملیاتی (Operations) و توسعه (Development)  بود.

سال 2008 میلادی در کنفرانس Agile، آقایی به نام Andrew Shafer پیشنهاد نشستِ Agile Infrastructure یا زیرساخت متد چابک را داد؛ اما پاتریک تنها کسی بود که در آن نشست شرکت کرد. با این‌حال پاتریک مشتاقانه با اندرو در این مورد بحث کرد. در نهایت گروهی  ایجاد می‌کنند که افراد دیگر نیز در رابطه با حل مشکلات و جدایی بین دو گروه Development  و Operations ایده‌ های خود را ارائه دهند؛ که در ابتدا استقبال زیادی نشد.

اما در سال 2009 در کنفرانسی، آقایان John Allspaw و   Paul Hammondتحت عنوان « 10+ استقرار در روز: همکاری های Dev و Ops در Flickr » سخنرانی کردند.

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

بنابراین در همان سال برای کنفرانسی با عنوان «DevOpsDays» به برنامه‌نویسان و sysadmin ها فراخوان داد. هدف پاتریک از این گردهمایی پیدا کردن بهترین راه برای پل زدن و از بین بردن شکاف بین دو تیم توسعه و عملیات بود. بعد از این کنفرانس هم در توئیتر هشتگ DevOps را راه اندازی کرد تا باز هم در این مورد بحث شود. . بعدها پاتریک به این مسئله اشاره کرده بود که نامِ دوآپس با برنامه ریزیِ قبلی انتخاب نشده بوده است.

دلیل استقبال ناگهانی از دوآپس

 در سال 2011 آقای Cameron Haight پیش‌بینی خودش را درباره‌ی آینده‌ی دوآپس ارائه داد. چشم‌انداز مثبت وی منجر شد که توجه بیشتری به سمت DevOps جلب شود.

مدتی نگذشت که شرکت‌های بزرگی این شیوه‌ی جدید را به کار بردند. از طرفی با جدی شدن بحث فضای ابری یا همان Cloud و حرکت تیم ها به سمت توسعه نرم افزار Agile، نسخه‌های جدیدی از برنامه دائم باید برای کاربران ارسال می‌شد.

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

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

تعاریف

دوآپس یک متدلوژی برای توسعه‌ی نرم افزار است. DevOps در لغت ترکیبی از دو کلمه‌ی Development به معنای توسعه و Operations به معنای عملیات می‌باشد.

 DevOps بر اساس ایجاد فرهنگ همکاری بین این دو تیم که مدت‌ها دیواری بین‌شان قرار گرفته، پایه گذاری شده است. این مفهوم را به دنبال دارد که تیم های Dev و Ops نباید متضاد هم باشند.

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

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

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

چرا از DevOps استفاده کنیم؟

قبل از توسعه‌ی نرم افزاری به شیوه DevOps روال کاری به صورت زیر پیش می‌رفت،

 تیم‌های مهندسی نرم افزار و برنامه نویسی (Dev)، کارِ تشخیص نیازمندی‌های یک نرم افزار و کد زدن را انجام می‌دهند. بعد از تحقق الزامات، تیم تضمین کیفیت یا همان QA (Quality Assurance) برنامه را در یک محیط توسعه ی جداگانه تست و آزمایش می‌کند. بعد از تأیید، برنامه به تیم عملیاتی (Ops) تحویل داده می‌شود.

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

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

1. معمولاً تیم Dev از موانع تیم QA و Ops اطلاعی ندارد؛ بنابراین برنامه طبق روالی که این گروه پیش‌بینی کرده بود پیش نمی‌رود. یعنی تیم توسعه بدون دانش از محیط عملیاتی نرم افزار را تولید می‌کند و در اختیار تیم Ops قرار می‌دهد تا در دسترس کاربران قرار گیرد.
2. دو تیم Ops و  QA اغلب بر روی ویژگی‌های برنامه‌ی نرم افزاری تمرکز دارند، بنابراین دانش آن‌ها نسبت به اهداف تجاری و اهمیت آن برنامه محدود تر است و پیش زمینه‌ی درستی در این رابطه ندارند. بنابراین تیم عملیات هم بدون دانش از ساختار نرم افزار و کدنوشتن، سعی می‌کند که برنامه را عملیاتی کند.
3. هر گروه اهداف متضاد یکدیگر را دارند. این امر می‌تواند منجر به ناکارآمدی شود. یعنی هر زمان که ایرادی پیش آمد هر واحد، گروه دیگر را مقصر می‌داند. پس این ایزوله بودن و عدم هماهنگی بین این دو تیم ممکن است به شکست پروژه منتهی شود.

در این مرحله است که اهمیت دوآپس آشکار می‌شود. DevOps با ایجاد تیم‌های مبتنی بر همکاری که عملکردی تعاملی دارند این چالش ها را پشت سر می‌گذارد.

فواید آن

در یک سازمان هر یک از واحد ها (IT , Dev , CEO ,CIO) دیدگاه متفاوتی نسبت به مزایای دوآپس دارند. اما مزایای DevOps محدود به یک گروه از افراد یا یک واحد نیست.

آقای David Linwood، مدیر مجرب IT، به این اختلاف‌نظر ها عنوانِ “لنزها” را می‌دهد. وی درحالی که بر روی مزایای دوآپس تحقیق می‌کرد متوجه شد که در واقع 24 مزیت وجود دارد؛ که سرعت بالا و هزینه کمتر Release نسخه‌ها، پشتیبانی بهتر و رفع فوری مشکلات در صدر این لیست قرار می‌گرفت. با این‌حال زمانی که این فواید را از طریق لنزها فیلتر کرد تصویری متفاوت پدید آمد. این‌که هر یک از افراد سازمان (ذی‌نفعان) نتایج متفاوتی را از دوآپس انتظار داشتند.

به‌طور مثال از نظر بخش عملیاتی فواید این متد، موارد زیر را شامل می‌شود:

1. پشتیبانی عملیاتی بهبود یافته و رفع سریع‌تر باگ‌ها
2. اتوماسیون شدن فرآیندهای IT
3. افزایش انعطاف پذیری و چابکی تیم فناوری اطلاعات
4. تیم‌های شادتر و منسجم‎‌تر
5. تبادل مهارت و تجربه بین همکاران
6. به وجود آمدن تیم‌های مشارکتی

ممکن است مزایای ذکر شده از نظر مدیرعامل سازمان (CEO) پیش‌پا افتاده باشد؛ اما برای CIO به دلیل حفظ کارایی تیم، حائز اهمیت است. به‌طور مثال افراد شادتر بیشتر تلاش کرده، کار را بهتر انجام داده و مدت بیشتری در تیم حضور پیدا می‌کنند.

به‌طور کلی DevOps فواید زیر را به دنبال خواهد داشت:

1. DevOps به شما کمک می‌کند تا در بازار سریع‌تر از رقبا رشد کنید.
2. میزان شکست و خطا را در نسخه‌های جدید برنامه‌ به طور محسوس کاهش می‌دهد.
3. زمان بین رفع و اصلاح ایرادات برنامه را کاهش می‌دهد.
4. کارایی نرم‌افزار را بهبود می‌بخشد.
5. در نهایت باعث افزایش رضایت مشتری خواهد شد.

روند بکارگیری دواپس (devops) در ایران و جهان

برای استفاده از دوآپس، باید با دو مسئله آشنا شویم؛ فاز های دوآپس و ابزار مورد استفاده.

• توسعه‌ی آبشاری (Waterfall Development)

تیم‌های توسعه (Development)، به مدت 3 تا 4 ماه کار کدنویسی را انجام می‌دهند. سپس به منظور Release کردن این کدها را باهم ادغام می‌کنند.

• ادغام مداوم (Continuous Integration)

این مرحله از دوآپس به این صورت است که کدهای جدیدی که توسعه داده شده سریع‌تر با کد اصلی ادغام شود. این عمل زمان زیادی را صرفه جویی می‌کند تا کد آماده‌ی Release شود. برای اتوماسیون سازی کارها، مهم‌ترین قدم اجرای صحیحِ Continuous Integration است.

• تحویل مداوم (Continuous Delivery)

در اجرای Continuous Delivery با انجام تست و اتوماسیون سازی، کد برای Deploy آماده‌ خواهد شد.

• Continuous Deployment

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

روال اتوماسیون ‌سازی در این مرحله از دوآپس به این‌صورت است که برنامه‌ی جدید فقط برای درصد کمی از کاربران Release می‌شود. این عمل منجر به ایجاد یک حلقه‌ی بازخورد اتوماتیک خواهد شد؛ این حلقه قبل از انتشار سراسری، کیفیت و نحوه‌ی عملکرد کد را Monitor می‌کند. تعداد کمی از شرکت‌ها هستند که این فاز از دوآپس را به درستی اجرا می‌کنند. نتفلیکس(Netflix)، آمازون،  Etsy، پینترست (Pinterest)، فلیکر(Flicker)، IMVU و گوگل نمونه های محبوب شرکت‌هایی هستند که این فاز را انجام می‌دهند.

بخشی از فرآیندِ دوآپس «اتوماتیک شدنِ روند کاری» می‌باشد. به این منظور باید از یک‌سری ابزارهایی که خوشبختانه به راحتی در دسترس هستند استفاده کرد.

تصویر بالا به طور خلاصه، چرخه‌ی Continuous Integration در دوآپس را به همراه ابزارهای رایج در هرمرحله نمایش می‌دهد.

1. برنامه‌ریزی و انتخاب الگوریتم و ماژول
2. برنامه‌نویسی: Git (که دارای تمام repository ها می‌باشد)
3. ساخت و تولید نرم افزار: gradle یا  maven
4. تست اتوماتیک: Selenium
5. اجرا: puppet، Docker و  یا Ansible
6. مانیتورینگ  اتوماتیک: Nagios
7. ادغام و ارسال کدها: Jenkins

توجه داشته باشید استفاده از این ابزارها است که پیاده سازیِ دوآپس در یک سازمان را نشان می‌دهد.

اهداف دوآپس

هدف کلی از اجرای دوآپس بهبود همکاری بین تمامی ذی‌نفعان می‌باشد. هیچ مانیفست نهایی وجود ندارد که صریحاً مدل DevOps را تعریف و توصیف کند؛ دوآپس یک مفهوم تا حدودی انتزاعی و نوعی تفکر است که بر روی چند اصل مهم متمرکز می شود که در ادامه به آنها می پردازیم:

افزایش سرعت چرخه‌ی تولید و ارائه محصول

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

افزایش پایداری و اعتبار در سرویس‌دهی

پیاده سازی تکنیک های دوآپس مانند Continuous Integration و Continuous Delivery به شما تضمین می‌دهد که برنامه بعد از Release، همواره به‌طور پایدار و مطمئن درحال سرویس‌ دادن به کاربران می‌باشد. علاوه بر این با منسجم بودن تیم‌ها، کارها با هماهنگی بالاتر و بهینه‌تر انجام خواهد شد. و همین‌طور موارد قابل توجه دیگری مانند:

• تحویل سریع
• امنیت بالا
• هزینه‌ی کم‌تر Release
• همکاری بین تمام کارکنان
• اصول دوآپس (DevOps)

برای درک راحت‌ترِ چگونگی فرآیند دوآپس، از چارچوب CALMS استفاده می‌کنیم. این چارچوب به 5 لغت زیر اشاره دارد:

Culture – Automation – Lean – Measurement – Sharing

چارچوب فرهنگ (Culture)

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

اتوماسیون (Automation)

تیم‌ها به دنبال راه هایی برای اتوماسیون‌سازی وظایف هستند. که به این منظور مفاهیم Continuous Delivery، Continuous Integration، Continuous Deployment مطرح شد. پس اگر کارها در یک سازمان به طور دستی انجام می‌شود، نشان‌دهنده اینست که مفهوم دوآپس در آن سازمان اجرا نشده است. چون روند کاری را کند کرده و درصد خطا را افزایش می‌دهد.

بی ارزش یا اندک (Lean)

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

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

سنجش (Measurement)

یکی از عواملی که نشان می‌دهد نرم‌افزار موفق بوده، وجود قابلیت سنجش بعد از Deploy شدن برنامه است. این قابلیت در دوآپس با عنوان Measurment شناخته می‌شود. باید با جمع‌آوری اطلاعات، توانایی های برنامه و همچنین توسعه‌های آینده‌ی آن ارزیابی شود. خوشبختانه، ابزارها و فناوری‌های زیادی برای اندازه گیری کارایی وجود دارد. منظور از سنجش کارایی پاسخ به یک‌سری سؤالات مشخص است، مانند: کاربران در برنامه‌ی شما چقدر وقت می‌گذرانند؟ مطلبی که در وبلاگ نوشته بودید تا چه درصدی بر روی فروش تأثیر داشته؟ لاگ های قبلی چه هشدار هایی داشتند؟

با ملاک‌های خاصی می‌توانیم روال کاری را بسنجیم:

1. بررسی و مانیتورینگِ زیرساخت
2. مدیریت لاگ ها
3. مدیریت کارایی و کاربرد برنامه
4. بررسی تعداد باگ‌ نسخه‌های قبلی
5. ارزیابی سرعت میانگین تحویل هر نسخه

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

اشتراک گذاری (Sharing)

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

تفاوت Agile و DevOps

بسیاری از افراد متدلوژیِ Agile و دوآپس را یک مفهوم در نظر می‌گیرند. درحالی که می‌توان گفت دوآپس نسخه‌ی پیشرفته‌تر از Agile است. اما این دو مفهوم، تفاوت هایی دارند که تصاویر زیر بیانگر این موارد خواهد بود.

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

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

اما تمرکز متدولوژی دوآپس، همان‌طور که اشاره شد بر روی برقراری ارتباط میان دو تیم توسعه و عملیاتی است. این راهکار به دنبال تولید و ارائه با سرعتی بالاتر و تا حد امکان خودکار می باشد.

از تفاوت های اساسی این دو متد می‌توان به موارد زیر اشاره کرد:

Task یا وظایف

وظایف افراد در Agile ایجاد تغییرات فوری طبق خواسته‌ی مشتری می‌باشد، درحالی که در DevOps قرار بر تست و Deploy به صورت مداوم است.

Purpose  یا هدف

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

Team Size تعداد اعضای تیم

در Agile هرچه تعداد کمتر و تیم کوچک‌تر باشد، سریع‌تر در مسیر تولید حرکت می‌کنند. در حالی که در دوآپس کاملا برعکس است.

Feedback یا بازخورد

در Agile بازخورد از ابتدای کار از جانب مشتریان است. اما در متد دوآپس از آنجایی که محصول در چرخه‌ی تولید دست به دست می‌شود، تیم های داخلی نیز یازخورد خود را ارائه می‌دهند.

Hamesh Chawla، مدیر ارشد مهندسی Zephyr می‌گوید:
دوآپس به ما کمک کرده تا به‌طور مکرر نسخه های جدید را Release کنیم و همراه با جریان بازار به سمت جلو حرکت کنیم. حتی نسخه هایی که به مدت 6 ماه زمان بر بود را به طور روزانه منتشر ‌کنیم؛ و بعد از برطرف کردن باگ های برنامه، محصول را سریع‌تر به دست کاربران برسانیم.