ما الذي تختبره مقابلات مهندسي DevOps فعلياً؟

من تتحدث إليه فعلياً

في معظم وظائف DevOps لن تقابل مُوظّف توظيف عام في الجولات التقنية. بعد الفحص الأولي (غالباً شريك مواهب يتحقق من فترة الإشعار، الراتب، حق العمل)، الأشخاص الذين يطرحون الأسئلة الصعبة عادةً هم من ستعمل معهم: قائد منصة أو SRE، مهندس DevOps أول، أحياناً مدير الهندسة الذي يملك جدول المناوبة. في البيئات المنظّمة — المالية، الصحية، أي شيء يمس PCI أو SOC 2 — غالباً يشارك مهندس أمن في جولة واحدة على الأقل، لأن التحكم بالوصول وسجلات المراجعة جزء من العمل، وليست اهتماماً جانبياً.

هذا مهم لأن هؤلاء المُحاوِرين عادةً قد استُدعوا الساعة 3 صباحاً لشيء يُتوقع منك إصلاحه. هم لا يختبرون إن كنت تستطيع تعريف "CI/CD" أو سرد خدمات AWS. يختبرون إن كانوا سيثقون بك للوصول إلى بيئة الإنتاج.

الفحص التقني: كيف يبدو فعلياً

معظم مسارات هذا الدور تتضمن أحد ثلاثة أشكال، أحياناً اثنين منها:

تمرين منزلي أو مباشر يتضمن بنية تحتية معطلة حقيقية. قد تحصل على مستودع بوحدة Terraform تفشل في التطبيق، أو Dockerfile ينشئ صورة 2GB بينما يجب أن ينشئ 200MB، أو خط GitHub Actions/GitLab CI ينجح محلياً لكنه يفشل في المُشغّل. يُطلب منك إصلاحه وشرح منطقك، وليس فقط لصق diff يعمل. يُولي المُحاوِرون انتباهاً لما إذا كنت تفحص مخرجات الخطة قبل التطبيق، وما إذا كنت تنظر لأكواد الخروج والسجلات قبل التخمين، وما إذا كنت تشرح لماذا يعمل الإصلاح وليس فقط أنه يعمل.

جلسة تصحيح أخطاء أو عمل جماعي مباشرة. تشارك شاشتك، يعطونك مجموعة Kubernetes (غالباً kind أو minikube) مع pod عالق في CrashLoopBackOff، أو خدمة تُرجع أخطاء 502 خلف موازن حمل، وتشرح تشخيصك في الوقت الفعلي: kubectl describe pod، التحقق من حدود الموارد، قراءة الأحداث قبل السجلات، التحقق مما إذا كانت المشكلة في التطبيق أم ingress. القيمة كلها في السرد. الصمت أثناء الكتابة إشارة أسوأ من تخمين أول خاطئ يليه خطوة تالية منطقية.

جولة تصميم نظام على السبورة أو شفوياً. صمّم خط نشر لخدمة بمتطلبات وقت تشغيل صارم، أو صمّم كيف ستُطلق ترحيل schema بلا توقف، أو صمّم مراقبة لمجموعة خدمات صغيرة. تُقيّم هذه بناءً على المقايضات: blue-green مقابل canary، لماذا تختار سياسة تحجيم تلقائي على أخرى، ماذا تضع في لوحة قيادة مقابل ما تُنبّه عليه، كيف تضع SLO وماذا تفعل عندما تنفد ميزانية الأخطاء.

الأسئلة التي تتحقق فعلياً من الكفاءة

بعض الأسئلة تظهر في كل مقابلة DevOps تقريباً، ولكل منها نسخة تفصل من أدّوا العمل عمّن قرؤوا عنه فقط.

"اشرح لي حادثة تعاملت معها." الإجابة الحقيقية تذكر العَرَض، خطوات التشخيص بالترتيب، السبب الجذري الفعلي، الإصلاح الفوري، و— والأهم— ماذا تغيّر بعدها: تنبيه جديد، دليل إجراءات، تغيير في بوابة النشر. عادةً تتضمن أيضاً شيئاً خاطئاً حدث في الاستجابة نفسها، لأن الحوادث نادراً ما تسير بسلاسة. إن لم تتضمن القصة تقرير ما بعد الحادثة ولا إجراء متابعة، سيسأل المُحاوِر ماذا تغيّر، ويجب أن تكون هناك إجابة.

"كيف تدير الأسرار؟" يستمعون لما إذا كنت تميّز بين الأسرار في التحكم بالإصدار (رسوب)، الأسرار في متغيرات البيئة (إجابة جزئية)، والأسرار المسحوبة عند التشغيل من شيء مثل Vault، أو AWS Secrets Manager، أو SSM Parameter Store مع أدوار IAM محددة النطاق ودوران. نقاط إضافية، دون مطالبة، لذكر كيف تُدوّر بيانات اعتماد تسربت بالفعل، لأن هذا هو السؤال خلف السؤال.

