نظرة عامة شاملة على مايكروسوفت الشركة الرائدة في مجال تكنولوجيا المعلومات وأنظمة التشغيل

ديف أوبس (DevOps) عبارة عن منهجية حديثة تهدف إلى تعزيز التكامل والتعاون بين فريقي التطوير (Development) والعمليات (Operations) في دورة حياة تطوير البرمجيات، تركز هذه المنهجية على تحسين التواصل وتبسيط العمليات لضمان تقديم البرمجيات بسرعة وكفاءة وبجودة عالية، تعتمد ديف أوبس على مجموعة من الممارسات التي تشمل الأتمتة، التكامل المستمر، والتسليم المستمر، بالإضافة إلى مراقبة الأداء وتحليل البيانات، يساعد هذا النهج المؤسسات على التكيف مع التغيرات السريعة في متطلبات السوق وتقديم حلول تقنية مبتكرة تدعم تحقيق أهداف العمل بشكل أكثر فعالية.

ما هو ديف أوبس (DevOps)؟

مصطلح ديف أوبس (DevOps) هو مزيج من كلمتي التطوير والعمليات، ويهدف إلى تمثيل نهج تعاوني أو تشاركي للمهام التي تؤديها فرق تطوير التطبيقات وعمليات تكنولوجيا المعلومات في الشركة.

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

على الرغم من أن ديف أوبس ليس تقنية بحد ذاته، إلا أن بيئات ديف أوبس تُطبق منهجيات مشتركة، منها:

• التكامل المستمر والتسليم المستمر (CI/CD) أو أدوات النشر المستمر، مع التركيز على أتمتة المهام.
• الأنظمة والأدوات التي تدعم تبني منهجية ديف أوبس، بما في ذلك تطوير البرمجيات، والمراقبة الآنية، وإدارة الحوادث، وتوفير الموارد، وإدارة التكوين، ومنصات التعاون.
• الحوسبة السحابية، والخدمات المصغرة، والحاويات، تُنفذ بالتزامن مع منهجيات ديف أوبس.

يُعدّ نهج ديف أوبس أحد الأساليب العديدة التي يستخدمها فريق تقنية المعلومات لتنفيذ مشاريع تقنية المعلومات التي تلبي احتياجات العمل، يمكن لديف أوبس أن يتعايش مع منهجية (Agile) وغيرها من نماذج التطوير المستمر للبرمجيات، وأطر إدارة خدمات تقنية المعلومات، مثل (ITIL)، وتوجيهات إدارة المشاريع، مثل (Lean و Six Sigma)، وغيرها من الاستراتيجيات.

يعتقد بعض متخصصي تقنية المعلومات أن الجمع البسيط بين التطوير والتشغيل غير كافٍ، وأن مصطلح ديف أوبس (DevOps) يجب أن يشمل الأعمال (BizDevOps)، والأمن (DevSecOps)، أو مجالات أخرى.

لماذا يُعدّ ديف أوبس (DevOps) مهمًا؟

في جوهره، أثبت ديف أوبس وممارساته قدرتهما على تحسين جودة البرمجيات ونتائج مشاريع التطوير للمؤسسة، تتخذ هذه التحسينات أشكالًا متعددة، منها:

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

تُمكّن بيئة ديف أوبس المُنفذة بكفاءة الشركات من تقديم منتجات برمجية أكثر تنافسية وجودة إلى السوق بشكل أسرع، مع متطلبات دعم وصيانة أقل، مقارنةً بنماذج التطوير التقليدية.

كيف يعمل ديف أوبس (DevOps)؟

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

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

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

ولتجنب فترات الانتظار، تستخدم فرق تقنية المعلومات مسارات التكامل المستمر/التسليم المستمر (CI/CD) وغيرها من أدوات الأتمتة لنقل التعليمات البرمجية من مرحلة تطوير ونشر إلى أخرى، تراجع الفرق التغييرات فورًا، ويمكنها الاعتماد على السياسات والأدوات لتطبيقها وضمان مطابقة الإصدارات للمعايير.

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

قد يتولى المطورون دعم البرمجيات قيد التشغيل، مما يضع على عاتقهم مسؤولية معالجة اعتبارات وقت التشغيل، قد يشارك مديرو عمليات تكنولوجيا المعلومات في اجتماعات تصميم البرمجيات، مقدمين التوجيهات حول كيفية استخدام الموارد بكفاءة وأمان، ويمكن لأي شخص المساهمة في تحليلات ما بعد الحادث دون توجيه اللوم، وكلما زاد تعاون هؤلاء المتخصصين وتبادلهم للمهارات، كلما تمكنوا من تعزيز ثقافة ديف أوبس (DevOps).

ما المشاكل التي يحلها منهج ديف أوبس (DevOps)؟

تواجه كل شركة تحدياتها الخاصة، لكن من بين المشاكل الشائعة: تأخر إصدارات البرامج، وعدم تلبية البرامج للتوقعات، وتقنية المعلومات التي تحد من نمو الأعمال.

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

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

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

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

تطور منهجية ديف أوبس (DevOps)

يُنسب الفضل إلى "باتريك ديبوا"، مستشار تطوير البرمجيات، في ابتكار مصطلح ديف أوبس عام 2009 عندما أطلق اسم "أيام ديف أوبس" على أحد المؤتمرات، عالجت ديف أوبس قصورًا في منهجية تطوير البرمجيات الرشيقة (Agile): فالتطوير السريع والمتكرر للبرمجيات لم يكن يؤدي بالضرورة إلى نشرها بنفس السرعة والتكرار.

بالتزامن مع تعميق منهجية (Agile) في العمليات التشغيلية، شعر مديرو تقنية المعلومات بالاستياء من خطوات إدارة التغيير المعقدة والمرهقة أحيانًا في إطار عمل (ITIL)، يدعم (ITIL) تقنية معلومات مستقرة وموثوقة وقابلة للتنبؤ، بينما تدعو منهجية (Agile) إلى التعاون والتغيير، لاقت ديف أوبس استحسانًا لدى كلا الطرفين، في الواقع، يمكن للمؤسسات تطبيق كل من (ITIL وDevOps)، خاصةً إذا تبنت الحوسبة السحابية.

ثم انتشر مفهوم ديف أوبس على نطاق واسع مع كتاب "مشروع العنقاء" (The Phoenix Project) عام 2013، يستخدم "مشروع العنقاء" سردًا خياليًا لتوضيح المشكلات المتأصلة ومساعدة مديري تقنية المعلومات على فهم مفاهيم وفوائد التعاون والتقنيات المشتركة.

من بين أوائل الداعمين لمنهجية ديف أوبس، نذكر الشخصيات الرئيسية التالية:

• ديبوا وشريكه أندرو كلاي شيفر.
• مؤلفو كتاب "مشروع فينيكس": جين كيم، وكيفن بير، وجورج سبافورد.
• بول هاموند وجون ألسپاو، من أوائل المؤثرين في تبني هذه المنهجية في شركة فليكر.
• رواد التسليم المستمر: جيز همبل وديف فارلي.
• داعم تقنية الحاويات: جون ويليس.
• منظمو تقرير حالة ديف أوبس، بمن فيهم ألانّا براون ونيكول فورسغرين.

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

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

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

منهجيات ومبادئ واستراتيجيات ديف أوبس (DevOps)

يرتبط ديف أوبس بتطوير البرمجيات الرشيقة (Agile) لأن ممارسي (Agile) روّجوا لديف أوبس كوسيلة لتوسيع نطاق المنهجية لتشمل بيئة الإنتاج، حتى أن هذا النهج وُصف بأنه ثقافة مضادة لممارسات إدارة خدمات تكنولوجيا المعلومات التي يدعمها إطار عمل (ITIL)، لا يوجد إطار عمل رسمي لديف أوبس.

