هنگامی که یک برنامه کاربردی کار نمی کند، آخرین چیزی که می خواهید از همکاران خود بشنوید عبارت "مشکل از طرف شماست." در نتیجه، کاربران رنج میبرند – و برایشان مهم نیست که کدام قسمت از تیم مسئول خرابی است. فرهنگ DevOps دقیقاً برای گردآوری توسعه و پشتیبانی حول مسئولیت مشترک برای محصول نهایی پدیدار شد.
چه اقداماتی در مفهوم DevOps گنجانده شده است و چرا به آنها نیاز است؟ مهندسان DevOps چه می کنند و چه کاری باید انجام دهند؟ کارشناسان EPAM به این سؤالات و سؤالات دیگر پاسخ می دهند: Kirill Sergeev، مهندس سیستم و مبشر DevOps، و Igor Boyko، مهندس پیشرو سیستم و هماهنگ کننده یکی از تیم های DevOps شرکت.
چرا DevOps مورد نیاز است؟
پیش از این، یک مانع بین توسعه دهندگان و پشتیبانی (به اصطلاح عملیات) وجود داشت. متناقض به نظر می رسد، اما آنها اهداف و شاخص های کلیدی عملکرد متفاوتی داشتند، اگرچه آنها همان کار را انجام می دادند. هدف توسعه این بود که الزامات تجاری را در سریع ترین زمان ممکن پیاده سازی کند و آنها را به یک محصول کارآمد اضافه کند. پشتیبانی مسئول اطمینان از عملکرد پایدار برنامه بود - و هر تغییری ثبات را به خطر میاندازد. تضاد منافع وجود دارد - به نظر می رسد DevOps آن را حل می کند.
DevOps چیست؟
این یک سوال خوب - و یک سوال بحث برانگیز است: جهان هنوز در این مورد به توافق نرسیده است. EPAM معتقد است که DevOps فناوری ها، فرآیندها و فرهنگ تعامل را در یک تیم ترکیب می کند. هدف این انجمن ارائه ارزش مستمر به کاربران نهایی است.
کریل سرگئیف: «توسعهدهندگان کد مینویسند، آزمایشکنندگان آن را بررسی میکنند و مدیران محصول نهایی را برای تولید پیادهسازی میکنند. برای مدت طولانی، این بخشهای تیم تا حدودی پراکنده بودند و سپس این ایده به وجود آمد که آنها را طی یک فرآیند مشترک متحد کنند. شیوههای DevOps اینگونه ظاهر شد.»
روزی فرا رسید که توسعه دهندگان و مهندسان سیستم به کار یکدیگر علاقه مند شدند. مانع بین تولید و حمایت شروع به از بین رفتن کرد. اینگونه بود که DevOps پدیدار شد که شامل تمرینها، فرهنگ و تعامل تیمی است.
ماهیت فرهنگ DevOps چیست؟
واقعیت این است که مسئولیت نتیجه نهایی بر عهده هر یک از اعضای تیم است. جالبترین و سختترین چیز در فلسفه DevOps این است که بفهمیم یک فرد خاص فقط مسئول مرحله کار خود نیست، بلکه مسئول نحوه عملکرد کل محصول است. مشکل از جانب کسی نیست - به اشتراک گذاشته شده است و هر یک از اعضای تیم به حل آن کمک می کند.
مهمترین چیز در فرهنگ DevOps حل مشکل است، نه فقط اعمال DevOps. علاوه بر این، این شیوهها «از طرف کسی» اجرا نمیشوند، بلکه در کل محصول اجرا میشوند. یک پروژه به خودی خود به یک مهندس DevOps نیاز ندارد - به یک راه حل برای یک مشکل نیاز دارد و نقش یک مهندس DevOps می تواند بین چندین عضو تیم با تخصص های مختلف توزیع شود.
انواع روش های DevOps چیست؟
اقدامات DevOps تمام مراحل چرخه عمر نرم افزار را پوشش می دهد.
ایگور بویکو: «مورد ایده آل زمانی است که ما شروع به استفاده از شیوه های DevOps درست در شروع یک پروژه می کنیم. به همراه معماران، برنامهریزی میکنیم که برنامه چه نوع منظره معماری داشته باشد، کجا قرار گیرد و چگونه مقیاس شود و یک پلتفرم را انتخاب کنیم. امروزه، معماری میکروسرویس مد است - برای آن ما یک سیستم ارکستراسیون را انتخاب می کنیم: شما باید بتوانید هر یک از عناصر برنامه را به طور جداگانه مدیریت کنید و آن را مستقل از سایرین به روز کنید. روش دیگر "زیرساخت به عنوان کد" است. این نام رویکردی است که در آن زیرساخت پروژه با استفاده از کد ایجاد و مدیریت میشود، نه از طریق تعامل مستقیم با سرورها.
در ادامه به مرحله توسعه می رویم. یکی از بزرگترین روشها در اینجا ساختن CI/CD است: شما باید به توسعهدهندگان کمک کنید تا تغییرات را به سرعت، در بخشهای کوچک، اغلب و بدون دردسرتر در محصول ادغام کنند. CI/CD شامل بررسی کد، آپلود اصلی در پایه کد و استقرار برنامه در محیط های آزمایش و تولید می شود.
در مراحل CI/CD، کد از گیت های با کیفیت عبور می کند. آنها با کمک آنها بررسی می کنند که کدی که از ایستگاه کاری توسعه دهنده خارج می شود با معیارهای کیفیت مشخص شده مطابقت دارد. تست واحد و رابط کاربری در اینجا اضافه شده است. برای استقرار سریع، بدون درد و متمرکز محصول، می توانید نوع استقرار مناسب را انتخاب کنید.
متخصصان DevOps نیز در مرحله پشتیبانی از محصول نهایی جایگاهی دارند. آنها برای نظارت، بازخورد، امنیت و معرفی تغییرات استفاده می شوند. DevOps به همه این وظایف از منظر بهبود مستمر نگاه می کند. ما عملیات های تکراری را به حداقل رسانده و آنها را خودکار می کنیم. این همچنین شامل مهاجرت، گسترش برنامه، و پشتیبانی عملکرد است.
مزایای شیوه های DevOps چیست؟
اگر بخواهیم یک کتاب درسی درباره شیوههای DevOps مدرن بنویسیم، سه نکته در صفحه اول وجود دارد: اتوماسیون، سرعت بخشیدن به انتشار و بازخورد سریع کاربران.
کریل سرگئیف: «اولین چیز اتوماسیون است. ما میتوانیم تمام تعاملات تیم را خودکار کنیم: کد را نوشت - آن را منتشر کرد - آن را بررسی کرد - آن را نصب کرد - بازخورد جمعآوری کرد - به ابتدا بازگشت. همه اینها خودکار است.
مورد دوم سرعت بخشیدن به انتشار و حتی ساده سازی توسعه است. همیشه برای مشتری مهم است که محصول در اسرع وقت وارد بازار شود و زودتر از محصولات مشابه رقبا شروع به ارائه منافع کند. فرآیند تحویل محصول را می توان به طور بی پایان بهبود داد: کاهش زمان، اضافه کردن علائم کنترل اضافی، بهبود نظارت.
سوم، تسریع بازخورد کاربران است. اگر او نظراتی داشته باشد، میتوانیم فوراً تنظیمات را انجام دهیم و بلافاصله برنامه را بهروزرسانی کنیم.»
مفاهیم "مهندس سیستم"، "مهندس ساخت" و "مهندس DevOps" چگونه به هم مرتبط هستند؟
آنها همپوشانی دارند، اما متعلق به مناطق کمی متفاوت هستند.
مهندس سیستم در EPAM یک موقعیت است. آنها در سطوح مختلف هستند: از متخصص جوان تا متخصص.
یک مهندس ساختمان بیشتر نقشی است که می تواند در یک پروژه انجام شود. اکنون این همان چیزی است که افراد مسئول CI/CD نامیده می شوند.
یک مهندس DevOps متخصصی است که رویههای DevOps را در یک پروژه پیادهسازی میکند.
اگر همه را خلاصه کنیم، چیزی شبیه به این به دست میآید: فردی در موقعیت یک مهندس سیستم، نقش مهندس ساخت یک پروژه را بازی میکند و در اجرای تمرینهای DevOps در آنجا مشارکت میکند.
یک مهندس DevOps دقیقا چه کاری انجام می دهد؟
مهندسان DevOps تمام قطعاتی که یک پروژه را تشکیل می دهند را کنار هم می گذارند. آنها ویژگی های کار برنامه نویسان، آزمایش کنندگان، مدیران سیستم را می دانند و به ساده سازی کار آنها کمک می کنند. آنها نیازها و الزامات کسب و کار، نقش آن در فرآیند توسعه را درک می کنند - و فرآیند را با در نظر گرفتن منافع مشتری می سازند.
ما در مورد اتوماسیون بسیار صحبت کردیم - این همان چیزی است که مهندسان DevOps در درجه اول با آن سروکار دارند. این نکته بسیار بزرگی است که از جمله شامل آماده سازی محیط است.
کریل سرگئیف: «قبل از اجرای بهروزرسانیها در محصول، باید در یک محیط شخص ثالث آزمایش شوند. توسط مهندسان DevOps تهیه شده است. آنها فرهنگ DevOps را در کل پروژه القا می کنند: آنها اقدامات DevOps را در تمام لایه های پروژه خود معرفی می کنند. این سه اصل: اتوماسیون، ساده سازی، شتاب - آنها به هر کجا که می توانند برسند، می آورند.
یک مهندس DevOps چه چیزی باید بداند؟
به طور کلی، او باید در زمینه های مختلف دانش داشته باشد: برنامه نویسی، کار با سیستم عامل ها، پایگاه های داده، مونتاژ و سیستم های پیکربندی. اینها شامل توانایی کار با زیرساخت های ابری، ارکستراسیون و سیستم های نظارت است.
1. زبان های برنامه نویسی
مهندسان DevOps چندین زبان اساسی برای اتوماسیون می دانند و می توانند به عنوان مثال به یک برنامه نویس بگویند: "چطور می شود کد را نه با دست، بلکه با استفاده از اسکریپت ما که همه چیز را خودکار می کند، نصب کنید؟ ما یک فایل کانفیگ برای آن آماده خواهیم کرد، خواندن آن برای شما و ما راحت خواهد بود و هر زمان که بخواهید قادر به تغییر آن خواهیم بود. ما همچنین خواهیم دید که چه کسی، چه زمانی و چرا تغییراتی در آن ایجاد می کند."
یک مهندس DevOps می تواند یک یا چند مورد از این زبان ها را یاد بگیرد: Python، Groovy، Bash، Powershell، Ruby، Go. نیازی به دانستن آنها در سطح عمیق نیست - اصول نحو، اصول OOP و توانایی نوشتن اسکریپت های ساده برای اتوماسیون کافی است.
2. سیستم عامل
یک مهندس DevOps باید بداند که محصول روی چه سروری نصب میشود، در چه محیطی اجرا میشود و با چه سرویسهایی تعامل خواهد داشت. شما می توانید انتخاب کنید که در ویندوز یا خانواده لینوکس تخصص داشته باشید.
3. سیستم های کنترل نسخه
بدون دانش سیستم کنترل نسخه، یک مهندس DevOps جایی نیست. Git یکی از محبوب ترین سیستم های حال حاضر است.
4. ارائه دهندگان ابر
AWS، Google، Azure - به خصوص اگر در مورد جهت ویندوز صحبت می کنیم.
کریل سرگئیف: «ارائه دهندگان ابری سرورهای مجازی را در اختیار ما قرار می دهند که کاملاً در CI/CD قرار می گیرند.
نصب ده سرور فیزیکی به حدود صد عملیات دستی نیاز دارد. هر سرور باید به صورت دستی راه اندازی شود، سیستم عامل مورد نیاز را نصب و پیکربندی کند، برنامه ما را روی این ده سرور نصب کرده و سپس همه چیز را ده بار دوبار بررسی کنید. سرویس های ابری این رویه را با ده خط کد جایگزین می کنند و یک مهندس DevOps خوب باید بتواند با آنها کار کند. این باعث صرفه جویی در زمان، تلاش و پول - هم برای مشتری و هم برای شرکت می شود.
5. سیستم های ارکستراسیون: Docker و Kubernetes
کریل سرگئیف: “سرورهای مجازی به کانتینرهایی تقسیم می شوند که در هر کدام می توانیم اپلیکیشن خود را نصب کنیم. وقتی کانتینرهای زیادی وجود دارد، باید آنها را مدیریت کنید: یکی را روشن کنید، دیگری را خاموش کنید، در جایی پشتیبان تهیه کنید. این بسیار پیچیده می شود و به یک سیستم ارکستراسیون نیاز دارد.
قبلاً هر برنامه توسط یک سرور جداگانه اداره می شد - هر گونه تغییر در عملکرد آن می تواند بر قابلیت سرویس دهی برنامه تأثیر بگذارد. به لطف کانتینرها، برنامه ها ایزوله می شوند و به طور جداگانه اجرا می شوند - هر کدام در ماشین مجازی خود. اگر خرابی رخ دهد، نیازی به تلف کردن زمان برای جستجوی علت نیست. از بین بردن ظرف قدیمی و اضافه کردن ظرف جدید آسان تر است."
6. سیستم های پیکربندی: آشپز، Ansible، Puppet
هنگامی که شما نیاز به نگهداری یک ناوگان کامل از سرورها دارید، باید بسیاری از عملیات های مشابه را انجام دهید. طولانی و دشوار است و کار دستی نیز احتمال خطا را افزایش می دهد. اینجاست که سیستم های پیکربندی به کمک می آیند. آنها با کمک آنها اسکریپتی ایجاد می کنند که برای برنامه نویسان، مهندسان DevOps و مدیران سیستم به راحتی قابل خواندن باشد. این اسکریپت کمک می کند تا عملیات مشابه روی سرورها به صورت خودکار انجام شود. این باعث کاهش عملیات دستی (و در نتیجه خطاها) می شود.
یک مهندس DevOps چه نوع حرفه ای می تواند بسازد؟
شما می توانید هم به صورت افقی و هم به صورت عمودی توسعه پیدا کنید.
ایگور بویکو: "از نقطه نظر توسعه افقی، مهندسان DevOps اکنون گسترده ترین چشم انداز را دارند. همه چیز دائماً در حال تغییر است و میتوانید مهارتهایی را در زمینههای مختلف ایجاد کنید: از سیستمهای کنترل نسخه گرفته تا نظارت، از مدیریت پیکربندی تا پایگاههای داده.
اگر یک کارمند علاقه مند به درک نحوه عملکرد یک برنامه کاربردی در تمام مراحل چرخه عمر خود - از توسعه تا پشتیبانی باشد، می توانید یک معمار سیستم شوید.
چگونه یک مهندس DevOps شویم؟
- کتاب The Phoenix Project و DevOps را بخوانید. اینها ستون های واقعی فلسفه DevOps هستند که اولین آنها یک اثر تخیلی است.
- فناوری ها را از لیست بالا بیاموزید: به تنهایی یا از طریق دوره های آنلاین.
- به عنوان یک مهندس DevOps برای یک پروژه منبع باز بپیوندید.
- تمرینات DevOps را در پروژه های شخصی و کاری خود تمرین کرده و ارائه دهید.
منبع: www.habr.com