راهنمای مصاحبه شغلی مهندس دواپس؛ پرسش‌ها و آمادگی فنی

معرفی

شایستگی‌های مورد سنجش

موارد زیر تصویری کلی از این بخش برای این راهنما ارائه می‌کنند.

• مدیریت Linux و عیب‌یابی سرویس

  توانایی بررسی پردازش‌ها، سرویس‌ها، فایل‌های لاگ، مجوزها، مصرف CPU و حافظه، فضای دیسک و تنظیمات پایه شبکه در Linux.

• طراحی و نگهداری CI/CD

  درک مراحل build، test، artifact، deployment، متغیرهای محیطی، تأیید دستی و بازگردانی نسخه در خط لوله‌هایی مانند GitLab CI/CD.

• کانتینرسازی و Kubernetes

  توانایی توضیح Dockerfile، image، volume و network و عیب‌یابی مفاهیمی مانند Pod، Deployment، Service، ConfigMap، Secret و Ingress.

• زیرساخت به‌عنوان کد

  توانایی تعریف تغییرات زیرساخت با Terraform، استفاده از state، بررسی plan، بازبینی تغییرات و کاهش تغییرات دستی در محیط‌ها.

• پایش و مشاهده‌پذیری

  توانایی تفکیک متریک، لاگ و تریس، انتخاب هشدارهای مفید و استفاده از Prometheus و Grafana برای بررسی اختلال سرویس.

• شبکه، ورودی سرویس و امنیت عملیاتی

  درک DNS، TLS، پورت، پراکسی معکوس، توازن بار، دسترسی‌های حداقلی و نگهداری امن متغیرها و کلیدهای حساس.

• اسکریپت‌نویسی و خودکارسازی

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

• پاسخ به رخداد و بازیابی

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

• همکاری با تیم توسعه

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

برنامه آماده‌سازی

در ادامه، مهم‌ترین موارد این بخش به تفکیک معرفی شده‌اند.

• سناریوی کامل استقرار یک سرویس

  یک سرویس ساده را روی Linux اجرا کنید، برای آن Dockerfile بنویسید و image را بسازید. سپس مسیر رسیدن تغییر از Git تا محیط اجرا را توضیح دهید: آغاز خط لوله، build، تست، نگهداری artifact یا image، استقرار و روش بازگردانی نسخه.

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

  برای مرور ساخت image و اجرای کانتینر، مستندات رسمی Docker را بخوانید.

• Linux، Bash و عیب‌یابی پایه

  فرمان‌های مربوط به systemd، journalctl، ps، top یا htop، df، free، ss، curl و grep را در یک محیط تمرینی به کار ببرید. تمرین کنید وقتی سرویس پاسخ نمی‌دهد، ابتدا وضعیت پردازش، پورت در حال شنود، لاگ برنامه، فضای دیسک و اتصال شبکه را به‌ترتیب بررسی کنید.

  برای آشنایی با مدیریت سرویس‌ها و journal، مستندات رسمی systemctl و journalctl را مرور کنید.

• Docker و Kubernetes

  تفاوت image و container، نقش لایه‌های Dockerfile، متغیر محیطی، volume و شبکه کانتینر را مرور کنید. در Kubernetes، رابطه Deployment، ReplicaSet، Pod، Service، Ingress، ConfigMap و Secret را با یک پروژه کوچک تمرین کنید.

  خروجی‌های kubectl get، kubectl describe و kubectl logs را بخوانید و برای وضعیت‌هایی مانند CrashLoopBackOff یا ImagePullBackOff علت‌های محتمل را توضیح دهید.

  برای رفتار Pod و عیب‌یابی، به مستندات رسمی Pod، عیب‌یابی Pod و مدیریت منابع کانتینر مراجعه کنید.

