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

ما هو DevOps؟

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

ما هو DevOps؟

DevOps هو مجموعة الممارسات الثقافية وأنماط التنظيم والأدوات التقنية التي تُزيل الجدار التقليدي بين الفرق التي تبني البرمجيات والفرق التي تُشغّلها في بيئة الإنتاج. فهم سبب وجود ذلك الجدار — وما يكلفه بالضبط — هو أساس كل ما سيأتي في هذه الدورة.

الجدار بين التطوير والتشغيل

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

أفرز هذا النموذج تضارباً حاداً في الحوافز:

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

الجزء العلوي: النموذج التقليدي المُجزَّأ مع تسليم صارم عبر جدار. الجزء السفلي: حلقة التسليم المستمر في DevOps حيث فريق متقاطع الوظائف يمتلك العملية بأكملها.

ما الذي تغير: حركة DevOps

شاع مصطلح "DevOps" حول عام 2009 على يد Patrick Debois وآخرين نظموا أول مؤتمر DevOpsDays في مدينة غنت البلجيكية. استوحت الحركة من Agile وتصنيع Lean (نظام إنتاج تويوتا) وأعمال Gene Kim وJez Humble وPatrick Debois — التي قُنّنت لاحقاً في كتابَي The Phoenix Project وAccelerate.

كانت الفكرة الجوهرية بسيطة: الجدار ليس مشكلة عملية، بل مشكلة تصميم تنظيمي. لا يمكن إصلاحه بنظام تذاكر أفضل. يُصلَح بتغيير المسؤول عن النتائج.

الفكرة الأساسية: DevOps ليس مسمى وظيفياً ولا أداة ولا فريقاً. إنه فلسفة تنظيمية: الأشخاص الذين يبنون البرمجيات يُشغّلونها أيضاً في الإنتاج ويكونون مناوبين عند الأعطال. "أنت تبنيه، أنت تُشغّله" — Werner Vogels، مدير التقنية في Amazon، 2006.

التحول الثقافي

التغييرات الثقافية أصعب تنفيذاً من التقنية، لكنها هي التي تُحرك المقاييس فعلاً:

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

التحول التقني

الثقافة وحدها لا تشحن البرمجيات. التحول الثقافي يُتيح — ويستوجب — ممارسات تقنية محددة:

كل شيء تحت إدارة الإصدارات: ليس كود التطبيق فحسب، بل تعريفات البنية التحتية وملفات التهيئة وسكريبتات الـ pipeline وهجرات قواعد البيانات. إن لم يكن في git، فهو غير موجود.
التكامل المستمر (CI): كل commit يُطلق بناءً آلياً وحزمة اختبارات. البنى المكسورة تعيق الـ pipeline وتُصلَح فوراً — القاعدة الكلاسيكية "لا تنصرف على بناء أحمر."
التسليم/النشر المستمر (CD): الحزم التي تجتاز CI تُرفَّع آلياً عبر التجهيز إلى الإنتاج (أو على بُعد ضغطة زر). الـ pipeline هو عملية الإصدار.
البنية التحتية كـ Code (IaC): الخوادم والشبكات وموازنات الحمل وقواعد البيانات تُعرَّف بالكود (Terraform، Pulumi، CloudFormation) وتُجهَّز برمجياً لا بالنقر في لوحات التحكم السحابية.
قابلية المراقبة: كل خدمة تُصدر مقاييس وسجلات منظَّمة وتتبعاً موزعاً. الفريق يستطيع طرح أسئلة اعتباطية عن حالة الإنتاج دون نشر أدوات قياس جديدة.

# أبسط pipeline CI ممكن — GitHub Actions
# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: ["main", "feature/**"]
  pull_request:
    branches: ["main"]

jobs:
  build-and-test:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4

      - name: Set up Node 22
        uses: actions/setup-node@v4
        with:
          node-version: "22"
          cache: "npm"

      - name: Install dependencies
        run: npm ci

      - name: Run linter
        run: npm run lint

      - name: Run tests
        run: npm test -- --ci --coverage

      - name: Build production artifact
        run: npm run build

