بقلم جمال بطيخ
مدرّس ومشرف في الجامعة الافتراضية السورية
تعرَّف DevOps: DEVelopment OPerationS بأنها ثقافة تَعتبر التعاون بين فريق التطوير البرمجي وفريق عمليات الاستثمار التطبيقية وفريق واضعي متطلبات العمل جانبًا مهمًّا من رحلتها الطويلة في مؤسسة الأعمال. لا يتعلق الأمر بأدوات التطوير البرمجي وعمليات الاستثمار فحسب، وإنما بالقيمة المضافة المستمرة التي تقدمها عمليات DevOps في المؤسسة للعملاء. وهذه الأدوات هي إحدى ركائز DevOps، أما الركيزتان الأخريان فهما الأشخاص والعمليات.
تزيد DevOps من قدرة المؤسسات على تقديم حلول عالية الجودة بوتيرة سريعة، وتقوم بأتمتة جميع العمليات بدءًا من التخطيط والإنشاء وحتى نشر التطبيق أو المنتَج المزمع صناعته.
تقدم هذه المقالة توضيحًا شاملًا لتطبيق أساليب DevOps وأدواتها وأطر عملها في رحلة DevOps ضمن مؤسسة الأعمال.
فيما يلي التحديات التي تواجهها شركة التطوير والعمليات العاملة بثقافة DevOps بفريقيها – فريق التطوير البرمجي وفريق عمليات الاستثمار:
تحديات فريق التطوير البرمجي
المطورون متحمسون ومستعدون للتكيف مع الأساليب والتقنيات الجديدة لمواجهة تحديات منظمات ومؤسسات العمل. ومع ذلك، فهم يواجهون العديد من التحديات؛ ومنها:
- يخلق السوق التنافسي الكثير من الضغط على الفريق للتسليم في الوقت المحدد.
- على فريق التطوير البرمجي أيضًا تلبية احتياجات إدارة التعليمات البرمجية الجاهزة للإنتاج وقدرات التنفيذ الجديدة المتاحة.
- دورة الإصدار طويلة لأي نسخة برمجية، ومن ثَم يتعين على فريق التطوير البرمجي وضع عدة افتراضات ومقاربات قبل نشر التطبيق. في مثل هذا السيناريو، يستغرق الأمر وقتًا أطول لحل المشكلات التي حدثت أثناء النشر في بيئة الإنتاج أو خلال المراحل الوسيطة للوصول إلى المنتج النهائي.
تحديات فريق عمليات الاستثمار
غالبًا ما يكون أعضاء فريق العمليات حساسين بشأن تغيير أي موارد أو الاستفادة من أي تقنيات جديدة أو مناهج جديدة، وذلك لأنهم يبحثون دائمًا عن الاستقرار في العمل وأدواته. ومع ذلك، فهم يواجهون العديد من التحديات؛ منها:
- التنازع على الموارد: من الصعب جدًّا التعامل مع الطلبات المتزايدة على الموارد.
- إعادة التصميم أو التغيير والتبديل: هذا من متطلبات تنفيذ التطبيق في بيئة الإنتاج والاستعمال.
- التشخيص والحلول: من المفترض أن يقوموا بتشخيص وحل المشكلات المتعلقة بالإنتاج بعد نشر التطبيق في بيئة معزولة عن المستعمل النهائي لإجراء الاختبارات اللازمة.
نظرة عامة على DevOps
تحاول الشركات معرفة إمكان طرح عدد قليل من الميزات البرمجية الخاصة بتطبيقٍ ما لعملائها ضمن سلسلة من الإصدارات المتكررة، بدلًا من إطلاق عدد كبير منها دفعة واحدة. يقدم هذا الأسلوب العديد من المزايا؛ مثل: الحصول على جودة أفضل للبرامج، وتلقي الانطباعات السريعة من العملاء على هذه الإصدارات، وما إلى ذلك. وهذا قد يضمن رضا العملاء العالي على هذه النسخ من التطبيق وعلى التطبيق كله أيضًا. حتى نضمن تحقيق هذه الأهداف وتقديم المزايا الفضلى، يتعين على الشركات:
- أن يكون معدل الإخفاق للإصدارات الجديدة منخفضًا.
- أن تزيد وتيرة النشر من الإصدارات.
- أن تزيد من استجابتها لاستعادة النسخة الأخيرة للعمل بسرعة كبيرة في حالة تعطل الإصدار الجديد للتطبيق.
- أن تكون فترة الانقطاع والتوقف أقصر ما يمكن خلال مدة إجراء الإصلاحات.
تحقق DevOps كل هذه الأهداف المبيَّنة آنفًا وتساعد على تحقيق التسليم السلس للتطبيق. اعتمدت شركات Google وEtsy وAmazon بنى DevOps خاصة بها لتحقيق مستويات أداء لم يكن من الممكن تصورها حتى قبل بضع سنوات؛ فهي تقوم بالعشرات أو المئات أو حتى الآلاف من عمليات النشر يوميًّا مع تقديم موثوقية واستقرار وأمان على مستوى عالمي.
تشكل DevOps إطار عمل لإجراءات العمل بحيث تضمن التعاون بين فريق التطوير وعمليات الاستثمار لنشر التعليمات البرمجية والترميز في بيئة الإنتاج بطريقة آلية وسريعة وقابلة للتكرار. إن كلمة DevOps هي دمج لكلمتي تطوير Development وعمليات الاستثمار Operation. تساعد DevOps على زيادة السرعة لتقديم التطبيقات والخدمات. وتتيح للمؤسسات خدمة عملائها بكفاءة لكي تصبح أكثر قدرة على المنافسة في السوق. بعبارات بسيطة، يمكن تعريف DevOps على أنه مواءمة بين عمليات التطوير وتقانة المعلومات مع تواصل وتعاون وتشارك أفضل. قبل البدء بالتحول نحو DevOps :
- كان فريق التطوير البرمجي يعمل في عزلة تامة عن فريق عمليات الاستثمار والتشغيل.
- كان الاختبار والنشر ينجزان في مرحلتين منفصلتين، ويتم إنجازهما بعد التصميم وبناء التطبيق وترجمته. ويتطلب ذلك وقتًا أطول من دورة حياة البناء والترجمة الحالية.
- كان أعضاء الفريق يمضون قدرًا كبيرًا من وقتهم في الاختبار والنشر والتصميم بدلًا من التركيز على الجزء الأساسي والمحوري الذي يؤدي إلى إنشاء خدمات الأعمال.
- كان نشر الترميز البرمجي يدويًّا، فأدى ذلك إلى حدوث أخطاء في الإنتاج.
- كان لدى فريق التطوير البرمجي وفريق عمليات الاستثمار وفريق التشغيل جداول زمنية منفصلة وخاصة بكل فريق على حدة، ولا تضمن التزامن والتناغم الفعال فيما بينها، مما قد يتسبب في تأخير زمني إضافي.
مقارنة سريعة بين DevOps وAgile وتقانة المعلومات التقليدية
تعرَّف منهجية تطوير البرمجيات الرشيقة Agile بأنها مجموعة من المبادئ والقيم والأساليب لإنتاج البرمجيات. على سبيل المثال، إذا كان لدى المرء أي أفكار ويريد تحويل تلك الأفكار إلى برامج، فيمكنه الاستفادة من مبادئ وقيم Agile. ولكن، قد يعمل هذا البرنامج فقط في بيئة التطوير أو الاختبار. يجب أن يكون لدى المرء طريقة لنقل البرنامج بسرعة وبشكل متكرر إلى بيئة إنتاج بطريقة بسيطة وآمنة.
لتحقيق ذلك، يحتاج المرء إلى أدوات وتقنيات DevOps. نعلم أن منهجية تطوير البرمجيات الرشيقة تركز على إجراءات التطوير البرمجي ومراحله، أما بنى DevOps، فهي مسؤولة عن عمليات التطوير والنشر بطريقة أكثر أمانًا وموثوقية.
لنقارن نموذج الشلال للبرامج التقليدية Waterfall Model مع DevOps للوقوف على الفوائد التي توفرها DevOps. نفترض أنه تم وضع جدول زمني لإنجاز التطبيق كما يلي: التطبيق مجدول لوضعه في الاستثمار في غضون 4 أسابيع، مع اكتمال الترميز البرمجي بنسبة 85٪. نفترض أن التطبيق هو إطلاق جديد، وأن عملية شراء الخوادم لشحن الترميز البرمجي قد بدأت للتو.
دورة حياة DevOps
التخطيط المستمر
يعزِّز التخطيط المستمر المبادئ التي تحد من الهدر، ويتيح توظيف أقل قدر ممكن من الموارد المختلفة للحصول على النتائج المطلوبة التي تتماشى مع قيم أو رؤى العمل المعتمدة، والتأقلم المستمر، وقياس التقدم المنجز، واكتساب خبرات التعلم من احتياجات العملاء، بما يؤدي إلى إمكان تغيير وتحديث خطط العمل بخفة ورشاقة.
التطوير التعاوني أو التشاركي
تتيح عملية التطوير التعاوني أو التشاركي التعاون الفعال بين فريق التطوير البرمجي وفريق الاختبار الموجودين في مناطق متباعدة مكانيًا؛ لتقديم برامج عالية الجودة باستمرار. يتضمن ذلك تطوير النظم الأساسية ذات منصات العمل المتعددة، ودعم البرمجة بلغات ترميز متعددة، والوقوف على متطلبات المستعملين وتوضيح أفكارهم ودمجها للمساعدة على إدارة دورة حياة المنتَج النهائي. تشمل عملية التطوير التعاوني إجراءات وخبرات الممارسة لتحقيق التكامل المستمر، الذي يعزز تكامل الترميز البرمجي باستمرار، وإنشاء ترجمة آلية للترميز البرمجي. يتيح التكامل المستمر للترميز البرمجي تحديدَ مشكلات التكامل في وقت مبكر من مراحل دورة الحياة للمنتَج النهائي، حيث يكون من السهل إصلاحها، ويجري تقليل جهد التكامل الكلي عن طريق التعليقات المستمرة، حيث يُظهر المشروع تقدمًا مستمرًّا يمكن إثباته.
الاختبار المستمر
يقلل الاختبار المستمر من تكلفة الاختبار مع مساعدة فريق التطوير البرمجي على تحقيق التوازن بين سرعة الإنجاز وجودة المنتَج. يؤدي هذا أيضًا إلى التخلص من اختناقات الاختبار عن طريق الخدمات الافتراضية، وكذلك يبسِّط إنشاء بيئات اختبار افتراضية يمكن مشاركتها ونشرها وتحديثها بسهولة عند تغير النظم. تقلل هذه الإمكانات من تكلفة توفير بيئات الاختبار وصيانتها وتقصير أوقات دورات الاختبار بالسماح باختبار التكامل مبكرًا في دورة حياة المنتج.
الإصدار والنشر المستمران
يتكون مسار الاعتماد هذا من ممارسة وخبرة راسخة واحدة هي الإصدار والنشر المستمران. يوفر الإصدار والنشر المستمران خطَّ إنتاج للتسليم المستمر يعمل على أتمتة الإجراءات الرئيسية. فهو يقلل من عدد الإجراءات اليدوية، ووقت انتظار الموارد، وتكرار نفس العمل، وذلك بتمكين النشر بضغطة زر تضمن عددًا أكبر من الإصدارات، وتقليل الأخطاء، وتوفير الشفافية الشاملة من البداية وحتى النهاية. تؤدي الأتمتة دورًا رئيسيًّا في ضمان إصدار البرنامج بشكل متكرر وموثوق. وتتمثل الأهداف الحاسمة للإصدار والنشر المستمرين في تحويل الإجراءات اليدوية، مثل الإنشاء والتراجع والنشر، وتوفير البنية التحتية وأتمتتها. ولتحقيق ذلك، نحتاج إلى التحكم في إصدارات الترميز البرمجي المصدري، ونصوص الاختبار والنشر، والبنية التحتية ومعطيات تكوين التطبيق، التي يعتمد التطبيق عليها من المكتبات والحزم البرمجية وغيرها. يجب أن تتاح أيضًا عملية الاستعلام عن حالة جميع البيئات.
المراقبة المستمرة
تضمن المراقبة المستمرة إمكان إعداد التقارير على مستوى المؤسسة، فهي تساعد فريق التطوير البرمجي على فهم مدى توفر التطبيقات وأدائها في مرحلة التشغيل والاستثمار من مراحل الإنتاج، وحتى قبل مرحلة النشر. تُعتبر هذه التغذية الراجعة المبكرة التي تقدِّمها المراقبة المستمرة أمرًا بالغ الأهمية لخفض تكلفة الأخطاء، ولتوجيه المشاريع في الاتجاه الصحيح.
التغذية الراجعة والتحسين المستمر
توفر التغذية الراجعة والتحسين المستمر دليلًا مرئيًّا لتحليل سلوك العملاء وتحديد مكان الضعف والأخطاء. يمكن تمكين التغذية الراجعة لكل من مرحلتي ما قبل الإنتاج وما بعده لزيادة القيمة المضافة وضمان إتمام المزيد من المناقلات بنجاح. يوفر هذا رؤيةً فورية للأسباب الحقيقية لما يعانيه العملاء من مشاكل تؤثر في سلوكهم وأعمالهم.
فوائد DevOps
يمكن استعراض بعض الفوائد المهمة لـ DevOps في النقاط التالية:
القدرة على التنبؤ: تقدم DevOps معدل إخفاق أقل بكثير للإصدارات الجديدة بسبب القدرة على التنبؤ المبكر.
قابلية الصيانة: تستهلك عملية استرداد النسخة الأخيرة جهدًا أقل في حالة تعطل الإصدار الجديد أو تعطيل التطبيق الحالي.
قابلية إعادة الإنتاج: أي تعيين الإصدار للبنى أو التعليمات أو الترميز البرمجية، بحيث يمكن استعادة إصدار سابق حسب الحاجة.
جودة أعلى: تُمكّن DevOps الفريق من إنشاء جودة محسّنة لتطوير التطبيقات لأنها تتضمن المشكلات المحتملة للبنية التحتية.
اختصار زمن التسويق للمنتج: يقلل DevOps من الوقت اللازم للتسويق عن طريق تسليم البرامج المجدولة بنسبة 50٪ عن الطرائق التقليدية.
تقليل المخاطر: يدمج DevOps سمات الأمان في دورة حياة المنتج البرمجي، مما يساعد على تقليل العيوب في دورة حياته.
فعالية التكلفة: تقدم DevOps أيضًا فعالية من حيث التكلفة في تطوير البرامج، وهو أحد أهداف الإدارة العليا للمؤسسة.
المرونة: يصبح النظام المعلوماتي والبرمجي أكثر استقرارًا وأمانًا، وتكون التغييرات قابلة للتدقيق والمراقبة.
كسر قاعدة الرموز الكبيرة إلى أجزاء يمكن التحكم فيها: تعتمد DevOps على طريقة البرمجة الرشيقة في معظم خطوات دورة حياة المنتج البرمجي. لذلك، فإنها تتيح تقسيم كتل التعليمات والترميز البرمجي الرئيسة إلى أجزاء صغيرة يمكن التحكم فيها بسهولة.
المنهج والأسلوب – DevOps
أنتج اعتمادُ DevOps العديدَ من المبادئ التي تطورت بمرور الوقت ولا تزال في قيد التطوير. كذلك طور معظم مزودي الحلول المعلوماتية المتكاملة المتغيرات الخاصة بهم. تتخذ كل هذه المبادئ منهجًا شاملًا تجاه DevOps، ويمكن لمؤسسات الأعمال من جميع الأحجام اعتمادها. سنستعرض فيما يلي أهمها:
تطوير واختبار في بيئة شبيهة ببيئة الإنتاج
الهدف هو السماح لفريق التطوير البرمجي وضمان الجودة (QA) بالتطوير والاختبار للنظم ومعرفة آلية عملها وكأنها في قيد التشغيل الفعلي حتى يتمكنوا من رؤية كيفية تصرف التطبيق وجودة عمله قبل أن يصبح جاهزًا للنشر. يجب أن يتم التصريح والتعريف بالتطبيق في بيئة نظام شبيه بالإنتاج في مرحلة مبكرة من دورة حياته قدر الإمكان لمعالجة مشكلتين رئيسيتين محتملتين؛ هما:
أولًا: السماح باختبار التطبيق في بيئة قريبة من بيئة الإنتاج الفعلية.
ثانيًا: إتاحة اختبار عمليات تسليم التطبيق والتحقق من صحتها مقدمًا. إنه يمكّن فريق عمليات التشغيل والاستثمار من التحقق في وقت مبكر من دورة الحياة من معرفة كيفية تصرف التطبيق في بيئة العمل عند نشر التطبيقات، مما يسمح بإنشاء تطبيقات مدركة لبيئة العمل ومعرفة إمكان إجراء التعديل عليها بدقة.
النشر بعمليات متكررة وموثوقة
يسمح هذا المبدأ لفريق التطوير البرمجي وفريق عمليات الاستثمار والتشغيل بدعم عملية تطوير البرمجيات السريعة طوال دورة حياة المنتَج. تمثل الأتمتة أمرًا بالغ الأهمية لإنشاء إجراءات تكرارية وموثوقة. ومن ثم يجب على منظمة الأعمال إنشاء خط إنتاج للتسليم يتيح النشر والاختبار المستمر والآلي. وكذلك تسمح عمليات النشر المتكررة للفرقاء باختبار هذه العمليات، ومن ثَم تقليل مخاطر عمليات إخفاق النشر للإصدارات الجارية.
المراقبة والتحقق من جودة التشغيل
تجيد منظمات الأعمال مراقبة التطبيقات في مرحلة الإنتاج لأن لديها أدوات تتعرف على المقاييس /مؤشرات الأداء الرئيسية في الزمن الحقيقي. ينتقل هذا المبدأ إلى المراقبة في وقت مبكر من دورة حياة التطبيق عن طريق ضمان إجراء الاختبار الآلي مبكرًا لمراقبة السمات الوظيفية وغير الوظيفية للتطبيق. عندما يتم اختبار التطبيق ونشره، يجب تعريف مقاييس الجودة وتحليلها. توفر أدوات المراقبة إنذارًا مبكرًا لقضايا التشغيل والجودة في حالات التشغيل الطبيعية التي قد تحدث في الإنتاج. يجب جمع هذه المقاييس ووضعها بتنسيقٍ يمكن لجميع أصحاب المصلحة في الأعمال فهمه والتعبير عنه.
توسيع حلقات التغذية الراجعة والملاحظات
يتمثل أحد أهداف عمليات DevOps في تمكين منظمات الأعمال من التفاعل وإجراء التغييرات بسرعة أكبر. في تسليم البرامج، يتطلب هذا الهدف أن تحصل منظمة الأعمال على ملاحظات مبكرة ثم تتعلم بسرعة من كل إجراء تتخذه. يدعو هذا المبدأ منظمات الأعمال إلى إنشاء قنوات اتصال تسمح لأصحاب المصلحة بالوصول إلى ملاحظات التغذية الراجعة والعمل بناءً عليها. قد تعمل عملية التطوير البرمجي عن طريق تعديل خطط مشروعها أو أولوياتها. في حين تعمل عمليات الإنتاج على تحسين بيئات الإنتاج.
أدوات DevOps
سبّب الفصل المنهجي والتقليدي بين فريق التطوير البرمجي وفريق الاستثمار العملياتي عدة مشاكل خلال دورة حياة المنتج حتى الوصول إلى مرحلة الإنتاج التجاري. ثم جاءت فكرة DevOps التي تستمد جذورها من منهجية البرمجيات الرشيقة. إذ تم التنسيق بين فريقي عمل DevOps والبرمجيات الرشيقة من أجل تحسين الإنتاجية بالعمل التعاوني التشاركي. وتساعد أدوات DevOps المتاحة حاليًّا، أعضاء فريق العمل على تحقيق الاستمرارية في الأتمتة والتطوير بفعالية أكبر. يمكن لكل مؤسسة أعمال أن تختار الأداة المناسبة لتطوير أتمتها من الأدوات التالية التي تعتبر الأكثر استعمالًا:
1-Docker
تتصدر الترتيب الأعلى لأدوات DevOps، وتعد Docker أداة DevOps الأكثر شيوعًا واستعمالًا لدى مهندسي DevOps. وتشكل Docker نظامًا أساسيًّا مفتوح المصدر يستند إلى نظام Linux ويركز على الحاويات، وهذا يعني وضع البرمجيات مع ملحقاتها وكل شيء معًا كوحدة واحدة لا تتجزأ- فيقلل ذلك من دواعي القلق بشأن إدارة الارتباطات فيما بين الأجزاء المختلفة بشكل منفصل. وهذه الأداة محمولة وآمنة جدًّا، ويمكن استعمال أي لغة برمجة معها، ويتوفر فيها إمكان التكامل الجيد والفعال مع عدد من الأدوات الأخرى، مثل Jenkins وAnsible وBamboo.
2- Ansible
الأداة الثانية الأكثر استعمالًا من أدوات DevOps. وهي متاحة للجميع كأي أداة مفتوحة المصدر. تُستعمل لأتمتة البرامج في مراحل الإعداد والتهيئة وإدارة الإعدادات حسب المتطلبات ونشر التطبيقات. هي سهلة الاستعمال - لا تحتاج حتى إلى وجود مدير نظم مخصص - ومع ذلك يمكن التعامل مع عمليات النشر المعقدة جدًّا، إضافة إلى أنها لا تحتاج إلى وسيط أو وكيل، وتَستعمل بنيةً بسيطة مكتوبة بلغة YAML. تستعمل وكالةُ ناسا الأداة Ansible.
3- Git
Git هي أداة DevOps مفتوحة المصدر شائعة الاستعمال لدى عمالقة شركات الصناعة المعلوماتية مثل Microsoft وAmazon وFacebook. تسمح بتتبع تقدم العمل المنجز في أعمال التطوير البرمجي وتنسيق أكبر للعمل بين أعضاء الفريق. يعد Git رائعًا للأعمال التجريبية والبحث العلمي، لأنه يسمح باستعادة الإصدارات المحفوظة مسبقًا خلال العمل، ويسمح أيضًا بإنشاء فروع للعمل بشكل منفصل ثم إضافة الميزات الجديدة عندما تكون جاهزة كتجميع لكل مكونات العمل لدى المطورين المختلفين في الفريق. عند استعمال هذه الأداة نحتاج إلى استضافة مستودع تجميعي للعمل أيضًا، مثل GitHub.
4- Puppet
تتيح Puppet إدارة وأتمتة فحص البرامج (وتدقيق محتواها) وتسليمها وتشغيلها. وهي أداة مفتوحة المصدر، ولها سجل حافل من التماسك وتحتوي على آلاف الوحدات البرمجية الجاهزة التي يمكن دمجها بسهولة مع العديد من بيئات العمل والنظم الأساسية الأخرى. يوجد منها إصدار مجاني رائع للمشاريع الصغيرة، ولكن لا يمكن استعماله في المشاريع الاحترافية؛ إذ يجب شراء نسخة Puppet Enterprise للمشاريع الكبيرة والاستراتيجية تجنبًا لأي محدودية في الاستعمال قد تسبب توقفًا في العمل. وتتيح نسخة Puppet Enterprise كذلك إدارة عدة فرقاء عمل وآلاف الموارد المختلفة.
5- Chef
Chef أداة قوية لإدارة الإعدادات والتكوين ذات بنية مفتوحة المصدر. تتيح تحويل البنية التحتية إلى ترميز برمجي لإدارة المعطيات والسمات (الواصفات) والأدوار ذوات الصلاحيات المختلفة وبيئات العمل وغير ذلك. تعتبر Chef من الأدوات المنافسة للأداة Puppet، فهي تدعم منصات العمل المتعددة وتتكامل بسهولة مع المنصات المبنية على مفهوم السحابة. وبقطع النظر عن حجم البنية الأساسية الخاصة بك، يمكن لأداة Chef أتمتة تكوين وإعدادات البنية الأساسية الخاصة بك ونشر التطبيقات، إضافة إلى إدارة التكوينات بواسطة الشبكة الخاصة بالعمل.
6- Jenkins
تتميز الأداة Jenkins بسرعة إيجاد المشكلات والأخطاء في التعليمات البرمجية. وهي أداة مجانية مفتوحة المصدر تُستعمل لأتمتة خطوط إنتاج تسليم المنتجات البرمجية، وتسمح باختبار التغييرات الأخيرة على المنتج والإبلاغ عنها بأسرع ما يمكن، في الزمن الحقيقي تقريبًا. تمتلك Jenkins نظامًا ضخمًا من البرمجيات المساعدة والمدمجة للمكونات الإضافية (أكثر من ألف مكون إضافي من الوحدات البرمجية الجاهزة)، لذا فهي تتكامل مع كل أدوات DevOps الأخرى تقريبًا. إضافة إلى ذلك، يمكن تشغيلها في عدة نظم تشغيل مثل Windows وMac OS X وLinux.
7- Nagios
ترتيبها السابع في أفضلية أدوات DevOps. تُستعمل لإيجاد وتصحيح المشاكل في الشبكات والبنية التحتية. وتعتبر أكثر أدوات المراقبة المجانية والمفتوحة المصدر استعمالًا. لها إصداران: Nagios Core وNagios XI. يوفر الإصدار Nagios XI العديد من الميزات الخاصة للقيام بمزيد من الوظائف البرمجية. يمكن استعمال Nagios لمراقبة التطبيقات والخدمات وبروتوكولات الشبكة وغير ذلك، وتتيح Nagios الاحتفاظ بسجلات مراقبة وتدقيق مثل الانقطاعات المفاجئة والإخفاق في إعادة العمل مجددًا.
8- Splunk
ترتيبها الثامن في أفضلية أدوات DevOps. تجعل Splunk معطيات المخدم الحاسوبي وسجلاته في متناول الجميع، ويمكن استعمالها من أي فرد في فريق عمل التطوير البرمجي والعمليات. ومع أن معطيات المخدم الحاسوبي تحتوي على الكثير من المعلومات التي يمكنها تحسين الإنتاجية والكفاءة، فمن الصعب تحليلها وتصورها بدون أداة مثل Splunk. يمكن للمطورين إنشاء تطبيقات Splunk المخصصة ودمج معطيات Splunk في تطبيقات أخرى.
9- Bamboo
تحتل الأداة Bamboo المرتبة التاسعة في شعبية أدوات DevOps. وهي مشابهة لأداة Jenkins، ولكنها ليست مجانية. يمكنك الحصول على وظائف وتوابع كثيرة تم إنشاؤها سلفًا كمكونات جاهزة للاستعمال، مما يعني أن هناك عددًا أقل بكثير من المكونات الإضافية التي يمكن أن يحتاج إليها المطورون عادة. تحتوي Bamboo أيضًا على واجهة سهلة الاستعمال مع ميزات أخرى مثل الإكمال التلقائي. وبوجه عام، يمكنها اختصار الوقت عند مقارنتها بأدوات مشابهة لها مفتوحة المصدر، لاسيما إذا كنت تريد تحقيق برمجيات وأتمتة ذات مستوى عالٍ في وقت قصير.
المراجع
1- https://analyticsindiamag.com/devops-tools-frameworks-everything-you-need-to-know
2- https://www.simplilearn.com/tutorials/devops-tutorial/devops-tools
قد ترغب كذلك بقراءة
الخدمات المعلوماتية وإدارتها
تطوير شركات صناعة البرمجيات، أفضل النماذج CMMI
خريطة عمليات الاتصالات المحسنة eTOM
إطار إدارة تقانة المعلومات COBIT
مكتبة البنية التحتية للمعلوماتية ITIL