الأدوار الوظيفية في السحابة

تنهي درس الأمان وتفتح موقع وظائف

بعد أن أنهيت مجال الأمان في هذا المقرر، صرت مرتاحاً مع IAM ونموذج المسؤولية المشتركة. تفتح موقع وظائف وتبحث عن "cloud"، فتظهر لك خمسة مسميات: Cloud Engineer، Cloud Architect، DevOps Engineer، Site Reliability Engineer، وCloud Security Engineer. نصف هذه الإعلانات يطلب نفس المتطلبات تقريباً: AWS أو Azure، شبكات، IAM، وقليل من الأتمتة. لا شيء في القائمة وحده يخبرك بأي إعلان تتقدم.

الإعلانات لا تختلف في مزود السحابة أو الخدمات المذكورة. تختلف في شيئين فقط: ماذا تفعل فعلياً خلال يومك، وكم من السلطة تملكها على تصميم النظام ككل. تعلّم قراءة هاتين الإشارتين، ويتوقف موقع الوظائف عن الظهور كخمس نسخ من نفس الدور.

Cloud Engineer: يبني ويشغّل ما يحدده التصميم

يأخذ Cloud Engineer تصميماً موجوداً بالفعل، كاملاً أو في خطوطه العريضة، ويحوّله إلى واقع: يوفر الحوسبة والتخزين، يوصل الشبكات، يكتب سكربتات infrastructure-as-code التي درستها سابقاً في هذا المقرر، ثم يحافظ على صحة النظام بعد تشغيله. هذا عادة نقطة الدخول الأكثر شيوعاً للعمل في السحابة، لأن العمل اليومي ملموس ومرتبط مباشرة بالخدمات التي درستها بالفعل.

أسبوع عمل نموذجي يشبه: إعداد VPC جديد وتوزيع subnets من تذكرة عمل، تشخيص سبب توقف Auto Scaling group عن تشغيل instances جديدة، أو تحديث سكربت Terraform لإضافة read replica لقاعدة بيانات. العمل عملي والقرارات محلية غالباً: كيف تنفذ جزءاً من النظام، لا هل يجب أن يبدو النظام هكذا من الأساس.

Cloud Architect: يصمم النظام ويتحمل قرارات الموازنة

يعمل Cloud Architect على مستوى أعلى. بدلاً من تنفيذ جزء من النظام، يقرر المعماري كيف يجب أن يبدو النظام كله: أي خدمات تناسب متطلبات العمل، أين تقع قرارات التكرار والتكلفة، وكيف تتصل الأجزاء ببعضها. يأتي هذا الدور عادة بعد سنوات من خبرة الهندسة، لأن العمل يتطلب توقّع نتائج لم يواجهها بعد مهندس أقل خبرة.

فكّر في Cloud Architect كمعماري مبنى حقيقي. المعماري يرسم المخطط، يحدد أين تقع الجدران الحاملة، وهو ما يقابل قرارات التكرار والتوسع في نظام سحابي، ويختار المواد، وهو ما يقابل اختيار الخدمات. أما Cloud Engineer فهو فريق المقاول: يصب الأساس، يمد الأسلاك، ويبني بالضبط ما يحدده المخطط، ثم يحافظ على تشغيل المبنى بعد تسليمه. التشبيه يصح في تقسيم التصميم عن التنفيذ، لكنه ينكسر في نقطة واحدة: بنية سحابية تستمر في التغيّر بعد إطلاقها، على عكس مبنى منتهٍ، لذلك ينتقل المهندس نفسه غالباً بين قرارات البناء والتصميم مع تطور النظام. الفصل بين الدورين في الواقع أقل حدة مما هو عليه في موقع بناء حقيقي.

الحد الفاصل: كيف تميّز بينهما في إعلان وظيفة حقيقي

DevOps Engineer و Platform Engineer: تحويل التشغيل إلى مشكلة برمجية

قابلت DevOps سابقاً في هذا المقرر كممارسة وأدوات تُغلق الفجوة بين كتابة الكود وتشغيله. DevOps Engineer هو نفس الفكرة كمسمى وظيفي: شخص يبني ويصون خط CI/CD وأتمتة infrastructure-as-code التي تتيح للمطورين النشر دون تسليم يدوي إلى فريق تشغيل منفصل. Platform Engineer مسمى قريب ومنتشر بشكل متزايد لنفس الفكرة الأساسية: بناء الأدوات الداخلية والمسارات الجاهزة التي تتيح لبقية المهندسين النشر بأمان بأنفسهم.

مهمة ملموسة تبدو هكذا: كتابة pipeline على GitHub Actions يشغّل الاختبارات، يبني صورة container، وينشرها على بيئة staging تلقائياً مع كل merge، دون أن ينسخ أحد الملفات يدوياً إلى خادم.

Site Reliability Engineer: نفس الفكرة، موجهة نحو الإتاحة

جوجل، الجهة التي صاغت المصطلح، تصف Site Reliability Engineering مباشرة: SRE هو ما يحدث حين تطلب من مهندس برمجيات تصميم وظيفة تشغيل. يقضي SRE يومه في بناء المراقبة والتنبيهات والمعالجة الآلية التي درستها في مجال الموثوقية من هذا المقرر، وSLIs وSLOs التي تقيس صحة النظام، والأتمتة التي تعالج فئة كاملة من الأعطال بدلاً من إصلاح كل حادثة يدوياً.

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

Cloud Security Engineer: تفعيل جانب العميل من المسؤولية المشتركة

يأخذ Cloud Security Engineer نموذج المسؤولية المشتركة الذي درسته سابقاً ويحوّله إلى عمل يومي: كتابة ومراجعة سياسات IAM، فحص storage buckets المُعدّة بشكل خاطئ ومكشوفة للعامة، مراجعة إعدادات التشفير للبيانات أثناء السكون والنقل، والتأكد أن ضوابط الحوكمة والامتثال مطبّقة فعلياً لا موثّقة فقط. هذا الدور موجود في مؤسسات من كل حجم، لأن سياسة IAM خاطئة أو storage bucket مفتوح يسببان الضرر نفسه في شركة ناشئة من 3 أشخاص كما في مؤسسة كبيرة.

كيف تترابط هذه الأدوار

الطلب الفعلي على هذه الأدوار

مكتب إحصاءات العمل الأمريكي (BLS) لا يتتبع مهنة باسم "Cloud Engineer" مباشرة، لكن أقرب تصنيف رسمي له، Computer Network Architects، يتوقع نحو 11,200 فرصة عمل سنوياً خلال العقد القادم، مدفوعة إلى حد كبير بتوسع الحوسبة السحابية المستمر وإعادة تصميم الشبكات المرافقة له. هذا الرقم وحده يقلل من الطلب الفعلي، لأنه يستثني تماماً أدوار التطوير والإدارة والأمان المرتبطة بالسحابة، لكنه إشارة محافظة ومفيدة على أن الاتجاه حقيقي ومتتبع حكومياً، لا مجرد تسويق من القطاع.

كيف تدخل المجال دون سنوات خبرة إنتاجية

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

خلاصة

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