لتحسين استراتيجياتها، ينبغي على المؤسسات فهم السياقات ذات الصلة بديف أوبس، وتطوير البرمجيات الرشيقة (Agile) والتقليدية (Waterfall)، وهندسة موثوقية الموقع (SRE)، وعمليات النظام (SysOps)، وحتى الاختلافات داخل ديف أوبس نفسها.

1. ديف أوبس (DevOps) مقابل التطوير التقليدي (Waterfall)

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

يُنسق نموذج ديف أوبس جهود التطوير وضمان الجودة وعمليات تكنولوجيا المعلومات من خلال تقليل عدد المراحل وزيادة استمرارية سير العمل، على سبيل المثال، تنتقل بعض مسؤوليات فريق العمليات إلى فريق التطوير في المراحل الأولى من مسار تسليم التطبيق، ويُقدم فريق عمليات تكنولوجيا المعلومات ملاحظات لتحسين البرنامج، وبدلاً من المراحل المُحددة، يعتمد ديف أوبس على التكامل المستمر/التسليم المستمر (CI/CD) وعمليات المراقبة المستمرة.

2. ديف أوبس مقابل التطوير الرشيق

التطوير الرشيق هو منهجية لتطوير البرمجيات مُحددة في بيان (Agile)، تُركز فرق Agile على دورات سريعة ومتزايدة لإنشاء وتسليم البرنامج، تُعرف باسم دورات التطوير السريعة (Sprints)، تُبنى كل دورة تطوير سريعة على سابقتها، مما يجعل البرنامج مرنًا وقابلاً للتكيف مع المتطلبات المتغيرة، ومن المُحتمل أن تضيع الرؤية الأصلية للمشروع خلال هذه الدورة.

نشأت منهجية ديف أوبس نتيجةً لنجاح منهجية (Agile) في تحسين سرعة التطوير، وإدراك أن الانفصال بين فريقي التطوير والعمليات (وكذلك بين قسم تقنية المعلومات والجانب التجاري للمؤسسة) يعيق بشكل كبير وصول برمجيات (Agile) إلى المستخدمين.

في سير عمل (Agile) فقط، يكون لكل من فريقي التطوير والعمليات أهداف وقيادة منفصلة، أما عند استخدام (DevOps وAgile) معًا، فيتولى كلا الفريقين إدارة الكود طوال دورة حياة تطوير البرمجيات، ورغم أن منهجية (Agile) غالبًا ما تُنظّم بإطار عمل، مثل (Scrum)، فإن ديف أوبس لا يعتمد على إطار عمل محدد.

3. ديف أوبس مقابل التكامل المستمر/التسليم المستمر (CD)

تتضمن منهجيات (CD) نمطًا دوريًا متكررًا لبناء الكود وحفظ التغييرات في مستودع مركزي، بعد ذلك، يمكن اختبار الكود والتحقق من صحته باستخدام تقنيات الاختبار الآلي واليدوي، في حال نجاح الاختبار، يمكن النظر في إمكانية إطلاق الإصدار في بيئة الإنتاج.

تتبع ديف أوبس النمط الدوري نفسه للتطوير والاختبار، إلا أن (CD) عادةً ما يتوقف عند الجوانب التقنية لإنشاء الكود، لا يقدم هذا النهج المبادئ والتركيز على التواصل والتعاون في جميع أنحاء المؤسسة التي يسعى منهج ديف أوبس إلى تحسينها.

4. ديف أوبس (DevOps) مقابل هندسة موثوقية الموقع (SRE)

ظهرت هندسة موثوقية الموقع (SRE) بالتزامن مع منهجيتي (Agile وDevOps)، بدأت في أوائل الألفية الثانية في جوجل، وهي منهجية تركز على البرمجة والأتمتة في دورة حياة تطوير البرمجيات، تُركز (SRE) على موثوقية البرمجيات وقابليتها للتوسع، بهدف توقع المشكلات التي قد تُؤثر على استقرار التطبيق وسلامته، والتخفيف من آثارها، يجب حل المشكلات بطريقة تمنع تكرارها، مع تقليل المهام الروتينية إلى أدنى حد.

تتشابه أدوات (SRE) إلى حد كبير مع أدوات ديف أوبس، يهدف كلا المنهجين إلى التحسين المستمر، يسعى مهندسو (SRE وDevOps) إلى إزالة الحواجز بين التطوير والعمليات، على الرغم من أن ديف أوبس قد يشمل أصحاب المصلحة في الأعمال، إلا أن (SRE) عادةً ما يقتصر على عمليات تكنولوجيا المعلومات.

5. ديف أوبس (DevOps) مقابل عمليات النظام (SysOps)

يشير مصطلح (SysOps) عادةً إلى أن مسؤول تكنولوجيا المعلومات أو فريق تكنولوجيا المعلومات يُدير نشر ودعم تطبيقات موزعة واسعة النطاق، مثل منتجات (SaaS)، كما هو الحال مع مُتبنّي منهجية ديف أوبس، يجب أن تكون فرق (SysOps) مُلِمّة بالحوسبة السحابية والأتمتة، بالإضافة إلى التقنيات الأخرى التي تُمكّن التطبيقات من العمل بكفاءة عالية على نطاق واسع، تتولى فرق (SysOps) مهمة استكشاف أعطال ومشاكل تقنية المعلومات وإصلاحها، ومراقبة مشاكل الأداء، وتطبيق قواعد الأمان، وتحسين العمليات.

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

6. DevSecOps مقابل BizDevOps مقابل GitOps

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

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

ما هي فوائد ديف أوبس (DevOps)؟

حظي ديف أوبس بانتشار واسع بين المطورين والمؤسسات لما يوفره من تحسينات عديدة مقارنةً بنماذج التطوير التقليدية، تشمل فوائد ديف أوبس ما يلي:

• تقليل الحواجز بين الأقسام وتعزيز التواصل بين فرق تقنية المعلومات.
• تسريع طرح البرامج في السوق، مما يعزز الإيرادات والفرص التنافسية للشركة.
• تحسين سريع بناءً على ملاحظات المستخدمين وأصحاب المصلحة.
• زيادة الاختبارات تؤدي إلى جودة برامج أفضل، وممارسات نشر أفضل، وتقليل وقت التوقف.
• تحسين مسار تسليم البرامج بالكامل من خلال عمليات البناء، واستخدام المستودعات، والتحقق من صحة البرامج، والنشر.
• تقليل الأعمال الروتينية في مسار ديف أوبس بفضل الأتمتة.
• تبسيط عمليات التطوير من خلال زيادة المسؤولية وملكية الكود.
• توسيع نطاق الأدوار والمهارات.

ما هي تحديات ديف أوبس (DevOps)؟

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

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

باختصار: لا تُحل منهجية ديف أوبس جميع مشاكل الأعمال، ولا تُفيد جميع مشاريع تطوير البرمجيات بنفس الطريقة.

أفضل ممارسات تبني منهجية ديف أوبس (DevOps)

قد يُحدث تبني منهجية ديف أوبس أو غيرها من نماذج التكامل المستمر (CI/CD) تغييرات جذرية في فرق تطوير البرمجيات والإدارة، إذ تُفرض تغييرات حتمية على سير العمل، والعمليات، ومجموعات الأدوات، وحتى في هيكل الموظفين، مما يستدعي المزيد من التدريب، ومن السهل أن ينحرف تبني ديف أوبس عن مساره ويتلاشى في نهاية المطاف، فيما يلي بعض النصائح التي تُساعد على تسهيل تبني ديف أوبس وزيادة فرص نجاحه.

1. ابدأ بخطوات صغيرة

لا تحدث تحولات ديف أوبس بين عشية وضحاها، تبدأ العديد من الشركات بمشروع تجريبي - تطبيق بسيط يُتيح لها التعرف على الممارسات والأدوات الجديدة، تسعى فرق ديف أوبس إلى تحقيق نجاحات سريعة وسهلة لتحسين سير العمل، وتعلم الأدوات، وإثبات قيمة مبادئ ديف أوبس، لتبني DevOps على نطاق واسع، يُنصح بالانتقال إلى مراحل.

