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

بعضی نفرات فکر می کنند که 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 کجاست؟

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

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

scrum.ir