DevOps

menu icon

DevOps

تعمل DevOps على سرعة تسليم البرامج بجودة أعلى من خلال دمج ما يقوم به فريق تطوير البرامج وفريق عمليات تكنولوجيا المعلومات من أعمال وتشغيل تلك الأعمال آليا.

ما هي DevOps؟

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

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

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

تهدف DevOps في النهاية إلى تلبية الطلب المتزايد بصفة دائمة لدى مستخدمي البرامج للحصول على الخصائص الجديدة والمتكررة والمبتكرة وتحقيق الأداء والإتاحة دون انقطاع.

كيف وصلنا إلى DevOps

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

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

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

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

لذلك فإن DevOps انبثقت من منهجية Agile. فقد أضافت عمليات وأدوات جديدة تتوسع في استخدام التكرار المستمر والتشغيل الآلي في منهجية التكامل المستمر/النشر المستمر ليشمل باقي دورة حياة تسليم البرامج. وقد أسست للتعاون الوثيق بين التطوير والعمليات في كل خطوة من خطوات العملية.

كيف يعمل DevOps: دورة حياة DevOps

رسم بياني يعرض مسار دورة حياة DevOps

الشكل ‏1‏:‏ دورة حياة DevOps

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

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

هناك ثلاث مسارات عمل مستمرة هامة أخرى تقع فيما بين مسارات العمل هذه:

الاختبار المستمر: تتضمن دورات حياة DevOps التقليدية مرحلة "اختبار" منفصلة تحدث بين التكامل والنشر. ومع ذلك، فقد تقدمت DevOps بحيث قد تحدث بعض عناصر الاختبار في مراحل التخطيط (التطوير الموجه بالسلوك)، والتطوير (اختبار الوحدات، اختبار العقود)، والتكامل (عمليات مسح الأكواد الثابتة، عمليات مسح CVE، واختبارات كشف الأخطاء البرمجية)، والنشر (اختبار الوظائف الأساسية، اختبار الاختراق، اختبار التوصيف)، والعمليات (اختبار إحداث الفوضى، اختبار الامتثال)، والتعلم (اختبار A/B). يشكل الاختبار شكلا قويا من أشكال تحديد المخاطر وأوجه الضعف، ويتيح الفرصة لتكنولوجيا المعلومات لقبول المخاطر أو التخفيف من حدتها أو معالجتها.

الأمان: بينما تحقق منهجيات الشلال وتجهيزات Agile السريعة 'إضافة' مسارات عمل للأمان بعد التسليم أو النشر، تبذل DevOps قصارى جهدها لتضمين الأمان من البداية (التخطيط) - عندما تكون معالجة مشاكل الأمان أسهل وأقل تكلفة - وباستمرار طوال الفترة المتبقية من دورة التطوير. يُشار إلى هذا المنهج نحو تحقيق الأمان على أنه الاختبار المبكر (يسهُل فهمه إذا نظرت إلى الشكل 1). حققت بعض المؤسسات نجاحا أقل من غيرها في الاختبار المبكر، مما أدى إلى ظهور DevSecOps (أنظر أدناه).

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

ثقافة DevOps

من المتعارف عليه عموما أن طرق DevOps لا يمكن أن تعمل دون الالتزام بثقافة DevOps، والتي يمكن تلخيصها كمنهج تنظيمي وفني مختلف نحو تطوير البرامج.

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

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

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

أدوات DevOps: بناء سلسلة أدوات DevOps

