DevOps یا اینکه چگونه دستمزدها و آینده صنعت IT را از دست می دهیم

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

هنگام خواندن جای خالی، گاهی اوقات حتی نه 2-3 نفر، بلکه یک شرکت کامل را در یک نفر می بینید، همه عجله دارند، بدهی فنی در حال رشد است، میراث قدیمی در پس زمینه محصولات جدید کمال به نظر می رسد، زیرا حداقل آن را داشته است. داک ها و نظرات در کد، محصولات جدید با سرعت نور نوشته می شوند، اما در نهایت پس از نوشتن آنها یک سال دیگر نمی توان از آنها استفاده کرد و اغلب امسال سودی به همراه ندارد؛ علاوه بر این، هزینه های "ابر" ” بالاتر از فروش خدمات هستند. پول سرمایه گذار صرف نگهداری سرویسی می شود که هنوز کار نمی کند، اما قبلاً به صورت آنلاین به عنوان سرویس کارآمد منتشر شده است.
به عنوان مثال: یک شرکت مشهور که ریمستر یک بازی قدیمی کمترین امتیاز را در کل تاریخ صنعت دریافت کرد. من یکی از کسانی بودم که این محصول را خریدم اما الان هم این محصول به طرز وحشتناکی کار می کند و از نظر تئوری نباید به این شکل به فروش می رسید. بازپرداخت، کاهش رتبه ها، تعداد زیادی ممنوعیت کاربران در انجمن ها برای شکایت در مورد کار خدمات. تعداد وصله ها شگفت انگیز نیست، اما وحشتناک است، اما همچنان، محصول قابل استفاده نیست. اگر این رویکرد برای شرکتی که از سال 91 در حال توسعه است منجر به چنین نتایجی شود، برای شرکت هایی که تازه شروع به کار کرده اند، وضعیت حتی بدتر است.

اما ما به نتایج این رویکرد از سمت کاربر سرویس نگاه کردیم و اکنون بیایید به مشکلاتی که کارمندان با آن برخورد کردند نگاه کنیم.

من اغلب این جمله را می شنوم که تیم های DevOps نباید وجود داشته باشند، این یک متدولوژی است و غیره، اما مشکل اینجاست که شرکت ها به دلایلی دیگر به دنبال noks، dba، زیرساخت ها و مهندسین ساخت نیستند - اکنون همه اینها یک مهندس DevOps است. . البته هنوز هم چنین جای خالی در شرکت ها وجود دارد، اما تعداد آنها کمتر و کمتر می شود. خیلی ها این را توسعه می نامند، من شخصاً در آن تنزل می بینم، حفظ سطح دانش خوب در همه زمینه ها غیرممکن است و در عین حال نمی توان بیش از 8 ساعت کار کرد. طبیعتاً اینها تخیلات هستند. در واقع، بسیاری از کارکنان فناوری اطلاعات مجبور به کار 12 یا 14 ساعتی هستند که از این تعداد 8 ساعت حقوق دریافت می کنند. و اغلب بدون روز مرخصی، زیرا "به من وظیفه داده شده است، هیچ مدرک و مدارکی وجود ندارد و خدمات هزینه دارد." و برای یک اشتباه در فضای ابری، اساساً نمی توانید در عرض چند ماه حقوق دریافت کنید، به خصوص اگر به عنوان یک کارآفرین فردی کار کنید. ما اساساً در حال از دست دادن قدرت خود در تجارت، همراه با تقسیم مسئولیت ها هستیم؛ من به طور فزاینده ای با این واقعیت مواجه می شوم که مدیران در فرآیندهای توسعه دخالت می کنند بدون اینکه اصلاً چیزی در مورد آنها درک کنند، آنها داده های تجاری و عملکرد برنامه را با هم اشتباه می گیرند، و به عنوان در نتیجه، هرج و مرج آغاز می شود.

هنگامی که هرج و مرج شروع می شود، کسب و کار می خواهد مقصر را پیدا کند، و در اینجا آنها به یک مقصر جهانی نیاز دارند؛ مقصر دانستن بیش از 10 نفر دشوار است، بنابراین مدیران موقعیت ها را ترکیب می کنند، زیرا هر چه یک متخصص مسئولیت های بیشتری داشته باشد، آسان تر است بی توجهی خود را ثابت کند و در شرایط Agile، یافتن "گناهکار" و شلاق زدن اساس این روش برای انجام تجارت در مدیریت است. Agile مدتها پیش از فناوری اطلاعات بیرون آمد و مفهوم اصلی آن به الزام نتایج روزانه تبدیل شد. مشکل این است که یک متخصص بسیار تخصصی همیشه نتایج روزانه نخواهد داشت، به این معنی که گزارش آن دشوارتر خواهد بود، و این دلیل دیگری است که کسب‌وکارها «متخصص در همه چیز» می‌خواهند. اما دلیل اصلی، البته، حقوق و دستمزد است - این دلیل اصلی همه تغییرات است، به خاطر پاداش، مردم موافقت کردند که برای خود و آن مرد کار کنند. اما در نهایت، مانند سایر حوزه‌ها، اکنون به سادگی به یک مسئولیت تبدیل شده است، هزینه کمتری برای تعداد بیشتری از خدمات ارائه شده.

امروزه حتی می‌توانید مقالاتی را ببینید که بیان می‌کنند توسعه‌دهندگان نیز باید بتوانند در زیرساخت‌ها در کنار یک مهندس DevOps کار کنند، اما این به چه چیزی منجر می‌شود؟ درست است - به کاهش کیفیت خدمات، به افت کیفیت توسعه دهندگان. همین 2 روز پیش به توسعه دهنده توضیح دادم که می توانید از هاست های مختلف بنویسید و بخوانید و آنها از دهانشان کف زدند تا ثابت کنند چنین چیزی را ندیده اند اما در تنظیمات orm host, port, db, user وجود دارد. ، پسورد و بس…. اما توسعه دهنده می داند که چگونه استقرارها را اجرا کند، یام را بنویسد... اما او قبلاً آزمایش های واحد و نظرات موجود در کد را فراموش می کند.

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

من یک بار در ITGM ارائه کردم "وقتی یاد می گیریم "نه" بگوییم - نتایج آن بسیار آشکار بود. تعداد زیادی از مردم بر این باورند که این کلمه تابو است و تا زمانی که ما اینگونه فکر نکنیم، مشکلات فقط رشد خواهند کرد.

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

فقط کاربران ثبت نام شده می توانند در نظرسنجی شرکت کنند. ورود، لطفا.

آیا تا به حال در محل کار برخورد کرده اید که یک کارفرما بخواهد چندین نفر را با شما جایگزین کند؟

  • ٪۱۰۰بله، مرتباً با آن برخورد می کنم183

  • ٪۱۰۰بله، 1 بار با آن برخورد کردم

  • ٪۱۰۰متوجه نشدم43

  • ٪۱۰۰من یک معتاد به کار هستم، خودم اضافه کار می کنم38

279 کاربر رای دادند. 34 کاربر رای ممتنع دادند.

منبع: www.habr.com

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