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

دوآپس و تصورات اشتباه درباره آن | DevOps Misundrestandings

تصورات اشتباه و کج فهمی ها درباره دوآپس ( DevOps )

دنیای فناوری اطلاعات با سرعت و شتاب زیادی در حال تغییر است و هر روز واژه های جدیدی در حال شکل گرفتن است، با این وجود شاید عجیب نباشد که درک های نادرست و کج فهمی هایی از این واژه ها ایجاد شود. واژه DevOps / دوآپس  (که اولین بار در کنفرانس Agile 2008 مطرح شد) هم از این قاعده مستثنی نبوده. از این رو سوالات زیادی درباره اینکه واقعا دوآپس چیست مطرح می شود. در این مطلب سعی کردم به طور خلاصه به برخی از تصورات اشتباه درباره DevOps بپردازم. در پست های آینده، به طور مفصل تری به “انواع روش های اشتباه اجرا و استقرار دوآپس در سازمان ها” خواهم پرداخت.

DevOps چیست ؟

بیشتر از آنکه روی پاسخ سوال “DevOps چیست ؟” توافق وجود داشته باشد، روی سوال “DevOps چه نیست ؟” وجود دارد. در ادامه بیشتر به این مطلب خواهم پرداخت
در ادامه مطالب زیر را خواهید خواند:


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

اشتباه بزرگ و رایجی که وجود دارد این است که تصور شود جنبش دوآپس کلا درباره ی خودکارسازی همه چیز با یک سری ابزار و تکنولوژی است. (مثل Docker, Ansible, Kubernetes, Team Foundation ). بسیاری بیان می کنند که ما در سازمان خودمان، دوآپس داریم آن را اجرا کردیم. وقتی که می پرسیم چطور آن را اجرا کردید، متوجه می شویم که از واقعیت دور هستند و فقط بخش کوچکی از آن را اجرا کرده اند. (معمولا پاسخ ها به مسائلی بیش از Automation و Continuous Delivery ختم نمی شود).

DevOps CD CI Agile چیست

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

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

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

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

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

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

در آخر به این موضوع هم اشاره کنم این جمله هم اشتباه است که بگوییم “هیچ ابزاری نباید به نام ابزار دوآپس معرفی شود”. آیا poker planning در Agile به این معنی است که انجام آن باعث چابک شدن شما می شود ؟ خیر. اما این یک ابزار مشترک در بسیاری از روش های چابک است، پس می توانیم از آن به عنوان یک “ابزار چابک” نام ببریم. به طور مشابه به این دلیل که نمی توان دوآپس را فقط مجموعه ای از ابزار دانست، نمی توان گفت که ابزارهایی که برای اجرای آن ساخته می شوند، “ابزار دوآپس” نیستند.

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

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

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

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

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

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

البته من مخالف این موضوع نیستم که کسی نباید از واژه ی دوآپس در عناوین شغلی استفاده کند. معمولا استفاده از این واژه برای تمایز بین دو تفکر است، یکی “تفکر به روش دوآپس، تاکید بر خودکارسازی، همکاری توسعه و عملیات، اجرای CI و …” و دیگری  “تفکر کسانی که در اتاق خودشان نشسته اند و اهمیتی نمی دهند که در بیرون از اتاق چه اتفاقی می افتد و منافع سازمان در چیست”.

دوآپس یک تیم نیست

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

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

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

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

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





Share Button

Continuous Delivery چیست ؟

Continuous Delivery چیست

Continuous Delivery یا (CD)، رویکردی در مهندسی نرم افزار است که تیم ها را قادر می سازد نرم افزار تولید شده را به روشی سریع و مطمئن برای انتشار و تحویل آماده کنند. این فرایند از لحظه اضافه شدن یا تغییر کد در source control شروع می شود و شامل بیلد، تست، پیکربندی و انتشار در محیط های مختلف تست و محیط عملیات می شود. این مفهوم در فارسی به “تحویل مداوم” یا “تحویل مستمر” ترجمه شده است.

به عبارت دیگر: Continuous Delivery توانایی اعمال تغییرات در محیط عملیات در هر لحظه با روشی سریع و مطمئن و به طور کاملا پایدار می باشد. این تغییرات شامل همه انواع آن از جمله تغییرات پیکربندی در نرم افزار، زیرساخت و پلتفرم، افرودن ویژگی های جدید، رفع باگ و خطا ها می شود.

به وسیله محیط های تست مختلف، می توان یک Release Pipeline ایجاد کرد تا بتوان یک زیرساخت جدید را به طور اتوماتیک ایجاد کرد و نرم افزار را روی آن منتشر کرد. منظور از زیرساخت، سرور، سیستم عامل، سرویس دهنده ی وب، virtualization، شبکه و پیکربندی و تنظیمات آنها می باشد. به کمک این محیط های متوالی می توان فعالیت های طولانی Integration، تست عملکرد و تست های پذیرش نهایی را به تدریج انجام داد. فرایند Continuous Delivery در Release Pipeline با Continuous Integration شروع میشود و با انتشار و پایان تست در هر محیط، انتشار و تست در مرحله بعدی شروع می شود. مجموع این کارها به صورت حلقه های یک زنجیر در پشت سر هم قرار گرفته و فرایند Continuous Delivery را تشکیل می دهند.