أضافت متطلبات DevOps وثقافة DevOps قيمة على الأدوات التي تدعم المشاركة غير المتزامنة، والتي تحقق التكامل السلس لمسارات عمل DevOps، والتي تقوم بالتشغيل الآلي لدورة حياة DevOps بأكملها قدر الإمكان. تتضمن تصنيفات أدوات DevOps:

  • أدوات إدارة المشروع - الأدوات التي تُمكن فرق العمل من بناء سجل متراكم من قصص المستخدم (المتطلبات) التي تشكل مشروعات التكويد، وتقسيمها إلى مهام أصغر، وتتبع المهام حتى يتم الانتهاء منها. تلقى ممارسات Agile لإدارة المشروعات دعم العديد من أطر العمل والطرق مثل طريقة Scrum وLean وKanban، التي يجلبها المطورون إلى DevOps. وتتضمن اختيارات المصدر المفتوح المشهورة GitHub وIssues وJira.
  • مستودعات مشاركة كود المصدر - بيئات التكويد التي تتحكم فيها النسخة والتي تسمح للعديد من مطوري البرامج بالعمل على نفس الأكواد الأساسية. يجب أن يتم التكامل بين مستودعات تخزين الأكواد وبين أدوات CI/CD والاختبار والأمان، بحيث يمكن الانتقال آليا إلى الخطوة التالية عندما يتم التعهد بالأكواد إلى مستودع التخزين. تتضمن مستودعات تخزين كود المصدر المفتوحة GiHub وGitLab.
  • مسارات CI/CD - أدوات التشغيل الآلي لعمليات إنهاء تخصيص الأكواد والبناء والاختبار والنشر. يُعد Jenkins من أشهر الأدوات مفتوحة المصدر في هذا التصنيف؛ هناك العديد من البدائل مفتوحة المصدر سابقا، مثل CircleCI، متاحة الآن في النسخ التجارية فقط. عندما يتعلق الأمر بأدوات النشر المستمر (CD)، يمتد Spinnaker بين التطبيق والبنية الأساسية كطبقات من الأكواد. كما يعتبر ArgoCD اختيارا أخر للمصدر المفتوح لمنهجيات CI/CD الأصلية في Kubernetes.
  • أطر عمل التشغيل الآلي للاختبار - تتضمن أدوات البرامج والمكتبات وأفضل الممارسات للتشغيل الآلي لاختبار الوحدة واختبار العقد والاختبارات التشغيلية واختبارات الأداء وقابلية الاستخدام واختبارات الاختراق واختبارات الأمان. تدعم أفضل هذه الأدوات لغات متعددة؛ بعضها يستخدم الذكاء الاصطناعي (AI) لإعادة توصيف الاختبارات آليا كاستجابة للتغييرات في الأكواد. اتسعت أدوات وأطر عمل الاختبار بشكل كبير ومتنوع! تشمل أطر العمل مفتوحة المصدر التي ذاعت شهرتها للتشغيل الآلي للاختبار Selenium وAppium وKatalon وRobot Framework وSerenity (المعروف سابقا باسم Thucydides).
  • أدوات إدارة التوصيف (البنية الأساسية ككود) - تتيح هذه الأدوات لمهندسي DevOps توصيف وإعداد البنية الأساسية ذات النسخ الكاملة والموثقة بالكامل عن طريق تنفيذ برنامج نصي. تتضمن اختيارات المصدر المفتوح Ansible (Red Hat) وChef وPuppet وTerraform. يقوم Kubernetes بنفس الوظيفة لتطبيقات الحاويات (ارجع إلى 'DevOps وعمليات التطوير الأصلية في البيئة السحابية'، أدناه).
  • أدوات المراقبة - تساعد هذه الأدوات فرق DevOps على تحديد مشاكل النظام وحلها؛ كما أنها تقوم بجمع وتحليل البيانات في الوقت الفعلي للكشف عن كيفية تأثير تغييرات الأكواد على أداء التطبيق. تتضمن أدوات مراقبة المصدر المفتوح Datadog وNagios وPrometheus وSplunk.
  • أدوات التعليقات التقييمية المرجعية المستمرة - هي الأدوات التي تقوم بجمع المعلومات المرجعية والتعليقات التقييمية من المستخدمين، إما من خلال خرائط التمثيل الحراري (تسجيل تصرفات المستخدمين على الشاشة) أو الاستطلاعات أو بطاقات الخدمة الذاتية للمشاكل.

DevOps وعمليات التطوير الأصلية في البيئة السحابية

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

تتسم التطبيقات السحابية الأصلية اليوم وبشكل نموذجي بأنها

  • يتم بناؤها باستخدام الخدمات المصغرة - مكونات متباعدة قابلة للنشر بشكل مستقل لها حزمة متضمنة ذاتيا خاصة بها، وتقوم بالاتصال ببعضها البعض بواسطة REST APIs أو تدفق مرسلات الأحداث أو البرامج الوسيطة للرسائل.
  • يتم نشرها في الحاويات - وحدات من الأكواد التي يمكن تنفيذها والتي تحتوي على كل ارتباطات الأكواد والتشغيل ونظام التشغيل اللازمة لتشغيل التطبيق. (بالنسبة لمعظم المؤسسات، فإن مصطلح 'الحاوية' يعني حاويات Docker، ولكن تتوافر أنواع أخرى من الحاويات.)
  • يتم تشغيلها (على نطاق واسع) باستخدام Kubernetes، وهو منصة مفتوحة المصدر لتنسيق الحاويات من أجل جدولة عمليات النشر والإدارة والتطوير وتشغيل هذه العمليات آليا لتطبيقات الحاويات.