2. ضع في اعتبارك سير العمل

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

3. اختاروا الأدوات المناسبة

قيّموا الأدوات الحالية لتطوير البرمجيات وعمليات تكنولوجيا المعلومات، قد تحتاجون إلى أدوات إضافية أو مختلفة، حددوا أوجه القصور في العمليات، مثل خطوة تُنفذ يدويًا دائمًا (كالانتقال من إيداع الكود إلى الاختبار، على سبيل المثال) أو أداة تفتقر إلى واجهات برمجة التطبيقات (APIs) للربط مع أدوات أخرى، فكروا في توحيد مسار ديف أوبس واحد للشركة بأكملها، باستخدام مسار واحد، يمكن لأعضاء الفريق الانتقال من مشروع إلى آخر دون الحاجة إلى إعادة تأهيل، يمكن لمتخصصي الأمن تعزيز أمان المسار، كما تُصبح إدارة التراخيص أسهل، لكن في المقابل، تتخلى فرق ديف أوبس عن حرية استخدام ما يناسبها.

4. استخدموا مقاييس ذات مغزى

مجرد تبني ديف أوبس لا يكفي لضمان النجاح، افهم الحاجة إلى منهجية ديف أوبس في المقام الأول - ما المشاكل التي تهدف إلى حلها، أو ما الفوائد التي تهدف إلى تحقيقها، اختر المقاييس ومؤشرات الأداء الرئيسية التي ستُظهر تلك النتائج، ثم خطط لقياس هذه المقاييس والإبلاغ عنها كمقياس موضوعي لنجاح ديف أوبس، على سبيل المثال، يمكن لمقياس مثل عدد العيوب المكتشفة أو سرعة إنجاز التعليمات البرمجية أن يساعد في إدارة نتائج ديف أوبس.

أصبحت المؤسسة الآن تمتلك عقلية ديف أوبس، ومقاييس لتتبع النجاح، وأدوات فعّالة، ركّز على أفضل الممارسات، وتبادل المعرفة، وتطوير المهارات لمواصلة التحسين، حسّن الأدوات والتقنيات، وحدّد العقبات والثغرات التي تؤثر على مؤشرات الأداء الرئيسية.

5. استخدم نموذج نضج ديف أوبس

يوضح نموذج نضج ديف أوبس خمس مراحل رئيسية للتبني، تتراوح من المبتدئ إلى المُترسّخ، يمكن للمؤسسات استخدام نموذج نضج ديف أوبس كدليل للتبني من خلال تحديد موقعها في النموذج:

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

أدوات ديف أوبس (DevOps)

يُعدّ ديف أوبس منهجيةً فكريةً، وليس مجموعة أدوات، ولكن يصعب إنجاز أي عمل في فريق تقنية المعلومات دون أدوات مناسبة ومتكاملة، يعتمد ممارسو ديف أوبس عمومًا على خط أنابيب التكامل المستمر/التسليم المستمر (CI/CD)، والحاويات، والاستضافة السحابية، قد تكون الأدوات مفتوحة المصدر، أو احتكارية، أو توزيعات مدعومة لتقنية مفتوحة المصدر.