• GitLab CI/CD و مدیریت انتشار

  یک فایل .gitlab-ci.yml ساده بسازید که مراحل build، test و deploy را جدا کند. تفاوت اجرای خودکار و تأیید دستی برای تولید، نگهداری متغیرهای حساس، وابستگی jobها و نگهداری artifact را بدانید.

  برای انتشار ناموفق، یک طرح روشن داشته باشید: متوقف کردن rollout، بررسی نسخه و تنظیمات، بازگردانی به نسخه سالم و ثبت علت رخداد.

  مستندات رسمی GitLab CI/CD، متغیرهای CI/CD و تأیید استقرار را مرور کنید.

• Terraform و تغییر کنترل‌شده زیرساخت

  مفهوم provider، resource، variable، output، module و state را مرور کنید. بتوانید توضیح دهید چرا terraform plan پیش از apply بررسی می‌شود و چرا state نباید بدون سازوکار اشتراکی و محافظت‌شده میان افراد جابه‌جا شود.

  روی یک مثال کوچک، تفاوت تغییر دستی در پنل زیرساخت و تغییر ثبت‌شده در مخزن Git را بیان کنید.

  برای درک plan و state، مستندات رسمی terraform plan و Terraform state را بخوانید.

• پایش، لاگ و رخداد

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

  یک رخداد فرضی مانند افزایش خطای 500 را تمرین کنید: تشخیص دامنه اثر، بررسی تغییرات اخیر، مقایسه متریک و لاگ، کاهش اثر و نوشتن اقدام پیشگیرانه.

  برای طراحی ruleهای هشدار و مدیریت هشدارها، مستندات رسمی قوانین هشدار Prometheus و Alertmanager را مرور کنید.

• نمونه‌کار قابل دفاع

  پروژه‌ای را آماده کنید که مخزن Git، Dockerfile، pipeline، فایل‌های استقرار، تنظیمات پایش و راهنمای اجرا داشته باشد. لازم نیست پروژه بزرگ باشد، اما باید بتوانید هر تصمیم را توضیح دهید. مثلاً چرا readiness probe گذاشته‌اید یا چرا Secret را داخل مخزن نگه نداشته‌اید.

  readiness probe تعیین می‌کند آیا Pod برای دریافت ترافیک آماده است یا نه. مستندات رسمی پروب‌های Kubernetes این تفاوت را توضیح می‌دهد. همچنین Secret در Kubernetes به‌طور پیش‌فرض فقط با base64 کدگذاری می‌شود و این کدگذاری رمزنگاری نیست. مستندات رسمی Secret را بخوانید.

  جزئیات انتخاب تعداد پروژه و ساختار رزومه را در راهنمای ورود این شغل دنبال کنید.

چک‌لیست آماده‌سازی

پیش از ادامه، فهرست زیر را مرور کنید و مطمئن شوید همه موارد را پوشش داده‌اید:

• یک سرویس نمونه را با Docker اجرا و مراحل ساخت image را توضیح داده‌ام.
• می‌توانم تفاوت Pod، Deployment، Service و Ingress را توضیح دهم.
• خروجی kubectl logs و kubectl describe را در یک خطای تمرینی بررسی کرده‌ام.
• یک pipeline ساده GitLab برای build، test و deploy ساخته‌ام.
• روش بازگردانی نسخه ناموفق در پروژه نمونه را مشخص کرده‌ام.
• مفاهیم terraform plan، apply و state را مرور کرده‌ام.
• برای یک API، داشبورد یا متریک‌های نرخ خطا و زمان پاسخ را بررسی کرده‌ام.
• می‌توانم مسیر بررسی یک سرویس پاسخ‌نداده در Linux را مرحله‌به‌مرحله بگویم.
• نمونه‌کارم راهنمای اجرا، وابستگی‌ها و محدودیت‌های شناخته‌شده دارد.
• درباره کشیک، دسترسی تولید و فرایند مدیریت رخداد پرسش آماده کرده‌ام.
• آگهی شغلی را خوانده و ابزارهای واقعاً موردنیاز همان موقعیت را جدا کرده‌ام.

سئوالاتی که از شما می‌پرسند

• فنی

  اگر یک سرویس داخل کانتینر اجرا می‌شود اما از بیرون پاسخ نمی‌دهد، چه مواردی را بررسی می‌کنید؟

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

  راهنمای پاسخ و نمونه پاسخ

  پاسخ باید از بررسی وضعیت خود کانتینر و لاگ برنامه آغاز شود. سپس پورت در حال گوش‌دادن برنامه، نگاشت پورت Docker، شبکه کانتینر، دیوار آتش یا security group و در صورت وجود پراکسی معکوس بررسی می‌شود.

  توضیح دهید که با curl از داخل کانتینر و از میزبان، محل قطع ارتباط را محدود می‌کنید. اگر Nginx در مسیر است، لاگ و upstream آن نیز باید بررسی شود.

  ابتدا بررسی می‌کنم کانتینر واقعاً در حال اجرا است و برنامه داخل آن crash نکرده باشد. لاگ برنامه و خروجی docker ps را می‌بینم. بعد از داخل کانتینر با curl بررسی می‌کنم برنامه روی پورت مورد انتظار پاسخ می‌دهد یا نه.

  اگر داخل کانتینر پاسخ می‌دهد، پورت expose یا publish‌شده، binding برنامه به 0.0.0.0 به‌جای localhost، شبکه Docker و قوانین firewall میزبان را بررسی می‌کنم. اگر درخواست از Nginx عبور می‌کند، تنظیم upstream، پورت مقصد و لاگ خطای Nginx را هم مقایسه می‌کنم.

• فنی

  در GitLab CI/CD چگونه خط لوله استقرار برای محیط تولید را ایمن‌تر طراحی می‌کنید؟

  سنجش درک جداسازی مراحل، کنترل دسترسی، محافظت از متغیرهای حساس، بازبینی تغییر و کاهش ریسک انتشار تولید.

  راهنمای پاسخ و نمونه پاسخ

  به مراحل جداگانه build، test، scan در صورت وجود، ساخت image و deploy اشاره کنید. توضیح دهید که انتشار تولید نباید با هر commit بدون کنترل اجرا شود. می‌توان آن را به branch یا tag محافظت‌شده، تأیید دستی و افراد مجاز محدود کرد.

  متغیرهای حساس باید در تنظیمات امن CI/CD نگهداری شوند، نه در فایل pipeline یا مخزن. درباره artifact، نسخه‌گذاری image و مسیر rollback نیز صحبت کنید.

  خط لوله را به jobهای مستقل build، test، ساخت image و deploy تقسیم می‌کنم تا محل شکست روشن باشد. استقرار تولید را فقط از branch یا tag محافظت‌شده اجرا می‌کنم و برای آن تأیید دستی و مجوزهای محدود می‌گذارم.

  رمزها و tokenها را به‌صورت متغیرهای Protected و Masked نگه می‌دارم و از چاپ آن‌ها در log جلوگیری می‌کنم. image را با شناسه commit یا tag نسخه‌گذاری می‌کنم تا در صورت خطا بتوانم نسخه مشخص قبلی را بازگردانم. پیش از deploy نیز وضعیت تست‌ها و تغییرات زیرساخت را بازبینی می‌کنم.

• فنی

  تفاوت liveness probe و readiness probe در Kubernetes چیست و انتخاب نادرست آن‌ها چه اثری دارد؟

  سنجش فهم چرخه عمر Pod، هدایت ترافیک و خطر restart غیرضروری یا ارسال درخواست به سرویس آماده‌نشده.

  راهنمای پاسخ و نمونه پاسخ

  بگویید readiness probe تعیین می‌کند Pod برای دریافت ترافیک از Service آماده است یا نه، اما liveness probe برای تشخیص وضعیت ناسالم یا گیرکردن برنامه و در صورت شکست مکرر، راه‌اندازی مجدد کانتینر به کار می‌رود. این رفتار در مستندات رسمی پروب‌های Kubernetes توضیح داده شده است.

  به زمان شروع برنامه، وابستگی‌هایی مانند اتصال پایگاه داده و endpoint مناسب اشاره کنید. انتخاب threshold یا timeout بیش از حد سخت‌گیرانه می‌تواند در بار بالا یا شروع سرویس، restart و اختلال زنجیره‌ای ایجاد کند.

  readiness probe تعیین می‌کند آیا Pod در حال حاضر باید در endpointهای Service قرار بگیرد یا خیر. برای نمونه، برنامه ممکن است اجرا شده باشد، اما هنوز migration یا اتصال اولیه به وابستگی‌ها را تمام نکرده باشد.

  liveness probe برای تشخیص وضعیتی است که برنامه گیر کرده و با restart کانتینر بهبود می‌یابد. اگر liveness را روی endpointی وابسته به سرویس بیرونی تنظیم کنم، قطعی آن سرویس می‌تواند باعث restart غیرضروری کانتینرهای Podهای سالم شود. بنابراین probe باید تا حد ممکن وضعیت خود برنامه را بسنجد و timeout و failure threshold با زمان واقعی شروع سرویس هماهنگ باشد.

• موقعیتی

  پس از انتشار نسخه جدید، نرخ خطای 500 افزایش یافته است. در ۳۰ دقیقه نخست چه می‌کنید؟

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

  راهنمای پاسخ و نمونه پاسخ

  ابتدا دامنه اثر را با متریک‌ها مشخص کنید: کدام endpoint، کدام نسخه، چه درصدی از درخواست‌ها و آیا همه کاربران درگیرند. تغییرات اخیر در برنامه، تنظیمات، image، Secret و وابستگی‌ها را بررسی کنید.

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

  ابتدا alert و داشبورد را بررسی می‌کنم تا بدانم خطا در کدام سرویس و از چه زمان شروع شده است. نرخ خطا، latency، نسخه‌های Podها، تغییرات pipeline و وضعیت وابستگی‌هایی مانند پایگاه داده را مقایسه می‌کنم.

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

• فنی

  چرا تغییر دستی منابع زیرساخت در پنل ابری می‌تواند مشکل‌ساز باشد؟

  سنجش درک Infrastructure as Code، قابلیت بازتولید محیط، بازبینی تغییرات و خطر drift میان وضعیت واقعی و کد زیرساخت.

  راهنمای پاسخ و نمونه پاسخ

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

  تغییر اضطراری ممکن است لازم باشد، اما باید ثبت، بازبینی و در اولین فرصت در کد زیرساخت منعکس شود.

  تغییر دستی ممکن است سریع به نظر برسد، اما معمولاً در pull request و تاریخچه مخزن ثبت نمی‌شود و بازتولید همان محیط را دشوار می‌کند. همچنین می‌تواند میان وضعیت واقعی زیرساخت و پیکربندی مدیریت‌شده با Terraform اختلاف ایجاد کند و در plan یا apply بعدی به تغییرات ناخواسته منجر شود.

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

