توسعه دهندگان نمی خواهند عملیات انجام دهند

توسعه‌دهندگان تحت این خواسته‌های «شما می‌سازید، اجرا می‌کنید» فشار می‌آورند و اپراتورها نیز فشار بیشتری را احساس می‌کنند. آیا زمان آن فرا رسیده است که توسعه و عملیات یک بار دیگر از هم جدا شوند؟

با پیچیدگی‌تر شدن کار توسعه نرم‌افزار، ممکن است زمان آن فرا رسیده باشد که متخصصان توسعه و عملیات یک بار دیگر از هم جدا شوند. اما آیا می توان بدون تکرار اشتباهات گذشته این کار را انجام داد؟

Devops همزمان با ظهور روش‌های چابک و رایانش ابری در اواخر دهه ۲۰۰۰ ظهور کردند، به‌عنوان نرم افزار شروع به خوردن دنیا کرد. یک مجموعه منظم از “توسعه” و “عملیات”، توسعه دهندگان به دنبال گردآوری دو گروه جداگانه قبلی بودند که مسئول ساخت و استقرار نرم افزار بودند. همچنین با نیاز مهندسان نرم‌افزار به تقویت حلقه‌های بازخورد کاربر و یا حتی بیشتر به‌روزرسانی به‌روزرسانی‌ها به تولید، مصادف شد، یا حتی به‌طور ناخواسته به جلو رانده شد.

در حالی که بسیاری از سازمان‌ها از این فرصت استفاده کردند تا دو مجموعه از متخصصان را گرد هم بیاورند تا مشکلات مشترک را با سرعت‌هایی که قبلاً غیرممکن بود، حل کنند، برخی دیگر ظهور devops را به عنوان مجوز برای توسعه‌دهندگان در نظر گرفتند تا مسئولیت وظایف عملیاتی را بر عهده بگیرند و به دنبال ایجاد یک تیم فوق‌العاده از

a>توسعه دهندگان تمام پشته نیمه افسانه ای.

«توسعه‌ها در بیشتر موارد نمی‌خواهند با نگرانی‌های عملیاتی مقابله کنند» توییت کرد Devops for Dummies نویسنده و مدیر مشارکت جامعه در خدمات وب آمازون، امیلی فریمن.

Freeman به وضوح به اعصاب خود ضربه زد، با صدها پاسخ از سوی توسعه دهندگانی که همچنین نمی خواستند عملیات انجام دهند.

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

«توسعه‌دهنده‌ها و عملیات‌ها باید در عین داشتن نقش‌های متفاوت، از نزدیک با هم کار کنند. اندرو گریسی، مبشر توسعه‌دهنده در SUSE، می‌گوید همدلی بین تیم‌ها نکته واقعی است.

در حالی که مفهوم تغییر نگرانی‌های عملیاتی و امنیتی بیشتر به “چپ” و به حوزه توسعه‌دهندگان نرم‌افزار به وضوح شایستگی‌های خود را دارد، همچنین پتانسیل ایجاد یک گلوگاه خطرناک را دارد.

“اگر توسعه دهندگان را به مناطق مختلف زیادی بکشید، در نهایت به پای خود شلیک می کنید. جیمز براون، رئیس محصول Ondat متخصص ذخیره سازی Kubernetes، به InfoWorld گفت: آنها مهارت های متفاوتی دارند.

یا همانطور که نیک دورکین، مدیر ارشد فناوری در هارنس می‌گوید، “مردم در حال درک هستند که ما یک برق‌کار را برای انجام لوله‌کشی خود استخدام نمی‌کنیم.”

افزایش “عظیم” در مسئولیت ها

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

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

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

دوگان نوشت: «به نظر من، وضعیت هرگز تا این حد تیره نبوده است. “توسعه به طور کامل با افزایش گسترده در دامنه مسئولیت های آنها (RIP QA) و همچنین با انتظارات غیرواقع بینانه مدیریت در مورد سرعت مواجه شده است.”

این فشار ممکن است در حال آشکار شدن باشد.

“ساختن سازمانی که به این سطح از هماهنگی تکراری دست یابد که برای یک دوره پایدار ادامه دارد، فوق العاده چالش برانگیز است” نوشت تایلر جول، مدیر عامل Dell Technologies Capital در یادداشتی تحقیقاتی. با افزایش پیچیدگی سیستم‌ها و افزایش بازخورد کاربر نهایی، استدلال کردن درباره تأثیر یک تغییر بر روی سیستم برای انسان به طور فزاینده‌ای دشوار می‌شود.»

تشخیص مشکل

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

دورکین Harness گفت: «هدف این نیست که بار را بر دوش توسعه‌دهنده بگذاریم، بلکه توانمندسازی توسعه‌دهندگان با اطلاعات مناسب در زمان مناسب است. آنها نمی‌خواهند همه چیز را پیکربندی کنند، اما اطلاعات آن سیستم‌ها را در زمان مناسب می‌خواهند تا به تیم‌های عملیاتی، امنیتی و زیرساختی اجازه دهند تا به درستی کار کنند. توسعه دهندگان نباید اهمیتی بدهند مگر اینکه چیزی خراب شود.”

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

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

