أين تُعلن وظائف مهندسي DevOps فعلياً

لماذا المنصات الكبرى لا تخدم هذا الدور جيداً

عندما تنشر وظيفة مهندس DevOps على منصة عامة، تُغرق بطلبات غير متطابقة — مطورو Java لمسوا Dockerfile مرة واحدة، موظفو الدعم التقني يذكرون "AWS" لأنهم أنشأوا S3 bucket في درس تعليمي. مديرو التوظيف الذين عانوا من هذا يتوقفون عن استخدام المنصات العامة لأي شيء غير الوظائف المبتدئة أو المسميات العامة. ما يحل محلها ليس السرية، بل التصفية: ينتقلون إلى قنوات حيث الجمهور قد اختار بالفعل المجال التقني المحدد.

هذا أهم لـ DevOps من كثير من الأدوار التقنية لأن المسمى نفسه فضفاض. "مهندس DevOps" يشمل أشخاصاً يعملون على Terraform وعمليات Kubernetes cluster، أشخاصاً يديرون خطوط CI/CD في Jenkins أو GitLab، وأشخاصاً هم فعلياً SRE مع مناوبات استدعاء ونقاش error-budget مع فريق المنتج. إعلان غامض على Indeed أو LinkedIn يجذب الثلاثة جميعاً؛ إعلان في Slack مخصص لـ Kubernetes يجذب غالباً الشخص المناسب. لذا الوظيفة تصل فعلاً للمنصات العامة — لكن غالباً كقناة ذات أولوية منخفضة، متأخرة، بعد أن يكون المُوظّف أو مدير التوظيف قد جرب قنوات أضيق.

أين تظهر الوظائف فعلياً

قنوات مجتمع CNCF وKubernetes. Slack الخاص بـ Cloud Native Computing Foundation، وقناة #kubernetes-jobs في Kubernetes Slack، تحمل وظائف تحتاج تحديداً خبرة تشغيلية في Kubernetes — ليس فقط "containers" في السيرة الذاتية. هذه الإعلانات تذكر بالضبط CNI، service mesh (Istio، Linkerd) أو أداة GitOps (ArgoCD، Flux) التي يشغلها الفريق، لأن الناشر يعلم أن الجمهور سيصفّي بناءً عليها.

منتدى مجتمع HashiCorp ومجموعات المستخدمين، للشركات التي تعتمد بكثافة على Terraform وVault. نفس المنطق: شركة تشغل Terraform Enterprise أو Vault على نطاق واسع تفضل النشر حيث المتقدم يعرف بالفعل ما هو state file.

r/devops وr/sre على Reddit، ونشرة DevOpsish الإخبارية، جميعها تحمل خيوط وظائف بشكل متقطع. إشارة أقل من مجتمعات Slack لكن تستحق المسح، خاصة للشركات التي تعمل عن بُعد.

شبكات شركاء وشهادات موفري السحابة. AWS وAzure وGoogle Cloud كل منها يدير برامج شركاء، وحيازة AWS Certified DevOps Engineer – Professional، أو شهادة Azure Administrator/DevOps Engineer Expert، أو Google's Professional Cloud DevOps Engineer أحياناً تضعك في قائمة مواهب الموفّر نفسه أو خط إحالة الشركاء — هذا يختلف حسب المنطقة ومستوى الشريك، لذا اعتبره يستحق البحث وليس مضموناً.

خيوط "Who's Hiring" في Hacker News (شهرياً، أول يوم عمل من الشهر) ما تزال تحمل أدوار البنية التحتية والمنصة من شركات لا تريد التعامل مع طبقة موظفين على الإطلاق، غالباً مع بريد إلكتروني مباشر لمهندس التوظيف بدلاً من رابط ATS.

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

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

الوكالات، والانقسام المحدد المهم هنا

توظيف DevOps ينقسم على خط لا يتطابق بوضوح مع توظيف الهندسة الأخرى: التوظيف الدائم يمر عبر موظفي توظيف تقنيين عامين أو فرق مواهب داخلية، لكن حصة كبيرة من العمل — خاصة مشاريع الانتقال السحابي، بناء المنصات، وتغطية SRE — تمر عبر موظفي توظيف عقود ومؤقتين بدلاً من ذلك.

جانب العقود يعمل على أساس أسعار يومية و، في المملكة المتحدة، على حالة IR35. وظيفة معلنة كـ "outside IR35" عبر umbrella أو شركتك المحدودة هي تفاوض مختلف ووضع ضريبي مختلف عن عقد PAYE أو دور دائم، وموظفو توظيف البنية التحتية المتخصصون عادة يبدأون بتلك الحالة في الرسالة الأولى لأنها تحدد ما إذا كنت ستنظر للسعر أصلاً. إذا لم يستطع موظف التوظيف إخبارك بتحديد IR35 عند أول اتصال، يستحق السؤال عنها قبل المضي قدماً، ليس بعد ذلك.

موظفو التوظيف المتخصصون الذين يركزون تحديداً على البنية التحتية السحابية وSRE وهندسة المنصات (على عكس وكالات "توظيف تقنية المعلومات" العامة) يميلون لأن يكون لديهم ملخصات أضيق لكن أدق — عادة تحدثوا مع مدير التوظيف، ليس فقط الموارد البشرية، ويمكنهم إخبارك أي orchestrator، أي سحابة، وما إذا كانت هناك مناوبة استدعاء مرفقة. الوكالات العامة التي تعمل على طلب DevOps من قائمة كلمات مفتاحية هي التي ترسل لك وظائف تتبين أنها وظائف sysadmin بمسمى معاد تسميته.

