بخش عمده‌ای از فضای فناوری اطلاعات در ایران، همانند سایر کشورهای جهان تحت تاثیر عبارات و کلمات دهان‌پرکنی است که به یک استاندارد، چارچوب و یا یک مفهوم تازه متولد شده اشاره دارد. نکته حائز اهمیت در این تاثیرپذیری طول عمر کوتاه آن و حرکت به سمت یک مفهوم و یا فناوری تازه از راه رسیده دیگر در مدت زمانی بسیار کوتاه است. بطور حتم بخش عمده‌ای از این تلاطم و این‌سو و آن‌سو رفتن‌ها ناشی از ذات فناوری اطلاعات و پویای بسیار شدید آن است؛ اما مشکل از آنجایی آغاز می‌شود که عمده شرکت‌ها و سازمانها بدون درک صحیح و تحلیل مناسب در رابطه با ضرورت استفاده از یک استاندارد، چارچوب و یا مفهوم جدید، همراه با این موج‌های زودگذر به این‌سو و آن‌سو در حرکت هستند و منابع با ارزش خود را (زمان، پول، توان نیروی انسانی و …) بدون عایدی مناسبی در این مسیر هدر می‌دهند.
واژه DevOps یکی از این واژه‌های نسبتا تازه وارد به فضای فناوری اطلاعات ایران است. واژه‌ای که عمده شناخت متخصصین فناوری اطلاعات از آن، به اینجا ختم می‌شود که ترکیبی از دو کلمه Development (توسعه) و Operation (عملیات) است. حال تصور کنید که با همین سطح از شناخت، پروژه‌های متعددی در سازمان‌های کوچک و بزرگ شکل‌گرفته و یا در حال شکل‌گیری است. هدف اصلی این نوشته کمک به ایجاد یک شناخت کلی نسبت به این جنبش در سطح دنیاست، تا شرکت‌ها و سازمان‌هایی که تمایل به سرمایه‌گذاری در این حوزه را دارند بتوانند با اشراف اطلاعاتی بیشتر و دید بازتری نسبت به این حوزه تصمیم‌گیری و برنامه‌ریزی کنند.
همانطور که قبل‌تر اشاره شد واژه DevOps ترکیبی از دو کلمه Development و Operation است. اما برای درک بهتر ضرورت قرارگیری این دو کلمه در کنار هم و ایجاد یک ترکیب جدید، بهتر است تا موضوع را کمی ریشه‌ای تر بررسی کنیم. نکته کلیدی در رابطه با واژه DevOps این است که DevOps یک استاندارد، چارچوب، متدولوژی، عنوان شغلی و … نیست. بلکه یک رویکرد نوین نسبت به مدیریت فضای فناوری اطلاعات و چالش‌های موجود در آن است. رویکردی که میتوان آن را به عنوان یک جنبش با عمری بیشتر از ده سال و در راستای پاسخ به یک سوال ریشه‌ای طبقه‌بندی کرد: چگونه میتوانیم یک مجموعه فناوری اطلاعاتی با عملکردی برتر داشته باشیم؟ بطور مثال اگر تولید کننده نرم‌افزار هستیم، چگونه میتوانیم فواصل زمانی مابین ویرایش‌ها و نسخ نرم‌افزارهای تولیدشده‌مان را کوتاه کرده و انتشارهای بیشتری از محصولاتمان ارائه کنیم؟ علیرغم اینکه پاسخ به این پرسش‌ها میتواند بسیار سخت و پیچیده به نظر بیاید، اما یک پاسخ بسیار ساده و منطقی نیز برای آن در دسترس است و آن پاسخ چیزی نیست جز: با اصلاح و حذف آن چیزهایی که مانع تحقق چنین شرایطی میشوند. به همین سادگی!
چگونه میتوانیم یک مجموعه فناوری اطلاعاتی با عملکردی برتر داشته باشیم؟ با اصلاح و حذف آن چیزهایی که مانع تحقق چنین شرایطی میشوند. به همین سادگی!
با این نوع نگاه به مسئله، هر سازمان اکنون میتواند متناسب با شرایط داخلی خود، DevOps را تعریف کرده و برای حرکت به سمت شرایط ایده‌آل برنامه‌ریزی کند.
همانطور که در بخش قبل هم به این پرسش اشاره شد، پاسخ بسیار ساده است، می‌بایست عواملی که عکس این نتیجه را رقم میزنند شناسایی و از مسیر خود حذف کنیم. احتمالا اگر بخواهیم چنین مواردی را شناسایی کنیم با یک لیست بلند در هر سازمان مواجه خواهیم شد، اما در ادامه نگاهی مختصر به برخی از رایج‌ترین و موثرترین این عوامل خواهیم انداخت.
ساختار سازمانی و نحوه تقسیم‌بندی وظایف افراد در سازمان همواره یکی از عوامل موثر در اتلاف زمان و کاهش بهره‌وری در سازمان محسوب می‌شود. در اغلب سازمانها، افراد بر حسب تخصص و نوع فعالیت‌شان دسته‌بندی شده‌اند. به عنوان مثال در یک سازمان که تولید کننده سامانه‌های نرم‌افزاری‌ست افراد به این شکل و مطابق با گام‌های مورد نیاز تقسیم‌بندی شده‌اند: تیم تحلیل، تیم طراحی، تیم توسعه، تیم تست، تیم استقرار و …؛ که خود، یکی از عوامل ریشه‌ای مشکل مورد بررسی است. برای درک بهتر مشکل، تصور کنید که مدت زمان انجام هر یک از فعالیتها (نظیر تحلیل، طراحی و …) پنج روز است و در مجموع هم، همان پنج فعالیتی که قبل‌تر به عنوان اسامی تیم‌ها ذکر شد برای تولید و ارائه یک سامانه نرم افزاری مورد نیاز است. با این اطلاعات، فکر میکنید مدت زمان مورد نیاز جهت ارائه یک قابلیت جدید در سامانه نرم‌افزاری مورد نظر چند روز است؟
در شرایط کلی انتظار می‌رود که این مدت ۲۵ روز باشد. پنج مرحله که هر کدام پنج روز زمان می‌برد و در نتیجه به نظر می‌رسد که ۲۵ روز برای انجام این فعالیتها کفایت کند. اما در واقعیت این ۲۵ روز تنها به زمان مفید و قطعی مورد نیاز اشاره دارد و در شرایط واقعی می‌بایست زمان‌های غیر مفید نظیر انتظارهای بین هر مرحله، هماهنگی‌های لازم و … را نیز مد نظر قرار داد. آیا تیم طراحی بلافاصله پس از دریافت مستندات تولید شده توسط تیم تحلیل، دست به کار میشوند؟ تیم توسعه چطور؟ آیا تیم استقرار، زیرساخت مناسب جهت استقرار نرم‌افزار تولید شده را در اختیار دارد و بلافاصله پس از دریافت نسخه اجرایی نرم‌افزار نسبت به استقرار و راه‌اندازی آن اقدام خواهد کرد؟ بطور حتم هیچ کدام از این مراحل این چنین نخواهد بود و این ۲۵ روز ممکن است با اضافه شدن زمان‌های غیر مفید، در بازه زمانی مثلا ۶۰ روز و یا حتی بیشتر به نتیجه برسد.
حال بماند که همین شرایط باعث می‌شود تا در نهایت یک پاسخگوی متمرکز و نهایی هم وجود نداشته باشد و در صورت بروز مشکل، هر تیم مسئولیت بروز آن را بر دوش دیگری خواهد انداخت.
پس بطور حتم میتوان انتظار داشت که حرکت به سمت شرایط آرمانی مورد انتظار از DevOps نیازمند اعمال اصلاحات بنیادین در ساختار و نحوه دسته‌بندی افراد در سطح سازمان و همچنین ایجاد تحول در فرهنگ جاری سازمانی خواهد بود. این تغییر در ساختار و شرح وظایف، بصورت سمبلیک با کنار هم قرار گرفتن دو واژه Development و Operation در کنار یکدیگر و خلق واژه DevOps به تصویر کشیده می‌شود.
وجود یا عدم وجود فرآیندهای سازمانی مستند شده و در حال اجرا، هر کدام گرفتاری‌های خود را برای سازمان به همراه خواهد داشت. از یکسو عدم وجود فرآیندهای سازمانی، ایجاد کننده بی‌نظمی و اعمال سلایق شخصی در طول کار خواهد بود و از سوی دیگر بسیاری از فرآیندهای سازمانی هم به دلیل عدم توجه به اصل چابکی، مسبب بروز کندی و وقفه‌های بعضا طولانی مدت در طی مسیر یک فعالیت هستند.
تصور کنید که می‌بایست بر اساس فرآیند از پیش تعریف شده مدیریت تغییر، برای انجام هر تغییر (به عنوان مثال افزودن یک قابلیت جدید در سامانه نرم‌افزاری) از کمیته‌ای که به این منظور تشکیل شده مجوز بگیرید و این در حالی است که این کمیته تنها هفته‌ای یکبار تشکیل جلسه می‌دهد! این شرایط به این معنی خواهد بود که شما در اغلب حالت‌های ممکن می‌بایست وقفه‌ای در حدود یک هفته را برای انجام ساده‌ترین تغییرات که ممکن است تنها به یک ساعت زمان نیاز داشته باشد را پیش‌بینی کنید.
میتوان از زوایای دیگری نیز به این مسئله پرداخت. آیا می‌توانید تصور کنید، سازمانی که برای تولید محصولات خود از روش آبشاری (Waterfall) استفاده می‌کند بتواند در طول یک هفته، چندین نسخه جدید از محصول خود به مشتری ارائه کند؟ بطور حتم نه! چرا که در این رویکرد، مراحل تولید یک محصول در قالب فرآیندهای مستقل پیش‌بینی شده و تنها در صورتی میتوان به مرحله بعدی وارد شد، که مرحله جاری بصورت کامل به اتمام رسیده باشد. به عنوان مثال تا زمانیکه فرآیند تحلیل محصول تمام نشده باشد نمی‌توان به مرحله طراحی وارد شد و یا زمانیکه مرحله طراحی بصورت کامل تمام نشده باشد نمی‌توان به مرحله توسعه وارد شد. پس بطور حتم لازم است تا چنانچه می‌خواهیم سرعت انتشار نسخ محصولاتمان را افزایش دهیم، در رابطه با رویکرد مورد استفاده در توسعه محصولات نیز تجدید نظر کنیم و به عنوان مثال از رویکردهای چابک (Agile) نظیر اسکرام (SCRUM) استفاده کنیم.
آیا معماری نرم‌افزار یا همان محصولی که در حال کار بر روی آن هستیم هم در سرعت عمل و چابکی ما موثر است؟ بطور حتم پاسخ مثبت است. تصور کنید که در حال کار بر روی یک محصول بزرگ و پیچیده هستید. پیچیدگی و وابستگی‌های متعدد اجزاء مختلف سبب خواهد شد که انجام تغییرات با ریسک و پیچیدگی بسیار زیادی همراه باشد. توسعه در هر بخش، میتواند باعث بروز اختلال در عملکرد سایر بخشها باشد و همین امر سبب می‌شود تا فرآیند توسعه با کندی‌های غیر قابل کنترل و متعددی همراه باشد. همچنین این پیچیدگی‌ها و وابستگی‌ها میتواند در کنار تاثیر منفی بر روی توسعه محصول، بر روی سایر فعالیت‌های وابسته نیز نظیر تست، استقرار، پیکربندی و … نیز تاثیر مستقیم منفی داشته باشد.
آیا معماری نرم‌افزار یا همان محصولی که در حال کار بر روی آن هستیم هم در سرعت عمل و چابکی ما موثر است؟ بطور حتم پاسخ مثبت است.
هر چه محصول بزرگتر و پیچیده‌تر باشد بطور حتم، استقرار و پیکربندی آن نیز بر روی بستر لازم پیچیده‌تر و زمان‌بر تر خواهد بود. پس چنانچه شما قصد داشته باشید برای سرعت بخشیدن به فعالیتها و حرکت به سمت آنچه DevOps نامیده می‌شود گام بردارید، می‌بایست در راستای ساده‌سازی و شکست ساختار محصول خود نیز اقداماتی جدی را در دستور کار داشته باشید. به عنوان مثال حرکت به سمت معماری مایکروسرویس یکی از رویکردهای شناخته شده برای تحقق همین مهم است.
میتوان از بسترها و زیرساخت‌های مورد استفاده، به عنوان یکی دیگر از عواملی که می‌توانند باعث بروز کندی و وقفه در چرخه تولید و ارائه یک محصول باشند، نام برد. به عنوان مثال پیچیدگی‌های مرتبط با پیکربندی و راه‌اندازی یک سرور و تبعات ناشی از بروز مشکل در این حوزه بر کسی پوشیده نیست، پس شاید لازم باشد تا اگر به دنبال سرعت بخشیدن به چرخه ارائه محصول خود هستید، بکارگیری راهکارهای جایگزین را در دستور کار قرار دهید.
استفاده از کانتینرهایی (Container) مانند داکر (Docker) یکی از رویکردهای مدرن در مسیر سرعت بخشیدن و ساده‌سازی فعالیت‌های مرتبط با استقرار یک محصول در محیط‌های مختلف توسعه، تست و یا عملیاتی است.
بر کسی پوشیده نیست که انجام دستی بسیاری از فعالیتها، در کنار پیچیدگی و زمان‌بر بودنشان، حداقل به دلیل تکرار بالا، از محبوبیت حداقلی در بین کارشناسان فناوری اطلاعات برخوردار است. تصور کنید که شما در سازمانتان به آن شرایط ایده‌آل رسیده‌اید و مثلا می‌توانید هر روز نسخه جدیدی از محصول خود را ارائه کنید. اما آیا گمان میکنید که افراد درگیر با فرآیند استقرار و پیکربندی حاضر هستند هر روز رویه مربوط به نصب و راه‌اندازی نسخه جدید را به صورت دستی و تکراری انجام دهند؟ اگر بازه‌های زمانی انتشار نسخه به روزی ۲ یا ۳ بار رسید چطور؟
میتوان مطمئن بود که در بسیاری از موارد حتی اگر کارشناس مربوطه حاضر باشد که هر روز عملیات مربوط به استقرار نسخه جدید و پیکربندی مثلا ۱۰ سرور مرتبط را هم انجام دهد، محدودیت زمانی و فشارهای متعدد باعث بروز خطاهای انسانی پرتکرار خواهد بود و این شتاب بالا در ارائه نسخه جدید، در نهایت جز تاثیرات منفی، برای سازمان عایدی دیگری را به همراه نخواهد داشت.
اگر شما کارشناس استقرار بودید، آیا حاضر می‌شدید تا در طول یکروز ۱۰ بار نسخه نصب شده از یک نرم‌افزار برروی مجموعه‌ای از سرورها را بروزرسانی کنید؟
پس بطور حتم لازم است تا در این رابطه از روش‌ها و ابزارهای خودکارسازی در حوزه‌های مختلف، از تست گرفته تا پیکربندی استفاده نمود. ابزارهایی مانند Azure DevOps، Jenkins و … از شناخته‌شده‌ترین ابزارهای این حوزه محسوب میشوند.
در جمعبندی این نوشته تنها کافیست سوال آغازین و پاسخ آن را یادآوری کنیم. توجه داشته باشید که DevOps مفهوم و رویکردی چندان خارق‌العاده و عجیب نیست؛ بلکه نگاهی کل‌نگر به مشکلات موجود در سطح سازمانها و فرصتهای بهبودی است که میتوان بصورت مرحله‌ای و تدریجی برروی آنها سرمایه‌گذاری نمود. مشکل اصلی در سازمانها عدم توجه به این مقوله با نگاهی کل‌نگر و تنها تمرکز جزئی و بر روی یکی از چندین مورد اشاره شده در این نوشته است. بطور حتم برنامه‌ریزی در تمامی مواردی که در این نوشته مورد اشاره قرار گرفت میتواند برای سازمانها مفید باشد اما تجمیع آنها کنار هم میتواند تحولی شگرف را در سازمان ایجاد کند. به عنوان مثال حرکت به سمت سامانه‌هایی نظیر Jenkins یا Microsoft Azure DevOps بطور حتم میتواند برای سازمان مفید باشد، اما تا زمانیکه الگوی مورد استفاده در تیم توسعه محصول، چابک نباشد و یا معماری محصول، یک معماری مناسب نباشد، راه‌اندازی چنین سامانه‌هایی فاقد ارزش افزوده چندانی است.
در پایان، با ارائه پاسخ به مجموعه‌ای از سئوالات رایج در حوزه DevOps، به جمعبندی این نوشته خواهیم پرداخت:
