مقدّمة

نظرة عامة

يُعدّ بدء العمل في وظيفة مهندس DevOps تحديًا كبيرًا؛ لأنّ نموذج DevOps تتعدّد تطبيقاته وأنماطه. والأمر أكثر تعقيدًا (لكنه يبقى ممكنًا) إذا كانت تلك أول وظيفة لك دون خبرة سابقة في صناعة البرمجيات. ومع ذلك، ما زالت خارطات طريق كثيرة مثل roadmap.sh/devops تتبع مسارًا خطّيًّا (أي أن تتعلّم موضوعًا حتى نهايته ثم تنتقل إلى آخر، وهكذا). وهذا لا ينجح جيدًا في وظيفة DevOps؛ لأنّ مهندس DevOps ينبغي أن يعرف مجموعة واسعة من الموضوعات المتعلّقة بالتطوير والعمليات.

إنّ تبنّي خارطة طريق تعلّم غير خطّية (أي تعلّم حالة الاستخدام والمفهوم الكامن وراءها قبل تعلّم الأدوات وتحسين النتيجة باستمرار) يزيد فرصك في دخول السوق والالتحاق بأول وظيفة لك كمهندس DevOps دون خبرة تطبيقية سابقة في البرمجيات (وإن كان في بعض الحالات قد لا يُنصح بالبدء في وظيفة DevOps كأول وظيفة لك).

ومن ثمّ، تسدّ خارطة طريق DevOps الديناميكية (Dynamic DevOps Roadmap) تلك الفجوة باستخدام منهجيات Agile نفسها وبنمط MVP ديناميكي يتبعه مشاريع تطبيقية من تصميم مهندس DevOps ذي خبرة، وقد حقّق ذلك نجاحًا كبيرًا.

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

استراتيجية التعلّم

خارطة الطريق هذه مصمّمة كمشروع تطبيقي وتدريجي. وهي لا تتعلّق بالجوانب التقنية لـ DevOps فحسب، بل أيضًا بإنتاج البرمجيات من البداية إلى النهاية كما ستفعل في عملك اليومي. ولهذا السبب، تتبع خارطة الطريق بشكل أساسي الأفكار نفسها في نموذج SET. لكن بدلًا من مراحل البقاء، التوسّع، التحوّل (survive, expand, transform) لدينا الأساسيات، الانطلاق، التوسّع، التحوّل، التحسين (basics, start, expand, transform, optimize). لذا، على الرغم من أنّ نموذج SET أقرب إلى الأعمال، فإنّنا نستخدم الفكرة نفسها لبناء خارطة طريق تشبه العالم الحقيقي.

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

من الناحية التقنية، تركّز خارطة الطريق على مهندس DevOps النموذجي العامل في شركة برمجيات. ومع ذلك، فإنها ما زالت تشترك في 90% على الأقل من المهارات المطلوبة مع أدوار أخرى مثل مهندس السحابة (Cloud Engineer) ومهندس المنصّات (Platform Engineer) ومهندس موثوقية الموقع (Site Reliability Engineer، SRE).

تتضمّن خارطة الطريق مشروعًا متعدّد المراحل بمستوى الصناعة يتبع منهج التعلّم بالممارسة (Learning by Doing) (المعروف أيضًا بـ التعلّم القائم على المشكلات (Problem-based Learning))، ويُنفّذ أيضًا على مراحل تكرارية حيث تتعلّم في كل وحدة أثناء تقدّمك وتغطّي دورة DevOps كاملة مثل البرمجة (Code) والحاويات (Containers) والاختبار (Testing) والتكامل المستمر (CI) والتسليم المستمر (CD) والرصد (Observability) والبنية التحتية (Infrastructure). تُعالَج كل مرحلة من مراحل هذا المشروع تدريجيًّا كجزء من وحدات خارطة الطريق. لكنها أيضًا قائمة بذاتها، ويمكنك العمل عليها إذا كانت لديك المعرفة المطلوبة لكل مرحلة.

طوبولوجيا DevOps

خارطة الطريق هذه مصمّمة لحقبة ما بعد الحاويات السحابية الأصلية (cloud-native post-container)، ما يعني أنها تركّز أساسًا على الممارسات الحديثة مثل السحابة وDocker وKubernetes. وهذا لا يعني أنّ كلّ شيء ينبغي أن يكون معقّدًا، بل يتعلّق فقط بـالتعامل مع خوادمك كقطيع ماشية لا كحيوانات أليفة. على سبيل المثال، استخدام Kubernetes لا يعني دائمًا أنك بحاجة إلى إنشاء عناقيد Kubernetes أو إدارتها! فكثير من حلول Kubernetes بلا خوادم (serverless) أصبحت الآن مثل AWS EKS Fargate أو GCP GKE Autopilot. لذا لا تدّعي خارطة الطريق هذه وجود طريقة وحيدة لممارسة DevOps؛ لأنّ لـ DevOps بالفعل تطبيقات وطوبولوجيات كثيرة، لكنها كما ذُكر تركّز على الممارسات والتقنيات الحديثة.

المهارات الناعمة

شكل توضيحي: أثر التمهيد في التعلّم. العمل مع موجّه أو زميل (حتى في المستوى نفسه) يمكن أن يؤثّر في عملية التعلّم ويحقّق نتائج أفضل.

وخلافًا لكثير من خرائط الطريق الأخرى، لا تركّز خارطة الطريق هذه على الجوانب التقنية المحضة لـ DevOps فحسب، بل تتضمّن أيضًا التخطيط والإدارة. وهناك جانب آخر بالغ الأهمية لمهندس DevOps ناجح، ألا وهو مهارات التواصل الجيدة! ولهذا يُنصح بأن تنفّذ خارطة الطريق هذه ضمن مجموعة. اقرأ المزيد حول لماذا لا يُنصح ببدء خارطة الطريق هذه منفردًا؟ وتذكّر دائمًا أنّ DevOps يقوم على التعاون؛ فمهندس DevOps ليس ذئبًا منفردًا!