در گذشته، بکارگیری زیرساخت‌ها و به‌روزرسانی اپلیکیشن‌ها، باعث کند شدن چرخه عمر آن‌ها می‌شد. امروز که تکنولوژی رایانش ابری به سازمان‌ها اجازه می‌دهد منابع را به جای چند ماه در چند دقیقه فراهم کنند، وقت آن رسیده که چرخه عمر اپلیکیشن‌ها هم به تناسب تغییر کند. در این زمینه، DevOps می‌تواند کمک کند، اما تنها در صورتی که فرا‌تر از تغییرات فرهنگی و گسترش مداوم حرکت کند.
DevOps (ترکیبی از دو کلمه Development به معنی توسعه و Operation به معنی عملیات)، روشی برای تولید نرم‌افزار است که بر ارتباطات، مشارکت و ادغام بین تولیدکنندگان نرم‌افزار و متخصصین IT تاکید می‌کند. در واقع، DevOps واکنشی به وابستگی متقابل تولید نرم‌افزار و عملیات IT است. هدف آن کمک به سازمان‌ها است تا بتوانند به سرعت محصولات و خدمات نرم‌افزاری تولید کنند.
واضح است که تکنولوژی رایانش ابری تغییرات بزرگی را در اپلیکیشن‌ها وارد و ممکن می‌سازد. برخی مقالات تاکنون بر تغییرات فنی که رایانش ابری بر ساختار اپلیکیشن‌ها تحمیل می‌کند، متمرکز بوده‌اند. این تغییرات همگی برای پشتیبانی از تغییرپذیری افزایش یافته مقیاس و بار، انتظار عملکرد بهتر و قیمت‌گذاری تغییریافته که رایانش ابری ایجاد می‌کند، طراحی شده‌اند.
اما چیزی که این مقالات به آن نپرداخته‌اند، فرضیه سنتی دیگری در مورد اپلیکیشن‌ها است که رایانش ابری در حال از بین بردن آن است: چرخه عمر اپلیکیشن. به طور خاص، تکنولوژی ابری نیازمند ریتم به شدت تندتری از مدیریت اپلیکیشن است که تغییر را در سازمان‌های IT اعمال می‌کند.
ظاهرا مشخص نیست چرا قابلیت فنی رایانش ابری در سازمان‌های IT و فرآیندهای کاری آن‌ها تحول ایجاد می‌کند. به هر حال، اتوماسیون که شالوده اصلی قابلیت فنی رایانش ابری است هم نیازمند تسریع چرخه عمر اپلیکیشن‌ها است.
رایانش ابری به سازمان مسوولیت می‌دهد، نه ساختارهای آن
DevOps (ترکیبی از دو کلمه Development به معنی توسعه و Operation به معنی عملیات)، روشی برای تولید نرم‌افزار است که بر ارتباطات، مشارکت و ادغام بین تولیدکنندگان نرم‌افزار و متخصصین IT تاکید می‌کند.
در گذشته – یعنی در واقع قبل از ظهور رایانش ابری – سرعت کند ساخت اپلیکیشن‌ها و از رده خارج شدن آن‌ها مساله چندان مهمی نبود. در فرآیند فراهم کردن زیرساخت منابع، اصطکاک زیادی وجود داشت، به طوری که افزایش سریع کاربردپذیری اپلیکیشن و به‌روزرسانی مداوم آن کار غیرممکنی بود. ایجاد، نصب و شکل‌دهی زیرساخت‌ها آنقدر طول می‌کشید که روند کند ایجاد و گسترش اپلیکیشن اصلا به عنوان بزرگ‌ترین مشکل صنعت IT به چشم نمی‌آمد. به عبارت دیگر، اصطکاک زیرساخت‌ها مهم‌تر از اصطکاک اپلیکیشن‌ها بود.
اکنون اتوماسیون رایانش ابری کل این اصطکاک زیرساختی را از بین برده است. امروز دستیابی به منابع جدید رایانشی در چند دقیقه، در مقایسه با گذشته که به دست آوردن منابع زیرساختی جدید چند هفته یا حتی چند ماه طول می‌کشید، کاری بسیار جزئی محسوب می‌شود. امروز واضح است که چارچوب‌های زمانی طولانی مدت برای تامین زیرساخت‌ها، به واسطه فرآیند سازمانی ایجاد می‌شوند، نه خود منبع زیرساخت.
همزمان، افزایش یکپارچگی اطلاعات دیجیتال با اطلاعات اصلی کسب‌وکار، بدین معنی است که عملیاتی کردن بخش‌هایی از تقاضای کسب‌وکار نیازمند دسترس‌پذیری سریع‌تر به کاربرد اپلیکیشن است. با از بین رفتن اصطکاک زیرساخت‌ها، مانع اصلی این موضوع، خود چرخه عمر اپلیکیشن است. در نتیجه، می‌توان انتظار داشت تغییر بعدی که رایانش ابری ایجاد خواهد کرد در فرآیند ایجاد و گسترش اپلیکیشن‌ها باشد. به بیان ساده‌تر، IT باید چرخه عمر اپلیکیشن را سریع‌تر کند.
این همان جایی است که DevOps وارد صحنه می‌شود؛ واژه‌ای که «توسعه» و «عملیات» را با هم دربرمی‌گیرد و نشان‌دهنده ترکیبی از سازمان‌ها و فرآیندهای مجزای گذشته است. دیدگاهی که در پس این کلمه قرار دارد، به سازمان‌های یکپارچه و کارآمدی مربوط می‌شود که روند به‌روزرسانی اپلیکیشن‌ها را از طریق یک فرآیند تلفیقی سرعت می‌بخشند و ایجاد تغییرات را به جای چند هفته یا چند ماه، در چند ساعت یا چند روز ممکن می‌کنند. اما این DevOps جادویی چگونه اتفاق می‌افتد؟
تغییر فرهنگ لازم است، اما کافی نیست
یک راه حل این موضوع تغییر فرهنگی است که اغلب جدی گرفته نمی‌شود. بر این اساس، همکاری تولیدکنندگان اپلیکیشن و مسوولین شبکه در قالب تیم‌های مشترک، مشارکت را توسعه می‌بخشد و چرخه عمر اپلیکیشن را تسریع می‌کند.
البته این رویکرد مخالفانی هم دارد. مطمئنا بین توسعه و عملیات اغلب اصطکاک وجود دارد و عضو بودن در چنین تیمی بدون شک روابط شخصی را توسعه می‌دهد. این رویکرد به طور فزاینده‌ای وضعیت فعلی را از طریق تقویت همکاری‌ها و کمتر کردن سرزنش‌ها ارتقا می‌بخشد. به هر حال، دقیقا مشخص نیست که تعامل شخصی بهتر بتواند کاربردپذیری اپلیکیشن و چرخه عمر آن را به میزان قابل توجهی سرعت ببخشد.
در هر صورت، این افزایش ناکافی است. کسب‌وکار‌ها نمی‌توانند با ۲۰ درصد کاربردپذیری سریع‌تر، در محیط کسبوکارهای دیجیتال آینده که با آن مواجه می‌شوند، موفق باشند. شاید تنها موفقیت آن‌ها این باشد که پروژه‌های ۲۱ روزه را به ۱۸ روز یا به طور متداول‌تر، پروژه‌های شش ماهه را به پنج ماه کاهش دهند. کسبوکارهای امروز بدون اغراق به افزایش سرعت ۲۰۰ درصدی نیازمندند.
اما در این صورت، مساله تغییر فرهنگ راه غلطی را می‌پیماید، چون به جای اینکه بر فرآیند متمرکز شود، بر افراد تمرکز می‌کند و به این ترتیب، این فرآیند است که از بین می‌رود. به علاوه، فرآیند سریع‌تر باید از طریق چرخه عمر اپلیکیشن گسترش یابد.
این یعنی ما در مهندسی نرم‌افزار به پیشرفت بیشتری دست یافته‌ایم. اقدامات توسعه‌ای به واسطه فعالیت‌های سریع‌الانتقال، چک کردن‌های مداوم و تست‌های خودکار از طریق اتوماسیون، طی ۱۰ سال گذشته به میزان قابل توجهی تسریع شده است. این تحول که «یکپارچه‌سازی مداوم» نامیده می‌شود، به توسعه سریع‌تر، تخریب پروژه‌های کمتر و پیش‌بینی‌پذیری بهتر فرآیند پروژه منجر شده است.
به هر حال، برای بسیاری از سازمان‌های IT، وقتی قرار است کد جدیدی را به تولید بدهند، سرعت بالای چرخه عمر اپلیکیشن به بن‌بست می‌خورد. در حوزه عملیات، احتمال بازگشت به فرآیندهای دستی زیاد است.
تا زمانی که سازمان‌های IT به گسترش مداومی دست یابند که در آن تغییرات کد درون چرخه عمر اپلیکیشن کاملا اتوماتیک حرکت کند، نیازهای کسب‌وکار به شکل واکنش سریع به شرایط آشفته بی‌پاسخ خواهند ماند. بد‌تر از آن، واحدهای کسب‌وکار به یکپارچگی مداوم افتخار خواهند کرد.
دیدگاهی که در پس DevOps قرار دارد، به سازمان‌های یکپارچه و کارآمدی مربوط می‌شود که روند به‌روزرسانی اپلیکیشن‌ها را از طریق یک فرآیند تلفیقی سرعت می‌بخشند و ایجاد تغییرات را به جای چند هفته یا چند ماه، در چند ساعت یا چند روز ممکن می‌کنند.
تجربه ثابت کرده دخالت دستی همان قدر که می‌تواند از مشکلات جلوگیری کند، می‌تواند عامل بروز مشکلات هم باشد. در هر صورت، هر توجیهی برای فرآیندهای دستی طولانی مدت به واسطه تقاضای کاربر باطل است. روی آوردن به رویکردهای ثابت، بی‌فایده خواهد بود.
گسترش مداوم نیازمند اتوماسیون و انگیزه‌های متحد
برای دستیابی به گسترش مداوم، وجود چهار مورد زیر ضروری است:
۱) یک فرآیند ساده‌سازی و اتوماتیک شده
اگر فرآیند دربرگیرنده بازدیدهای مهم از سوی کمیسیون مربوطه، توقف فرآیند در شرایطی که فردی توسعه بیشتر را تایید کرده و یا هر نوع دیگری از نظارت دستی باشد، دیگر هیچ چیزی نمی‌تواند باعث حرکت سریع‌تر سیستم شود. اثبات اینکه تغییرات موقعیتی نباید به صورت اتوماتیک پیش بروند – به دلیل پیچیدگی یا دلایل دیگر – مثل اثبات این نیست که هر تغییری نیازمند دخالت دستی است، بلکه فقط بدین معنی است که شما باید فرآیندی را اجرا کنید که در مواقع لزوم دخالت کند و در عین حال امکان تجربه اتوماتیک را برای تغییرات روتین ایجاد کند.
۲) زنجیره ابزار یکپارچه و پیوسته
مسلما، تا زمانی که ابزارهای حمایتی برای فرآیند وجود نداشته باشد، جریان کاری اتوماتیک شده بی‌معنا خواهد بود. در اصل، خروجی ابزار‌ها در یک فاز باید به ابزارهایی در فاز بعدی منتقل شود که یعنی ابزار‌ها باید با هم کار کنند. امروز، انتخاب شما برای زنجیره ابزار DevOps، یا رهنمودهای اختصاصی پرهزینه از فروشنده‌های بزرگ است و یا مجموعه‌های خانگی به هم پیوسته از عناصر متن باز. هر رویکردی هم نقاط ضعف دارد و هم نقاط قوت. با در نظر داشتن منافع هر حوزه و اهمیت فزاینده آن، می‌توان مطمئن بود که به زودی راه حل‌های انعطاف‌پذیر‌تر و مقرون به صرفه‌تری وارد بازار می‌شوند.
۳) اپلیکیشن‌های دستی
ابزارهای به هم پیوسته مزبور، باید همراستای محصولاتی حرکت کنند که استفاده از آن‌ها در همه گروه‌ها متداول است. بازآفرینی کارهای اجرایی یا موقعیت‌ها، فرصتی را برای ظهور خطا‌ها ایجاد می‌کند و جلوی کاربردپذیری سریع را می‌گیرد. استفاده از یک مجموعه واحد از محصولات دستی و انتقال آن‌ها در میان گروه‌ها بسیار بهتر خواهد بود.
۴) معیار‌ها و انگیزه‌های هم‌تراز در سازمان
با وجود انگیزه‌ها، دوباره به موضوع فرهنگ برمی‌گردیم. همان طور که اشاره شد، این باور غلط است که اگر گروه‌های مختلف در کنار هم قرار گیرند، توسعه روابط شخصی باعث می‌شود خطا‌ها از بین برود. برای اینکه گروه‌ها با بازدهی بیشتری در کنار هم کار کنند، باید مجموعه واحدی از معیار‌ها و انگیزه‌ها را به اشتراک بگذارند. اگر یک گروه به واسطه کاربردپذیری به‌روزرسانی سنجیده می‌شود و گروه دیگری به واسطه ثبات عملیاتی، در کار آن‌ها اختلال ایجاد خواهد شد.
بنابراین، باید مجموعه واحدی از اقدامات را اجرایی کنید، به طوری که همه بتوانند با هم همکاری کنند فکر نکنید این کار با ایجاد اتحادیه‌ای از معیارهای قبلی تحقق می‌یابد، چون ترکیب نیازمندی‌ها برای به‌روزرسانی‌های مکرر با نیاز برای ثبات عملیاتی فقط باعث ایجاد درگیری در یک گروه می‌شود.
مسلما مخالفتی که با این توصیه‌ها می‌توان کرد این است که خیلی سختگیرانه‌اند و آشفتگی زیادی ایجاد خواهند کرد. این موضوع درست است و اگر ما در دنیای IT یک دهه پیش زندگی می‌کردیم، نیازی به اجرای چنین اقدامات مخربی نبود.
اما به هر حال، ما در چنین دنیایی زندگی نمی‌کنیم. دنیای امروز جایی است که افزایش سرعت تغییرات کسب‌وکار، مستلزم کار دوباره در مورد عملکرد IT از اولین روزهای شکل‌گیری آن است. تولید صنعتی تجربه ۳۰ سال دردآور فاز بازمهندسی را پشت سر گذاشت که اقداماتی به قدمت یک قرن را به هدف افزایش کارایی و کاهش هزینه‌ها تخریب کرد. اما اکنون همه چیز سریع‌تر پیش می‌رود و IT جایی برای صرف ۳۰ سال انجام کار دوباره را ندارد.
منابع:
cio
en.wikipedia