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


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


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

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

دوآپس فقط ابزار نیست

دوآپس به سادگی اجرا و به کارگیری چند ابزار ساده نیست. یکی از مسائل نگران کننده که در تعاریف موجود وجود دارد، مفاهیم گیج کننده و با ساختاری ضعیف در آن ها است که باعث می شود افراد بعد از یادگیری این تئوری شروع کنند به اجرای فرایند ها و یا به کارگیری ابزارها بدون اینکه اصول دوآپس را در ذهن خود داشته باشند، که این قطعا یک ضد الگو است. همانقدر کهخودکارسازی هوشمندانه می تواند سودمند باشد، خودکارسازی غیر هوشمندانه باعث آسیب هایی می شود.
معمولا در چابک سازی تیم ها هم مشابه این اتفاق می افتد، اعضای گروه کار کردن در قالب iteration و اجرای سایر تمرین های چابک (Agile) را شروع می کنند بدون آنکه همکاری معناداری با هم داشته باشند. من تیم های زیادی را می شناسم که از برخی از روش ها و ابزارهای چابک استفاده می کنند بدون آنکه به اصول چابک توجه کافی داشته باشند. مشخص است که نتیجه ایده آل نمی شود. مطمئنا ابزارهای چابک (یا به طور مشابه ابزارهای دوآپس) می توانند مفید باشند، اما اگر ندانید که چطور از آن ها درست استفاه کنید، شبیه چاقوی جراحی ای است که با آن هندوانه قاچ کنید!
در آخر به این موضوع هم اشاره کنم این جمله هم اشتباه است که بگوییم “هیچ ابزاری نباید به نام ابزار دوآپس معرفی شود”. آیا poker planning در Agile به این معنی است که انجام آن باعث چابک شدن شما می شود ؟ خیر. اما این یک ابزار مشترک در بسیاری از روش های چابک است، پس می توانیم از آن به عنوان یک “ابزار چابک” نام ببریم. به طور مشابه به این دلیل که نمی توان دوآپس را فقط مجموعه ای از ابزار دانست، نمی توان گفت که ابزارهایی که برای اجرای آن ساخته می شوند، “ابزار دوآپس” نیستند.

 

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


 

چارچوب CALMS در DevOps چیست و چه کمکی می کند؟

پایه و اساس DevOps ، تغییر است. Keep CALMS !
به وسیله DevOps، کسانی که با آخرین ابزارهای توسعه کار میکنند، محتاطانه عمل نمی کنند. DevOps علاوه بر افراد و فرایند ها، به ابزارها هم اهمیت می دهد و روش های مختلفی برای گرد هم آوردن این سه مجموعه در کنار هم ایجاد می کند.
کافی است تا عبارت “DevOps” را در google جستجو کنید تا دیاگرام ها و متدولوژی های بسیاری را پیدا کنید که هر کدام از آن ها جنبه ی متفاوتی را برجسته کرده اند. اما می توان گفت که همه ی آن ها در موارد زیر با هم مشترک اند:

1. فرهنگ سازی | Culture
2. خودکارسازی | Automation
3. تفکر ناب | Lean thinking
4. اندازه گیری همه چیز | Measurement
5. اشتراک گذاری | Sharing

Culture
همانطور که گفته شد، DevOps  بیشتر یک مفهوم فرهنگی است، یعنی دقیقا چیز خاصی نیست که آن را پیاده سازی کنید. نیاز داریم تا دیوار بین افراد و تیم ها شکسته شود تا آنها تعامل خوبی با هم داشته باشند و اهداف متضاد آنها تبدیل به اهداف مشترک شود.
همه میدانیم فرهنگ چیزی نیست که یک نفر بتواند آن را پیاده سازی کند. فرهنگ در یک محیط طبیعی که شامل سرتاسر تیم تولید نرم افزار می شود وجود دارد. منظور از سرتاسر همه ی افراد است از جمله توسعه دهندگان (Development)، تضمین کنندگان کیفیت (QA) و تیم های عملیات (Operation) و … . در چنین اکوسیستمی که متشکل از مجموعه ای از افراد و ابزارها است، برای رفع موانع و تسهیل همکاری برای دستیابی به اهداف نهایی، یک کار فرهنگی لازم است.
 
