تصورات اشتباه درباره دواپس (DevOps)تصورات اشتباه درباره دواپس (DevOps)

تصورات اشتباه درباره دواپس (DevOps)

نویسنده: امید شریعتی

دسته بندی: دواپس
10 دقیقه زمان مطالعه
۱۴۰۰/۰۴/۲۳
0 نظر
امتیاز 3.3 از 5

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

چه تصورات اشتباهی درباره دواپس وجود دارد؟

بیشتر از آن که روی پاسخ سوال «دواپس چیست؟» توافق وجود داشته باشد، روی سوال «دواپس چه نیست؟» توافق وجود دارد! مواردی که در ادامه بیان می‌کنیم، تا حدودی پاسخ سوال دوم را مشخص و تصورات اشتباه درباره دواپس را رفع می‌کند: 

دواپس فقط Automation و Continuous Delivery نیست.

یک تعریف اشتباه اما رایج در مورد دواپس این است: خودکارسازی همه چیز با یک سری ابزار و تکنولوژی مانند  Terraform، Ansible، Docker، Kubernetes، Azure DevOps و GitLab.

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

دواپس به معنی حذف عملیات نیست.

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

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

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

  • اعضای تیم عملیات خودکارسازی را توسعه دهند.
  • توسعه‌دهندگان برای «operation» کدنویسی کنند.
  • هر دو مورد

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

 

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

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

در چابک‌سازی تیم‌ها نیز مشابه این اتفاق رخ می‌دهد: اعضای گروه، کار کردن در قالب Iteration و اجرای سایر تمرین‌های چابک (Agile) را شروع می‌کنند بدون آن که همکاری معناداری با هم داشته باشند. بسیاری از تیم‌ها،  بعضی از روش‌ها و ابزارهای چابک را به کار می‌برند، بدون آن که به اصول چابک توجه کافی داشته باشند و طبیعتا به نتیجه ایده‌آل نمی‌رسند. مطمئنا ابزارهای چابک (و ابزارهای دواپس) می‌توانند مفید باشند به شرطی که روش صحیح استفاده از آن‌ها را بدانیم. استفاده نادرست از این ابزارها مانند استفاده از چاقوی جراحی برای بریدن هندوانه است! 

دقت داشته باشید که این جمله اشتباه است: «هیچ ابزاری نباید به نام ابزار دواپس معرفی شود.» آیا Poker Planning در Agile به این معنی است که انجام آن باعث چابک شدن شما می‌شود؟ خیر. اما این یک ابزار مشترک در بسیاری از روش‌های چابک است، پس می‌توانیم از آن به عنوان یک «ابزار چابک» نام ببریم. در مورد دواپس نیز وضعیت مشابه است: دواپس مجموعه‌ای از ابزار نیست اما نمی‌توان گفت ابزارهایی که برای اجرای آن ساخته می‌شوند، «ابزار دواپس» نیستند.

دواپس فقط یک فرهنگ نیست.

بسیاری از افراد اصرار دارند که بگویند «دواپس فقط یک فرهنگ است» و شما نمی‌توانید آن را با یک سری اصول و تمرین‌ها اعمال کنید اما این جمله هم درست نیست. Agile فقط به واسطه بعد فرهنگی‌اش به هزاران تیم کمک نکرده است بلکه اعضای تیم‌های چابک در کنار هم به‌روش‌هایی (Best Practice) را شناسایی کرده‌اند و ابزارهایی را به کار گرفته‌اند و آن‌ها را به اشتراک گذاشته‌اند. دواپس از به‌روش، ابزارها و به طور کلی آیتم‌هایی در سطوح مختلف تشکیل شده (و همچنان در حال کامل‌تر شدن است) و عمدتا بدون اجرای تمریناتی که حول آن به وجود آمده، بی‌فایده است.

دواپس فقط توسعه و عملیات نیست.

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

همان طور که در توسعه چابک، تمرکز بر ارتباط و همکاری بین کسب‌وکار (Business) و تیم توسعه (Development) است (Biz + Dev)، در دواپس تمرکز بر ارتباط و همکاری بین توسعه (Development) و عملیات (IT Operation) است اما تنها به این موارد محدود نمی‌شود. در نتیجه دواپس شامل تمام کسانی می شود که به نحوی در تحویل یک محصول یا سرویس مشارکت دارند. به همین منظور، اسامی مشابهی مانند DevSecOps, DevOpSec, SecOps, SecureDevOps یا BizDevSecOps مطرح می‌شود اما رویکرد و طرز تفکر دواپس همه این موارد را در بر می‌گیرد؛ درگیر عناوین نشوید.

دواپس فقط یک عنوان شغلی نیست.

به سادگی و با تغییر نام تیم عملیات (IT Operation) به تیم دواپس، هیچ چیز عوض نمی‌شود. با تعویض عنوان شغلی به مهندس دواپس (DevOps Engineer) هم چیزی عوض نمی‌شود. اگر ارزش‌ها و اصول دواپس را قبول نکنید (که نیازمند تغییرات در سطح کلی سازمان است و نه فقط تغییرات در یک بخش یا تیم)، نمی‌توانید از تمام مزایای آن بهره‌مند شوید.
البته ایرادی ندارد که کسی از واژه دواپس در عناوین شغلی استفاده کند. معمولا این واژه برای نشان دادن تمایز بین دو تفکر به کار می‌رود. یکی «تفکر به روش دواپس، تاکید بر خودکارسازی، همکاری توسعه و عملیات، اجرای CI و …» و دیگری «تفکر کسانی که در اتاق خودشان نشسته‌اند و اهمیتی نمی‌دهند که در بیرون از اتاق چه اتفاقی می‌افتد و منافع سازمان در چیست».

دواپس یک تیم نیست.

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

دواپس راجع به همه چیز و همه جا نیست

برخی از افراد با طرح یک ادعای بزرگ، به اشتباه مدعی می‌شوند که دواپس درباره «همه چیز و همه جا» است. دواپس با تفکرهای چابک (Agile) و ناب (Lean) آمیخته می‌شود و به عنوان فرصتی برای همکاری درون‌سازمانی استفاده به کار می‌رود اما واقعا همه چیز را در بر نمی‌گیرد. 

برخی از افراد به اشتباه دواپس را به یک نسخه کوچک از Agile و Lean یا فقط به یک علاقه‌مندی تبدیل می‌کنند (البته به عنوان یک چشم‌انداز خوب است) اما با دنبال کردن سلسله مراتب پیچیدگی‌ها، بیشتر به یکپارچگی عملیاتی (Operational Integration) می‌رسند و تلاش در سایر بخش‌ها امیدوارکننده نیست. همچنان مشکلات حل نشده‌ای در تحویل نرم‌افزار و نگهداری سرویس و همچنین سریعتر، قابل اعتمادتر و امن‌تر کردن آن باقی می‌ماند. این که فردی بخواهد با استفاده از آموزه‌های دواپس در محدوده (Scope) بزرگتری از سازمان به مشاوره بپردازد، خیلی هم عالی است اما معمولا افراد فنی درگیر دواپس هستند که می‌خواهند کار خودشان را بهبود ببخشند نه کار دیگران را!

به گفته ارنست مولر، دواپس را می‌توان «تحویل و عملیات چابک نرم‌افزار» (Agile Software Delivery and Operations) دانست که در آن افراد با همکاری یکدیگر روی ابتکارات سازمانی بزرگتر کار می‌کنند، بدون این که ارزش پیشنهادی اصلی خود را از یاد ببرند.

جمع‌بندی

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