DevOps چیست؟ و کاربرد آن کجاست؟

شاید IT یکی از بزرگترین صنایعی باشد که هر روز در آن واژگان جدیدی به دایره لغات ما افزوده می شود، یکی از این لغات جدید DevOps است که از سال 2009 شروع به ظهور کرده و  از 2014  بسیار مورد استقبال قرار گرفته است و اگر در لیست مشاغل خارجی بدنبال آن باشید، می بینید که شرکت ها بشدت دنبال افراد متخصص در این حوزه می گردند.

اما دلیل نوشتن این پست، کج فهمی های زیاد در مورد DevOps بود، اینکه واقعا DevOps چیست؟

روزگاری در شرکت ها توسعه نرم افزار دو تیم وجود داشتند که با یکدیگر دوست نبودند، یکی از آن ها Dev یا تیم توسعه و آن دیگری Ops یا تیم عملیات بود. شاید به ظاهر در یک واحد تحت فرمان مدیریتی یکسان بر روی پروژه(های) مشترک کار می کردند ولی اهداف آنها کاملا متضاد بود. هدف تیم توسعه ساخت ویژگی های جدید و تغییرات زیاد بر روی محصول بود ولی تیم عملیات بدنبال پایداری و ثابت نگه داشتن وضعیت سرویس های موجود بود.

برای همین مابین این دو تیم یک دیوار نامرئی (و گاها در تجربه ما در ایران دیوارهای مرئی) به وجود می آمد. مفهوم DevOps بدنبال این است که با از بین بردن دیوار مابین (مرئی یا نامرئی) تیم ها، و افزایش تعامل نفرات، موجب افزایش سرعت تحویل ارزش به مشتری شود. پس خیلی ساده، DevOps  فرآیندی است برای تحویل سریع ارزش به مشتری و از بین بردن هر نوع مشکل که باعث کندی در فرآیند تحویل ارزش شود. 

این مفهوم چرا مهم شد؟

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

در مفهوم DevOps ما سعی می کنیم این تیم ها به هم نزدیک تر شوند و با تعامل و همکاری بهتر و البته اتوماتیک کردن بسیاری از روال های تکراری، تحویل ارزش به مشتری دچار مشکل یا کندی نشود.

کج فهمی ها در مورد DevOps

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

DevOps فقط Continuous Delivery نیست

خیلی از دوستان فکر می کنند DevOps همان Continuous Delivery است. یعنی اینکه ما در ابزار TFS یا Jenkins یک CI راه بیاندازیم و عملیات Deployment را اتوماتیک کنیم، پس ما DevOps هستم. حتی در بعضی از جاها با عنوان مهندس DevOps آگهی استخدام می زنند که در شرح شغل فقط دنبال کسی هستند که ابزار CI را پیکربندی کنند.

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

ارتباط DevOps با روش های چابک و CI و CD

ارتباط DevOps با روش های چابک و CI و CD

DevOps یک تیم نیست

بعضی نفرات فکر می کنند که DevOps یعنی یک تیم متشکل از برنامه نویسان و بچه های عملیات. خود ساخت این تیم مفهوم DevOps نیست ولی شاید یک روش برای رسیدن به این فرآیند باشد و شاید در بسیاری از سازمان این روش نارکارآمد باشد.

چارچوب CALMS

CALMS یک چارچوب راهنما برای رسیدن به فرآیند Devops است:

Culture

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

Automation

در اینجا دقیقا مفاهیم Continuous Delivery – Continuous Integration – Continuous  Deployment مطرح می شود، امکان ندارد شما ادعا کنید ما فرآیندهای DevOps را داریم ولی از ابزارهای مثلا CI استفاده نمی کنیم و همه کارها را دستی انجام می شود. فرآیندهای دستی کند هستند و امکان خطای انسانی در آنها زیاد است. برای همین تا آنجایی که امکان دارد باید تمام فرآیند تحویل محصول (از کامپیوتر برنامه نویس ها تا مشتری واقعی) اتوماتیک شده باشند.

Lean

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

برای مثال، کوچک بودن تیم های توسعه، توسعه ویژگی هایی که مشتری واقعا نیاز دارد، کم کردن دوباره کاری، کم کردن Task Switch و … .

Measurement

تا زمانیکه ندانیم کجا هستیم، نخواهیم دانست که کجا می خواهیم برویم.

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

  • Infrastructure Monitoring
  • Log Management
  • Application and Performance Management

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

Sharing