• نمونه‌کار

  در پروژه دواپس خود، از زمان push شدن تغییر تا اجرای سرویس چه مراحلی طی می‌شود؟

  سنجش مالکیت واقعی نمونه‌کار، درک ارتباط Git، pipeline، image، استقرار و پایش.

  راهنمای پاسخ و نمونه پاسخ

  معماری پروژه را به‌ترتیب توضیح دهید: آغاز خط لوله، تست‌ها، ساخت image، ثبت image، اعمال manifest یا Helm، بررسی rollout و مشاهده لاگ یا متریک. ابزارهایی را نام ببرید که واقعاً در پروژه استفاده کرده‌اید.

  یک محدودیت واقعی پروژه را نیز بیان کنید. مثلاً نبود محیط staging یا ساده‌بودن سازوکار Secret، و بگویید در محیط تولید چگونه آن را بهتر می‌کردید.

  با push به branch اصلی، pipeline GitLab ابتدا تست‌های برنامه را اجرا می‌کند. اگر موفق باشد، Docker image با شناسه commit ساخته و در registry ثبت می‌شود. job استقرار، نسخه image را در manifest Kubernetes به‌روزرسانی می‌کند و rollout را بررسی می‌کند.

  بعد از استقرار، با kubectl وضعیت Podها و با Grafana نرخ خطا و مصرف منابع را می‌بینم. در این پروژه Secretها فقط برای محیط تمرینی تنظیم شده‌اند. برای محیط واقعی آن‌ها را در مخزن قرار نمی‌دهم و از سازوکار مدیریت Secret با دسترسی محدود استفاده می‌کنم.

• فنی

  برای یک هشدار Prometheus چگونه تشخیص می‌دهید که هشدار قابل اقدام است؟

  سنجش توانایی طراحی هشدار بر مبنای اثر کاربر و عملیات، نه صرفاً عبور یک عدد از آستانه.

  راهنمای پاسخ و نمونه پاسخ

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

  برای مثال، افزایش نرخ خطای درخواست همراه با اثر بر کاربران معمولاً از مصرف بالای CPU بدون افت سرویس عملیاتی‌تر است. CPU بالا می‌تواند ابتدا روی داشبورد یا هشدار با آستانه و مدت مناسب قرار گیرد. برای ساخت rule، مستندات رسمی Prometheus را ببینید.

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

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

• رفتاری

  نمونه‌ای بگویید که درخواست انتشار سریع با ملاحظات پایداری یا امنیتی تعارض داشت.

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

  راهنمای پاسخ

  یک موقعیت واقعی مانند انتشار بدون تست کافی، تغییر مستقیم تنظیمات تولید یا درخواست دسترسی گسترده را شرح دهید. روشن کنید چه ریسکی را تشخیص دادید؛ مثلاً نبود rollback، نداشتن backup یا افشای Secret.

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

• موقعیتی

  یک Pod در وضعیت CrashLoopBackOff قرار گرفته است. از کجا شروع می‌کنید؟

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

  راهنمای پاسخ و نمونه پاسخ

  با kubectl describe pod رویدادها و با kubectl logs لاگ کانتینر را بررسی کنید. به آرگومان اجرای برنامه، متغیرهای محیطی، ConfigMap، Secret، دسترسی به وابستگی‌ها، image و exit code اشاره کنید.

  اگر مشکل به کمبود حافظه مربوط است، وضعیت OOMKilled و resource limit را بررسی کنید. از حذف و ساخت مجدد Pod بدون جمع‌آوری شواهد به‌عنوان راه‌حل اصلی یاد نکنید. راهنمای رسمی عیب‌یابی Pod مرجع مناسبی است.

  ابتدا kubectl describe pod را اجرا می‌کنم تا eventها، image، restart count و علت خاتمه را ببینم. سپس با kubectl logs و در صورت نیاز kubectl logs --previous خروجی اجرای فعلی و اجرای قبلی را می‌خوانم.

  بررسی می‌کنم برنامه به دلیل متغیر محیطی ناقص، Secret اشتباه، خطای اتصال پایگاه داده، فرمان startup نادرست یا نبود فایل پیکربندی متوقف نشده باشد. اگر OOMKilled دیده شود، مصرف حافظه و limit را با رفتار واقعی برنامه مقایسه می‌کنم. بعد از یافتن علت، تغییر را از مسیر manifest یا pipeline اعمال می‌کنم تا قابل‌ردیابی باشد.

