برای استخدام مهندس DevOps، فهرست بلند Linux، Docker، Kubernetes، Terraform و چند سرویس ابری به‌تنهایی کافی نیست. ممکن است یک نفر همه‌ی این ابزارها را بشناسد، اما هنوز نتواند درباره‌ی Rollback یک انتشار پرریسک تصمیم بگیرد. فرد دیگری با ابزارهای کمتر، مالکیت یک سرویس را از Pipeline تا پاسخ‌گویی به Incident بر عهده می‌گیرد.
این راهنما برای مدیر فنی، مسئول استخدام و مهندسی نوشته شده که می‌خواهد سطح موردنیاز یک موقعیت DevOps را مشخص کند. معیارهای زیر یک چارچوب پیشنهادی هستند؛ تعریف Junior و Senior بین شرکت‌ها فرق دارد و این جدول استاندارد رسمی صنعت نیست.
قبل از استخدام DevOps، مسئله‌ی تیم را تعریف کنید
اول مشخص کنید قرار است چه چیزی بهتر شود. آیا انتشارها دستی و خطاپذیرند؟ کسی مالک کلاستر نیست؟ Alert زیاد دارید اما نمی‌دانید کدام مهم است؟ یا چند تیم برای ساخت سرویس جدید به تنظیمات تکراری وابسته‌اند؟ پاسخ این سؤال‌ها از انتخاب عنوان شغلی مهم‌تر است.
| وضعیت تیم | نیاز اصلی | سطحی که باید بررسی شود |
|---|---|---|
| زیرساخت مستند و منتور در دسترس است | اجرای تغییرهای محدود و یادگیری عملیات | Junior با پشتیبانی مشخص |
| یک سرویس یا Pipeline موجود به مالک نیاز دارد | تحویل مستقل کار، عیب‌یابی و نگهداری | Mid-level |
| تصمیم‌ها چند سرویس و Production را تحت تأثیر می‌گذارند | طراحی، مدیریت ریسک و هماهنگی بین تیم‌ها | Senior |
| چند تیم به مسیر مشترک نیاز دارند | اولویت‌گذاری، استانداردها، منتورینگ و طراحی پلتفرم | Lead یا مسئول فنی پلتفرم |
تفاوت Junior، Mid-level، Senior و Lead در DevOps چیست؟
Junior: اجرای مطمئن کارهای محدود با راهنمایی
Junior باید مبانی Linux، شبکه، Git و اسکریپت‌نویسی را بفهمد، دستورها را با آگاهی اجرا کند و وقتی از اثر یک تغییر مطمئن نیست، سؤال بپرسد. از او انتظار نداریم به‌تنهایی معماری Production را انتخاب کند.
نمونه‌ی خروجی قابل ارزیابی: اصلاح یک Job در Pipeline آزمایشی، توضیح علت شکست آن و ثبت مراحل بررسی. توانایی خواندن Log، تشخیص خطای دسترسی یا DNS و نوشتن یک Runbook ساده، از حفظ کردن ده‌ها دستور ارزشمندتر است.
Mid-level: مالکیت مستقل یک سرویس یا مسیر تحویل
Mid-level مسئله را به کارهای قابل اجرا تبدیل می‌کند، راه‌حل را در Develop و Staging می‌آزماید و برای Production برنامه‌ی بازگشت دارد. او باید رابطه‌ی اپلیکیشن، زیرساخت، CI/CD و مانیتورینگ را دنبال کند، نه اینکه فقط بخش خودش را سالم بداند.
نمونه‌ی خروجی: ساخت Pipeline یک سرویس شامل تست، Build، اسکن، انتشار Image و استقرار کنترل‌شده؛ همراه با مستندات، مدیریت Secret و راه تشخیص شکست. برای جزئیات، راهنمای GitLab CI/CD نمونه‌ی مناسبی از این دامنه‌ی کار است.
Senior: تصمیم‌گیری در شرایط مبهم و مدیریت ریسک
Senior فقط سریع‌تر دستور نمی‌زند. باید بتواند بین چند راه‌حل با توجه به هزینه، پیچیدگی، امنیت و توان تیم انتخاب کند. مرز خرابی را محدود می‌کند، اثر تغییر روی سرویس‌های دیگر را می‌سنجد و تصمیم را برای توسعه‌دهنده و مدیر فنی توضیح می‌دهد.
نمونه‌ی خروجی: برنامه‌ی مهاجرت مرحله‌ای یک سرویس حساس، تعریف معیار توقف انتشار، طراحی Rollback و بازیابی داده، مشخص کردن مسئول هر مرحله و ثبت محدودیت‌های راه‌حل. «همه‌چیز را روی Kubernetes ببریم» بدون تحلیل نیاز، نشانه‌ی Senior بودن نیست.
Lead: شکل دادن به مسیر و توانمندی تیم
Lead علاوه بر قضاوت فنی، باید کارهای زیرساخت را اولویت‌بندی کند، مسئولیت‌ها را روشن نگه دارد و وابستگی تیم به یک نفر را کم کند. بسته به شرکت، این نقش ممکن است مسیر فنی داشته باشد یا با مدیریت افراد ترکیب شود؛ این دو را در شرح موقعیت صریح بنویسید.
نمونه‌ی خروجی: تعیین استاندارد Pipeline برای چند تیم، طراحی مسیر پذیرش آن، اندازه‌گیری زمان تحویل و نرخ شکست تغییر، منتورینگ و بازبینی Incidentها بدون سرزنش. تعداد ابزارهای نصب‌شده معیار موفقیت این نقش نیست.
ماتریس مهارت‌های DevOps برای استخدام
این ماتریس نقطه‌ی شروع گفت‌وگوست. لازم نیست هر فرد در تمام ردیف‌ها سطح یکسانی داشته باشد؛ برای مثال نقش Platform با نقش متمرکز بر CI/CD تفاوت دارد.
| حوزه | Junior | Mid-level | Senior | Lead |
|---|---|---|---|---|
| Linux و شبکه | Log، Process، Permission، DNS، HTTP و TLS | عیب‌یابی اتصال و مصرف منابع یک سرویس | تحلیل خرابی بین لایه‌ها و محدود کردن اثر آن | استاندارد عملیات و انتقال دانش بین تیم‌ها |
| Git و اسکریپت | تغییر کوچک، Review و Bash یا Python ساده | اتوماسیون تکرارپذیر با کنترل خطا | طراحی ابزار قابل نگهداری و تصمیم Build یا Buy | کاهش کار دستی با اولویت روشن و سنجش اثر |
| CI/CD | اصلاح Job و خواندن خروجی تست | Pipeline کامل یک سرویس و Rollback | استاندارد چند سرویس، Artifact معتبر و کنترل انتشار | مسیر مشترک تحویل و پذیرش آن توسط تیم‌ها |
| Docker و Kubernetes | ساخت Image و شناخت Pod، Service و Deployment | Probe، Resource، Helm و عیب‌یابی استقرار | ظرفیت، دسترسی، ارتقا و طراحی دامنه‌ی خرابی | تصمیم درباره‌ی پلتفرم و مدل مسئولیت تیم‌ها |
| مانیتورینگ | خواندن داشبورد و دنبال کردن Runbook | متریک و Alert قابل اقدام برای یک سرویس | SLI/SLO، تحلیل علت و کاهش Alert بی‌اثر | تعیین اولویت پایداری و فرایند یادگیری از Incident |
| امنیت | رعایت حداقل دسترسی و حفاظت از Secret | اسکن CI/CD، RBAC و مدیریت Secret | مدل تهدید، کنترل زنجیره‌ی تحویل و پذیرش ریسک | تبدیل کنترل‌های امنیتی به فرایند قابل استفاده |
| IaC | تغییر محدود با Review و فهم Plan | Module یا Role قابل استفاده و مدیریت State | طراحی تغییر امن و بازیابی زیرساخت | استاندارد مالکیت، Review و چرخه‌ی عمر زیرساخت |
| همکاری | سؤال دقیق و مستندسازی بررسی‌ها | هماهنگی مستقل با توسعه‌دهنده | توضیح Trade-off و منتورینگ | هم‌راستایی تیم‌ها، اولویت و رشد افراد |
همه‌ی ابزارها برای همه‌ی موقعیت‌ها الزامی نیستند
اگر زیرساخت شما روی سرور داخلی است، ندانستن یک سرویس اختصاصی AWS به‌تنهایی دلیل رد فرد نیست. در مقابل، کسی که فقط با پنل یک Cloud کار کرده باید بتواند درباره‌ی شبکه، هویت و خرابی زیرساخت هم استدلال کند. در تیم‌های ایرانی، محدودیت رجیستری و وابستگی به اینترنت نیز می‌تواند بخشی از سناریوی واقعی باشد؛ طراحی Mirror با Harbor و Nexus یکی از موضوع‌های مرتبط است.
برای هر مهارت مشخص کنید «از روز اول لازم»، «قابل یادگیری در شروع همکاری» یا «مزیت» است. این کار آگهی استخدام را دقیق‌تر و مقایسه‌ی نامزدها را منصفانه‌تر می‌کند.
سؤال‌های مصاحبه DevOps بر اساس سطح
به همه‌ی نامزدهای یک موقعیت، مسئله‌ی پایه‌ی یکسان بدهید و با سؤال‌های پیگیری عمق بررسی را بیشتر کنید. پاسخ خوب همیشه یک دستور مشخص نیست؛ فرضیات، ترتیب بررسی و توجه به خطر تغییر را هم ثبت کنید.
سناریوی CI/CD: بعد از انتشار، خطای ۵۰۰ زیاد شده است
- Junior: از کجا Log و نتیجه‌ی Job را پیدا می‌کنی؟ چه اطلاعاتی را پیش از ارجاع جمع می‌کنی؟
- Mid-level: چطور ارتباط خطا با نسخه‌ی جدید را بررسی می‌کنی؟ چه زمانی Rollback می‌کنی و چطور نتیجه را می‌سنجی؟
- Senior: اگر انتشار شامل تغییر دیتابیس باشد چه؟ چه تغییری در طراحی Release می‌دهی که ریسک تکرار کمتر شود؟
- Lead: تصمیم انتشار یا توقف با چه کسی است؟ چه استانداردی باید بین تیم‌ها مشترک شود؟
در پاسخ دنبال این باشید که فرد قبل از دست‌کاری Production شواهد جمع می‌کند، وضعیت کاربر را می‌سنجد و راه بازگشت را می‌فهمد. برای مطالعه‌ی تکمیلی، استراتژی‌های Rolling، Blue/Green و Canary را ببینید.
سناریوی Kubernetes: Pod در وضعیت Pending مانده است
Junior باید بتواند وضعیت و Eventها را بخواند. Mid-level باید فرضیه‌هایی مثل کمبود منابع، Taint، Affinity یا مشکل Volume را با شواهد بررسی کند. Senior باید علاوه بر رفع مورد فعلی، درباره‌ی ظرفیت، رفتار Scheduler و جلوگیری از اثر زنجیره‌ای صحبت کند. Lead باید روشن کند چه ابزار و مالکیتی به تیم کمک می‌کند مشکل مشابه را مستقل تشخیص دهد.
پاسخ «من همیشه Pod را حذف می‌کنم» بدون بررسی علت، شواهد کافی نیست. همچنین از روی یک پاسخ ضعیف، درباره‌ی کل توانایی فرد حکم قطعی ندهید؛ یک سؤال پیگیری فرصت توضیح می‌دهد.
سناریوی مانیتورینگ: تیم از Alert زیاد خسته شده است
از نامزد بخواهید یک Alert را انتخاب و توضیح دهد: چه علامتی از آسیب به کاربر می‌دهد، مسئول اقدام کیست و Runbook آن چیست؟ برای سطح بالاتر بپرسید چگونه اثر تغییر Alert را اندازه می‌گیرد و چه زمانی به‌جای آستانه‌ی مصرف منابع از SLO استفاده می‌کند. طراحی Alert با Prometheus و Alertmanager و Incident Response منابع مرتبط‌اند.
تمرین عملی کوتاه و منصفانه برای ارزیابی DevOps
یک سناریوی ساختگی با زمان مورد توافق، مثلاً ۶۰ تا ۹۰ دقیقه، آماده کنید. خروجی باید کوچک باشد؛ طراحی رایگان زیرساخت واقعی شرکت یا دسترسی به Production بخشی از این تمرین نیست. از قبل بگویید استفاده از مستندات و ابزارهای AI مجاز است یا نه و نتیجه را با توضیح خود فرد بسنجید.
نمونه‌ی تمرین: یک سرویس HTTP ساده، Dockerfile و Pipeline ناقص بدهید. از نامزد بخواهید مشکل Build را پیدا کند، یک تست Health اضافه کند و برای استقرار در Staging و بازگشت نسخه توضیح کوتاه بنویسد.
خروجی قابل تحویل:
- تغییر کوچک در فایل‌ها با توضیح علت؛
- دستور اجرای محلی و روش بررسی موفقیت؛
- فرضیات، محدودیت‌ها و آنچه در زمان تمرین انجام نشده؛
- برنامه‌ی Rollback و نکات مربوط به Secret و دسترسی.
برای Junior دامنه را به یک خطای مشخص محدود کنید. برای Mid-level استقلال در تکمیل مسیر را بسنجید. برای Senior و Lead، بعد از تمرین درباره‌ی Trade-offها، محدودیت تیم و نحوه‌ی تعمیم راه‌حل گفت‌وگو کنید؛ حجم کد بیشتر الزاماً امتیاز بیشتر ندارد.
چک‌لیست امتیازدهی در مصاحبه استخدام DevOps
پیش از مصاحبه، اهمیت هر معیار را با توجه به نقش تعیین کنید. مقیاس پیشنهادی زیر به ثبت شواهد کمک می‌کند و جایگزین قضاوت تخصصی نیست:
| امتیاز | شواهد مورد انتظار |
|---|---|
| ۰ | هنوز شاهد کافی نداریم یا پاسخ با مسئله ارتباط ندارد |
| ۱ | با راهنمایی، مسیر بررسی را پیدا می‌کند |
| ۲ | برای دامنه‌ی توافق‌شده مستقل کار می‌کند و نتیجه را بررسی می‌کند |
| ۳ | محدودیت‌ها و ریسک‌ها را توضیح می‌دهد و راه‌حل را برای استفاده‌ی دیگران قابل نگهداری می‌کند |
برای هر یک از معیارهای زیر یک شاهد کوتاه بنویسید: عیب‌یابی، تحویل تغییر، امنیت و Rollback، مانیتورینگ، مستندسازی و همکاری. اگر موضوعی پرسیده نشده، «ارزیابی نشد» ثبت کنید؛ آن را ضعف فرد حساب نکنید. جمع امتیاز را هم مستقیماً به عنوان Senior یا Lead تبدیل نکنید؛ دامنه‌ی مسئولیت و زمینه‌ی تجربه مهم است.
در شرح موقعیت شغلی DevOps چه بنویسیم؟
شرح موقعیت خوب باید به این سؤال‌ها پاسخ بدهد:
- زیرساخت فعلی چیست و چه کسی مالک آن است؟
- مهم‌ترین مسئله‌ای که انتظار دارید در شروع همکاری حل شود چیست؟
- فرد روی چند سرویس یا چند تیم اثر می‌گذارد و چه اختیاری دارد؟
- On-call، ساعات پوشش و مسیر Escalation چگونه است؟
- کدام مهارت‌ها ضروری‌اند و کدام‌ها را می‌توان حین کار یاد گرفت؟
- نوع همکاری، محل کار و بازه‌ی جبران خدمات چگونه تعریف شده‌اند؟
نمونه‌ی هدف روشن: «برای سرویس موجود، انتشار در Staging را تکرارپذیر کنیم، Rollback را آزمایش کنیم و Alertهای اصلی را به Runbook وصل کنیم.» این هدف از «تسلط به تمام ابزارهای DevOps» قابل ارزیابی‌تر است. زمان رسیدن به آن باید بعد از شناخت وضعیت واقعی توافق شود.
سؤال‌های رایج درباره مهارت‌ها و استخدام دواپس
چند سال سابقه برای Senior DevOps لازم است؟
تعداد سال به‌تنهایی معیار قابل اتکایی نیست. شواهد مالکیت Production، تصمیم در شرایط مبهم، مدیریت ریسک و کمک به رشد دیگران را بررسی کنید. پنج سال تکرار یک کار الزاماً با پنج سال افزایش مسئولیت یکسان نیست.
آیا مدرک CKA برای استخدام DevOps کافی است؟
CKA می‌تواند شاهدی از دانش Kubernetes باشد، اما جای تجربه‌ی تحویل نرم‌افزار، عیب‌یابی، امنیت و همکاری را نمی‌گیرد. مدرک را کنار تمرین عملی و بررسی سوابق بسنجید.
DevOps با SRE و Platform Engineering چه تفاوتی دارد؟
مرز این نقش‌ها در شرکت‌ها متفاوت است. SRE معمولاً روی قابلیت اطمینان و عملیات مبتنی بر SLO تمرکز دارد؛ Platform Engineering روی ساخت قابلیت‌های مشترک برای تیم‌های توسعه. نقش DevOps ممکن است بخش‌هایی از هر دو را پوشش دهد. مسئولیت واقعی را مشخص کنید، نه فقط عنوان را.
برای تیم کوچک، Kubernetes الزام است؟
خیر. انتخاب باید با نیاز استقرار، توان عملیات و هزینه‌ی نگهداری متناسب باشد. در بعضی تیم‌ها یک مسیر ساده‌ی Docker و CI/CD انتخاب مناسب‌تری است. مهندس باتجربه باید بتواند دلیل انتخاب یا کنار گذاشتن Kubernetes را توضیح دهد.
بررسی همکاری با سبحان میربابایی
من سبحان میربابایی، مهندس ارشد DevOps هستم. تمرکز سوابقم روی CI/CD، Kubernetes، مانیتورینگ و DevSecOps در زیرساخت‌های بانکی، مخابراتی و فین‌تک است. جزئیات مسئولیت‌ها، ابزارها و گواهینامه‌ها در رزومه‌ی من آمده است.
اگر برای تیم خود به دنبال استخدام متخصص DevOps یا بررسی یک همکاری فنی هستید، صفحه‌ی همکاری با کارفرماها را ببینید. با توضیح نیاز تیم و دامنه‌ی مسئولیت می‌توانیم درباره‌ی تناسب تجربه‌ی من با موقعیت شما گفت‌وگو کنیم.