"ما الفرق بين المراقبة والتنبيه؟" هذا يختبر إن كنت تفكر بـ SLIs و SLOs أو فقط بلوحات القيادة. الإجابة القوية تفصل ما ستنظر إليه أثناء التحقيق (مقاييس، تتبّع، سجلات — بالأسماء مثالياً: Prometheus/Grafana، Datadog، حزمة ELK أو Loki) عمّا يجب أن يوقظ شخصاً فعلياً، وتشرح لماذا إرهاق التنبيه فشل تصميم، وليس حتمية.

"كيف ستتراجع عن هذا؟" يُسأل عن أي سيناريو نشر تقريباً. الإجابة تحتاج آلية محددة — وسم صورة سابق، مراجعة Helm، ترحيل قاعدة بيانات قابل للعكس أو على الأقل متوافق للأمام — وليس "سنعيد نشر النسخة القديمة فقط"، وهو ما يفترض أن النسخة القديمة لا تزال قابلة للبناء وأن التراجع نفسه لن يكسر شيئاً آخر.

"لماذا Terraform/Ansible/Puppet على البديل؟" أقل عن الأداة وأكثر عمّا إذا كنت تفهم إدارة الحالة التصريحية مقابل الأمرية، ما هو الانحراف، وكيف تكتشفه وتوفّقه. إن كان فريقك يستخدم GitOps (ArgoCD، Flux)، توقع سؤالاً عما يحدث عندما يغيّر شخص شيئاً مباشرة في المجموعة بدلاً من Git، لأن هذا هو الاحتكاك اليومي الفعلي للنموذج.

كيف تبدو الإجابة السطحية

لشخص يؤدي هذا العمل، للإجابة السطحية شكل محدد. تذكر الأدوات دون ذكر قرار: "استخدمنا Kubernetes و Terraform و Jenkins" لا تخبر المُحاوِر شيئاً عمّا اخترته فعلياً أو لماذا. تتخطى وضع الفشل: وصف عملية نشر دون ذكر ما يحدث عند فشلها، أو إعداد مراقبة دون ذكر ما لا تراقبه حالياً. تعامل "سأعيد تشغيله" كتشخيص بدلاً من حل مؤقت — إعادة تشغيل pod قد تزيل عَرَضاً، لكن إن لم تستطع قول ما سبب التعطل، يعرف المُحاوِر أنك ستعود الساعة 3 صباحاً تفعلها مجدداً. وتجيب أسئلة تصميم النظام ببنية واحدة ولا بدائل مُعتبرة، وهو ما يُقرأ كحفظ رسم واحد بدلاً من وزن مقايضات على نظام حقيقي بقيود حقيقية — التكلفة، حجم الفريق، الأدوات الموجودة.

العكس صحيح أيضاً ويستحق المعرفة: الإفراط في شرح كل اختصار، أو تلاوة تعريف كتاب مدرسي لنشر blue-green عند السؤال كيف ستنشر خدمة محددة، يُقرأ بنفس الطريقة. المُحاوِر يريد منطقك مُطبّقاً على سيناريوهم، وليس محاضرة عامة.

ماذا تفعل قبل المقابلة

ارجع لآخر حادثتين أو ثلاث حوادث حقيقية، ترحيلات، أو تغييرات بنية تحتية واكتب، بالترتيب: العَرَض، خطوات التشخيص، الإصلاح، وماذا تغيّر بعدها. إن لم تستطع ملء الجزء الأخير، هذا يستحق الملاحظة قبل المقابلة، وليس أثناءها.

إن ذكر إعلان الدور أدوات محددة — Terraform على Pulumi، EKS على Kubernetes مُدار ذاتياً، Datadog على Prometheus مفتوح المصدر — تحقق من خبرتك مقابل تلك المجموعة بصدق. حيث استخدمت المكافئ وليس الأداة بالضبط، قل ذلك واشرح المقابلة؛ المُحاوِرون عموماً يحترمون "استخدمت Chef، وليس Puppet، لكن النموذج نفسه" أكثر بكثير من ادّعاء مبهم بالإلمام ينهار تحت سؤال متابعة واحد.

وإن كنت ترسل حجماً كبيراً من الطلبات ولا تسمع شيئاً، يستحق التحقق مما إذا كانت متطلبات الإعلان المحددة تظهر مبكراً بما يكفي في سيرتك الذاتية لتوصلك لهذه المرحلة أصلاً — المقابلة تختبر فقط ما تعرفه بالفعل؛ لا يمكنها إصلاح سيرة ذاتية تدفن خبرة Kubernetes و Terraform التي طلبها الإعلان في الصفحة الثانية.