برای این که بدانیم ماهیت دواپس چیست و تیم دواپس چه وظیفه ای بر عهده دارد، شاید بهتر باشد شرایط قبل از شکل‌گیری دواپس را بررسی کنیم. در سال ۱۹۹۷ شخصی به‌نام Winston W مدل آبشاری را تحت عنوان Waterfall mode ارائه کرد. این مدل بنا داشت شرایط تولید و توسعه نرم‌افزار را مشخص کند. به این صورت بود که وقتی از سوی کارفرما نیازی به تیم توسعه نرم‌افزار اعلام می‌شد، ابتدا چند ماه زمان جهت شناخت پروژه، تحلیل و تهیه مستندات سپری می‌شد، سپس در تیم تولید جلسه‌ای برای بیان نیازمندی‌های طراحی‌، تولید و توسعه برگزار شده و در نهایت تیم توسعه نرم افزار، شروع به کار می‌کردند و پس از آماده‌شدن کد برنامه، پروژه را تست، منتشر و نگهداری می‌کردند. اما این مدل یک مشکل بزرگ داشت آن هم این که نسبت به تغییرات چابک نیست‌، مثلا اگر نیازمندی درخواست دهنده نرم افزار در حین کار تغییر پیدا می‌کرد و نیازمندی دیگری اعلام می شد ، تیم توسعه نرم افزار باید از نقطه ی صفر شروع  می کردند، مجدد جلسه ای جهت نیازسنجی و طراحی و… برگزار می‌شد. در واقع هیچ جای این مدل ، بازخورد گرفتن از مشتری مطرح نبود و درخواست دهنده نرم افزار باید تا پایان کار (فرضا چندیدن ماه یا سال) منتظر می ماند تا پروژه به اتمام برسد و بتواند در خصوص آن نظر دهد (حالا فرض کنید در انتهای پروژه تازه از جانب مشتری اعلام نقص یا مغایرت در اعلام بیزینس و تحلیل اولیه اعلام می‌شد) و این موضوع باعث اتلاف زمان و انرژی زیادی می شد و حتی در برخی از بیزینس ها باعث می شد بعد از گذشت این مدت زمان ، بازار هدف از دست برود. این موضوع باعث شکل گرفتن یک دیوار بین صاحبان کسب و کار و صنعت توسعه ی نرم افزار شد .چند سال بعد، در سال 2000 مدل چابک (Agile) معرفی شد و تمام حرفش این بود که کارها را به بازه های کوچکتر تقسیم کنیم و فرآیند بازخورد گرفتن را در انجام کار لحاظ کنیم که در نهایت خروجی کار چابک باشد.در این نقطه بود که روند توسعه‌ی نرم‌افزار در دنیا برای همیشه عوض شد و Agile  کمک کرد که آن دیوار ما بین صاحبان بیزینس و تیم توسعه ی محصول از بین برود چون حالا محصول کوچک تر و سبک تر و خیلی سریع تر عرضه می شد ، در حین توسعه فیدبک گرفته می شد و بعد از اعلام نظر مشتری مجدد تغییرات مورد نیاز اعمال می شد و  این فرایند تا رسیدن به نقطه ی انتهایی تکرار می شد . این بین برای انجام فرایندها مفاهیم اسکرام بوجود آمد که به پیش بردن پروژه ها به بهترین شکل ممکن کمک کند .در نتیجه محصولات می توانستند سریعتر راه اندازی شوند ، سریع‌ تر وارد مارکت شوند و در نتیجه سریع‌تر به درآمدزایی برسند اما نکته اینجاست که کد رو تولید کردیم و به روش Agile  طی یک سری اسپرینت تغییرات را اعمال می کنیم اما چه کسی  وظیفه ی استقرار و نگهداری سرور و سرویس ها  را بر عهده دارد؟طبیعتا این امر به تیم تولید و توسعه ی نرم افزار که مرتبط نمی شود، چون در چهارچوب وظایف آن ها نیست .اینجاست که نقش تیم عملیات(Operation)  مشخص می شود.تیم عملیات در واقع جمعی از کارشناسان نرم افزار و کارشناسان شبکه(SysAdmin‌ها و  Network  Engineers‌های‌)سابق هستند که در شرکت‌های توسعه نرم‌افزار وظایفی مثل فراهم‌سازی زیرساخت مناسب جهت استقرار( Deployment )، بررسی منابع سرور‌ها، برقراری و بررسی موارد شبکه‌ای و ارتباطات سامانه‌ها‌، بررسی صحت عملکرد سرویس‌ها، در دسترس نگه داشتن سرورها، پیاده‌سازی مکانیزم‌های Backupگیری، پیاده‌سازی فرایند‌های تولید گزارش و لاگ‌های سیستمی و‌… را به‌عهده داشتند. بنابراین هر چه تعداد محصولات بیشتر باشد‌، کار تیم عملیات هم بیشتر می‌شود.