في نواح عدة، تكون عمليات التطوير الأصلية بالبيئة السحابية مناسبة جدا لممارسات DevOps.

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

(المصدر: 'Microservices in the enterprise 2021: Real benefits, worth the challenges'.)

عن طريق تجميع كل ارتباطات نظام التشغيل وتثبيتها بصفة دائمة، تُحقق الحاويات إتاحة دورات سريعة من CI/CD والنشر، لأن كل عمليات التكامل والاختبار والنشر تحدث في نفس بيئة التشغيل. كما يقوم تنسيق Kubernetes بنفس مهام التوصيف المستمرة لتطبيقات الحاويات كما يفعل كل من Ansible وPuppet وChef للتطبيقات التي لا يتم تضمينها بالحاويات.

معظم الكيانات الرائدة من مقدمي خدمات الحوسبة السحابية - بما في ذلك من AWS وGoogle وMicrosoft Azure وIBM Cloud - تقوم بتقديم نوعا من حلول مسارات DevOps المُدارة.

ما هو DevSecOps؟

DevSecOps هو عبارة عن DevOps يقوم بدمج الأمان وتشغيله آليا بشكل دائم طوال دورة حياة DevOps - من البداية إلى النهاية، من التخطيط إلى المعلومات التقييمية المرجعية والعودة إلى التخطيط مرة أخرى.

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

ظهر DevSecOps كجهد محدد لتكامل الأمان وتشغيله آليا كما كان مقررا في الأصل. في DevSecOps، يعتبر الأمان هو مواطن "من الدرجة الأولى" وصاحب مصلحة جنبا إلى جنب مع التطوير والعمليات، ويجلب الأمان في عملية التطوير مع التركيز على المنتج.

شاهد الفيديو عن ما هو DevSecOps لمعرفة المزيد عن مبادئ DevSecOps ومزاياه وحالات استخدامه:

DevOps وهندسة موثوقية الموقع (SRE)

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

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

يحقق مهندسو موثوقية الموقع هذا التوازن عن طريق تحديد مستوى مقبول من المخاطر التشغيلية الناتجة عن التطبيقات - يسمى 'ميزانية الخطأ' - وعن طريق التشغيل الآلي للعمليات من أجل تحقيق هذا المستوى.

في فريق DevOps متعدد الوظائف، يمكن أن يعمل SRE كجسر بين التطوير والعمليات، مما يوفر المقاييس والتشغيل الآلي التي يحتاج إليها الفريق من أجل دفع تغييرات الأكواد والخصائص الجديدة من خلال مسار مهام DevOps في أسرع وقت ممكن، دون 'مخالفة' شروط اتفاقيات مستوى الخدمة الخاصة بالمؤسسة.

معرفة المزيد عن هندسة موثوقية الموقع

DevOps وIBM Cloud

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

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

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

اتخذ الخطوة التالية:

البدء باستخدام حساب IBM Cloud اليوم.

يستخدم IBM Cloud Pak for Watson AIOps التعلم الآلي وفهم اللغة الطبيعية لربط البيانات الهيكلية وغير الهيكلية عبر سلسلة أدوات العمليات الخاصة بك في الوقت الفعلي للكشف عن الرؤى الخفية والمساعدة في تحديد الأسباب الجذرية بشكل أسرع. لإلغاء الحاجة إلى العديد من لوحات المعلومات، يقوم Watson AIOps بتوفير الرؤى والتوصيات مباشرة في مسارات عمل فريقك لتسريع حل الحوادث.

نبذة عن المؤلف

أندريا سي. كراوفورد هي مهندسة متميزة في IBM لديها خبرة في DevOps التقليدية والحديثة. لديها شغف لمساعدة العملاء في تحويل تسليم التطبيقات من خلال تطوير الأشخاص والعمليات والأدوات. تستمتع أندريا باستكشاف الأنشطة "الخارجية" التكتيكية مثل أعمال الحدائق وركوب الدراجات النارية.

https://twitter.com/acmthinks (يوجد الرابط خارج موقع IBM)

https://medium.com/@acmThinks (يوجد الرابط خارج موقع IBM)