ContinuousDelivery Process چیست

هدف Continuous Delivery چیست ؟

هدف CD این است که که انتشار و تحویل نرم افزار را به خصوص برای سیستم های توزیع شده در مقیاس بسیار بزرگ و محیط های عملیاتی پیچیده به یک فرایند روتین، ساده و قابل پیش بینی تبدیل کند. رسیدن به این هدف تنها در صورتی امکان پذیر است که کدهای نرم افزار همیشه در وضعیت آماده برای انتشار باشند، حتی در شرایطی که یک تیم با هزاران توسعه دهنده به طور روزانه در حال تغییر و به روزرسانی کد ها و نرم افزار هستند. به این ترتیب روش سنتی فازهای ادغام (Integration)، تست، پیکربندی و Hardening جای خود را به روش های اتوماتیک می دهد. همچنین زمان آماده شدن برای انتشار، زمان مهاجرت به محیطهای دیگر (Time to Remediate) و زمان برطرف کردن رخداد در محیط عملیات را کاهش (Time To Mitigate or time to remediate production incidents) می دهد.

تفاوت Continuous Delivery و Continuous Deployment چیست ؟

بسیاری از مواقع دو مفهوم Continuous Delivery و Continuous Deployment به اشتباه به جای هم استفاده می شوند اما تقاوت این دو چیست ؟ Continuous Deployment به این معنی است که هر تغییر در نرم افزار به طور اتوماتیک (یا بر طبق یک زمان بندی مشخص) در محیط عملیات منتشر شود. اما Continuous Delivery به این معنی است که هر تغییر در نرم افزار، آماده انتشار در هر محیطی باشد اما ممکن است تصمیم این باشد که منتشر نشود (معمولا به دلایل کسب و کاری). این محیط ها شامل محیط تست تیم توسعه، محیط تست تیم کنترل کیفیت و محیط عملیات و هر محیط دیگری می شود.

تفاوت Continuous Delivery و دواپس چیست ؟

این دو مفهوم از جهاتی به هم نزدیک هستند و اما تفاوت های بنیادی با هم دارند. دامنه ی DevOps بسیار گسترده تر از CD است و علاوه بر خودکارسازی فرایند تحویل نرم افزار، شامل تغییرات فرهنگی به خصوص ارتباط بین تیم های مختلفی که در جریان آماده سازی و تحویل محصول نرم افزاری (Software Delivery) هستند هم می شود. (از جمله تیم های توسعه، عملیات، تضمین کیفیت، مدیریت و … ) اما Continuous Delivery روشی است برای اتوماتیک سازی زنجیره تحویل محصول و بر این موضوع تمرکز دارد که فرایند های مرتبط در کنار هم طوری اجرا شود که منجر شود محصول نرم افزاری، سریعتر، امن تر و با تکرار بیشتری به دست مشتری برسد.

DevOps CD CI Agile چیست

در نبود Continuous Delivery …

در نبود CD، انتشار نرم افزار یک bottleneck برای تیم های “عملیات فناوری اطلاعات” و در نهایت برای محصول است. فرایند دستی و غیر اتوماتیک، باعث انتشارهای غیر قابل اتکا، با تاخیر و پر از خطا می شود. تیم های درگیر این موضوع معمولا به کارهای دستی که افراد انجام می دهند تکیه می کنند که باعث مشکلات جدی خواهد شد.

حداقل الزامات اجرای Continuous Delivery

برای راه اندازی و اجرای Continuous Delivery الزاماتی وجود دارد که در کمترین حالت می توان از دو مورد زیر نام برد

  • زیربنایی از تست ها که تا حد قابل قبولی خیال شما را از اینکه نرم افزار به درستی کار می کند، راحت کند و به شما اعتماد به نفس لازم را برای شروع استقرار بدهد
  • ابزارهای خودکارسازی (automation) و اسکریپت های لازم که به شما اطمینان دهد استقرار با موفقیت انجام خواهد شد و در صورت نیاز امکان Rollback وجود خواهد داشت

سخن آخر

در آخر باید این این نکته را اضافه کنم که فرایند Continuous Delivery و Infrastructure as Code و Monitoring به طور قابل ملاحظه ای مکمل یکدیگر هستند. Continuous Delivery برای کنترل تاثیر تغییرات در محیط عملیاتی از استراتژی های استقرار از جمله Blue-Green Deployment و همچنین تکنیک Feature Flags (یا Feature Toggles) نیز پشتیبانی می کند. (در آینده راجع به استراتژی های انتشار مطلبی خواهم نوشت)
امروزه ارزش هایی که CD برای سازمان ها ایجاد می کند، آن را به یک نیاز ضروری تبدیل کرده است. برای رساندن ارزش به مشتریان نهایی، باید محصول را به طور پیوسته و بدون خطا منتشر کرد. Release Pipeline های پیشرفته به توسعه دهندگان اجازه می دهد که feature های جدید را سریع و مطمئن منتشر کنند. با کمک CD، رفع خطاها در محیط عملیات و اضافه کردن ویژگی های جدید بسیار سریع تر و با اطمینان بالا انجام خواهد شد و به دست مشتری خواهد رسید.

Share Button