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

نسخه جدید محصول آماده انتشار است، اما 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 اجرا کند و برای طراحی امنیت یا مهاجرت پیچیده از مشاور کمک بگیرد. پلتفرم الزاماً نیاز به متخصص را از بین نمی‌برد؛ دامنه کار او را از عملیات تکراری به مسائل اختصاصی‌تر منتقل می‌کند.

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

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

یک Sheet بسازید و برای هر گزینه این ردیف‌ها را ثبت کنید:

1. هزینه نیروی انسانی یا قرارداد

2. هزینه منابع اجرایی، دیتابیس، ذخیره‌سازی و ترافیک

3. هزینه ابزارهای مانیتورینگ، بکاپ و امنیت

4. زمان ماهانه تیم توسعه برای عملیات

5. زمان مدیریت تأمین‌کننده یا نیروی جدید

6. هزینه مهاجرت و خروج از گزینه انتخابی

7. اثر مالی وقفه‌های ثبت‌شده

8. هزینه مستندسازی و انتقال دانش

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

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

پاستا چه زمانی راه‌حل مناسبی نیست؟

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

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

وابستگی به پلتفرم نیز یک Trade-off واقعی است. پیش از انتخاب، مسیر خروج را بررسی کنید: آیا سورس، Dockerfile یا Compose لازم برای اجرای پروژه در محیط دیگری را دارید؟ داده‌های پایدار چگونه صادر می‌شوند؟ DNS و Secrets ها چگونه منتقل خواهند شد؟

اشتباهات رایج و مسیر تشخیص

هزینه پیشنهادی کمتر از انتظار است، اما زمان تیم توسعه کاهش پیدا نمی‌کند

• آنچه کاربر می‌بیند: ابزار یا تأمین‌کننده خریداری شده، ولی توسعه‌دهندگان همچنان استقرارها و رخدادها را دستی پیگیری می‌کنند.

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

• روش تشخیص: فعالیت‌های عملیاتی یک دوره را مرور کنید و برای هر مورد، مالک و ابزار اجرا را بنویسید.

• اقدام بعدی: مسئولیت‌ها را بازتعریف کنید و کارهای پرتکرار را برای خودکارسازی یا انتقال به تأمین‌کننده اولویت‌بندی کنید.

• آیا داده کاربر در خطر است؟ به‌خودی‌خود نه؛ ولی اگر مسئول بکاپ یا مدیریت Secret مشخص نباشد، ریسک عملیاتی وجود دارد.

استقرار روی پلتفرم انجام می‌شود، اما سرویس آماده نمی‌شود

• آنچه کاربر می‌بیند: Build یا استقرار کامل نمی‌شود، یا سرویس پس از اجرا وضعیت سالم نمی‌گیرد.

• علت‌های محتمل و تأییدشده: تنظیم نادرست پروژه، Dockerfile یا Compose، کمبود منابع انتخابی، متغیر محیطی ناقص یا Health Check ناسازگار با رفتار برنامه.

• روش تشخیص: نتیجه تشخیص پروژه، وضعیت Build، Log سرویس، متغیرهای محیطی و تنظیمات Health Check را بررسی کنید.

• اقدام بعدی: نخستین مرحله ناموفق را اصلاح کنید. Secret را داخل Repository یا Command history قرار ندهید.

• آیا داده کاربر در خطر است؟ شکست Build معمولاً داده سرویس موجود را تغییر نمی‌دهد، اما تغییرات دیتابیس یا Volume را جداگانه ارزیابی کنید.

 

پس از خروج نیروی زیرساخت، تیم به حساب‌ها دسترسی کامل ندارد

• آنچه کاربر می‌بیند: مالکیت دامنه، حساب ابری، Registry یا بکاپ با حساب شخصی فرد قبلی گره خورده است.

• علت‌های محتمل و تأییدشده: تیم مدیریت دسترسی سازمانی تعریف نکرده و فهرست دارایی‌ها یا فرایند خروج ندارد.

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

• اقدام بعدی: مالکیت را به حساب سازمانی منتقل کنید، دسترسی غیرضروری را لغو کنید و Secretهای در معرض دسترسی قبلی را بچرخانید.

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

چک‌لیست تصمیم برای CTO

• کارهای عملیاتی سه ماه گذشته را از Issue ها، رخدادها و گزارش زمان استخراج کنید.

• برای استقرار، DNS، دیتابیس، بکاپ، مانیتورینگ و پاسخ به رخداد یک مالک مشخص بنویسید.

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

• زمان عملیاتی توسعه‌دهندگان را از هزینه توسعه جدا کنید.

• هزینه سرور، ذخیره‌سازی، ترافیک، Registry، بکاپ و ابزارهای جانبی را در همه گزینه‌ها وارد کنید.

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

• برای مشاور یا برون‌سپاری، خروجی، سطح دسترسی و فرایند پایان قرارداد را مکتوب کنید.

• برای PaaS، سازگاری ورودی پروژه، نیاز به دیسک پایدار، دیتابیس، دامنه و Health Check را بررسی کنید.

• قیمت و موجودی منابع پاستا را هنگام تصمیم از صفحه قیمت‌گذاری زنده دریافت کنید.

• یک سناریوی خروج تعریف کنید و مشخص کنید انتقال سورس، داده، DNS و Secrets ها چگونه انجام می‌شود.

• بازیابی بکاپ را آزمایش کنید؛ وجود فایل بکاپ به‌تنهایی بازیابی‌پذیری را ثابت نمی‌کند.

• دسترسی‌های حیاتی را به حساب شخصی یک همکار محدود نکنید.

جمع‌بندی: اول مسئله را تفکیک کنید، بعد مدل همکاری را بخرید

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

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