• مستودعات الشفرة المصدرية: تُمكّن مستودعات الشفرة المصدرية المُتحكَّم في إصداراتها العديد من المطورين من العمل على الشفرة، يقوم المطورون بتسجيل الشفرة وإضافتها، ويمكنهم الرجوع إلى إصدار سابق منها عند الحاجة، تحتفظ هذه الأدوات بسجل للتعديلات التي أُجريت على الشفرة المصدرية، بما في ذلك هوية من قام بالتغييرات وتاريخها، بدون هذا التتبع، قد يواجه المطورون صعوبةً في معرفة التغييرات الحديثة وإصدارات الشفرة المتاحة للمستخدمين النهائيين.
• في خط أنابيب التكامل المستمر/التسليم المستمر (CI/CD): يؤدي أي تغيير في الشفرة يُضاف إلى مستودع التحكم في الإصدارات إلى تشغيل الخطوات التالية تلقائيًا، مثل تحليل الشفرة الثابت أو بناء واختبارات الوحدات، تشمل أدوات إدارة شفرة المصدر (Git وGitHub)، بالإضافة إلى (Bitbucket وMercurial وSubversion) وغيرها.
• مستودعات المُخرجات البرمجية: تُجمّع شفرة المصدر في مُخرجات برمجية لأغراض الاختبار، تُمكّن مستودعات المُخرجات البرمجية من الحصول على مُخرجات قائمة على الكائنات ومُتحكّم في إصداراتها، تُعدّ إدارة المُخرجات البرمجية ممارسة جيدة للأسباب نفسها التي تُفضّل من أجلها إدارة شفرة المصدر المُتحكّم في إصداراتها، من أمثلة مستودعات المُخرجات البرمجية: (JFrog Artifactory وNexus Repository وAzure Artifacts وAmazon Elastic Container Registry وCloudsmith وDist وProGet وYarn).
• محركات خط أنابيب التكامل المستمر/التسليم المستمر (CI/CD): يُمكّن التكامل المستمر/التسليم المستمر فرق ديف أوبس من التحقق من صحة التطبيقات وتسليمها للمستخدم النهائي بشكل متكرر من خلال الأتمتة خلال دورة حياة التطوير، تُهيّئ أداة التكامل المستمر العمليات بحيث يُمكن للمطورين إنشاء الشفرة واختبارها والتحقق من صحتها في مستودع مشترك كلما دعت الحاجة دون تدخل يدوي، يُوسّع التسليم المستمر هذه الخطوات التلقائية لتشمل اختبارات على مستوى الإنتاج وإعدادات التكوين لإدارة الإصدارات، يتجاوز النشر المستمر ذلك، إذ يشمل الاختبارات والتكوين والتجهيز، بالإضافة إلى المراقبة وإمكانية التراجع، من الأدوات الشائعة للتكامل المستمر (CI) والنشر المستمر (CD) أو كليهما: (Jenkins وGitLab وTravis CI وAtlassian Bamboo وConcourse وCircleCI).
• الحاويات: هي بيئات تشغيل معزولة للبرمجيات على نظام تشغيل مشترك، توفر الحاويات تجريدًا يمكّن الكود من العمل بنفس الكفاءة على بنى تحتية مختلفة، بدءًا من التطوير والاختبار والتجريب، وصولًا إلى الإنتاج، يُعد (Docker وApache Mesos) من أشهر برامج الحاويات، بينما تقدم مايكروسوفت خيارات حاويات خاصة بنظام ويندوز، تقوم أنظمة تنسيق الحاويات مثل (Kubernetes وتوزيعات Kubernetes) التجارية بنشر الحاويات وتوسيع نطاقها وصيانتها تلقائيًا.
• إدارة التكوين: تُمكّن أنظمة إدارة التكوين أقسام تقنية المعلومات من توفير وتكوين البرمجيات والبرمجيات الوسيطة والبنية التحتية بناءً على نص برمجي أو قالب، يستطيع فريق ديف أوبس إعداد بيئات نشر لإصدارات البرامج وتطبيق السياسات على الخوادم والحاويات والأجهزة الافتراضية باستخدام أداة إدارة التكوين، يمكن التحكم في إصدارات التغييرات التي تُجرى على بيئة النشر واختبارها، مما يُمكّن فرق ديف أوبس من إدارة البنية التحتية كبرنامج (IaC)، تشمل أدوات إدارة التكوين (Ansible وTerraform وSaltStack وPuppet وChef).
• البيئات السحابية: غالبًا ما تتبنى مؤسسات ديف أوبس البنية التحتية السحابية بالتزامن مع البرامج، نظرًا لقدرتها على أتمتة النشر والتوسع ومهام الإدارة الأخرى، تُعد (AWS وGoogle Cloud وMicrosoft Azure) من بين أكثر مزودي الخدمات السحابية استخدامًا، كما يُقدم العديد من مزودي الخدمات السحابية خدمات التكامل المستمر/التسليم المستمر (CI/CD).
• المراقبة: بالإضافة إلى ذلك، تُمكّن أدوات المراقبة متخصصي ديف أوبس من مراقبة أداء وأمان إصدارات البرامج على الأنظمة والشبكات والبنية التحتية، يُمكنهم دمج المراقبة مع أدوات التحليل التي تُوفر معلومات تشغيلية، تستخدم فرق ديف أوبس هذه الأدوات معًا لتحليل كيفية تأثير التغييرات في البرامج على البيئة بشكل عام، تتنوع الخيارات بشكل كبير، وتشمل (New Relic One وDynatrace وPrometheus وDatadog وSplunk).
• مسارات ديف أوبس السحابية: توفر شركات الحوسبة السحابية العامة مجموعات أدوات ديف أوبس مدمجة لاستخدامها مع أحمال العمل على منصاتها، تتضمن هذه المجموعات، على سبيل المثال لا الحصر، (AWS CodePipeline وCloudFormation، وAzure DevOps وPipelines، وGoogle Cloud Deployment Manager)، يُمكن لمستخدمي الحوسبة السحابية استخدام هذه الخدمات المدمجة مسبقًا أو تشغيل أدوات خارجية، على سبيل المثال، يُمكن للمؤسسة استخدام (HashiCorp Terraform أو CloudFormation) لإنشاء قوالب البنية التحتية كبرنامج (IaC) لأحمال عمل (AWS).
• نماذج الخدمة: أخيرًا، يُعد ديف أوبس كخدمة نموذجًا لتوفير مجموعة من الأدوات التي تُسهّل التعاون بين فريق تطوير البرمجيات وفريق عمليات تكنولوجيا المعلومات في المؤسسة، في هذا النموذج، يُجمّع المزوّد مجموعة من الأدوات ويتولى عمليات التكامل لتغطية عملية إنشاء التعليمات البرمجية وتسليمها وصيانتها بسلاسة.