این مفهوم در مورد اشتراک گزاری درس های یادگرفته است. ما از اندازه گیری ها و مانتیتورینگ چه درسی گرفتیم؟ پیشتر وجود دیوار مابین اعضای تیم باعث می شد این درس ها بین اعضای تیم پخش نشوند ، اشتباهات مکررا تکرار میشد و کارها صرفا با غر زدن پیش می رفت.

اینکه درس بگیریم که دیگر اشتباهات را تکرار نکنیم، یا اقدامات پیشگیرانه انجام دهیم و … .

کاربرد DevOps کجاست؟

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

چابک و موفق باشید

اسد صفری

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

مطالب را هم دوست داشتید می توانید از طریق این لینک عضو فید دنیای چابک شوید تا مطالب جدید برای شما ارسال شود

در ضمن دوره های آموزشی نیز برگزار می کنیم که شاید برای شما یا تیم شما نیز مفید باشند اگر اینگونه بود خوشحال می شوم با من تماس بگیرید

اسد صفری

اسد صفری – مربی تحول چابک سازمان و تیم های نرم افزاری. مدارک حرفه ای: CSP - CSM - PSM - PSPO - CDA - Management 3.0 برخی تجربیات: رئیس دفتر تحول چابک شرکت داده ورزی سداد(بیشتر از ده تیم نرم افزاری) - مربی چابک شرکت رامند (تیم های موبایل و گیم سازی) - مدیر تولید نرم افزار SimplyDesk برای شرکت فرانسوی PCI - مربی مشاور شرکت های:خدمات انفورماتیک، ارکید فارمد، فراداده، الفبا برخی از سوابق مشاوره کوتاه مدت و تدریس : علی بابا، فناپ، تجارت الکترونیک پارسیان، بیمه سامان، انیستیتو ایزایران، مهندسین مشاور تجارت (بانک تجارت)، بیمه ایران، پارس آنلاین، شرکت رهنما، ورانگر، انتشارات پزشکی کوثر و صنایع ارتباطی آوا، فولا آلیاژی یزد، پارک علم فناوری کردستان و ... . عضو انجمن های بین المللی Agile Alliance - Scrum Alliance

3 دیدگاه

  1. علی اژدری   •  

    در واقع DevOps یک گام بعد از ALM به حساب میاد، با تمام کارهایی که تیم ها انجام میدن تا Agile باشن فقط دارن روند تولید نرم افزار رو سرعت می بخشن، ولی از روند Publish نرم افزار و رسوندن ارزش به دست مشتری غافل شدن، اینجا بود که بعد از تمام مباحث CI و CD مفهوم دیگه ایی مطرح شد به نام DevOps تا فرآیند بعد از تولید نرم افزار هم با سرعت بیشتری انجام بشه. با این روش کار توسعه دهنده ها Done نیست مگر اینکه در محیط عملیاتی به دست مشتری برسه. شرکت های معدودی در ایران روند ALM رو پیاده سازی کردن و شرکت های خیلی کمتری به سمت DevOps در حال حرکت هستن.

    • محمود   •  

      با كليات ديدگاه شما موافق هستم. با اين تفاوت كه به نظر من devops هم جزيي از ALM هست

  2. امید شریعتی   •  

    با تشکر از متن بسیار عالی که ارائه دادید آقای صفری. مدتی بود که میخواستم چنین متنی بنویسم اما شما بسیار بهتر از من این کار را انجام دادید. بنده و همکارانمون یک تجربه بسیار موفق در این زمینه در شرکت ویستا سامانه آسا داشتیم که دوست دارم نتایج اون را با شما به اشتراک بزارم.
    تقریبا از اواسط سال 2014 به طرف CI و CD پیش رفتیم و بعد از چند ماه کم کم سعی کردیم فرهنگ devops در شرکت جا بیافته. بعد از گذشت دو سال شاید جزء معدود شرکت هایی در ایران هستیم که این فرهنگ به خوبی در اون جا افتاده.
    در سال اول از 40 انتشار در ماه که حدود 100 نفر-ساعت زمان میبرد و بعد از اون کلی باگ پیدا می شد و کلی آدم درگیر می شدند و عملا دو برابر زمان انتشار به این مشکلات صرف می شد، به 55 انتشار در ماه با حدود 40 نفر-ساعت در پایان همان سال رسیدیم به اضافه اینکه باگ ها بسیار کمتر و خطاهای انتشار تقریبا به صفر رسید. این انتشار ها در آن زمان مربوط به حدود 50 اپلیکیشن بود که باید در 5 سرور منتشر می شدند.

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *