DevOps چه کسانی هستند؟

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

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

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

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

پس مهندسان DevOps چه کسانی هستند؟

بیایید با تاریخچه ظهور آن شروع کنیم - عملیات توسعه به عنوان یک پیامد مورد انتظار به عنوان گام دیگری در جهت بهینه سازی تعامل در تیم های کوچک برای افزایش سرعت تولید محصول ظاهر شد. ایده این بود که تیم توسعه با دانش رویه ها و رویکردها در مدیریت محیط محصول تقویت شود. به عبارت دیگر، توسعه‌دهنده باید بفهمد و بداند که محصولش در شرایط خاص چگونه کار می‌کند، باید بفهمد که چگونه محصول خود را به کار گیرد، چه ویژگی‌هایی از محیط را می‌توان برای بهبود عملکرد تنظیم کرد. بنابراین، برای مدتی، توسعه دهندگان با رویکرد DevOps ظاهر شدند. توسعه دهندگان DevOps برای ساده کردن فعالیت های خود و عملکرد محیط تولید، اسکریپت های ساخت و بسته بندی نوشتند. با این حال، پیچیدگی معماری راه‌حل و تأثیر متقابل اجزای زیرساخت در طول زمان شروع به بدتر شدن عملکرد محیط‌ها کرد؛ با هر بار تکرار، درک عمیق‌تر از مؤلفه‌های خاص مورد نیاز بود که به دلیل موارد اضافی، بهره‌وری توسعه‌دهنده را کاهش داد. هزینه های درک اجزاء و سیستم های تنظیم برای یک کار خاص. هزینه خود توسعه دهنده افزایش یافت، هزینه محصول همراه با آن، الزامات توسعه دهندگان جدید در تیم به شدت افزایش یافت، زیرا آنها همچنین باید مسئولیت های توسعه "ستاره" را پوشش دهند و، طبیعتا، "ستاره ها" کمتر شدند. و کمتر در دسترس است. همچنین شایان ذکر است که طبق تجربه من، تعداد کمی از توسعه دهندگان به ویژگی های پردازش بسته توسط هسته سیستم عامل، قوانین مسیریابی بسته ها و جنبه های امنیتی میزبان علاقه مند هستند. گام منطقی جذب مدیری بود که با این امر آشنا بود و مسئولیت های مشابهی را به او واگذار کرد که به لطف تجربه او امکان دستیابی به همان شاخص ها را با هزینه کمتر در مقایسه با هزینه توسعه "ستاره" فراهم کرد. چنین مدیرانی در یک تیم قرار می گرفتند و وظیفه اصلی او مدیریت محیط های آزمایشی و تولیدی، طبق قوانین یک تیم خاص، با منابع تخصیص یافته به این تیم خاص بود. در واقع DevOps در ذهن اکثریت اینگونه ظاهر شد.

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

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

چرخه پس از چرخه، سیستم‌های مختلفی ظاهر می‌شوند که توسعه و/یا مدیریت را ساده می‌کنند، سیستم‌های ارکستراسیون ظاهر می‌شوند که تا زمانی که نیاز به انحراف از فرآیند استاندارد نداشته باشید، استفاده از آنها آسان است. معماری میکروسرویس نیز با هدف ساده کردن همه چیزهایی که در بالا توضیح داده شد ظاهر شد - روابط کمتر، مدیریت آسان تر. در تجربه‌ام، معماری کاملاً میکروسرویسی پیدا نکردم، می‌توانم بگویم 50 تا 50 - 50 درصد میکروسرویس‌ها، جعبه‌های سیاه، وارد شدند، پردازش‌شده بیرون آمدند، 50 مورد دیگر یکپارچه پاره شده‌اند، سرویس‌ها قادر به کار جدا از سایرین نیستند. اجزاء. همه اینها دوباره محدودیت هایی را بر سطح دانش توسعه دهندگان و مدیران اعمال کرد.

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

مهندس ساخت/مهندس انتشار

مهندسان بسیار متخصصی که به عنوان ابزاری برای استانداردسازی نرم افزارها، فرآیندها و انتشارات را ایجاد کردند. در روند معرفی گسترده Agile، به نظر می رسد که آنها دیگر مورد تقاضا نیستند، اما این بسیار دور از واقعیت است. این تخصص به عنوان وسیله ای برای استانداردسازی مونتاژ و تحویل نرم افزار در مقیاس صنعتی ظاهر شد، یعنی. استفاده از تکنیک های استاندارد برای تمام محصولات شرکت. با ظهور DevOps، توسعه دهندگان تا حدی عملکرد خود را از دست دادند، زیرا این توسعه دهندگان بودند که شروع به آماده سازی محصول برای تحویل کردند و با توجه به تغییر زیرساخت و رویکرد تحویل در سریع ترین زمان ممکن بدون توجه به کیفیت، به مرور زمان به متوقف کننده تغییرات است، زیرا رعایت استانداردهای کیفیت به ناچار سرعت تحویل را کاهش می دهد. بنابراین، به تدریج، بخشی از عملکرد مهندسان Build/Release به دوش مدیران سیستم منتقل شد.

عملیات بسیار متفاوت است

ما پیش می رویم و دوباره وجود طیف وسیعی از مسئولیت ها و کمبود پرسنل واجد شرایط ما را به سمت تخصصی شدن سخت سوق می دهد، مانند قارچ پس از باران، عملیات های مختلف ظاهر می شود:

• TechOps - مدیران سیستم enikey با نام مهندس HelpDesk
• LiveOps - مدیران سیستم در درجه اول مسئول محیط های تولید هستند
• CloudOps - مدیران سیستم متخصص در ابرهای عمومی Azure، AWS، GCP و غیره.
• PlatOps/InfraOps/SysOps - مدیران سیستم زیرساخت.
• NetOps - مدیران شبکه
• SecOps - مدیران سیستم متخصص در امنیت اطلاعات - انطباق با PCI، انطباق CIS، وصله و غیره.

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

برای انجام این نوع کارها و مسئولیت ها، این شخص باید ابزاری داشته باشد تا نه تنها فرآیندهای توسعه و آزمایش، بلکه مدیریت زیرساخت محصول و همچنین برنامه ریزی منابع را نیز مدیریت کند. DevOps در این درک نمی تواند نه در IT، نه در R&D، یا حتی در PMO قرار گیرد؛ بلکه باید در همه این زمینه ها نفوذ داشته باشد - مدیر فنی شرکت، مدیر ارشد فنی.

آیا این موضوع در شرکت شما صادق است؟ - شک ​​دارم. در بیشتر موارد، این یا IT یا تحقیق و توسعه است.

فقدان بودجه و توانایی تأثیرگذاری بر حداقل یکی از این سه حوزه فعالیت، وزن مشکلات را به سمت جایی که این تغییرات آسان‌تر اعمال می‌شوند، تغییر می‌دهد، مانند اعمال محدودیت‌های فنی در انتشار در ارتباط با کد «کثیف» مطابق با استاتیک. سیستم های آنالایزر یعنی وقتی PMO ضرب‌الاجل دقیقی برای انتشار عملکرد تعیین می‌کند، R&D نمی‌تواند نتیجه باکیفیت را در این مهلت‌ها ایجاد کند و آن را به بهترین شکل ممکن تولید می‌کند، و بازپرداخت را برای بعد موکول می‌کند، DevOps مربوط به IT انتشار را با ابزارهای فنی مسدود می‌کند. . فقدان اختیار برای تغییر وضعیت، در مورد کارکنان مسئول، منجر به تجلی مسئولیت بیش از حد در مورد آنچه که نمی توانند تأثیر بگذارند، می شود، به ویژه اگر این کارکنان اشتباهات را درک کنند و ببینند، و چگونه آنها را اصلاح کنند - "سعادت در جهل". و در نتیجه فرسودگی شغلی و از دست دادن این کارکنان.

بازار منابع DevOps

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

ما آماده ایم با شما ملاقات کنیم اگر:

1. شما صاحب Zabbix هستید و می دانید پرومتئوس چیست.
2. Iptables;
3. دانشجوی دکتری BASH;
4. پروفسور آنسیبل؛
5. استاد لینوکس؛
6. آشنایی با نحوه استفاده از اشکال زدایی و یافتن مشکلات برنامه همراه با توسعه دهندگان (php/java/python).
7. مسیریابی شما را هیستریک نمی کند.
8. توجه زیادی به امنیت سیستم داشته باشید.
9. پشتیبان گیری از "هر چیزی و همه چیز"، و همچنین با موفقیت این "هر چیزی و همه چیز" را بازیابی کنید.
10. شما می دانید که چگونه سیستم را به گونه ای پیکربندی کنید که حداکثر از حداقل بدست آورید.
11. Replication را قبل از رفتن به رختخواب در Postgres و MySQL تنظیم کنید.
12. تنظیم و تنظیم CI/CD به اندازه صبحانه/ناهار/شام برای شما ضروری است.
13. داشتن تجربه با AWS؛
14. آماده برای توسعه با شرکت؛

پس:

• از 1 تا 6 - مدیر سیستم
• 7 - کمی مدیریت شبکه که به مدیر سیستم نیز می رسد سطح متوسط
• 8 - امنیت کمی که برای یک مدیر سیستم سطح متوسط ​​الزامی است
• 9-11 – مدیر سیستم میانی
• 12 - بسته به وظایف محول شده، مدیر سیستم میانی یا مهندس ساخت
• 13 - مجازی سازی - مدیر سیستم میانی یا به اصطلاح CloudOps، دانش پیشرفته از خدمات یک سایت میزبانی خاص، برای استفاده بهینه از وجوه و کاهش بار تعمیر و نگهداری

با جمع بندی این جای خالی، می توان گفت که مدیر سیستم میانی / ارشد برای بچه ها کافی است.

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

بیایید جای خالی دیگری را در نظر بگیریم:

1. تجربه در ساخت سیستم های بار بالا؛
2. دانش عالی از سیستم عامل لینوکس، نرم افزار سیستم عمومی و پشته وب (Nginx، PHP/Python، HAProxy، MySQL/PostgreSQL، Memcached، Redis، RabbitMQ، ELK)؛
3. تجربه با سیستم های مجازی سازی (KVM، VMWare، LXC/Docker)؛
4. تسلط به زبان های برنامه نویسی؛
5. آشنایی با اصول عملکرد شبکه های پروتکل شبکه
6. آشنایی با اصول ساخت سیستم های مقاوم در برابر خطا
7. استقلال و ابتکار عمل؛

بیایید نگاهی بیندازیم به:

• 1 - مدیر ارشد سیستم
• 2 - بسته به معنی قرار داده شده در این پشته - مدیر سیستم میانی/ ارشد
• 3 - تجربه کاری، از جمله، ممکن است به این معنا باشد - "خوشه افزایش نمی دهد، بلکه ماشین های مجازی ایجاد و مدیریت می کند، یک میزبان Docker وجود دارد، دسترسی به کانتینرها در دسترس نبود" - مدیر سیستم میانه
• 4 - Junior System Administrator - بله، مدیری که نمی داند چگونه اسکریپت های اولیه اتوماسیون را بدون توجه به زبان بنویسد، نه یک admin - enikey.
• 5 - مدیر سیستم میانی
• 6 - مدیر ارشد سیستم

به طور خلاصه - مدیر سیستم میانی / ارشد

یکی دیگه:

1. تجربه Devops;
2. تجربه در استفاده از یک یا چند محصول برای ایجاد فرآیندهای CI/CD. Gitlab CI یک مزیت خواهد بود.
3. کار با کانتینرها و مجازی سازی؛ اگر از docker استفاده کردید، خوب است، اما اگر از k8s استفاده کردید، عالی است!
4. تجربه کار در یک تیم چابک؛
5. آشنایی با هر زبان برنامه نویسی؛

اجازه بدید ببینم:

• 1 - هوم... بچه ها یعنی چی؟ =) به احتمال زیاد آنها خودشان نمی دانند پشت آن چه چیزی پنهان شده است
• 2 - مهندس ساختمان
• 3 - مدیر سیستم میانی
• 4 - مهارت نرم، فعلاً آن را در نظر نمی گیریم، اگرچه Agile چیز دیگری است که به گونه ای مناسب تفسیر می شود.
• 5 - خیلی پرمخاطب - می تواند یک زبان برنامه نویسی یا یک زبان کامپایل شده باشد. نمی دانم آیا نوشتن به زبان پاسکال و پایه در مدرسه برای آنها مناسب است؟ =)

همچنین می خواهم در مورد نکته 3 یادداشتی بگذارم تا درک اینکه چرا این نکته توسط مدیر سیستم پوشش داده شده است را تقویت کنم. Kubernetes فقط یک ارکستراسیون است، ابزاری که دستورات مستقیم را به درایورهای شبکه و میزبان‌های مجازی‌سازی/ایزوله‌سازی در چند دستور می‌پیچد و به شما امکان می‌دهد ارتباط با آنها را انتزاعی کنید، همین. به عنوان مثال، بیایید ساخت چارچوب را در نظر بگیریم، که اتفاقاً من آن را چارچوبی در نظر نمی‌گیرم. بله، من در مورد مد هل دادن Make در هر جایی، جایی که لازم است و لازم نیست - پیچیدن Maven در Make، به طور جدی، می دانم؟
اساسا، Make فقط یک پوشش روی پوسته است که دستورات محیط کامپایل، پیوند و کامپایل را مانند k8s ساده می کند.

