سوالات مصاحبه دواپس (DevOps) + پاسخ‌های کامل و کاربردی

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

در این مقاله، سؤال‌های پرتکرار مصاحبه برای موقعیت‌های Junior و Mid را از Linux، Git و Docker تا Kubernetes و سناریوهای عیب‌یابی مرور می‌کنیم. پاسخ‌ها کوتاه و کاربردی‌اند تا بتوانید پیش از مصاحبه نکات اصلی را سریع مرور کنید.

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

 سؤالات مصاحبه DevOps برای سطح Junior

در مصاحبه Junior قرار نیست جواب همه‌چیز را بدانید. چیزی که بیشتر اهمیت دارد این است که مفاهیم پایه را درست فهمیده باشید و بتوانید ارتباط میان آن‌ها را توضیح دهید. مثلاً فقط تعریف Docker کافی نیست؛ باید بدانید چرا از کانتینر استفاده می‌کنیم یا یک Pipeline چه مشکلی را در فرایند انتشار حل می‌کند.

سؤال‌های این بخش بیشتر روی همین پایه‌ها متمرکزند: از مفهوم DevOps و CI/CD تا Linux، شبکه، Git و Docker. در بعضی سؤال‌ها هم مصاحبه‌گر با یک «چرا؟» یا «اگر این اتفاق بیفتد چه می‌کنی؟» بررسی می‌کند که دانسته‌هایتان چقدر از تعریف‌های حفظی فراتر رفته است.

مفاهیم پایه و فرهنگ DevOps

این سؤال‌ها مشخص می‌کنند چقدر با منطق DevOps، همکاری بین تیم‌ها و فرایندهایی مثل CI/CD و Automation آشنا هستید.

سؤال‌ ۱: DevOps چیست و چه مسئله‌ای را حل می‌کند؟

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

مهارت مورد سنجش: اینکه DevOps را یک نقش یا فهرستی از ابزارها نمی‌دانید و منطق پشت آن را درک کرده‌اید.

برای مرور دقیق‌تر این مفهوم و اصول آن می‌توانید مقاله DevOps چیست را بخوانید.

سؤال‌ ۲: تفاوت Continuous Integration و Continuous Delivery چیست؟

پاسخ کلیدی: در Continuous Integration یا CI تغییرات کد مرتب با کد اصلی ادغام می‌شوند و فرایندهایی مثل Build و Test به‌صورت خودکار اجرا می‌شوند. در Continuous Delivery این مسیر تا آماده‌شدن یک نسخه قابل انتشار ادامه پیدا می‌کند؛ اما انتشار در Production می‌تواند همچنان به تأیید دستی نیاز داشته باشد.

سؤال تکمیلی احتمالی: Continuous Deployment چه تفاوتی دارد؟
در Continuous Deployment، تغییراتی که تمام مراحل Pipeline را با موفقیت طی کنند، بدون تأیید دستی وارد Production می‌شوند.

سؤال‌ ۳: چرا Automation در DevOps مهم است؟

پاسخ کلیدی: چون کارهایی مثل Build، Test و Deployment بارها تکرار می‌شوند. خودکارکردن آن‌ها علاوه بر سرعت، اجرای یکسان و قابل‌تکرار فرایند را ممکن می‌کند و احتمال خطای انسانی را کاهش می‌دهد.

Linux و مبانی شبکه

سؤال‌های این بخش، تسلط شما به لینوکس و عیب‌یابی مشکلات پایه شبکه را می‌سنجند.

سؤال‌ ۴: اگر بخواهید Processهای در حال اجرا را در لینوکس بررسی کنید، از چه دستورهایی استفاده می‌کنید؟

پاسخ کلیدی: بسته به نیاز می‌توان از ps برای مشاهده Processها و از top یا htop برای بررسی لحظه‌ای آن‌ها و مصرف CPU و Memory استفاده کرد. اگر دنبال Process مشخصی باشم، می‌توانم خروجی ps را با grep فیلتر کنم یا از pgrep استفاده کنم.

مهارت مورد سنجش: آشنایی عملی با مدیریت Processها در لینوکس، نه صرفاً حفظ‌کردن نام دستورها.

سؤال‌ ۵: Permissionهای فایل در لینوکس چگونه کار می‌کنند؟

