برای اینکه بدانیم DevOps در اصل چیست ، بهتر است ابتدا با معنی و شرحی که در ویکی پدیا در ذیل این کلمه آمده است ، شروع کنیم. در ادامه با نوین هاست همراه باشید…
طبق آنچه که در ویکی پدیا آمده ، DevOps به این معنی است:
” DevOps یک فرایند تحویل نرم افزار است که بر ارتباط و همکاری از مرحله ی طرح ایده تا بازار ، شامل مدیریت تولید ، ساخت نرم افزار و عملیات تخصصی مربوط به آن ، تأکید دارد. DevOps همچنین فرایندهای تکمیل و جمع آوری نرم افزار ، آزمایش ، تنظیم و تغییر زیرساخت های آن را به صورت خودکار انجام می دهد. هدف این فرایند ایجاد فضا و شرایطی است که در آن بتوان ساخت ، آزمایش و ارائه ی نرم افزار را با سرعت ، اطمینان و اعتماد بیشتر و به دفعات مکرر انجام داد.”
این تعریف ، تعریف خوبی است ، اما به نظر می رسد که نکته ای در آن مورد توجه قرار نگرفته است . بین این که یک برنامه به صورت جداگانه ( در خلاء) قابل اجرا باشد و این که بتوان همان برنامه را در یک محصول تولید شده نیز اجرا کرد ، تفاوت زیادی وجود دارد، متأسفانه در بیشتر مواقع، این تفاوت در زمان بررسی و تعیین مواردی که برای تولید یک محصول موفق لازم است ، نادیده گرفته می شود.
بیایید برای درک بهتر آنچه که مهندسین DevOps انجام می دهند ، نگاهی به چرخه ی تولید یک نرم افزار بیندازیم. این چرخه پنج بخش اصلی دارد که عبارتند از : طراحی و برنامه ریزی، ساخت ، آزمایش ، تنظیم و حفظ و نگهداری ، البته تجربه نشان داده است که بیشتر وقت مهندسین DevOps صرف دو مرحله ی طراحی و برنامه ریزی و حفظ و نگهداری می شود، البته به خاطر داشته باشید که مراحل بالا دقیقاً به همین ترتیب اجرا نمی شوند و گاهی با یکدیگر ترکیب شده و گاه هم زمان با هم انجام می شوند.
طراحی و برنامه ریزی
در این مرحله اعضای تیم ( ایده پردازان ، مدیران تولید …) اهداف انجام پروژه را شرح می دهند . آنها در این مرحله باید در خصوص طرح کلی نرم افزار تصمیم بگیرند.
بخش مهمی که در این مرحله باید یک مهندس DevOps انجام دهد. این است که از دانش فنی خود در مورد ویژگی های ساخت یک پلت فرم استفاده کند و مشخص کند که چطور می توان این ویژگیهای پراکنده را کنار هم جمع کرد و به صورت یک سیستم منسجم و مجزا در آورد. پس از اینکه سیستم اولیه طراحی و تکمیل شد ، به این می پردازند که چگونه می توان یک فن آوری جدید را به سیستم موجود اضافه کرد.
این امر می تواند به صورت برنامه ریزی و طراحی برای یکی از موارد زیر باشد: چطور می توان یک لایه ی هماهنگ کننده ساخت ، چطور می توان یک database جدید تنظیم کرد ، چطور می توان از زیر ساخت های ارائه ی خدمات ظریف جدید پشتیبانی کرد. این مهندسین همچنین باید به این موضوع نیز بیندیشند که چگونه می توان این سیستم و فن آوری همراه آن را حفظ کرد و به صورت خودکار درآورد. در واقع مهندسین DevOps همیشه باید در جستجوی راهی برای انجام خودکار کارها و خلاصی از انجام دستی آنها باشند.
سوالهایی که معمولاً در این مرحله مطرح می شوند، عبارتند از :
- چگونه می توان دو سرویس جداگانه را به یکدیگر ربط داد؟
- از کدام پروتکل برای این ارتباط باید استفاده کرد؟
- آیا لازم است که نگران سخت افزار لازم برای این کار باشم، یا از یک سرور مجازی استفاده می کنم؟
- مهندسین باید چه چیزی را به صورت درست و قانونی بسازند تا من هم برای تولید آن به آنها کمک کنم؟
- سرویس آماده ی تولید (production-ready) چیست؟
- تمام نرم افزارهای مورد نیاز ما چگونه اجرا خواهند شد؟
- آیا می توانیم تمام خدمات وابسته ی موجود در سیستم را کنترل کنیم و ایا این خدمات را بطور کامل می شناسیم تا بتوانیم در صورت لزوم اشکالات به وجود آمده را رفع کنیم؟
- بهتر است سیستم را بسازیم یا آن را بخریم؟
- می توان این سیستم را به صورت خودکار اجرا کرد؟
- چگونه می توان این سیستم را در اینده پشتیبانی کرد؟
ساخت
در این مرحله بیشتر ویزگیهای کار مشخص شده و بخش اعظم کار انجام می شود. طراحان با یکدیگر صحبت کرده ، قهوه می خورند ، برنامه های لازم را می نویسند و در نهایت محصول ساخته شده را ارائه می کنند .
هدف اصلی یک مهندس DevOps در این مرحله ، سرعت بخشیدن به کار برای گذر از این مرحله است. بدین معنی که این مهندسین باید شرایطی ایجاد کنند که طراحان با بیشترین سرعت ممکن و به بهترین و مناسب ترین شکل ممکن ، به نتیجه ی نهایی که همان تولید سیستم است ، دست پیدا کنند.
در این مرحله است که وجود برخی ابزارها اهمیت پیدا می کند. بهتر است بگوییم مهندس DevOps وقتش را صرف آن می کند که این زیرساختهای جالب و جذاب را که ممکن است قابلیت ترمیم خود بخود و خود ارزیابی و ….را داشته باشند، در کنار یکدیگر قرار دهند؛ اما اگر این نرم افزار که توسط طراحان ساخته شده است ، در شرایط دیگری ساخته می شد ، بیشتر شکوه و زیباییش را ازدست می داد.
بدیهی است که ما نمی توانیم اطمینان داشته باشیم که شرایط و موقعیت طراحان هنگام ساخت ، دقیقاً مانند شرایط تولید محصول باشد _ این امر بطور کامل عملی نیست ، اما می توان تا حد امکان این دو موقعیت را به یکدیگر شبیه کرد. وجود container نشانه ی آن است که امروزه امکان شبیه کردن این شرایط فراهم شده است ، البته پیش از این هم با وجود دستگاه ها و ماشین های مجازی ، می توانستند تا حدی این شرایط مشابه را ایجاد کنند.
در این مرحله مهندسین DevOps با این سوالات روبرو هستند:
- چگونه می توانند به طراحان اجازه دهند که از ابزار دلخواه خود استفاده کنند ، در حالیکه باید شرایط مشابه با شرایط محیط تولید را رعایت کنند؟
- چگونه می توانند شرایطی ایجاد کنند که طراحان کارآمد تر بشوند؟
- چگونه می توانند شرایط محیط مورد نظر برای استفاده از نرم افزار را به طراحان آموزش دهند؟
آزمایش
طراحان ، QA و هر کس دیگری این سیستم را آزمایش می کند .
آنها تمام وسایل و فرمانها را به گونه ای تنظیم می کنند که این سیستم به صورت خودکار اجرا شود ، اما در نهایت در پایان روز ، هنوز هم لازم است که سیستم را به صورت دستی بر روی دستگاههای خود اجرا کنند. اگر بخواهیم این سیستم را در شرایط تولید یا شبه تولید آزمایش کنیم ، چه؟ اگر برنامه ی آزمایشی بیش از حد کند عمل کند یا برای داشتن عملکرد قابل قبول ، کنترل دستگاه هاست را به دست بگیرد، چه؟ اینگونه آزمایشها را نمی توان در شرایط محدود انجام داد ، بلکه باید در شرایظی پایدار و به صورت اتوماتیک انجام شوند. DevOps راه حل این مشکل است.
مهندسین DevOps نقش اصلی را در تشخیص و تنظیم و ایجاد زیر ساختهایی دارند که امکان انجام این آزمایشات را به صورت مکرر و به دفعات فراهم می کنند. آنها زیرساختهایی را ایجاد می کنند که می توانیم به Jenkins ، Bamboo و یا Drone به عنوان نمونه هایی از این زیرساختها اشاره کنیم. این زیرساختها ابزارهای Continuous Integration) CI) هستند که بخش اصلی تنظیمات پیچیده ی سیستمهای آزمایش کننده را بر عهده دارند.
سوالهای این مرحله :
- چگونه می توان شرایطی قابل تکرار شبیه به شرایط مشتریان به وجود آورد؟
- چگونه می توان دانست که کدام نسخه از خدمات در حال بررسی و آزمایش هستند؟
- چگونه می توان آزمایشات انجام شده را پیگیری و ردیابی کرد تا بر اساس آن ، تغییرات به وجود آمده را مشاهده کرد ؟
- چگونه می توان طراحان را از شرایط ساخت آگاه کرد؟
- اطلاعات مربوط به آزمایش را از کجا به دست بیاوریم؟
تنظیم
برنامه ی نوشته شده را به محیطی که در این مقاله به عنوان محیط تولید فرض می شود ، بیاورید.
چه مقدار از ویژگیها و امکانات برنامه ی ساخته شده به محیط تولید منتقل شده و در نهایت به دست کاربران نهایی می رسد؟ مرحله ی تنظیم به پاسخ این سوال می پردازد. مهندسین DevOps معمولاً از ابزاری شبیه به ابزارهای CI که قبلاً نام برده شد، برای یافتن پاسخ این پرسش استفاده می کنند.
یافتن پاسخ پرسشهایی همچون:
- یک سیستم ساخته شده چه وقت آماده ی استفاده است؟
- چگونه می توان بدون در نظر گرفتن مشتریان از یک سرویس استفاده کرد؟
- چگونه می توان مطمئن شد که یک سرویس تازه به کار گرفته شده سبب پسرفت نمی شود؟
- چگونه می توان از یک سرویس به صورت اتوماتیک استفاده کرد؟
- چگونه می توان مراحل انجام کار دستی را در یک سیستم اتوماتیک وارد کرد؟
- چگونه می توان محصولاتی ساخت که آماده ی استفاده باشند؟
- چگونه می توان یک محصول را به صورت مکرر مورد استفاده قرار داد؟
حفظ و نگهداری
بخش زیادی از وقت مهندسین DevOps به این مرحله اختصاص داده می شود؛ در واقع Google بخشی دارد که کاملاً به همکاری با این افراد اختصاص داده شده است ، این بخش SRE نامیده میشود.
این مرحله در حقیقت مرحله ای است که با کارها و ابزار خود ، یک سیستم را تبدیل به چیزی می کند که قابل اجرا و قابل دسترس برای بسیاری از کاربران است.
این کارها و ابزار شامل سوالاتی هستند از قبیل :
- چگونه می توان از اشکالات موجود در محصول تولید شده آگاه شد؟
- وقتی اشکالی در محصول به وجود می آید ، چگونه می توان آن را به تیم تصحیح و رفع ایراد منعکس کرد؟
- چگونه می توان اشکالات زیرساختهای محصول تولید شده را برطرف کرد؟
- چگونه مهندسان اشکالات محصول را در سرویسهای خود برطرف می کنند؟
- چگونه می توان سلامت سرویسهای ارائه شده را پیگیری کرد؟
- چگونه می توان خدماتی ارائه کرد که قادر باشند به صورت اتوماتیک اشکالات را برطرف کنند و بار وارده را محاسبه کنند؟
نتیجه
DevOps در حقیقت ترکیبی از تمام نقشهایی است که تا به حال به آنها اشاره کردیم و طراح و مهندس سیستم را در کنار یکدیگر قرار می دهد. DevOps حلقه ی گم شده بین قابل اجرا بودن یک برنامه به تنهایی و اجرای همان برنامه در یک محصول تولید شده است.