با این حال، مشکل مدل Agile چیست؟

چیزی که Agile  در نظر نمی‌گرفت همین فرایندهای عملیات (Opera‌tion)  و چالش های مرتبط با آن بود چون با مدل Agile برنامه نویسان تمایل داشتند سریع‌تر نسخه دهند و تست کنند در مقابلش تیم عملیات این حجم از تغییر را دوست نداشتند چون ممکن بود روی سروری که در دسترس بود و در حال کار بوده با اضافه شدن یک قابلیت جدید و بروزرسانی محصول، یک سری موارد از کار بیفتد یا باری که روی سرور هست تغییر کند و مشکلاتی رو به‌وجود آورد، حتی گاهی از دسترس خارج شدن سرویس ممکن است باعث شود تیم عملیات تا دیر‌وقت در محل کار بمانند و زمانی را برای از دسترس خارج کردن سرویس جهت بررسی و برطرف کردن مشکل اخذ کنند. این موارد گاهی اوقات چابکی که در مدل Agile  مد نظر بود را هم نقض می‌کرد. همین مسئله باعث به‌وجود آمدن دیواری به نام Wall of confusion،  بین تیم‌های تولید نرم‌افزار و تیم عملیات شد.

تضادی در میان است

از طرف دیگر گاهی اوقات همکاران عملیات قصد داشتند تغییری را اعمال کنند مثلا اینکه یک سری سرویس‌ها از یک دیتاسنتر و زیر‌ساخت، به یک زیر ساخت دیگر منتقل شود. در این تغییر ممکن بود اپلیکشن درست کار نکند‌، حالا تیم تولید اعلام می‌کرد که چون اپلیکیشن روی محیط قبلی کار می‌کرد حتما سرور جدید مشکل دارد، تیم عملیات هم نمی‌پذیرفت و می‌گفت سرور مشکلی ندارد و به‌درستی کانفیگ شده است، کد شما مشکل دارد و در زیر‌ساخت به روزرسانی دچار خطا شده است و خلاصه هدف Agile که قرار بود به‌وسیله آن با سرعت و چابکی بیشتری این فرایند‌ها انجام شود‌، به‌درستی محقق نمی‌شد. اینجا بود که دواپس شکل گرفت تا این مشکلات را برطرف کند و می‌توان گفت پیوندی بین Develop و Operation شکل گرفت و حاصل آن شد DevOps. بزرگان صنعت توسعه نرم‌افزار و شبکه، به این نتیجه رسیدند که باید تیمی باشد که هم دانش SysAdmin بداند، هم مباحث شبکه را به خوبی بشناسد، هم با برنامه‌نویسی آشنایی داشته باشد از طرفی تیم عملیات که به هر حال برنامه‌نویس اپلیکیشن نبوده، پس طبیعی به نظر می‌رسد اگر زمان مواجه با خطا، به‌درستی تشخیص ندهد که مشکل دقیقا چیست پس گفتند ما به عنوان تیم دواپس با دید و با ابزارهایی که داریم، بستری برای برنامه‌نویسان ایجاد می‌کنیم تا کسی که تولید نرم‌افزار را انجام داده و به خطاهای آن علم دارد، بتواند شرایط را ببینید و به سرعت خطا را برطرف کند نه کسی که تخصصش عملیات است و گاها ممکن است از آن بیزینس به طور کامل مطلع نباشد. پس تیم دواپس یک سری Tools در اختیار تیم تولید و توسعه قرار می‌هد، تا بتوانند ببینیند کد در محیط عملیاتی چگونه اجرا می شود.
پس شاید در وهله اول به نظر برسد DevOps = Develop + Operation هست اما در عمل فقط این نیست، دواپس در اصل یک فرهنگ کاری است که فقط به تیم دواپس منتهی نمی‌شود، این فرهنگ باید در تیم‌های مختلف اجرا شود که در نهایت بتوانیم بگوییم یک مجموعه‌ای ساختار دواپسی دارد. حتی در تیم برنامه‌نویس و توسعه دهندگان هم باید تغییراتی در جهت دواپسی شدن انجام گردد مثلا مهاجرت به سمت ساختارهای مایکروسرویسی.

در مدل دواپس کارها چگونه انجام می شود؟

