چرا مدیران سیستم، توسعه‌دهندگان و آزمایش‌کنندگان باید رویه‌های DevOps را بیاموزند؟

چرا مدیران سیستم، توسعه‌دهندگان و آزمایش‌کنندگان باید رویه‌های DevOps را بیاموزند؟

الکساندر تیتوف، شریک مدیریت Express 42 و نویسنده می گوید: با این دانش به کجا برویم، در پروژه چه کاری انجام دهیم و چقدر کسب درآمد کنیم، در مصاحبه چه بگوییم و بپرسیم. دوره آنلاین "روش ها و ابزارهای DevOps".

سلام! اگرچه اصطلاح DevOps از سال 2009 وجود داشته است، هنوز در جامعه روسیه اتفاق نظر وجود ندارد. احتمالاً متوجه شده اید که برخی DevOps را یک تخصص می دانند، برخی دیگر آن را یک فلسفه و برخی دیگر این اصطلاح را مجموعه ای از فناوری ها می دانند. من قبلاً بارها با آن اجرا کرده ام سخنرانی ها در مورد توسعه این جهت، بنابراین من به جزئیات در این مقاله نمی پردازم. فقط بگویم که در Express 42 موارد زیر را در آن گنجانده ایم:

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

در توسعه کلاسیک شرکتی، همه چیز به ترتیب پیش می رود: برنامه نویسی، آزمایش و تنها پس از آن عملیات، و سرعت این فرآیند از ایده تا تولید 3 ماه است. این یک مشکل جهانی برای محصولات دیجیتال است، زیرا دریافت سریع بازخورد از مشتریان غیرممکن است.

در DevOps، ابزارها و رویکردها برای اطمینان از اجرای همزمان فرآیندهای توسعه، آزمایش و عملیات طراحی شده‌اند.

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

  • شما نمی توانید یک "مهندس" را استخدام کنید که بیاید و تمام مشکلات تولید را حل کند. کل تیم باید از این تکنیک استفاده کنند.

    چرا مدیران سیستم، توسعه‌دهندگان و آزمایش‌کنندگان باید رویه‌های DevOps را بیاموزند؟

  • DevOps فرم بعدی sysadmin برای ارتقاء نیست. «مهندس DevOps» تقریباً شبیه «توسعه‌دهنده چابک» است.

    چرا مدیران سیستم، توسعه‌دهندگان و آزمایش‌کنندگان باید رویه‌های DevOps را بیاموزند؟

  • اگر تیمی از Kubernetes، Ansible، Prometheus، Mesosphere و Docker استفاده می‌کند، این بدان معنا نیست که شیوه‌های DevOps در آنجا پیاده‌سازی شده‌اند.

    چرا مدیران سیستم، توسعه‌دهندگان و آزمایش‌کنندگان باید رویه‌های DevOps را بیاموزند؟

زندگی پس از DevOps هرگز یکسان نخواهد بود

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

1. خودتعیین

ابتدا، ماهیت رویکرد DevOps را با جزئیات بررسی می‌کنیم و دانش‌آموزان نقش‌های جدیدی را در تیم کشف می‌کنند، می‌بینند که کدام یک بیشتر پاسخ می‌دهد، و خودشان تعیین می‌کنند که کدام جهت را توسعه دهند.

2. ابزارها و شیوه ها

دانش‌آموزان بر فناوری‌های خاص از دیدگاه روش DevOps تسلط پیدا می‌کنند.

ابزارهای DevOps را می توان هم در رویکرد DevOps و هم در توسعه کلاسیک استفاده کرد. واضح ترین مثال استفاده از ابزار مدیریت پیکربندی Ansible است. این برنامه برای اجرای تمرین DevOps "زیرساخت به عنوان کد" ایجاد و تصور شده است، به این معنی که حالت های مختلف سیستم، از تنظیمات سیستم عامل گرفته تا نرم افزار کاربردی، توصیف می شود. توضیحات به لایه ها تقسیم می شود و به شما امکان می دهد پیکربندی پیچیده و دائماً در حال تغییر را مدیریت کنید. اما مهندسان اغلب از Ansible به عنوان راهی برای اجرای اسکریپت های bash بر روی چندین ماشین استفاده می کنند. این نه بد است و نه خوب، اما باید بدانید که وجود Ansible حضور DevOps در شرکت را تضمین نمی کند.

ما در جریان هستیم دوره شما در فرآیند توسعه اپلیکیشنی شبیه به معروف Reddit غوطه ور خواهید شد و از نسخه یکپارچه آن شروع می کنید و قدم به قدم به سمت میکروسرویس ها می روید. گام به گام بر ابزارهای جدید مسلط خواهیم شد: Git، Ansible، Gitlab و با Kubernetes و Prometheus پایان می دهیم.

