ثقافة DevOps وأساسياتها

أدوار DevOps ومسارات المسيرة المهنية

18 دقيقة الدرس 8 من 28

أدوار DevOps ومسارات المسيرة المهنية

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

مهندس DevOps

مهندس DevOps متخصص شامل يعمل عند تقاطع تطوير البرمجيات والعمليات. مهمته الأساسية هي تقليص وقت الدورة: نقل الكود من حاسوب المطور إلى موازن التحميل في الإنتاج بأسرع ما يمكن وأكثر ما يمكن من الأمان. هذا يعني امتلاك خطوط CI/CD، وبنية اختبارات مؤتمتة، واستراتيجيات نشر (blue-green، وcanary، وfeature flags)، وحلقات التغذية الراجعة التي تكشف الأعطال مبكرًا.

في الممارسة اليومية، يقضي مهندس DevOps في شركة متوسطة أو كبيرة يومه في كتابة YAML للخطوط، وتصحيح الاختبارات المتذبذبة، وضبط manifests لـ Kubernetes، والتحقيق مع مهندسي المنتج حين يُعطل نشرٌ ما. الدور تعاوني بطبيعته — أنت الشخص الذي يُزيل الاحتكاك لكل مهندس آخر.

المأزق الشائع: مهندسو DevOps الذين ينجرفون نحو العمليات البحتة ويتوقفون عن كتابة الكود يفقدون أقوى أدواتهم. مهارة الكتابة تضمر بسرعة؛ احرص على صونها بوعي.

الواقع في كبرى الشركات: في شركات كـ Meta وGoogle وAmazon، مسمى "مهندس DevOps" نادر. الوظيفة موجودة لكنها موزعة — مهندسو المنتج يمتلكون خطوطهم، والفرق المتخصصة (SRE والمنصة) تمتلك البنية التحتية الأساسية. إذا كنت تستهدف كبرى شركات التقنية، ابحث عن مسميات "production engineer" أو "infrastructure engineer".

مهندس موثوقية المواقع (SRE)

ابتكرت Google مسمى SRE عام 2003. الفكرة الأساسية: الموثوقية مشكلة برمجية، لذا حلّها بالهندسة البرمجية. العملة الأساسية لمهندس SRE هي ميزانية الخطأ — مقدار التوقف المسموح به والمُحدَّد بـ SLO (هدف مستوى الخدمة). إذا لم تُستنزف الميزانية، تستطيع الفريق المخاطرة أكثر (شحن أسرع، تجارب أكثر). إذا نفدت، يتجمد كل تغيير حتى تُستعاد الموثوقية.

يختلف SRE عن مهندس DevOps في التركيز:

تقليص العمل المتكرر (Toil) — لدى SRE تفويض صريح لأتمتة أي شيء يفعله الإنسان بشكل متكرر. يستهدف كتاب Google's SRE أقل من 50% توقف للعمل المتكرر؛ والباقي يجب أن يكون عملًا هندسيًا.
تقارير ما بعد الحوادث — تقارير بلا لوم بعد كل حادثة كبيرة، مع متابعة بنود العمل حتى إغلاقها.
تخطيط السعة — اختبار التحميل، وسياسات التوسع التلقائي، والتنبؤ بالطلب.
دوريات الاستجابة الطارئة — SREs في المناوبة الأولى للخدمات التي يدعمونها، غالبًا مع مسار تصعيد رسمي يعود لمهندسي المنتج.

حسابات SLO وميزانية الخطأ: خدمة بـ SLO توافر شهري 99.9% تملك 43.8 دقيقة توقف مسموح به شهريًا (30 يومًا × 24 ساعة × 60 دقيقة × 0.001). إذا أحرق الحادث الأخير 30 دقيقة، لم يبقَ إلا 13.8 دقيقة. هذا الرقم يقود كل قرار إصدار لبقية الشهر.

في مقابلات SRE النموذجية في Google أو Netflix ستُطلب منك تصميم استراتيجية تنبيه، والمرور بتقرير ما بعد حادثة، والتفكير في أنماط الفشل في نظام موزع — لا مجرد سرد أوامر Linux.

مهندس المنصة

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

يبني مهندس المنصة منصة المطور الداخلية (IDP) — طبقة منسقة للخدمة الذاتية فوق بدائيات السحابة وKubernetes الخام. تخفي المنصة التعقيد خلف مسارات ذهبية: قوالب معيارية، وكتالوجات خدمات، وتوفير بيئات بنقرة واحدة، وخطوط آلية موحدة. يتعامل مهندسو المنتج مع المنصة، لا مع البنية التحتية مباشرةً.

أبرز أدوات هندسة المنصة في 2025: Backstage (كتالوج الخدمات مفتوح المصدر من Spotify)، وCrossplane (توفير البنية التحتية بأسلوب Kubernetes)، وArgo CD (التوصيل المستمر بأسلوب GitOps)، وPort أو OpsLevel (بوابات IDP).

قس اعتماد المنصة، لا ميزاتها. تتابع فرق المنصة الناجحة "نسبة فرق المنتج التي تستخدم المسار الذهبي" و"متوسط وقت إطلاق خدمة جديدة." منصة لا يستخدمها أحد ضريبة على البنية التحتية، لا مضاعف قوة.

مهندس السحابة