پاسخ کلیدی: دسترسی هر فایل یا دایرکتوری برای سه گروه User، Group و Others مشخص می‌شود و می‌تواند شامل Read، Write و Execute باشد. برای تغییر Permission از chmod و برای تغییر مالک یا گروه فایل از chown استفاده می‌کنیم.

سؤال تکمیلی احتمالی: Permission برابر ۷۵۵ یعنی چه؟
مالک فایل دسترسی Read، Write و Execute دارد و Group و Others فقط Read و Execute دارند.

سؤال‌ ۶: تفاوت TCP و UDP چیست؟

پاسخ کلیدی: TCP اتصال‌گراست و تحویل مرتب و قابل‌اعتماد داده‌ها را فراهم می‌کند. UDP بدون برقراری اتصال عمل می‌کند و تضمینی برای رسیدن یا ترتیب Packetها ندارد، اما سربار کمتری دارد. انتخاب بین آن‌ها به نیاز سرویس بستگی دارد؛ برای مثال HTTP معمولاً بر TCP اجرا می‌شود، درحالی‌که DNS می‌تواند از UDP یا TCP استفاده کند.

سؤال‌ ۷: وقتی یک سرویس در دسترس نیست، از کجا عیب‌یابی را شروع می‌کنید؟

پاسخ کلیدی: قبل از حدس‌زدن علت، مسیر ارتباط را مرحله‌به‌مرحله بررسی می‌کنم: آیا سرویس اجراست؟ روی Port موردنظر Listen می‌کند؟ DNS درست Resolve می‌شود؟ ارتباط شبکه تا مقصد برقرار است؟ Firewall یا تنظیمات شبکه مانع اتصال نیستند؟ سپس Logهای سرویس را بررسی می‌کنم.

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

Git و CI/CD

در این بخش، مصاحبه‌گر می‌خواهد بداند علاوه بر کار با Git، مسیر تغییر کد از Repository تا Build، Test و Deployment را چقدر می‌شناسید.

سؤال‌ ۸: تفاوت git merge و git rebase چیست؟

پاسخ کلیدی: هر دو برای ترکیب تغییرات Branchها استفاده می‌شوند، اما merge تاریخچه دو Branch را با یک Merge Commit حفظ می‌کند. rebase Commitها را روی یک Base جدید بازنویسی می‌کند و تاریخچه خطی‌تری می‌سازد. به همین دلیل روی Branchهای مشترک باید با احتیاط از Rebase استفاده کرد.

مهارت مورد سنجش: درک Git History و انتخاب روش مناسب برای مدیریت Branchها.

سؤال‌ ۹: اگر در Git با Merge Conflict روبه‌رو شوید، چه می‌کنید؟

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

سؤال‌ ۱۰: یک CI/CD Pipeline معمولاً چه مراحلی دارد؟

پاسخ کلیدی: ساختار Pipeline به پروژه بستگی دارد، اما معمولاً شامل دریافت کد، Build، اجرای Testها، بررسی‌های کیفیت یا امنیت و آماده‌سازی Artifact یا Image است. پس از آن نیز مراحل Deployment به محیط‌هایی مثل Staging یا Production اجرا می‌شوند.

سؤال تکمیلی احتمالی: اگر یکی از Testها Fail شود چه اتفاقی باید بیفتد؟
Pipeline باید متوقف شود و نسخه نامعتبر به مرحله Deployment نرسد. سپس علت شکست از طریق Log همان Job بررسی می‌شود.

سؤال‌ ۱۱: Artifact در CI/CD چیست؟

پاسخ کلیدی: Artifact خروجی قابل‌استفاده یک مرحله از Pipeline است؛ مثلاً فایل Buildشده برنامه، Package یا گزارش تست. این خروجی می‌تواند در مراحل بعدی همان Pipeline یا برای انتشار نسخه استفاده شود.

سؤال‌ ۱۲: چرا نباید Secretها را مستقیماً داخل Repository قرار داد؟

پاسخ کلیدی: چون اطلاعاتی مثل Password، Token و API Key ممکن است از طریق Repository یا حتی Git History افشا شوند. Secretها باید خارج از کد و با ابزارهای مدیریت Secret یا متغیرهای امن CI/CD نگهداری و در زمان اجرا در اختیار برنامه قرار بگیرند.

