هزینه واقعی استخدام یک دواپس در ایران و سه جایگزین آن

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

برای تصمیم درست باید هزینه نیروی انسانی، ابزار، زیرساخت، ریسک وابستگی و زمان تیم توسعه را کنار هم ببینید. گاهی استخدام تمام‌وقت منطقی است؛ گاهی مشاور، برون‌سپاری عملیات یا PaaS نیاز تیم را با ساختار هزینه مناسب‌تری پوشش می‌دهد.

پاسخ سریع: هزینه واقعی دواپس را چگونه حساب کنیم؟

هزینه واقعی استخدام نیروی DevOps از مجموع این موارد ساخته می‌شود:

هزینه واقعی DevOps =  هزینه همکاری مستقیم + مزایا و الزامات استخدام + هزینه جذب و جایگزینی + ابزارها و زیرساخت عملیاتی + زمان سایر اعضای تیم + هزینه وقفه و خطای عملیاتی

عدد یکسانی برای همه شرکت‌ها وجود ندارد. حقوق دواپس در ایران به سطح تجربه، شیوه همکاری، دامنه مسئولیت، شهر، نوع محصول و حساسیت سرویس بستگی دارد. مقایسه صرفاً بر اساس حقوق ماهانه می‌تواند تصمیم را منحرف کند.

نیازهای عملیاتی سه ماه گذشته را فهرست کنید: استقرار، مانیتورینگ، پاسخ‌گویی به رخداد، مدیریت دیتابیس، شبکه، امنیت، CI/CD و ظرفیت‌سنجی. بعد مشخص کنید کدام کارها دائمی‌اند و کدام را می‌توان به ابزار یا تأمین‌کننده سپرد.

هزینه دواپس از چه اجزایی تشکیل می‌شود؟

برای محاسبه، هزینه‌ها را در چهار سبد قرار دهید.

هزینه مستقیم همکاری

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

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

هزینه ابزار و زیرساخت

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

بعضی ابزارهای متن‌باز لایسنس پولی ندارند؛ نصب، ارتقا، پایش و رفع اشکال آن‌ها همچنان زمان می‌برد. نرم‌افزار رایگان به معنای عملیات رایگان نیست.

هزینه اختلال و وابستگی

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

هزینه رخداد را می‌توانید با این مدل بررسی کنید:

هزینه مورد انتظار رخداد =  احتمال تقریبی رخداد × مدت اثر × هزینه اثر بر کسب‌وکار و تیم

این فرمول پیش‌بینی دقیق مالی نیست؛ فقط مانع می‌شود ریسک عملیاتی را در جلسه تصمیم‌گیری صفر در نظر بگیرید.

هزینه پنهان تیم توسعه

وقتی عملیات مالک مشخصی ندارد، توسعه‌دهندگان بخشی از وقت خود را صرف بررسی Log، تنظیم DNS، رفع مشکل Build و نگهداری سرور می‌کنند. این زمان را ثبت کنید.

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

چه زمانی استخدام DevOps تمام‌وقت انتخاب درستی است؟

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

نشانه‌های مناسب‌بودن استخدام تمام‌وقت عبارت‌اند از:

• چند تیم توسعه یا چند محیط اجرایی دارید و تغییرات زیرساختی مداوم‌اند.

• معماری به شبکه، امنیت، مشاهده‌پذیری یا سیاست‌های استقرار اختصاصی نیاز دارد.

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

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

• برای انتقال دانش، مستندسازی و پوشش زمان نبود یک نفر برنامه دارید.

نیروی DevOps نباید به کسی تبدیل شود که همه درخواست‌های استقرار از صف او عبور می‌کنند. اگر هر تغییر ساده به دخالت دستی یک نفر نیاز دارد، تیم یک گلوگاه تازه ساخته است.

برای سنجش زیرساخت خام در برابر پلتفرم، مطالعه «PaaS یا سرور مجازی؟ کدام برای تیم شما مقرون‌به‌صرفه‌تر است» مکمل این تصمیم است.

سه جایگزین استخدام DevOps چه هستند؟

گزینه اول: مشاور یا نیروی پاره‌وقت

