DevOps ثقافة ومجموعة ممارسات تقرّب فرق التطوير (Dev) والتشغيل (Ops) لتسليم برمجيات أسرع وأكثر تكراراً وأكثر موثوقية.
DevOps ليس أداة ولا منصباً. هو أولاً طريقة عمل مشتركة. الأدوات (Git، Docker، Jenkins…) ليست سوى وسائل في خدمة هذه الثقافة.
الكلمة نفسها دمج لـ Developer + Operations:
| الركيزة | الفكرة المركزية |
|---|---|
| التعاون | Dev و Ops يتقاسمان مسؤولية المنتج |
| الأتمتة | المهام المتكررة تُكتَب سكربتات، لا تُنفَّذ يدوياً |
| التغذية الراجعة | نقيس، نتعلّم، ونحسّن باستمرار |
تمرين مصغّر — كلمة «DevOps» دمج لكلمتين. ما هما، وماذا تعني كل واحدة؟
Developer (التطوير: كتابة الميزات) + Operations (التشغيل: جعل النظام يعمل في الإنتاج).
قبل DevOps، كان المطوّرون والتشغيليون يعملون في صوامع منفصلة. هذا ما يُسمّى جدار الالتباس (wall of confusion).
كان المطوّر يسلّم شفرته وينتقل إلى شيء آخر. وكان التشغيلي مطالَباً بتشغيلها في الإنتاج، دون أن يفهم دائماً كيف. النتيجة: نزاعات، وبطء، والجملة الشهيرة «يعمل على جهازي».
| عرض الصومعة | النتيجة |
|---|---|
| Dev و Ops لا يتحدثان | أخطاء تُكتشَف متأخراً، في الإنتاج |
| نشر يدوي ونادر | إصدارات إنتاج مرهقة وخطرة |
| مسؤوليات ضبابية | «هذه ليست مشكلتي» من الطرفين |
DevOps يهدم هذا الجدار بجعل الفريقين فريقاً واحداً، يتقاسمان الأهداف نفسها والأدوات نفسها.
التعاون يعني أن الفريق كله مسؤول عن المنتج، من كتابة الشفرة حتى حسن عمله في الإنتاج.
عملياً، يترجم التعاون إلى:
تشبيه: فريق مطبخ. الطاهي (Dev) والنادل (Ops) لا يتقاذفان الكرة — يستهدفان معاً رضا الزبون. إذا عاد طبق، فالأمر شأن اللواء كله.
الأتمتة هي استبدال المهام اليدوية المتكررة بسكربتات وأدوات. هذا المحرّك الذي يجعل DevOps ممكناً على نطاق واسع.
ما نؤتمته عادة:
| المهمة اليدوية | تُؤتمت بـ | الوحدة |
|---|---|---|
| التجميع والاختبار | Jenkins، GitHub Actions | 04، 05، 10 |
| تغليف التطبيق | Docker | 06 |
| النشر على الخوادم | Kubernetes، Helm | 07–09 |
| إعداد البنية التحتية | Ansible، Terraform | 11، 12 |
لماذا الأتمتة؟ لأن إنساناً يكرر مهمة يخطئ ويضيّع وقتاً. والآلة تنفّذ الإجراء نفسه ألف مرة بلا خطأ. أسرع، وأكثر موثوقية، وقابل لإعادة الإنتاج.
تمرين مصغّر — اذكر سببين ملموسين لتفضيل أتمتة مهمة متكررة على تنفيذها يدوياً.
التغذية الراجعة السريعة (fast feedback) هي اكتشاف المشكلات في أقرب وقت ممكن والتعلّم بسرعة للتحسين.
| لحظة اكتشاف الخطأ | الكلفة النسبية للتصحيح |
|---|---|
| أثناء التطوير | منخفضة |
| أثناء الاختبارات الآلية | متوسطة |
| في الإنتاج، يبلّغ عنه زبون | مرتفعة جداً |
مصادر التغذية الراجعة في DevOps:
تشبيه: منظم حرارة. يقيس الحرارة باستمرار (تغذية راجعة) ويضبط التدفئة فوراً. بلا هذه الحلقة، لا نعلم أن الغرفة باردة إلا ونحن نرتجف.
تمرين مصغّر — بالاستعانة بجدول الكلف، بيّن في أي لحظة يكون تصحيح خطأ أغلى، ولماذا الاكتشاف المبكر أفضل.
أغلى تصحيح يكون في الإنتاج، يبلّغ عنه زبون. الاكتشاف المبكر (أثناء التطوير أو الاختبارات الآلية) يخفّض الكلفة بقوة، لأن المشكلة تُصلَح قبل أن تبلغ المستخدمين.
غالباً ما يُمثَّل DevOps بـ حلقة لا نهائية (∞)، ترمز إلى التحسين المستمر: لا «ننتهي» أبداً، نكرّر بلا توقف.
| المرحلة | الجانب | مثال أداة |
|---|---|---|
| Plan، Code | Dev | Git، GitHub |
| Build، Test | Dev | Maven، Jenkins، GitHub Actions |
| Release، Deploy | Dev + Ops | Docker، Kubernetes، Helm |
| Operate، Monitor | Ops | Ansible، Terraform، أدوات المراقبة |
النصف الأيسر أقرب إلى «Dev»، والنصف الأيمن أقرب إلى «Ops» — لكن الحلقة واحدة ومشتركة. هذا جوهر DevOps.
| الفائدة | بلا DevOps | مع DevOps |
|---|---|---|
| وتيرة التسليم | بضع مرات في السنة | عدة مرات في اليوم |
| مهلة تصحيح خطأ | أيام / أسابيع | دقائق / ساعات |
| معدل فشل النشر | مرتفع | منخفض |
| التوتر عند الإصدار | مرتفع جداً | روتين متحكَّم فيه |
| تعاون الفرق | صوامع، نزاعات | هدف مشترك |
أفضل الشركات أداءً تنشر مئات المرات يومياً بمعدل فشل منخفض جداً. هذا ليس سحراً: نتيجة الثقافة + الأتمتة + التغذية الراجعة.
تمرين مصغّر — بحسب الجدول، قارن وتيرة التسليم مع DevOps وبدونه.
بلا DevOps: بضع مرات في السنة. مع DevOps: عدة مرات في اليوم.
السؤال 1: DevOps هو أولاً…
a) برنامج يُثبَّت
b) منصب محدَّد في المؤسسة
c) ثقافة ومجموعة ممارسات
d) لغة برمجة
الإجابة: c) — DevOps ثقافة تعاون، مدعومة بممارسات (أتمتة، تغذية راجعة). الأدوات ليست سوى وسائل.
السؤال 2: ما «جدار الالتباس»؟
a) ثغرة أمنية
b) الفصل في صوامع بين Dev و Ops يولّد نزاعات
c) نوع من جدار ناري
d) مرحلة في خط الأنابيب
الإجابة: b) — الفصل التاريخي بين التطوير والتشغيل، حيث يرمي كل طرف العمل فوق الجدار. DevOps يهدمه.
السؤال 3: لماذا الأتمتة مركزية في DevOps؟
a) لإلغاء كل الوظائف
b) لأنها تجعل المهام المتكررة سريعة وموثوقة وقابلة لإعادة الإنتاج
c) لأنها إلزامية قانوناً
d) لإبطاء عمليات النشر
الإجابة: b) — الآلة تنفّذ الإجراء نفسه بلا خطأ ولا تعب، وهذا ما يجعل التسليم المتكرر ممكناً.
السؤال 4: ما فائدة التغذية الراجعة السريعة؟
a) اكتشاف المشكلات وتصحيحها مبكراً، حين تكون أقل كلفة
b) تجنّب كتابة الاختبارات
c) تقليل التعاون
d) النشر مرة واحدة في السنة
الإجابة: a) — كلما اكتُشف الخطأ أبكر، قلّت كلفته. الاختبارات الآلية والمراقبة توفران هذه التغذية الراجعة.
السؤال 5: ماذا ترمز حلقة DevOps اللانهائية؟
a) أن العمل لا ينتهي أبداً وأننا ندور في حلقة فارغة
b) التحسين المستمر وتكرار دورة Plan ← Monitor ← Plan بلا نهاية
c) خطأ في خط الأنابيب
d) إعادة تشغيل الخوادم
الإجابة: b) — الحلقة ∞ تمثّل التحسين المستمر: كل دورة تغذي التالية بفضل التغذية الراجعة.
شركة وهمية، DataCorp، تسلّم تطبيقها مرتين في السنة. كل إصدار إنتاج يستغرق عطلة نهاية أسبوع كاملة، ويفشل كثيراً، وفريق Ops يتهم فريق Dev (والعكس). والأخطاء التي يبلّغ عنها الزبائن تستغرق أسابيع لتصحيحها.
حدّد 3 مشكلات واقترح ممارسة DevOps لكل واحدة.
| المشكلة المرصودة | السبب | ممارسة DevOps المطبَّقة |
|---|---|---|
| تسليم نادر (مرتين/سنة) وخطر | نشر يدوي، دفعات كبيرة | أتمتة خط أنابيب CI/CD ← تسليم متكرر وصغير |
| Dev و Ops يتهمان بعضهما | صوامع، «جدار الالتباس» | تعاون: مسؤولية مشتركة، أهداف مشتركة |
| أخطاء الزبائن تُصلَح في أسابيع | لا اكتشاف مبكر | تغذية راجعة سريعة: اختبارات آلية + مراقبة |
الخلاصة المتوقعة: DataCorp تعاني نقصاً في الركائز الثلاث. بأتمتة النشر، وكسر الصوامع، ووضع اختبارات + مراقبة، تنتقل من تسليمين في السنة إلى تسليم متكرر وموثوق وقليل التوتر.
تلميح: كل مشكلة DevOps تقريباً تعود إلى نقص في إحدى الركائز الثلاث — التعاون، أو الأتمتة، أو التغذية الراجعة.
حان وقت المفاهيم التي تنظّم الدورة كلها: الدرس 03 — CI/CD: المفاهيم وخط الأنابيب.
جميع الحقوق محفوظة. يُحظَر نسخ هذه الدورة أو نشرها أو استخدامها أو تكييفها، كلياً أو جزئياً، دون إذن كتابي مسبق من الدكتور هيثم رحومة.
دورة من إعداد الدكتور هيثم رحومة — تطوير ونشر حلول البيانات