اگر می‌خواهید یادگیری را فراتر از مطالعه ادامه دهید و با ابزارهای این حوزه بیشتر کار کنید، دوره‌های DevOps را هم می‌توانید ببینید.

Docker و Container

در مصاحبه جونیور، سؤال‌های Docker بیشتر روی Image، Container و نحوه ساخت و اجرای آن‌ها متمرکزند.

سؤال‌ ۱۳: تفاوت Docker Image و Container چیست؟

پاسخ کلیدی: Image یک قالب فقط‌خواندنی شامل فایل‌ها، وابستگی‌ها و تنظیمات لازم برای اجرای برنامه است. Container نمونه در حال اجرای یک Image است که یک لایه قابل‌نوشتن هم به آن اضافه می‌شود. از یک Image می‌توان چند Container مستقل ایجاد کرد.

مهارت مورد سنجش: درک رابطه Image و Container و نحوه اجرای برنامه در Docker.

Dockerfile چیست؟

پاسخ کلیدی: Dockerfile فایلی متنی شامل دستورهایی برای ساخت Docker Image است. در آن می‌توان Base Image، فایل‌های برنامه، وابستگی‌ها، متغیرهای محیطی و دستور اجرای برنامه را مشخص کرد. Docker هنگام Build این دستورها را پردازش و Image را به‌صورت لایه‌ای ایجاد می‌کند.

سؤال‌ ۱۴: تفاوت Volume و Bind Mount چیست؟

پاسخ کلیدی: هر دو امکان نگهداری داده خارج از لایه قابل‌نوشتن Container را فراهم می‌کنند. Volume توسط Docker مدیریت می‌شود، اما Bind Mount مستقیماً یک فایل یا مسیر مشخص از سیستم میزبان را داخل Container مانت می‌کند.

سؤال تکمیلی احتمالی: برای داده‌های یک Database کدام را انتخاب می‌کنید؟
در بسیاری از سناریوها Volume انتخاب مناسب‌تری است، چون مدیریت آن به Docker سپرده می‌شود و به یک مسیر مشخص روی Host وابسته نیست. البته انتخاب نهایی به معماری و نیاز پروژه بستگی دارد.

سؤال‌ ۱۵: چرا یک Container ممکن است بلافاصله بعد از اجرا متوقف شود؟

پاسخ کلیدی: عمر Container به Process اصلی آن وابسته است. اگر این Process تمام شود یا به‌دلیل خطا متوقف شود، Container هم متوقف می‌شود. برای پیدا کردن علت، وضعیت Container و Logهای آن را بررسی می‌کنم و در صورت نیاز تنظیمات اجرای Image را هم می‌بینم.

مهارت مورد سنجش: درک چرخه عمر Container و داشتن مسیر مشخص برای عیب‌یابی، نه صرفاً توانایی اجرای docker run.

سؤالات مصاحبه DevOps برای سطح Mid

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

Kubernetes و مدیریت سرویس‌ها

سؤال‌های Kubernetes معمولاً میزان درک شما از اجرای Workloadها، ارتباط سرویس‌ها و مدیریت وضعیت مطلوب در Cluster را می‌سنجند.

سؤال‌ ۱۶: تفاوت Pod، Deployment و Service در Kubernetes چیست؟

پاسخ کلیدی: Pod کوچک‌ترین واحد قابل استقرار در Kubernetes است و یک یا چند Container را اجرا می‌کند. Deployment وضعیت مطلوب و تعداد Replicaهای Podها را مدیریت می‌کند و برای Update و Rollback هم به کار می‌رود. Service نیز یک Endpoint پایدار برای دسترسی شبکه‌ای به مجموعه‌ای از Podها فراهم می‌کند. 

مهارت مورد سنجش: شناخت نقش منابع اصلی Kubernetes و ارتباط میان آن‌ها.

سؤال‌ ۱۷: اگر یک Pod مرتب Restart شود، چطور علت را پیدا می‌کنید؟

پاسخ کلیدی: ابتدا وضعیت Pod و Eventها را بررسی می‌کنم تا دلیل Restart مشخص شود. بعد سراغ Logهای Container می‌روم و مواردی مثل خطای برنامه، تنظیمات اشتباه، مشکل در Probeها یا کمبود منابع را بررسی می‌کنم. اگر Container قبلی Crash کرده باشد، Log اجرای قبلی هم می‌تواند سرنخ مهمی بدهد.