از نظر تمرینات، ما تاکتیک های سه مسیری را که در دفترچه DevOps توضیح داده شده است دنبال خواهیم کرد - شیوه های تحویل مداوم، شیوه های بازخورد، و ماهیت کل دوره تمرین یادگیری مداوم همراه با سیستم شما است.

این دانش به هر یک از متخصصان چه می دهد؟

برای مدیران سیستم

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

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

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

توسعه دهندگان

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

برای آزمایش کننده ها

مدت‌هاست که تست به حالت خودکار رفته است؛ همه ما می‌گوییم که تست‌های زیادی را نباید انجام داد، بلکه باید نوشت :) تست بخشی از کل خط لوله تحویل محصول شما می‌شود. یک آزمایشگر نه تنها باید یاد بگیرد که چگونه کد بنویسد، بلکه باید بداند که چگونه آن را در سیستم های تحویل پیوسته ادغام کند، چگونه از کد در تمام مراحل تحویل بازخورد دریافت کند، و چگونه به طور مداوم آزمایش را بهبود بخشد تا خطاها را تشخیص دهد. هر چه زودتر

و بنابراین معلوم می شود که هر سه مرحله به طور همزمان رخ می دهد. به عنوان مثال، ممکن است به شکل زیر باشد:

توسعه‌دهنده کد را می‌نویسد، فوراً آزمایش‌هایی برای آن می‌نویسد و یک محفظه docker برای کدی که باید اجرا شود، توصیف می‌کند. همچنین بلافاصله نظارتی را که بر عملکرد این سرویس در تولید نظارت می کند، توضیح می دهد و همه اینها را انجام می دهد.

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

من DevOps را مطالعه کردم، بعد چه؟

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

و اکنون در مورد چیزهای خوب: تسلط بر شیوه‌ها و ابزارهای DevOps تقریباً 30% بیشتر از ارزش شما در بازار کار است. حقوق ها از 140 هزار روبل شروع می شود، اما طبیعتاً با تخصص و عملکرد اصلی شما تعیین می شود.

می‌توانید به جاهای خالی با علامت «زیرساخت‌گرا» نگاه کنید، جایی که اتوماسیون آزمایشی، توسعه برنامه‌های میکروسرویس با استفاده از فناوری‌های ابری، جای خالی مهندسان زیرساخت و انواع ارجاعات به DevOps وجود دارد. فقط به یاد داشته باشید که هر شرکت با این تعریف معنای متفاوتی دارد - توضیحات را با دقت بخوانید.

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

این دلیلی است تا به شدت از شرکت دریابید که فرآیند تحویل نرم افزار چگونه کار می کند، پشته فناوری و مسئولیت هایی که انجام خواهید داد.

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

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

توجه به این نکته مهم است که تمرین‌کنندگان Devops تنها با تجربه در توسعه/اداره/آزمایش ارزش واقعی کسب می‌کنند. تنها در این صورت است که دانش انتزاعی نخواهد بود، بلکه متخصص (به تمام معنا) را غنی می کند. بنابراین، ایده "یادگیری DevOps از ابتدا" تقریباً مانند یادگیری "استفاده از لنز از ابتدا" است، اگر هرگز دوربینی را در دستان خود نگه نداشته اید یا فیلمبرداری را کارگردانی نکرده اید. برای اینکه به شما کمک کنیم تصمیم بگیرید که آیا این دوره برای شما مناسب است یا خیر، ما یک آزمون ورودی ساخته ایم که سطح دانش کافی شما را بررسی می کند.

به نظر من یکی از ترفندها دوره - که در طول دوره آموزش، هر دانش آموز برای خود تعیین می کند که در چه جهتی می خواهد پیشرفت کند. زمانی که یک توسعه‌دهنده مهندس زیرساخت می‌شود، و یک مدیر متوجه می‌شود که به نوشتن کد علاقه‌مند است، اغلب شاهد انتقال هستیم - سپس زبان را بیشتر مطالعه می‌کند و آن را با مهارت‌های DevOps اکتسابی تکمیل می‌کند. بنابراین، ما به ویژه از کسانی استقبال می کنیم که احساس می کنند شغلشان در یک دوراهی گیر کرده است. این دوره از 28 اردیبهشت شروع می شود، اما شما می توانید 2 هفته پس از شروع کلاس ها شرکت کنید. می توانید برنامه را مشاهده کرده و در آزمون شرکت کنید по ссылке. شما را در OTUS می بینیم!

منبع: www.habr.com

اضافه کردن نظر