DevOps چیست؟

DevOps چیست؟

DevOps ترکیبی از چندین نقش بوده است. ضرورتا یک توسعه دهنده و مهندس اجرایی کنار یکدیگر قرار می گیرند و ویژگی ها با زیرساخت ها با یکدیگر ترکیب می شوند.اصطلاح DevOps از دو واژه Development (توسعه) و Operations (عملیات) ساخته شده است. ما در این مقاله به بررسی کلی DevOps و سپس به بررسی هر یک از نقش ها به صورت جداگانه خواهیم پرداخت.

 

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

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

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

برای درک بهتر از اینکه مهندسان DevOps چه کاری ممکن است انجام دهند اجازه دهید به چرخه ی عمر نرم افزار نگاه کنیم. در ذهن من 5 بخش اصلی وجود دارد که شامل طرح ریزی یا برنامه ریزی (Planning)، توسعه(Development)، تست(Testing)، گسترش یا راه اندازی (Deployment) و نگهداری (Maintenance) می باشد. تجربه ی من همچنین نشان می دهد که اکثرا زمان یک مهندس روی Planning و Maintenance صرف می شود. درنظر داشته باشید که گام ها همیشه به ترتیبی که گفته شد نمی باشد و اغلب این روند همانطور که شما همان وظایف برای آینده که بخشی از یک پروژه ی بزرگ است را انجام می دهید، در خودش تعبیه شده است.

 

طرح ریزی (Planning)

طرح ریزی مرحله ای  است که تیم (توسعه دهندگان آینده، QA، مدیران محصول و غیره) اهداف یک پروژه را تعریف می کنند. آن ها ممکن است یک معماری سراسری برای نرم افزار تعریف کنند.

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

سوالات معمول در این گام ...

-چگونه دو سرویس جداگانه ارتباط برقرار می کنند؟

-چه پروتکل ارتباطی استفاده خواهیم کرد؟

-آیا نیاز است که درباره ی سخت افزار نگران باشم یا سخت افزار، پاسخگوی نیاز ما هست؟

-مهندسان باید چه چیزهایی را برای ما تولید کنند تا به آنها کمک کند آن ها را به تولید برسانند؟

-یک سرویس آماده به تولید (Production-Ready) چیست؟

-چگونه همه ی نرم افزار هایی که نیاز داریم اجرا خواهند شد؟

-آیا همه ی وابستگی های ما قابل مانیتور کردن هستند و آیا ما درکی کافی از آنها برای دیباگ کردن داریم؟

-چه چیزهایی لازم است در مقابل ساخت خریداری کنیم؟

-آیا این کار قابل اتوماتیک کردن است؟

-چگونه می توانیم از این کار در آینده پشتیبانی کنیم؟

 

توسعه (Development)

این قسمت کلی کار یا ویژگی های کار مشخص شده و توسعه دهندگان همکاری و کد نویسی می کنند، قهوه می نوشند و آینده را تغییر می دهند.

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

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

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

سوال هایی که مهندسان DevOps در این گام مطرح می کنند...

-چگونه به توسعه دهندگان امکان استفاده از ابزار های مورد علاقه شان در فضای محصول هستند را بدهیم؟

-چگونه می توانیم توسعه دهندگان را فعال کنیم تا کارآمد تر باشند؟

-چگونه می توانیم به توسعه دهندگان درباره ی محیطی که درحال ساخت آن هستند آموزش دهیم؟

 

تست (testing)

توسعه دهندگان و QA و هرکس دیگری تست را انجام می دهد. کد موجود را برای یکپارچه شدن با کد اصلی آماده می کند.

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

مهندسان DevOps نقش تعریف و پیاده سازی زیرساخت هایی که می توانند این تست ها را به یک روش قابل تکرار اجرا کنند، را دارند. آن ها باید چیزی شبیه Jenkins،Bamboo یا Drone را برای نامگذاری تعدادی، تنظیم کنند. این موارد ابزار های Continuous Integration یا به اختصار (CI) می باشد. که از پیچیدگی زیاد تنظیم تست های مداوم جلوگیری می کند. درواقع احتمالا این کار در مرحله ی طرح ریزی نیز انجام شود اما فکر می کنم که بیان این مورد در این مرحله بیشتر قابل درک است زیرا این ابزار ها عمدتا برای مهندسان DevOps است.

سوالات این گام...

-چگونه محیط های کلاینت (Client Environment) که قابل تکرار هستند را بسازیم؟

-چگونه متوجه شویم که چه نسخه ای از یک سرویس تست درحال اجرا است؟

-چگونه متوجه تاریخچه ی تست شویم تا بتوانیم تمایلات را متوجه شویم؟

-چگونه به توسعه دهندگان نسبت به وضعیت ساختشان هشدار بدهیم؟

-داده های تست را از کجا بیاوریم؟

 

گسترش یا استقرار (Deployment)

منظور از Deployment این است قرار دادن کدها روی سرور اصلی نرم افزار است.

چگونه یک ویژگی از کد در محصول قرار بگیرد تا نهایتا به دست کاربر نهایی برسد؟ این همان چیزی است که مرحله گسترش انجام می دهد. مهندسان DevOpsمعمولا ابزار هایی مشابه ابزار های CI که قبلا برای انجام این کار لیست کردیم، استفاده می کنند.

برخی از وظایف اصلی که شامل پاسخ به سوال های زیر می شوند...

-چه زمانی تعریف ساخت آماده برای توسعه است؟

-چگونه توسعه ی یک نرم افزار را بدون توجه به مشتریانم انجام دهم؟

-چگونه اطمینان پیدا کنم سرویسی که به تازگی توسعه یافته است باعث پس رفت نمی شود؟

-چگونه به صورت اتوماتیک گسترش را انجام دهم؟

-چگونه تنظیمات دستی را در یک روند گسترش اتوماتیک شده وارد کنم؟

-چگونه محصولات صحیح را تولید کنیم تا آماده ی گسترش باشد؟

-چگونه گسترش را به یک راه قابل تکرار انجام بدهم؟

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

 

نگهداری(Maintenance)

من معتقدم که بیشترین زمان مهندسان DevOps به خود اختصاص می دهد. گوگل ضرورتا یک قانونی در شرکت خود دارد تا اینکار بطور کامل انجام شود. به این افراد SRE ها گفته می شود.

این مرحله ضرورتا شامل تمام کار و ابزار هایی است که باعث می شود سیستم با عملکرد و دسترس پذیری بالایی باشد. این مرحله شامل سوالاتی از قبیل موارد زیر می باشد...

-چگونه از باگ های هر سطح تولیدی اطلاع پیدا کنم؟

-چگونه زمانی که یک باگ در تولید اتفاق می افتد مشکلات مختلف را به تیم درست مربوط سازیم؟

-چگونه باگ های زیرساختی تولید را حل کنیم؟

-چگونه مهندسان باگ های تولید را در سرویس های خودشان حل کنند؟

-چگونه از سلامت و کارایی همه ی سرویس ها اطمینان حاصل کنیم؟

-چگونه سرویس های خود را می توانیم به طریقی بسازیم به ترتیب خودمان را بهبود بخشیم و به علت خراب شدن و بارگذاری های مختلف به صورت خودکار راه اندازی کنیم؟

 

برای ارسال نظر نیاز است وارد سایت شوید. در صورت نداشتن حساب کاربری عضو شوید.