«کنترل برنامه‌نویس بر زیرساخت یک پیشنهاد همه یا هیچ نیست،» لیدیا لئونگ، تحلیلگر گارتنر نوشت. مسئولیت را می توان در طول چرخه عمر برنامه تقسیم کرد، به طوری که می توانید از مزایای “شما آن را می سازید، شما اجرا می کنید” بدون اینکه لزوماً توسعه دهندگان خود را با چتر نجات در یک بیابان رام نشده و ناشناخته بفرستید و برای آنها آرزوی موفقیت در بقا داشته باشید، زیرا این یک زیرساخت نیست و مشکل تیم عملیات دیگر”

به عبارت دیگر، “کاملاً اشکالی ندارد که به توسعه دهندگان خود اجازه دسترسی کامل سلف سرویس به محیط های توسعه و آزمایش، و توانایی ساخت زیرساخت به عنوان الگوهای کد برای تولید، بدون اینکه آنها را به طور کامل مسئول تولید بکنید، کاملاً اشکالی ندارد.”

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

در واقع، طبق گزارش “وضعیت Kubernetes در سال ۲۰۲۲” VMware< /a>، ۵۴٪ از ۷۷۶ پاسخ دهندگان گفتند که کارایی بهتر توسعه دهندگان دلیل اصلی پذیرش Kubernetes است و بیش از یک سوم (۳۷٪) گفتند که می خواهند کارایی اپراتور را بهبود بخشند.

کاسپار فون گرونبرگ، بنیانگذار Humanitec، “در تلاش برای متخصص ساختن همه افراد دچار اشتباه نشوید.” ” rel=”nofollow”>در خبرنامه ایمیلی خود نوشت. «در با عملکرد بالا تیم‌ها، تعداد کمی از کارشناسان برجسته در Kubernetes وجود دارد، و سطح بالایی از انتزاع برای پایین نگه داشتن بار شناختی برای دیگران وجود دارد.”

Devops مرده است

اگر دوره devops واقعاً به پایان می رسد، یا حتی اگر براقیت تازه شروع به از بین رفتن کرده است، بعد چه می شود؟

مهندسی قابلیت اطمینان سایت (SRE)، که از Google بیرون آمد و زمانی که مشکلات رو به رشد مربوط به توسعه خود را متحمل شد، یک راه حل محبوب ثابت شده است.

بن ترینور، معاون مهندسی در Google و پدرخوانده SRE، اغلب می‌گوید: «در اساس، وقتی از یک مهندس نرم‌افزار می‌خواهید یک عملکرد عملیاتی را طراحی کند، این اتفاق می‌افتد.

دو مؤسسه مالی بزرگ، Vanguard و Morgan Stanley را در نظر بگیرید، که به سختی می‌توانند بین مسئولیت‌های توسعه‌دهنده و عملیاتی تعادل ایجاد کنند، زیرا آنها به سمت شیوه‌های ابر بومی بیشتر می‌روند.

قرار دادن یک پتوی ایمنی SRE در سطح عملیات مرکزی و در تیم‌های توسعه‌دهنده به هر دو شرکت کمک کرده است تا اطمینان حاصل کنند که تعادل مناسبی بین سرعت توسعه‌دهنده و ثبات عملیاتی ایجاد می‌کنند.

با این حال، تابع SRE نیز انتقاداتی را به دنبال داشته است. همانطور که تروور برازنان، رئیس توسعه و معماری فناوری سازمانی در مورگان استنلی، مشاهده کرد، ایجاد اصول SRE “گاهی اوقات به عنوان تغییر نام تجاری تیم عملیات اشتباه درک می شود”.

کریستینا یاکومین، مهندس قابلیت اطمینان سایت در Vanguard، گفت: “این یک مشکل ظریف برای حل است.” “معرفی SRE باعث می شود مردم احساس کنند که ما دوباره در حال انجام عملیات در آن نقش هستیم.” در عوض، Yakomin می‌خواهد توسعه‌دهندگان و متخصصان عملیات Vanguard را تشویق کند تا مسئولیت امنیت را به اشتراک بگذارند و اطمینان حاصل کند که تیم‌هایی با پلت‌فرم‌های مشترک مسئولیت عملیاتی کامل آنها را بر عهده می‌گیرند.

زنده باد مهندسی پلت فرم

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

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

“Devops مرده است، زنده باد مهندسی پلت فرم”، توئیت کرد a> مهندس نرم افزار و مفسر Sid Palas را توسعه می دهد. «توسعه‌دهندگان دوست ندارند با زیرساخت‌ها سروکار داشته باشند، شرکت‌ها در حین رشد به کنترل زیرساخت‌های خود نیاز دارند. مهندسی پلتفرم این دو واقعیت را قادر می‌سازد تا در کنار یکدیگر وجود داشته باشند.”