المكتبة العربية لعلوم الحاسوب
خارطة طريق DevOps الديناميكية › الأساسيات 3 / 6 السابق التالي

مرحبًا بك في عالم DevOps

مرحبًا بك في عالم DevOps

نظرة عامة على الوحدة

  • مقدمة عن نموذج DevOps ومجالات التركيز.
  • العلاقة بين DevOps وDevSecOps وأجايل في ضوء دورة حياة تطوير البرمجيات (SDLC).
  • تنفيذ المشروع العملي التدريجي HiveBox المرحلة 1.

تلميح — مجالات التركيز

إنتاج البرمجيات (50%)، منهجية DevOps (50%)

1.1 تمهيد - ما DevOps ولماذا؟

شكل توضيحي: ركائز منهجية DevOps.

منهجية DevOps هي مجموعة من الممارسات (Practices) والأدوات (Tools) والثقافة (Culture)، والأهم العقلية (Mindset)، تهدف إلى تحسين التعاون والتواصل بين فريقي تطوير البرمجيات (Dev) والعمليات (Ops). وتسعى إلى تفكيك الصوامع التشغيلية التقليدية. وتُروّج لثقافة تعاونية ومؤتمتة ومستدامة، ما يعزّز كفاءة دورة حياة تطوير البرمجيات بأكملها (بدءًا من التخطيط والبرمجة والاختبار والنشر والعمليات).

وخلاصة القول، إنّ تبنّي DevOps يعزّز التعاون بين الفرق، ويحسّن حلقات التغذية الراجعة، ويضمن سرعة الوصول إلى السوق، ويحسّن الجودة، ويزيد الموثوقية والاستقرار، ويرفع كفاءة التكلفة، والأهم من ذلك كله، يوفّق بين الأهداف التقنية وأهداف العمل.

الجمهور

الجمهور المستهدف: جميع الأدوار (بما فيها أدوار DevOps والبرمجيات وغيرها)

ما تحتاج إلى معرفته

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

تلميح

قد تبدو بعض المواضيع في هذه الوحدة جديدة أو نظرية، لكن لا تقلق! واصل القراءة والتعلّم عن تلك المواضيع، وستراها مطبَّقة عمليًّا في خارطة الطريق هذه.

المصادر

  • ما هو DevOps؟ - GitLab: نقطة بداية جيدة للحصول على نظرة عامة على الجوانب التقنية لـ DevOps.
  • تقرير حالة DevOps 2023: تقرير مفصّل عن DevOps في 2023 من DevOps Research and Assessment (DORA) يغطّي جوانب كثيرة من DevOps في العالم الواقعي، مثل أداء المنظمة وأداء الفريق ورفاه الموظفين. لا تحتاج حقًّا إلى قراءة التقرير كاملًا كمهندس DevOps مبتدئ، لكن من الجيد فهم كل جوانب DevOps! فالأمر ليس تقنية فحسب!
  • DevOps ليس ثقافة فحسب، بل هو أيضًا دور - Ahmed AbouZaid: مقال يشرح لماذا أصبحت عبارة "DevOps ثقافة وليس دورًا" في الواقع كليشيهًا لا يصمد أمام الواقع.

1.2 إنتاج البرمجيات - دورة حياة تطوير البرمجيات

دورة حياة تطوير البرمجيات (SDLC) هي عملية أو مجموعة أطوار توجّه تطوير البرمجيات. وهي تغطّي العملية كاملةً لصناعة البرمجيات، بما يشمل التخطيط والتصميم والتطوير والاختبار والنشر وصيانة أنظمة البرمجيات.

الجمهور

الجمهور المستهدف: جميع الأدوار (بما فيها أدوار DevOps والبرمجيات وغيرها)