عدد ملموس من أدوار DevOps والمنصات لا تذهب لأي وكالة خارجية على الإطلاق — تُملأ عبر موظف توظيف الشركة نفسها يتواصل مباشرة على LinkedIn مع أشخاص ملفهم يذكر أدوات محددة (Terraform، Kubernetes، Prometheus، Grafana) وليس فقط المسمى الوظيفي. إبقاء ذلك القسم من الملف الشخصي حديثاً ومحدداً، ليس فقط العنوان، يقوم بعمل حقيقي هنا.

الحركة الداخلية ومشكلة فريق المنصة

كمية كبيرة من توظيف DevOps في الشركات القائمة ليس توظيفاً على الإطلاق — هو نقل داخلي. مديرو النظام ومطورو backend ينتقلون إلى فريق منصة أو SRE مع اعتماد الشركة ممارسات infrastructure-as-code وCI/CD، غالباً دون إعلان الوظيفة خارجياً قط. الشركات التي تمر بإعادة تنظيم هندسة المنصات — تقسيم "فريق DevOps" الضخم إلى فريق منصة مركزي بالإضافة إلى مهندسين مدمجين في فرق المنتج — عادة توظف البنية الجديدة من الموظفين الحاليين أولاً، وتفتح طلبات خارجية فقط للأدوار التي لا يريدها أحد داخلياً أو ليس لديه المهارة المحددة لها (غالباً مناصب SRE الثقيلة بمناوبات الاستدعاء).

هذا له نتيجة عملية: إذا كنت تحاول الانتقال من عمل sysadmin أو backend إلى DevOps، المسار الداخلي داخل صاحب عملك الحالي قد يكون أسرع وأكثر واقعية من سوق العمل الخارجي، لأنك تتنافس ضد لا أحد بدلاً من متخصصين موظفين خارجياً. إذا كنت بالفعل مهندس DevOps تحاول تغيير صاحب العمل، يعني أن العدد الوظيفي الذي تطارده قد يكون لديه بالفعل مرشح داخلي غير رسمي في الاعتبار، والإعلان الخارجي — إن وُجد — جزئياً إجراء شكلي تتطلبه سياسة التوظيف للشركة نفسها.

التوقيت والموسمية الخاصة بهذا السوق

توظيف DevOps والمنصات يتبع تقويمين لا يتماشيان دائماً: السنة المالية للشركة نفسها، ومعالم مشاريع الإنفاق السحابي أو الانتقال.

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

التوظيف المدفوع بالمشروع أكثر خصوصية لهذا المجال. انتقال سحابي، بناء منصة Kubernetes، أو إصلاح بنية تحتية مدفوع بالامتثال (جاهزية SOC 2، ISO 27001) يخلق انفجاراً محدداً من توظيف DevOps بعقود ودائم مرتبط ببدء المشروع، وانخفاضاً مقابلاً في تجديدات العقود مع وصول المشروع لحالة مستقرة. مهندسو DevOps بالعقود الذين يفهمون هذا الجدول الزمني أحياناً يتتبعون عمداً أي شركات أغلقت للتو جولات تمويل أو أعلنت انتقالات سحابية، لأن ذلك مؤشر مسبق لتوظيف البنية التحتية بعد ستة إلى اثني عشر أسبوعاً.

صيف نصف الكرة الشمالي والفترة حول عطلات ديسمبر يُذكران على نطاق واسع كفترة أبطأ للتوظيف عموماً عبر التقنية، بما في ذلك DevOps — طلبات جديدة أقل تُفتح، أدوار أكثر تجلس في limbo المقابلات لأن عضو لجنة في إجازة. هذا ليس سبباً للتوقف عن التقديم، لكنه سبب لعدم قراءة الصمت في أغسطس كإشارة رفض.

ماذا تفعل بهذا

انضم إلى Kubernetes Slack وCNCF Slack هذا الأسبوع إن لم تكن قد فعلت، وافحص قنوات الوظائف مباشرة بدلاً من انتظار ملخص. انظر إلى مدونات الهندسة وصفحات الوظائف للشركات المستهدفة مباشرة — إذا كتبوا عن انتقال أو إعادة بناء منصة في الستة أشهر الأخيرة، تلك إشارة أفضل من بحث عام على منصة وظائف. إذا كنت تعمل بعقود، اسأل عن حالة IR35 في المحادثة الأولى، ليس الثالثة. وإذا كنت داخل شركة بالفعل، اسأل قائد المنصة أو SRE مباشرة ما إذا كان النقل الداخلي واقعياً قبل افتراض أنك تحتاج للمغادرة لإجراء الانتقال.

ما تفعله في هذه المرحلة هو إلى حد كبير القراءة والمطابقة — معرفة أي من الوظائف التي تجدها تناسب فعلاً مجالك التقني وخبرتك المحددة، وأيها لا تناسب. jobmarket.pro يقوم بتلك القراءة والمطابقة لك: يبحث عبر هذه القنوات، يقرأ كل إعلان بالكامل، ويُعد طلباً من خبرتك الفعلية بدلاً من سيرة ذاتية معاد كتابتها.