يتخصص مهندس السحابة في تصميم وبناء وتشغيل البنية التحتية السحابية — الشبكات والحوسبة والتخزين والهوية والتكلفة. حيث قد يوصل مهندس DevOps نموذج EC2 أو cluster EKS لتشغيل تطبيق، يُصمم مهندس السحابة تخطيط VPC، وهيكل transit gateway، وحدود صلاحيات IAM، وحوكمة landing-zone التي يرثها كل تطبيق.

كثيرًا ما يحصل مهندسو السحابة على شهادات من الموردين (AWS Solutions Architect Professional، وGCP Professional Cloud Architect، ومستوى الخبير في Azure) لأن اتساع عروض الخدمات كبير فعلًا. لكن الشهادات تُشير إلى اتساع المعرفة لا عمق الإنتاج — سيدفعك المحاورون إلى ما هو أبعد من المنهج الرسمي نحو سيناريوهات فشل حقيقية.

قد يبدو نموذج AWS landing-zone مؤهل للإنتاج — يبنيه مهندس السحابة — كالتالي في Terraform:

# terraform/landing-zone/main.tf
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"

  name             = "prod-vpc"
  cidr             = "10.0.0.0/16"
  azs              = ["us-east-1a", "us-east-1b", "us-east-1c"]
  private_subnets  = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets   = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway     = true
  single_nat_gateway     = false   # واحد لكل منطقة توافر للتوافر العالي
  enable_dns_hostnames   = true

  tags = {
    Environment = "production"
    ManagedBy   = "terraform"
    Team        = "platform"
  }
}

# سياسة التحكم في الخدمات — منع استخدام الحساب الجذر عبر API في المنظمة
resource "aws_organizations_policy" "deny_root_access" {
  name        = "DenyRootAPIAccess"
  type        = "SERVICE_CONTROL_POLICY"
  content     = file("${path.module}/scps/deny-root.json")
}

كيف تتفاعل الأدوار في الإنتاج

كيف تتعاون الأدوار الأربعة في مؤسسة إنتاجية.

تداخل المهارات والتحولات المهنية

تشترك هذه الأدوار في طبقة عميقة مشتركة — بواطن Linux، وأسس الشبكات، والحاويات، وKubernetes، والمراقبة، والبنية التحتية كـ Code. إتقان هذه الأساسيات يفتح جميع المسارات المهنية الأربعة. يكمن الاختلاف في التركيز:

مهندس DevOps — الأعمق في ميكانيكا الخطوط، واستراتيجيات النشر، وتجربة المطور.
SRE — الأعمق في نظرية الأنظمة الموزعة، وهندسة الموثوقية، وإدارة الحوادث الرسمية.
مهندس المنصة — الأعمق في التفكير بالمنتج الداخلي، وأنماط Kubernetes operators، وإنتاجية المطور على نطاق واسع.
مهندس السحابة — الأعمق في هندسة الشبكات، وحوكمة متعددة الحسابات، وهندسة التكلفة، والخدمات الخاصة بالموردين.

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

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

المناوبة والاستجابة للحوادث — مسؤولية مشتركة

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

# سياسة تصعيد PagerDuty كـ Terraform
resource "pagerduty_escalation_policy" "api_service" {
  name      = "API Service Escalation"
  num_loops = 2

  rule {
    escalation_delay_in_minutes = 10
    target {
      type = "schedule_reference"
      id   = pagerduty_schedule.sre_primary.id
    }
  }

  rule {
    escalation_delay_in_minutes = 10
    target {
      type = "schedule_reference"
      id   = pagerduty_schedule.eng_manager.id
    }
  }
}

تُنبّه القاعدة الأولى SRE الأساسي في المناوبة. إذا لم يُقرّ خلال 10 دقائق، يُنبَّه مدير الهندسة. ترميز سياسات التصعيد بـ Terraform يمنع الانجراف في الإعدادات أثناء التناوب ويجعل السياسة قابلة للمراجعة في pull requests — عادة إنتاجية يجب أن يُرسّخها كل دور في هذه العائلة.

ما الذي تبنيه لكل دور

إذا كنت لا تزال تقرر أي المسارات تتبع، اختر مشاريع تُظهر إتقانًا لمحور الاهتمام الأساسي لدور المستهدف:

محفظة مهندس DevOps: خط CI/CD كامل (GitHub Actions أو GitLab CI) يبني ويختبر ويفحص وينشر تطبيقًا في حاويات على Kubernetes مع تحديثات متدرجة بلا توقف.
محفظة SRE: لوحة SLO (Prometheus + Grafana) لخدمة حقيقية، وقالب تقرير ما بعد حادثة بلا لوم، ودليل تشغيل اختبار الفوضى.
محفظة مهندس المنصة: كتالوج خدمات Backstage مع قالب برمجي يُهيئ خدمة جديدة مع CI معياري و Helm chart ومراقبة مُسبقة التوصيل.
محفظة مهندس السحابة: منظمة AWS متعددة الحسابات مع وحدات Terraform وسياسات SCPs وتنبيه شذوذات التكلفة موصول بـ Slack.

سوق العمل في 2025: "مهندس المنصة" هو الأسرع نموًا في عائلة DevOps. يظل مهندس السحابة مدفوعًا بشكل جيد لكنه يتحول تدريجيًا نحو السلعية مع نضوج تجريدات IaC. وظائف SRE في أكبر خمس شركات تقنية تُعدّ من بين أكثر الوظائف الهندسية طلبًا وأفضلها تعويضًا عالميًا.