ما تحتاج إلى معرفته

  • توجد عوامل ودوافع كثيرة لإنتاج البرمجيات، لكن أكثرها شيوعًا هو "المثلث الحديدي" (Iron Triangle) أو "القيد الثلاثي" (Triple Constraint)، وهي الوقت والنطاق والتكلفة. وتلعب هذه دورًا رئيسيًّا في إدارة مشاريع البرمجيات.
  • توجد نماذج مختلفة لدورة حياة تطوير البرمجيات (SDLC)، مثل الشلّال (Waterfall) وأجايل (Agile) والحلزوني (Spiral) والنماذج التكرارية. ويعمل كل منها بطريقة مختلفة لتحقيق أهداف المشروع. فمثلًا، كان نموذج الشلّال شائعًا في الماضي، وهو يتّبع تسلسلًا خطّيًّا. أما اليوم فأجايل أكثر شيوعًا، وهو يركّز على التطوير التكراري والتراكمي مع التركيز على التعاون والمرونة.
  • وبصرف النظر عن النموذج، سيكون لكل منها أطوار جوهرية مثل التخطيط والتصميم والتطوير والاختبار والنشر والصيانة.
  • وكمهندس DevOps، تحتاج إلى فهم الأنواع المختلفة لدورات حياة تطوير البرمجيات (SDLC) حتى تكون قادرًا على تحسين العملية وتطويرها من البداية المبكّرة (استباقيًّا لا تفاعليًّا).
  • وباختصار، تحتاج إلى معرفة أساسية بإدارة مشاريع البرمجيات، وخصوصًا إدارة المنتجات/المشاريع البرمجية بأسلوب أجايل.

المصادر

1.3 إنتاج البرمجيات - تطوير البرمجيات الرشيق

الجمهور

الجمهور المستهدف: جميع الأدوار (بما فيها أدوار DevOps والبرمجيات وغيرها)

ما تحتاج إلى معرفته

  • تُعدّ منهجيات أجايل من أكثر الممارسات شيوعًا في إنتاج البرمجيات الحديث. ويمكن اعتبارها الوضع الافتراضي، لكن تذكّر أنه لا يوجد حلّ سحري!
  • كما ذُكر في القسم السابق، فإنّ أجايل في جوهره تكراري. وهذا يعني أنه يعمل على أطوار تدريجيًّا لتحقيق الأهداف بدلًا من الأسلوب الخطّي (تمامًا مثل خارطة الطريق هذه!).
  • توجد تطبيقات كثيرة لأطر عمل منهجيات أجايل مثل سكرم (Scrum) وكانبان (Kanban) والبرمجة القصوى (Extreme Programming, XP). وكثيرًا ما تنشأ أطر جديدة من الأطر الأصلية، مثل Scrumban (وهو مزيج بين Scrum وKanban).
  • أهم نقطة هنا هي تجزيء العمل إلى قطع صغيرة؛ لكن تجنّب في الوقت نفسه تضخّم النطاق (Scope Creep)! وباختصار: اجعله يعمل، ثم اجعله صحيحًا، ثم اجعله سريعًا!
  • الإزاحة إلى اليسار (Shift-Left) والإزاحة إلى اليمين (Shift-Right) نموذجان مهمّان للجودة، وكلاهما متكاملان لا متناقضان!
    • الإزاحة إلى اليسار (Shift-Left): تشير إلى الكشف المبكّر عن المشكلات والوقاية منها. وتُجرى الاختبارات في أقرب وقت ممكن في دورة حياة تطوير البرمجيات (SDLC). وتُنفَّذ أنواع الأنشطة المختلفة (مثل اختبار الوحدات والتكامل ومن البداية إلى النهاية) وفحوص الجودة قبل الانتقال إلى الإنتاج (الإصدار أو النشر)، بطريقة "مستمرة".
    • الإزاحة إلى اليمين (Shift-Right): تشير إلى الأنشطة المتأخّرة في دورة حياة تطوير البرمجيات (SDLC) بعد الانتقال إلى الإنتاج (الإصدار أو النشر). وتُنفَّذ خلال هذا الطور أنشطة مثل اختبار A/B وفحوص الأمان وقت التشغيل، وهي ذات قيمة أكبر في نهاية المسار.

المصادر

1.4 إنتاج البرمجيات - إدارة التغيير والمثلث الذهبي

الجمهور

الجمهور المستهدف: جميع الأدوار (بما فيها أدوار DevOps والبرمجيات وغيرها)

ما تحتاج إلى معرفته

شكل توضيحي: المثلث الذهبي.

  • إنتاج البرمجيات كلّه يدور حول "التغيير"! متى وأين ولماذا ... أو بعبارة أخرى، إنه يدور حول "إدارة التغيير" (Change Management).
  • كل ميزة جديدة ينفّذها المطوّرون تحمل مخاطرة! ويجب حسابها وتخفيفها.
  • في معظم الأحيان، تؤثّر التغييرات في المكوّنات الثلاثة الرئيسية لأي منظمة، وهي الأشخاص والعمليات والتقنية. وإن لم يراعِ التغيير هذه العناصر الثلاثة، فسيكون على الأرجح غير فعّال! لذا فإنّ DevOps لا يتعلّق بالتقنية فحسب!
  • مع أي تغيير، يوجد دائمًا "تدهور" لشيء مرتبط بذلك التغيير (وقد يكون أيّ شيء في الواقع! السرعة، الكفاءة، إلخ)، وهو ما يُعرف بـ منحنى J (J-Curve).
  • يساعدك تبنّي عقلية المنتج الأدنى القابل للتطبيق (MVP)، وهي إحدى منهجيات أجايل الجوهرية، على إدارة مخاطر التغيير وتخفيفها.
  • لذا، فإنّ دورك كمهندس DevOps يربط بين مجالين جوهريين في إنتاج البرمجيات (التطوير والعمليات)، ويتطلّب منك امتلاك بعض المعرفة بإدارة التغيير.