• فنی

  Secretها و متغیرهای حساس را در فرایند استقرار چگونه مدیریت می‌کنید؟

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

  راهنمای پاسخ

  بگویید مقدار واقعی Secret را در Git، Dockerfile یا log قرار نمی‌دهید. بسته به معماری شرکت، می‌توان از متغیرهای محافظت‌شده CI/CD، Secretهای Kubernetes یا سامانه‌های مدیریت Secret استفاده کرد. به اصل حداقل دسترسی، تفکیک محیط‌ها، ثبت و بازبینی دسترسی و چرخش کلیدها نیز اشاره کنید.

  توضیح دهید که base64 در Secret Kubernetes رمزنگاری نیست و برای حفاظت از اطلاعات حساس باید از کنترل دسترسی و سازوکار مناسب مدیریت Secret استفاده شود. این نکته در مستندات رسمی Secretهای Kubernetes آمده است.

• فرهنگی

  درباره کشیک و دسترسی به محیط تولید چه انتظاری دارید؟

  سنجش تناسب با واقعیت عملیاتی نقش، مسئولیت‌پذیری و توجه به فرایندهای امن هنگام رخداد.

  راهنمای پاسخ

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

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

• نمونه‌کار

  در نمونه‌کار شما چرا این ابزارها و معماری را انتخاب کرده‌اید؟

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

  راهنمای پاسخ

  انتخاب‌ها را به مسئله وصل کنید. مثلاً Docker برای یکسانی محیط اجرا، GitLab برای اجرای pipeline، Kubernetes برای مدیریت چند replica و Prometheus برای جمع‌آوری متریک. محدودیت‌ها و جایگزین‌های معقول را نیز بگویید.

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

• رفتاری

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

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

  راهنمای پاسخ و نمونه پاسخ

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

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

  ابتدا از توسعه‌دهنده اطلاعات قابل‌بررسی می‌گیرم: endpoint یا جریان کاربر، زمان رخداد، نسخه deployed و شناسه درخواست در صورت وجود. بعد تفاوت تنظیمات، نسخه وابستگی‌ها، منابع و مسیر شبکه میان staging و production را بررسی می‌کنم.

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

• موقعیتی

  اگر مصرف CPU همه Podهای یک سرویس بالا برود، پیش از افزایش replica چه بررسی‌هایی انجام می‌دهید؟

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

  راهنمای پاسخ و نمونه پاسخ

  روند ترافیک، نرخ خطا، latency، تعداد درخواست، تغییرات اخیر، throttling و مصرف حافظه را بررسی کنید. افزایش replica می‌تواند پاسخ مناسبی به بار واقعی باشد، اما خطای retry، loop برنامه، query کند یا محدودیت پایگاه داده را حل نمی‌کند.

  به بررسی HPA، request و limit منابع، ظرفیت nodeها و اثر افزایش replica بر وابستگی‌های مشترک اشاره کنید.

  ابتدا بررسی می‌کنم افزایش CPU با رشد ترافیک هم‌زمان بوده یا پس از یک تغییر نرم‌افزاری رخ داده است. نرخ خطا، latency، تعداد درخواست، لاگ‌های retry و متریک وابستگی‌ها مانند پایگاه داده را می‌بینم.

  اگر ترافیک واقعی بالا رفته و وابستگی‌ها ظرفیت دارند، HPA و request و limitها را بررسی می‌کنم تا مقیاس‌دهی کنترل‌شده انجام شود. اما اگر CPU همراه با خطای زیاد یا retry غیرعادی بالا رفته باشد، ابتدا علت نرم‌افزاری یا وابستگی را پیدا می‌کنم؛ چون افزایش replica ممکن است فشار را به سرویس‌های دیگر منتقل کند.

• فرهنگی

  چه نوع مستنداتی را برای عملیات و استقرار ضروری می‌دانید؟

  سنجش توجه به انتقال دانش، تکرارپذیری عملیات و کاهش وابستگی تیم به حافظه افراد.

  راهنمای پاسخ

  به راهنمای استقرار، rollback، متغیرهای محیطی بدون افشای مقدار Secret، معماری وابستگی‌ها، راهنمای اقدام برای هشدارها، مالک سرویس و فرایند دسترسی اشاره کنید.

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