ممارسة احترافية: تعامل مع pipeline CI المكسور كما تتعامل مع حادثة إنتاج — أوقف الخط. في شركات كـ Google وMeta، يُتوقع من المطور الذي يكسر الفرع الرئيسي ولا يصلحه خلال دقائق أن يتراجع عن تغييره. الـ pipeline مورد مشترك؛ حمايته مسؤولية الجميع.

ما ليس DevOps

شاع المصطلح وتخفّف معناه. فهم ما ليس DevOps يوفر جهداً مهدراً:

ليس مجرد مجموعة أدوات: شراء Jenkins وKubernetes وDatadog لا يجعلك DevOps. يمكنك تشغيل الثلاثة ولا يزال لديك جدار، ولا تزال تُصدر فصلياً، ولا يزال لديك "فريق DevOps" منفصل.
ليس فريقاً منفصلاً اسمه "DevOps": أكثر الأنماط المضادة شيوعاً. إنشاء "فريق DevOps" يمتلك الـ pipeline لكل الفرق الأخرى ينقل الجدار فحسب — الآن هو بين مهندسي المنتج وحُرّاس DevOps. الممارسة الفعّالة تُدمج الممارسات في كل فريق منتج.
ليس حصراً عن السرعة: الهدف هو سرعة مستدامة بجودة عالية. يُظهر بحث DORA أن الفرق المتميزة تنشر كثيراً ولديها معدل فشل تغيير منخفض — السرعة والاستقرار متكاملان لا متعارضان.

# قياس وتيرة الإصدار الحالية لديك — نقطة بداية عملية
# شغّل على تاريخ git لتفهم موقعك الحالي

# كم مرة يدمج فريقك إلى main؟
git log --oneline --merges origin/main --since="30 days ago" | wc -l

# ما متوسط الوقت من commit إلى الإنتاج؟ (يستلزم وسوم النشر)
# ضع وسماً لكل نشر إنتاجي: git tag deploy/$(date +%Y%m%d-%H%M%S)
# ثم قارن آخر commit للميزة على فرع مقابل وسم نشره
git log --pretty=format:"%h %ai %s" --all | grep -E "(feat|fix|chore)" | head -20

لماذا هذا مهم على نطاق واسع

البحث لا لبس فيه. وجد كتاب Accelerate (Forsgren، Humble، Kim — استناداً إلى ست سنوات من مسح DORA لحالة DevOps) أن المؤسسات الهندسية عالية الأداء تنشر 973 مرة أكثر من المؤسسات المتدنية الأداء، مع متوسط وقت استعادة أقل من ساعة مقابل أكثر من ستة أشهر للمؤسسات الضعيفة. هذه ليست مكاسب هامشية — بل فوارق بمقدار ترتيب من الحجم تترجم مباشرة إلى ميزة تنافسية.

تنشر Amazon إلى الإنتاج كل 11.6 ثانية في المتوسط. تُنفّذ Netflix مئات النشرات يومياً. هذه المؤسسات لا تفعل ذلك لأن لديها مهندسين أكثر — بل لأنها أزالت الجدار وأتمتت الأعباء الممرورة وبنت ثقافة يكون فيها كل مهندس مسؤولاً عن الدورة الكاملة لبرمجياته.

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

ما تبقى من هذا الدرس التعليمي

يُرسي هذا الدرس الأول الـ "لماذا". تبني الدروس التسعة الأخرى في هذا الدرس التعليمي النموذج الذهني الكامل:

الدرس 2 يُحلّل إطار CALMS — العدسة الهيكلية لتشخيص أي تحول في DevOps.
الدروس 3-5 تغطي دورة حياة التسليم وكيف تشحن شركات التقنية الكبرى ومقاييس DORA التي ستستخدمها لقياس تقدمك.
الدروس 6-10 تنتقل إلى المجال العملي: تطور البنية التحتية وتوب-آدوات واجهة السلسلة ومسارات المهن وتطبيق الاثني عشر عاملاً ورسم pipeline تسليم حقيقي.

بنهاية هذا الدرس التعليمي سيكون لديك المفردات والنماذج الذهنية للتعامل مع العمق التقني الذي يأتي في دروس لاحقة حول Linux وCI/CD والحاويات وKubernetes وما هو أبعد.