سؤال‌ ۱۸: Readiness Probe و Liveness Probe چه تفاوتی دارند؟

پاسخ کلیدی: Readiness Probe مشخص می‌کند Container آماده دریافت Traffic هست یا نه؛ در صورت Fail شدن، Pod از Endpointهای Service خارج می‌شود. Liveness Probe بررسی می‌کند Container همچنان سالم است یا نیاز به Restart دارد.

سؤال تکمیلی احتمالی: آیا Fail شدن Readiness Probe باعث Restart شدن Container می‌شود؟
خیر. Fail شدن Readiness به‌تنهایی Container را Restart نمی‌کند؛ فقط آن را تا زمان Ready شدن از دریافت Traffic کنار می‌گذارد.

سؤال‌ ۱۹: Deployment در Kubernetes چگونه به‌روزرسانی برنامه را مدیریت می‌کند؟

پاسخ کلیدی: با تغییر Pod Template در Deployment، Kubernetes یک ReplicaSet جدید ایجاد می‌کند و در Rolling Update به‌تدریج Podهای نسخه جدید را جایگزین نسخه قبلی می‌کند. اگر نسخه جدید پایدار نباشد، می‌توان Deployment را به Revision قبلی Rollback کرد. 

سؤال‌ ۲۰: چرا معمولاً برای دسترسی به Podها مستقیماً از IP آن‌ها استفاده نمی‌کنیم؟

پاسخ کلیدی: چون Podها موقتی‌اند و با حذف و ایجاد مجدد، مجموعه Podها و IPهایشان می‌تواند تغییر کند. Service یک آدرس پایدار در اختیار Clientها می‌گذارد و Traffic را به Backendهای مربوط هدایت می‌کند. 

Cloud و Infrastructure as Code

در این بخش بیشتر از حفظ نام سرویس‌های Cloud، درک شما از مدیریت زیرساخت و دلیل استفاده از Infrastructure as Code اهمیت دارد.

سؤال‌ ۲۱: Infrastructure as Code چیست و چه مزیتی دارد؟

پاسخ کلیدی: Infrastructure as Code یا IaC یعنی زیرساخت را به‌جای تنظیم دستی، با فایل‌های قابل نسخه‌بندی تعریف و مدیریت کنیم. این کار ساخت محیط‌های تکرارپذیر، بررسی تغییرات و مدیریت زیرساخت در Git را ساده‌تر می‌کند.

مهارت مورد سنجش: درک دلیل استفاده از IaC، نه فقط آشنایی با Terraform.

سؤال‌ ۲۲: Terraform State چیست و چرا اهمیت دارد؟

پاسخ کلیدی: Terraform در State ارتباط بین Configuration و Resourceهای واقعی را نگه می‌دارد. از این اطلاعات برای تشخیص تغییرات لازم هنگام اجرای Plan و Apply استفاده می‌شود.

سؤال تکمیلی احتمالی: در یک تیم State را کجا نگه می‌دارید؟
معمولاً از Remote Backend استفاده می‌شود تا State به‌صورت مشترک و کنترل‌شده در دسترس تیم باشد؛ در کار تیمی باید امکان Locking هم متناسب با Backend در نظر گرفته شود.

سؤال‌ ۲۳: تفاوت Scale Up و Scale Out چیست؟

پاسخ کلیدی: در Scale Up منابع یک سرور، مثل CPU یا RAM، افزایش پیدا می‌کند. در Scale Out تعداد Instanceها یا Nodeها بیشتر می‌شود تا بار بین چند سیستم توزیع شود.

سؤال‌ ۲۴: چرا استفاده از Cloud به معنی حذف نیاز به مدیریت زیرساخت نیست؟

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

Monitoring، Logging و Incident Management

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

سؤال‌ ۲۵: تفاوت Monitoring و Logging چیست؟

پاسخ کلیدی: Monitoring با Metricهایی مثل CPU، Memory، Latency و Error Rate وضعیت سیستم را نشان می‌دهد. Logging جزئیات رویدادها و اتفاقات برنامه یا زیرساخت را ثبت می‌کند. معمولاً Metric وجود مشکل را نشان می‌دهد و Log به پیدا کردن علت آن کمک می‌کند.