في حالات أخرى، يعمل مزودو خدمات ديف أوبس كاستشاريين لمساعدة الشركات في مشاريع ديف أوبس، أو لتوفير الخبرات اللازمة في أي مرحلة من مراحل عملية ديف أوبس، يجب تقييم أي مزود خدمة بناءً على عوامل تشمل مدة مزاولة العمل، والخبرة المثبتة - لا سيما في القطاعات السوقية ذات الصلة - ومدى توافقه مع أدوات وممارسات ديف أوبس الحالية.

مهارات ديف أوبي (DevOps) وأدوارها الوظيفية

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

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

تتطلب العديد من إعلانات وظائف ديف أوبس معرفة بالحاويات والحوسبة السحابية و(CI/CD)، بالإضافة إلى مهارات شخصية مثل التواصل وقيادة الفريق، قد يحتاج مهندس ديف أوبس أيضًا إلى تغيير العمليات وحل المشكلات التنظيمية لتحقيق أهداف العمل.

تشمل المسميات الوظيفية الأخرى الشائعة في مؤسسات ديف أوبس ما يلي:

• مطور بنية تحتية.
• مستشار سحابي.
• مهندس موثوقية الموقع.
• مهندس معمارية ديف أوبس.
• مهندس بناء وإصدار.
• مطور تطبيقات متكاملة.
• أخصائي أتمتة.
• مهندس منصة (CI/CD).

لا تحكم على الوظيفة من خلال مسمى الوظيفة فقط، فالأدوار الوظيفية تختلف اختلافًا كبيرًا، لذا خذ وقتك للاطلاع على المؤهلات التعليمية ومتطلبات الوظيفة والخبرة المطلوبة لكل نوع من أنواع الفرص.

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

تعديل المقال