مشاور برای تیمی مناسب است که به طراحی اولیه، بازبینی معماری، ساخت CI/CD، تعریف سیاست بکاپ یا حل مسئله‌ای مشخص نیاز دارد، اما هنوز کار دائمی کافی برای استخدام تمام‌وقت ندارد.

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

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

گزینه دوم: برون‌سپاری زیرساخت و عملیات

در برون‌سپاری زیرساخت، تیمی بیرونی مسئول مجموعه مشخصی از کارها می‌شود؛ برای مثال نگهداری سرورها، مانیتورینگ، بکاپ یا اجرای تغییرات.

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

پیش از قرارداد، این موارد را روشن کنید:

• مالک حساب‌های زیرساخت و دامنه چه کسی است؟

• دسترسی تأمین‌کننده چگونه ایجاد و لغو می‌شود؟

• بکاپ کجا نگهداری و چگونه بازیابی می‌شود؟

• تغییر اضطراری چه فرایندی دارد؟

• پس از پایان همکاری، مستندات و تنظیمات چگونه تحویل داده می‌شوند؟

• کدام فعالیت‌ها داخل مبلغ قرارداد هستند و کدام جداگانه محاسبه می‌شوند؟

گزینه سوم: استفاده از PaaS

PaaS بخشی از مسیر تبدیل کد به سرویس در حال اجرا را به‌صورت پلتفرمی ارائه می‌کند. این مدل می‌تواند کارهای تکراری مانند Build، استقرار یا Deploy، مشاهده وضعیت سرویس، مدیریت متغیر محیطی، اتصال دامنه و دسترسی به Log را از دوش تیم بردارد.

پاستا یک PaaS فارسی است که پروژه را از ورودی‌هایی مانند Repository گیت، Dockerfile، Docker Compose، ZIP پروژه یا Docker Image عمومی دریافت می‌کند. کاربر باید بتواند نتیجه تشخیص پروژه را پیش از Build بررسی کند و وضعیت Build و استقرار را ببیند.

این سازوکار نیاز به دانش عملیات را حذف نمی‌کند. تیم شما همچنان درباره معماری اپلیکیشن، مقدار منابع، نگهداری داده، متغیرهای محیطی، Secret ها و رفتار نرم‌افزار هنگام خرابی تصمیم می‌گیرد.

پاستا برای سرویس‌های سازگار قابلیت‌هایی مانند HTTPS، دامنه شخصی، Health Check، Log، دیسک پایدار و دیتابیس مدیریت‌شده دارد. قیمت، موجودی پلن‌ها، ناحیه‌ها، نسخه دیتابیس و ظرفیت‌ها متغیرند؛ آن‌ها را در صفحه زنده قیمت‌گذاری بررسی کنید.

معیار	استخدام تمام‌وقت	مشاور پاره‌وقت	برون‌سپاری	PaaS
مالکیت عملیات روزانه	داخل تیم	معمولاً محدود	طبق قرارداد	میان تیم و پلتفرم تقسیم می‌شود
مناسب برای تغییرات اختصاصی	زیاد	مناسب پروژه مشخص	وابسته به قرارداد	محدود به قابلیت‌های پلتفرم
وابستگی به فرد	ممکن است زیاد باشد	ممکن است زیاد باشد	وابستگی به تأمین‌کننده	وابستگی به پلتفرم
نیاز به مدیریت سرور و ابزار	معمولاً باقی می‌ماند	باقی می‌ماند	به تأمین‌کننده منتقل می‌شود	بخشی از آن پشت پلتفرم قرار می‌گیرد
نیاز به دانش داخل تیم	زیاد	برای تحویل‌گیری ضروری	برای نظارت ضروری	برای معماری و عیب‌یابی اپلیکیشن ضروری
مدل هزینه	نیروی انسانی و ابزار	قرارداد زمانی یا پروژه‌ای	قرارداد خدمت و زیرساخت	منابع و قابلیت‌های انتخاب‌شده

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

مقاله «دواپس استخدام کنیم، برون‌سپاری کنیم یا پلتفرم بخریم» مقایسه قراردادی و سازمانی این مدل‌ها را تکمیل می‌کند.