یک بار، با مردی مصاحبه کردم که از k8s در کار خود در بالای OpenStack استفاده می کرد، و او در مورد نحوه استقرار سرویس ها در آن صحبت کرد، با این حال، وقتی در مورد OpenStack پرسیدم، معلوم شد که مدیریت شده است، و همچنین توسط سیستم افزایش یافته است. مدیران آیا واقعاً فکر می کنید شخصی که OpenStack را نصب کرده است، صرف نظر از اینکه از چه پلتفرمی پشت سر خود استفاده می کند، قادر به استفاده از k8 نیست؟ =)
این متقاضی در واقع یک DevOps نیست، بلکه یک مدیر سیستم و به عبارت دقیق تر، یک مدیر Kubernetes است.

اجازه دهید یک بار دیگر خلاصه کنیم - مدیر سیستم میانی / ارشد برای آنها کافی است.

چقدر وزن بر حسب گرم

محدوده حقوق پیشنهادی برای مشاغل خالی مشخص شده 90 تا 200 هزار است
اکنون می‌خواهم بین پاداش‌های پولی مدیران سیستم و مهندسان DevOps تشبیه کنم.

در اصل، برای ساده کردن کارها، می توانید نمرات را بر اساس تجربه کاری پراکنده کنید، اگرچه این دقیق نیست، اما برای اهداف مقاله کافی است.

یک تجربه:

1. تا 3 سال - جوان
2. تا 6 سال - میانه
3. بیش از 6 - ارشد

سایت جستجوی کارمند ارائه می دهد:
مدیران سیستم:

1. جونیور - 2 سال - 50 هزار مالش.
2. وسط - 5 سال - 70 هزار مالش.
3. ارشد - 11 سال - 100 هزار روبل.

مهندسان DevOps:

1. جونیور - 2 سال - 100 هزار مالش.
2. وسط - 3 سال - 160 هزار مالش.
3. ارشد - 6 سال - 220 هزار روبل.

با توجه به تجربه "DevOps"، از تجربه ای استفاده شد که حداقل به نحوی بر SDLC تأثیر گذاشت.

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

فرآیند آموزش مهندسان DevOps نیز تنها به مجموعه‌ای از کارهای خاص، ابزارهای کاربردی محدود می‌شود و درک کلی از فرآیندها و وابستگی‌های آنها ارائه نمی‌کند. مطمئناً خوب است که شخصی بتواند AWS EKS را با استفاده از Terraform، همراه با کارگاه جانبی Fluentd در این خوشه و پشته AWS ELK برای سیستم گزارش‌گیری در 10 دقیقه، تنها با استفاده از یک فرمان در کنسول، استقرار دهد، اما اگر متوجه نشود اصل پردازش لاگ های خود و موارد مورد نیاز آنها، اگر نمی دانید چگونه معیارهای مربوط به آنها را جمع آوری کنید و خرابی سرویس را ردیابی کنید، باز هم همان enikey خواهد بود که می داند چگونه از برخی برنامه های کاربردی استفاده کند.

با این حال، تقاضا باعث ایجاد عرضه می شود و ما شاهد یک بازار بسیار داغ برای موقعیت DevOps هستیم که در آن الزامات با نقش واقعی مطابقت ندارند، بلکه تنها به مدیران سیستم اجازه می دهند تا درآمد بیشتری کسب کنند.

پس آنها چه کسانی هستند؟ DevOps یا مدیران سیستم حریص؟ =)

چگونه به زندگی ادامه دهیم؟

کارفرمایان باید الزامات را با دقت بیشتری فرموله کنند و دقیقاً به دنبال کسانی باشند که مورد نیاز هستند، نه اینکه برچسب ها را دور بزنند. شما نمی دانید DevOps چه می کند - در این صورت به آنها نیاز ندارید.

کارگران - یاد بگیرید. به طور مداوم دانش خود را بهبود بخشید، به تصویر کلی فرآیندها نگاه کنید و مسیر رسیدن به هدف خود را دنبال کنید. شما می توانید هر کسی که می خواهید شوید، فقط باید تلاش کنید.

منبع: www.habr.com