Automation
هنگامی که فرهنگ سازی در سازمان انجام شد، می توانید بر خودکارسازی یا اتوماسیون تمرکز کنید. اتوماسیون تنها به نوشتن Script ها و استفاده از Unit Test ها یا Functional Test ها محدود نمی شود. خودکارسازی شامل همه قسمت ها از جملهContinuous-Integration ، Continuous-Delivery/Deployment، Infrastructure-Automation و هر جای دیگری می شود.
با راه اندازی Automation می توانید برای همه چیز برنامه ریزی کنید.
فرایند های دستی بسیار کند و مستعد خطای انسانی هستند. راهی برای رهبری تمامی ابتکارات جدید به وسیله اتوماسیون پیدا کنید و برای رسیدن به مقیاس های بزرگتر به طور مستمر به اتوماسیون فکر کنید.
 
در اینجا دقیقا مفاهیم Continuous Delivery – Continuous Integration – Continuous  Deployment مطرح می شود، امکان ندارد شما ادعا کنید ما فرآیندهای DevOps را داریم ولی از ابزارهای مثلا CI استفاده نمی کنیم و همه کارها را دستی انجام می شود. فرآیندهای دستی کند هستند و امکان خطای انسانی در آنها زیاد است. برای همین تا آنجایی که امکان دارد باید تمام فرآیند تحویل محصول (از کامپیوتر برنامه نویس ها تا مشتری واقعی) اتوماتیک شده باشند.
 
 
Lean
بعد از راه اندازی اتوماسیون، به یاد داشته باشید که همچنان ناب بمانید و اصول تولید ناب نرم افزار را رعایت کنید.
اجرای Lean به معنی نگه داشتن همه چیز در حداقل است.
ابزارها، جلسات و حتی iteration ها و همه چیز دیگر باید Lean باشد یعنی در حداقل ممکن باشد. تفکر ناب یعنی ارزش محور بودن فعالیت ها و کاهش فعالیت های اضافه و در حداقل نگه داشتن همه چیز. این هم بخشی از فرهنگ DevOps است. وقتی شما ناب هستید، برای هر ابزار، و روشی که انتخاب می کنید، هدفی دارید.
ناب بودن تنها به یک یا چند فرد محدود نمی شود و شامل همه ی تیم ها و افراد می شود.
باید تیم را در اندازه ای نگه داشت که بیشترین کارایی را داشته باشد. یک آشپزخانه با آشپزهای بیش از حد، بازده کمی خواهد داشت. اگر پیچیدگی اپلیکیشن به گونه ای باشد که نیاز به تیم های بزرگ باشد، تیم را به زیرگروه های کوچکتر تقسیم کنید، همانطور که سازمان های بزرگ این کار را می کنند (Spotify) یکی از موفق ترین مثال ها در این زمینه است.
 
Measurement
تا زمانیکه ندانیم کجا هستیم، نخواهیم دانست که کجا می خواهیم برویم.
برای ایجاد یک فرآیند خوب و منظم، نیاز به شفافیت در کلیه سطوح داریم، برای ایجاد شفافیت و تصمیم گیری بهتر، نیاز داریم تا بتوانیم وضعیت موجود را ارزیابی کنیم. معمولا در هر سطح نرم افزار برای نوع سرویسی به چنین مانیتورینگ هایی نیاز است:

• Infrastructure Monitoring
• Log Management
• Application and Performance Management

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


Sharing
این مفهوم در مورد اشتراک گزاری درس های یادگرفته است. ما از اندازه گیری ها و مانتیتورینگ چه درسی گرفتیم؟ پیشتر وجود دیوار مابین اعضای تیم باعث می شد این درس ها بین اعضای تیم پخش نشوند ، اشتباهات مکررا تکرار میشد و کارها صرفا با غر زدن پیش می رفت.
اینکه درس بگیریم که دیگر اشتباهات را تکرار نکنیم، یا اقدامات پیشگیرانه انجام دهیم و … .
ایجاد جریان اطلاعات دوطرفه یکی از مزیت های شکستن دیوار بین تیم ها می باشد و باعث جلوگیری از انداختن توپ در زمین تیم دیگر می شود. با این وجود اگر اطلاعات به صورت proactive و فعالانه به اشتراک گذاشته نشوند، ارزشی نخواهند داشت.
Sharing و Reporting کاملا با هم متفاوت هستند، Sharing تنها گزارش واقعیات نیست، بلکه مبادله ی ایده ها در سر تا سر تیم ها و به طور دائمی است. Reporting معمولا به صورت انفعالی (reactive) اتفاق می افتد در حالی که Sharing به صورت فعالانه و proactive می باشد.


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