سؤال‌ ۲۶: چه Metricهایی را برای یک سرویس وب مانیتور می‌کنید؟

پاسخ کلیدی: انتخاب Metric به سرویس بستگی دارد، اما مواردی مثل Latency، Traffic، Error Rate و Saturation مهم‌اند. در کنار آن‌ها، مصرف CPU و Memory و Metricهای مخصوص خود برنامه را هم بررسی می‌کنم.

مهارت مورد سنجش: توانایی انتخاب Metric براساس رفتار سرویس، نه صرفاً نام‌بردن ابزارهای Monitoring.

سؤال‌ ۲۷: Alert خوب چه ویژگی‌ای دارد؟

پاسخ کلیدی: Alert باید به مشکلی اشاره کند که نیاز به اقدام دارد و اطلاعات کافی برای شروع بررسی بدهد. Alertهای زیاد و کم‌اهمیت می‌توانند باعث Alert Fatigue شوند و هشدارهای مهم میان آن‌ها گم شوند.

سؤال‌ ۲۸: هنگام وقوع Incident چه چیزی را در اولویت قرار می‌دهید؟

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

سؤال تکمیلی احتمالی: Postmortem چه کاربردی دارد؟
بعد از Incident، اتفاقات، علت‌ها و اقدام‌های اصلاحی ثبت و بررسی می‌شوند تا احتمال تکرار همان مشکل کمتر شود.

سؤالات سناریومحور و عیب‌یابی DevOps

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

شکست Deployment و Rollback

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

سؤال‌ ۲۹: اگر Deployment جدید با خطا مواجه شود، چه می‌کنید؟

پاسخ کلیدی: ابتدا وضعیت Deployment، Logها و تغییرات نسخه جدید را بررسی می‌کنم. اگر اختلال جدی باشد و شواهد به نسخه جدید اشاره کنند، سرویس را به آخرین نسخه سالم Rollback می‌کنم و بعد سراغ پیدا کردن علت اصلی می‌روم.

مهارت مورد سنجش: توانایی اولویت‌بندی بازیابی سرویس و عیب‌یابی براساس شواهد.

خطاهای 5xx و مشکلات ارتباط سرویس‌ها

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

سؤال‌ ۳۰: بعد از Deployment تعداد خطاهای 5xx افزایش یافته؛ از کجا شروع می‌کنید؟

پاسخ کلیدی: زمان شروع خطا را با Deployment مقایسه می‌کنم و Logها، Error Rate و وضعیت سرویس‌های وابسته را می‌بینم. اگر نسخه جدید عامل خطا باشد، برای کاهش سریع اختلال Rollback را در نظر می‌گیرم.

سؤال‌ ۳۱: اگر دو سرویس نتوانند با هم ارتباط برقرار کنند چه چیزهایی را بررسی می‌کنید؟

پاسخ کلیدی: اول مطمئن می‌شوم هر دو سرویس در حال اجرا هستند. بعد DNS، Port، مسیر شبکه، Firewall یا Network Policy و تنظیمات اتصال را بررسی می‌کنم تا محل قطع ارتباط مشخص شود.

مصرف بالای CPU، Memory و فضای Disk

در این سناریوها، مهم است قبل از Restart یا حذف فایل‌ها بفهمید کدام Process یا داده باعث مصرف غیرعادی منابع شده است.

سؤال‌ ۳۲: اگر CPU یک سرور ناگهان بالا برود، چه می‌کنید؟

پاسخ کلیدی: Processهای پرمصرف را پیدا می‌کنم و Traffic، Metricها و تغییرات اخیر را بررسی می‌کنم. بعد مشخص می‌کنم افزایش CPU ناشی از بار واقعی سرویس است یا مشکلی مثل Loop یا یک Process معیوب.

سؤال‌ ۳۳: اگر Memory سرور به‌طور مداوم افزایش پیدا کند، چه چیزی را بررسی می‌کنید؟

پاسخ کلیدی: Processهای پرمصرف و روند مصرف Memory را بررسی می‌کنم تا مشخص شود با افزایش بار روبه‌رو هستیم یا احتمال مشکلی مثل Memory Leak وجود دارد. Logها و Metricهای برنامه هم برای پیدا کردن علت کمک می‌کنند.

سؤال‌ ۳۴: اگر Disk سرور پر شده باشد، اولین اقدام چیست؟