المصادر

1.5 منهجية DevOps - الركائز الجوهرية لـ DevOps وDevSecOps

الجمهور

الجمهور المستهدف: جميع الأدوار (بما فيها أدوار DevOps والبرمجيات وغيرها)

ما تحتاج إلى معرفته

  • DevOps منهجية هدفها الأسمى تحسين إنتاج البرمجيات.
  • ولأنّ DevOps منهجية، فلها في الواقع تطبيقات كثيرة، لذا فكّر دائمًا في DevOps كالشاورما/الدونر/الجيروس! فهو يأتي بأنواع وأشكال مختلفة كثيرة!
  • ومع ذلك، توجد ركائز ومبادئ قليلة لـ DevOps.
  • الركائز الرئيسية لـ DevOps:
    • الممارسات (Practices) (إدارة الشيفرة المصدرية SCM، والبنية التحتية كشيفرة IaC، والتكامل/التسليم المستمر CI/CD، والمراجعة من الأقران، إلخ).
    • الأدوات (Tools) (الأدوات الحديثة المستخدمة في الممارسات مثل Git وJenkins وKubernetes، إلخ).
    • الثقافة (Culture) (احرص على تعريف أهداف DevOps بوضوح على مستوى عالٍ، مثل المنظمة أو القسم).
    • العقلية (Mindset) (موقف إيجابي، وإصلاح المشكلات الصحيحة، والتركيز على الحل لا على المشكلة، وعدم إجراء تغييرات غير متتبّعة، وتجنّب البطولة، إلخ).
  • المبادئ الرئيسية لـ DevOps:
    • أتمتة دورة حياة تطوير البرمجيات (ومع ذلك، فالأتمتة ليست غاية في ذاتها، بل وسيلة لغاية).
    • التعاون والتواصل (التواصل هو المفتاح دائمًا، ليس فقط بين فريقي التطوير والعمليات بل في كل مراحل دورة حياة تطوير البرمجيات).
    • التحسين المستمر وتقليل الهدر (العمل بأسلوب تكراري وبأسلوب MVP، دون انفجارات كبيرة).
    • التركيز على احتياجات المستخدم مع حلقات تغذية راجعة قصيرة (التحسينات التقنية بلا أثر تجاري لا معنى لها في معظم الأحيان).
  • وماذا عن DevSecOps؟ لقد كان أمن سلسلة توريد البرمجيات أحد المواضيع الساخنة بسبب الهجمات والاستغلالات المتواصلة في السنوات القليلة الماضية. لذا لم تعد ممارسة الأمان السليمة رفاهية!
  • ومع ذلك، فإنّ DevOps لا يقتصر على التطوير والعمليات؛ بل يضمّ ضمْنًا بينهما كل الأجزاء الأخرى من إنتاج البرمجيات مثل الأمان والاختبار وضمان الجودة والبيانات (علم/هندسة)، إلخ. وإلا فسيصبح شيئًا مثل DevSecQADataMLOps (بل يمكنك إضافة أي شيء هنا فعلًا).
  • لذا، سنتعامل في خارطة الطريق هذه مع DevOps على أنه DevSecOps؛ فالأمان مضمّن افتراضيًّا.

المصادر

1.6 منهجية DevOps - DevOps والسحابة ومهندس المنصات وSRE

الجمهور

الجمهور المستهدف: جميع الأدوار (بما فيها أدوار DevOps والبرمجيات وغيرها)