بهتر است نگاهی به شکل زیر بندازیم:

این حلقه از برنامه (Plan) شروع شده و به مانیتور ختم می شود. بیایید فرض کنیم از سمت کارفرما درخواستی مبنی‌بر اضافه کردن یک قابلیت جدید به ما داده میشود، طبیعتا در گام اول نیازسنجی‌هایی را انجام می‌دهیم و برای انجام کار برنامه‌ریزی می‌کنیم. در اینجا ابزارهایی که به طور کلی بتوانیم به‌وسیله آن برنامه‌ریزی کنیم مثلا جیرا قابل بهره‌برداری هستند. در مرحله  بعد بر اساس برنامه‌ای (Plan) که در قسمت قبلی چیده ایم، کد را تولید می‌کنیم و به خروجی می‌رسیم و خروجی را در یک مخزن نگهداری کد (code repository ) نگهداری می‌کنیم. مثلا GitLab و…حالا برای بیلد‌کردن کدی که نوشتیم می‌توان از ابزارهای مختلف استفاده کرد مثل Maven یا مثلا اگه پروژه در بستر داکر بود‌، خود داکر می‌تواند نقش ابزار بیلدمان را بازی کند و به طور کلی هر ابزاری که این کد را بتوانیم بر اساس آن بیلد کنیم. بعد از اینکه کد بیلد شد‌، نیاز داریم تستش کنیم مثلا می‌توانیم از سلنیوم استفاده کنیم. پس از پاس شدن تست‌ها، می‌رسیم به یک ریلیز یا نسخه نهایی که نیاز به مستقر شدن (Deploy) دارد، یعنی طبیعتا روی یک سروری باید راه‌اندازی شود، برای قسمت عملیات و استقرار (Deploy و Operation) می‌توانیم از ابزارهای مدیریت پیکربندی Configuration manager‌های مختلف استفاده کنیم. مثلا Ansible در نهایت بعد از اینکه کد ما مستقر (Deploy) شد نیاز داریم که تک‌تک اجزای برنامه و کامپوننت‌های اپلیکیشن و سیستم‌عامل و به طور کلی هر چیزی که روی اپلیکیشن تاثیر می گذارد را مانیتور کنیم مثلا با ابزار Zabbix. حالا می‌توانیم به تفاوت‌ مدل DevOps با مدل Agile پی ببریم. در مدل دواپس با هر تغییری کد ما آماده مستقر شدن و Deploy کردن سمت سرور هست اما Agile به این صورت نیست و خروجی کار در آخر اسپرینت و بازه مشخص قابل مستقر شدن (Deploy کردن) است. همه توضیحات بالا و مقایسه روش‌ها و معرفی ابزارها می‌تواند ما را با تعریف دواپس تا حدودی آشنا کند اما اصلا و ابد کافی نیست .باید این را بدانیم که در واقع دواپس نه یک شغل ، نه یک موقعیت یا پوزیشن ، نه یک ابزار ، نه یک تکنولوژی هست… بلکه دواپس در اصل یک فرهنگ است. فرهنگی برای توسعه بهتر و سریعتر نرم افزارها و اجرای سریع آن‌ها در محیط عملیاتی، با وجود این فرهنگ مراحل توسعه نرم‌افزار به مراحل استقرار نرم‌افزار در سرورها نزدیکتر می‌شود و چرخه‌ای را ایجاد می‌کند که توسعه تا تحویل نرم افزار سریع تر و با کیفیت بالاتر اتفاق بیافتد .یک مثالی هست که میگه مهندس عمران ، کارهای عمرانی رو انجام می دهد، مهندس برق، کارها ی مرتبط با رشته ی برق رو انجام می دهد، مهندس کامپیوتر برنامه‌نویس، برنامه می‌نویسد اما مهندس دواپس چه کاری انجام می دهد؟ در واقع اینکه فکر کنیم DevOps فقط یادگیری یک سری ابزار است، درست نیست واقعا…

آنچه یک مهندس DevOps نیاز دارد

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

• مهارت‌های ارتباطی و تعامل با افراد
• شناخت بیزینس و محصول
• توانایی‌ حل مسئله و تحلیل شرایط
• توانایی استفاده از ابزارهای آی‌تی و توسعه و خودکارسازی عملیات و فرایندها
• درک اهمیت امنیت و پایداری
• آشنایی با زبان‌های برنامه‌نویسی و کد نویسی
• مهارت درک نیازهای سازمان و مشتریان

منابع:

https://aws.amazon.com/devops/what-is-devops

https://www.scrum.org