پاسخ کلیدی: ابتدا با ابزارهایی مثل df و du مشخص می‌کنم کدام مسیرها بیشترین فضا را مصرف کرده‌اند و بعد سراغ علت می‌روم؛ مثلاً Logهای حجیم، فایل‌های موقت یا داده‌های برنامه. بدون بررسی، فایل‌ها را صرفاً برای خالی‌کردن فضا حذف نمی‌کنم.

کار با df، du، top و ابزارهای مشابه در چنین سؤال‌هایی زیاد به کار می‌آید. مرور دستورات لینوکس برای DevOps هم می‌تواند برای بخش عملی مصاحبه به شما کمک کند.

سؤالات رفتاری و همکاری با تیم توسعه

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

سؤال‌ ۳۵: اگر با توسعه‌دهنده درباره نحوه Deployment اختلاف‌نظر داشته باشید، چه می‌کنید؟

پاسخ کلیدی: اول دلیل هر دو راه‌حل و تأثیرشان روی پایداری، سرعت انتشار و ریسک را بررسی می‌کنم. تصمیم را تا جای ممکن براساس نیاز پروژه و شواهد فنی می‌گیریم، نه صرفاً ترجیح شخصی.

مهارت مورد سنجش: همکاری فنی و توانایی دفاع منطقی از تصمیم‌ها.

سؤال‌ ۳۶: اگر اشتباهی از طرف شما باعث اختلال در Production شود، چه واکنشی دارید؟

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

سؤال‌ ۳۷: اگر تجربه کار با ابزاری که تیم استفاده می‌کند نداشته باشید، چه پاسخی می‌دهید؟

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

سؤال‌ ۳۸: یک پروژه DevOps که روی آن کار کرده‌اید را چطور توضیح می‌دهید؟

پاسخ کلیدی: به‌جای فهرست‌کردن ابزارها، مسئله پروژه، مسئولیت خودم، تصمیمی که گرفتم و نتیجه آن را توضیح می‌دهم. مثلاً چرا Docker انتخاب شد، Pipeline چطور طراحی شد یا یک مشکل Deployment را چطور برطرف کردم.

اگر هدف شما ورود به این حوزه است، شناخت مهارت‌های موردنیاز در فرصت‌های شغلی DevOps کمک می‌کند بفهمید شرکت‌ها معمولاً از یک نیروی Junior یا Mid چه انتظاری دارند.

نکات پاسخ‌گویی و چک‌لیست پیش از مصاحبه

نکات پاسخ‌گویی و چک‌لیست پیش از مصاحبه

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

چطور به سؤال‌های فنی جواب بدهیم؟

پاسخ را با اصل مطلب شروع کنید و بعد، اگر لازم بود، دلیل یا مثال بیاورید. برای سؤال‌های سناریو محور هم به‌جای نام‌بردن پشت‌سرهم ابزارها، مسیر بررسی خودتان را توضیح دهید: اول چه چیزی را چک می‌کنید، دنبال چه نشانه‌ای هستید و براساس نتیجه چه تصمیمی می‌گیرید.

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

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

قبل از مصاحبه چه چیزهایی را مرور کنیم؟

قرار نیست شب قبل از مصاحبه تمام ابزارهای DevOps را دوباره بخوانید. روی چیزهایی تمرکز کنید که باید بتوانید درباره‌شان توضیح بدهید یا مسئله حل کنید:

• دستورات و مفاهیم پایه لینوکس و شبکه
• Git و مراحل یک CI/CD Pipeline
• Docker، Image، Container، Volume و Network
• مفاهیم پایه Kubernetes، اگر در شرح شغل آمده است
• چند سناریوی عیب‌یابی مثل خطای Deployment، مصرف بالای منابع یا قطع ارتباط سرویس‌ها
• پروژه‌های خودتان و دلیل تصمیم‌های فنی‌ای که در آن‌ها گرفته‌اید

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

جمع‌بندی

آمادگی برای مصاحبه DevOps با حفظ‌کردن جواب چند سؤال تمام نمی‌شود. باید بتوانید مفاهیم را به مسئله‌های واقعی وصل کنید؛ از توضیح تفاوت Image و Container گرفته تا اینکه هنگام شکست Deployment یا افزایش مصرف CPU چه مسیری را برای عیب‌یابی طی می‌کنید.

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