پرسش‌های شما از پنل مصاحبه

• زیرساخت فعلی بیشتر روی ماشین مجازی، Kubernetes یا سرویس‌های مدیریت‌شده ابری قرار دارد؟

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

• مسیر فعلی استقرار از merge تا تولید چیست و کدام بخش آن بیشترین مشکل را ایجاد می‌کند؟

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

• برای محیط تولید چه فرایند تأیید، rollback و ثبت تغییری دارید؟

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

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

  به شما کمک می‌کند بلوغ مشاهده‌پذیری و تقسیم مسئولیت میان توسعه و عملیات را ارزیابی کنید.

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

  برای سنجش تعهد زمانی و شرایط واقعی پاسخ‌گویی به رخداد ضروری است.

• دسترسی به محیط تولید چگونه اعطا، ثبت و بازبینی می‌شود؟

  سطح بلوغ امنیت عملیاتی و مسئولیت‌پذیری سازمان در مدیریت دسترسی را نشان می‌دهد.

• تیم توسعه تا چه حد مسئولیت لاگ‌گیری، health check و رفع رخدادهای سرویس خود را می‌پذیرد؟

  مرز همکاری دواپس و توسعه را روشن می‌کند و از انتظارهای مبهم جلوگیری می‌کند.

• در شش ماه اخیر چه رخداد عملیاتی مهمی داشته‌اید و چه تغییری پس از آن ایجاد شده است؟

  نحوه یادگیری تیم از رخدادها و کیفیت فرایند بهبود پس از حادثه را آشکار می‌کند.

اشتباه‌های رایج

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

• فهرست‌کردن ابزارها بدون تجربه قابل توضیح

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

• پاسخ‌دادن با دستورها بدون توضیح علت

  به‌جای گفتن چند فرمان kubectl یا Docker، بگویید هر فرمان چه فرضیه‌ای را بررسی می‌کند و نتیجه آن چگونه گام بعدی عیب‌یابی را تعیین می‌کند.

• نادیده‌گرفتن rollback و اثر تغییرات تولید

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

• تلقی Kubernetes به‌عنوان راه‌حل همه مسائل

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

• افشای اطلاعات حساس از پروژه یا محل کار قبلی

  توکن، IP داخلی، معماری محرمانه، نام مشتری و جزئیات دسترسی را بیان نکنید. تجربه را با سناریوی فنی و داده‌های غیرحساس توضیح دهید.

• مقصر دانستن توسعه‌دهنده یا تیم دیگر هنگام رخداد

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

• سؤال‌نکردن درباره کشیک و دسترسی تولید

  پیش از پذیرش پیشنهاد، درباره نوبت کشیک، اختیارهای زمان رخداد، فرایند escalation، ثبت دسترسی و جبران مسئولیت خارج از ساعت کاری شفاف سؤال کنید.

پس از مصاحبه

پرسش‌های پرتکرار

در این بخش، به تعدادی از پرسش‌های رایج درباره این راهنما پاسخ داده شده است.

آموزش‌های مرتبط در فرادرس

• آموزش داکر جادی، مفاهیم و شروع کار با Docker (رایگان) + گواهینامه آموزش ویدئویی
• آموزش مقدماتی کوبرنتیز، مدیریت کانتینرها با Kubernetes + گواهینامه آموزش ویدئویی
• آموزش مسیر یادگیری دواپس DevOps + راهنمای عملی (رایگان) آموزش ویدئویی
• آموزش لینوکس مقدماتی – ساختار داخلی و ترمینال Linux + گواهینامه آموزش ویدئویی

منابع پیشنهادی

• NotHarshhaa/DevOps-Interview-Questions ... وب‌سایتgithub.com
• Troubleshooting Clusters مستنداتkubernetes.io