ما تحتاج إلى معرفته

  • ربما ليس مسمّى "مهندس DevOps" أدقّ مسمّى في صناعة البرمجيات، لأنّه قد يعني أشياء كثيرة.
  • أدّت التطبيقات والطوبولوجيات المختلفة لـ DevOps إلى معايير مختلفة لمهندس DevOps، تتفاوت بين الشركات والقطاعات.
  • لذا لا تُصب بالذعر حين ترى توصيفين وظيفيين لـ DevOps غير متشابهين (لكن لا تخلط بينهما وبين دور DevOps المزيف، الذي ليس سوى مسؤول نظام Sysadmin بِلافتة DevOps).
  • توجد أيضًا أدوار قليلة مرتبطة بـ مهندس DevOps، لكنها تتشارك في معظمها 90% على الأقل من مجموعة المهارات نفسها.
    • مهندس DevOps: التعاون مع فريقي التطوير والعمليات لتحسين عملية تطوير البرمجيات ونشرها (مجال التركيز الرئيسي: عملية الإصدار).
    • مهندس موثوقية الموقع (Site Reliability Engineer, SRE): ضمان موثوقية أنظمة البرمجيات وتوفّرها وأدائها (مجال التركيز الرئيسي: جودة الخدمة).
    • مهندس السحابة: تصميم البنية التحتية والخدمات السحابية وتنفيذها وإدارتها (مجال التركيز الرئيسي: إدارة البنية التحتية الحديثة).
    • مهندس المنصات: بناء المنصات التي تدعم تطوير التطبيقات ونشرها وصيانتها (مجال التركيز الرئيسي: الأدوات والتجريدات).
  • توجد أيضًا تطبيقات أخرى في السوق.
  • في سوق اليوم، تستخدم شركات كثيرة الأدوار والمسمّيات بالتبادل! فلا تعتمد كثيرًا على التسمية بل على الوظيفة الفعلية.
  • تركّز خارطة الطريق هذه على مهندس DevOps النموذجي، ومع ذلك فإنها تتشارك 90% على الأقل من المهارات المطلوبة مع الأدوار الأخرى.

المصادر

1.7 منهجية DevOps - مهندس DevOps ذو المهارات على شكل T

الجمهور

الجمهور المستهدف: جميع الأدوار (بما فيها أدوار DevOps والبرمجيات وغيرها)

ما تحتاج إلى معرفته

  • تشير المهارات على شكل T (T-shaped skills) إلى الجمع بين مهارات واسعة وعميقة في مجال محدّد. فالشريط الأفقي في حرف "T" يمثّل نطاقًا واسعًا من المعرفة والمهارات العامة عبر تخصّصات أو مجالات مختلفة، أما الساق الرأسية في حرف "T" فتمثّل خبرة عميقة في مجال محدّد. وهو ببساطة مزيج بين أن تكون متخصّصًا وعامًّا (generalist) في الوقت نفسه!
  • سيساعدك ذلك على العمل في شركات ذات أنماط DevOps مختلفة. وستستطيع الانتقال بسهولة بين مجالات مختلفة في طيف DevOps. ولا يقتصر الأمر على ذلك، بل سيساعدك أيضًا على التعامل مع التحديات الجديدة بفعالية. وفي الواقع، كان أفضل مهندسي DevOps الذين قابلتهم يمتلكون مهارات على شكل T.
  • هل يعني ذلك أنه لا يوجد مهندس DevOps ذو مهارات على شكل I يتخصّص في مجالات معيّنة ويملك معرفة قليلة في مجالات أخرى؟ أقول إنّ ذلك ممكن، لكنه قد يحدّ من الفرص المتاحة والشركات التي يمكنك العمل معها.
  • في الواقع، مع تقدّمك في مسيرتك المهنية، من الأفضل تطوير مزيد من التخصّص (أي مزيد من السيقان الرأسية)، وبعد بضع سنوات في المجال ينبغي أن تكون خطوتك التالية مهارات على شكل π (Pi-Shaped) (ابحث أيضًا عن المهارات على شكل M وعلى شكل V وحتى على شكل مفتاح (Key-Shaped)، لكن تلك حكاية ليوم آخر).
  • وخلاصةً، ينبغي أن تستهدف التعرّض لمجالات مختلفة من ممارسات وتقنيات DevOps دون التعمّق كثيرًا في كل واحد منها. لكن عليك التعمّق في بعضها (وفقًا للسوق أو المنظمات التي تستهدفها). ولهذا السبب، ينبغي ألّا تكون خارطة طريقك خطّية بل تتبّع مقاربة أسلوب MVP!

المصادر

الاختبار

التطبيق العملي

اتبع التعليمات في المرحلة 1 من مشروع HiveBox.

أسئلة المقابلات

راجع أسئلة المقابلات المتعلّقة بـ الوحدة 1.

السابق مقدّمة التالي الأساسيات - جوهر DevOps