5 اختلافات أساسية بين DevOps و SRE يجب أن تعرفها
نشرت: 2021-02-22غالبًا ما يدمج عالم تكنولوجيا المعلومات وتطوير البرمجيات DevOps مع SRE ليعني الشيء نفسه. ومع ذلك ، هناك اختلافات شاسعة بين الاثنين. بينما اكتسبت هندسة موثوقية الموقع (SRE) زخمًا في السنوات الأخيرة ، كانت DevOps موجودة لفترة أطول (حتى قبل وجود مصطلح DevOps).
لتوضيح الأمر ببساطة ، تعتبر كل من DevOps و SRE من الممارسات الموضوعة لتقديم البرامج بشكل أسرع. الاختلاف الوحيد بين الاثنين هو في مقاربتهم. تركز DevOps على تقليل دورة حياة تطوير البرامج ، وتركز SRE على القضاء على نقاط ضعف النظام لتحقيق نفس الغرض.
في هذه المقالة ، سنلقي نظرة على الطرق الأساسية التي يختلف بها DevOps و SRE عن بعضهما البعض. قبل أن نفعل ذلك ، لنبدأ بفهم ماهية DevOps و SRE.
جدول المحتويات
ما هو DevOps؟
على حد تعبير جين كيم ، مؤلف كتاب DevOps Handbook و The Phoenix Project ،
"DevOps هو [] مجموعة من المعايير الثقافية والممارسات التقنية التي [تتيح] التدفق السريع للعمل المخطط له ، من بين أمور أخرى ، من التطوير ، من خلال الاختبارات إلى العمليات مع الحفاظ على الموثوقية والتشغيل والأمن على مستوى عالمي. لا تتعلق DevOps بما تفعله ، ولكن ما هي نتائجك ".
لذلك ، تركز DevOps بشكل أساسي على تحويل الممارسات الثقافية داخل المؤسسة لتسريع دورة حياة تطوير البرامج (SDLC). لا يستهدف شخصًا أو مجموعة أو منصبًا. تهدف DevOps إلى تعزيز التعاون بين كل من عمليات تقنية المعلومات وفرق تطوير البرامج.
ما يفعله وكيف يفعل ذلك ليس مهمًا ؛ يتم الاعتراف فقط بنتيجة العملية.
تستخدم DevOps مجموعة من المبادئ لتكثيف تعرض فرق هندسة البرمجيات لأنظمة الإنتاج وتمكين فريق عمليات تكنولوجيا المعلومات من تصعيد التناقضات إلى فريق التطوير بشكل أكثر كفاءة. في الواقع ، تلعب SRE دورًا مهمًا في مؤسسة DevOps من خلال تسهيل الاختبار الاستباقي والسرعة والسماح بإمكانية المراقبة وتحسين موثوقية الخدمة. تشجع DevOps كل مؤسسة تتمحور حول DevOps للعمل وفقًا للمبادئ الثقافية الموضحة في نموذج CALMS الخاص بها.
ما هو SRE؟
SRE ، اختصار لهندسة موثوقية الموقع ، هو مصطلح صاغه نائب الرئيس الأول لشركة Google Ben Treynor المسؤول عن الإشراف على العمليات الفنية.
يوضح درو فارنسورث (من Green Lane Design) ، "أحب عمومًا التفكير في SRE كنظام تتحكم فيه عمليات التطوير. هذا نظام يتم فيه تقسيم البيئة إلى المكونات الأساسية لمكدس تكنولوجيا المعلومات ويتم طرحه مع أفضل الممارسات المخبوزة في الأجهزة ".
بشكل أساسي ، يتم تكليف فريق SREs ذو الخبرة في تطوير البرامج بمسؤولية حل المشكلات في إنتاج النظام مع الحفاظ على التوازن بين سرعة التسليم وموثوقية النظام. بهذه الطريقة ، يجمع نهج SRE بين موظفي تطوير البرمجيات تحت أدوار العمليات لتطبيق ممارسات الهندسة المهيكلة لدعم سياسات المنظمة.
إنها تضمن أن الأنظمة متوفرة وتعمل بكفاءة في جميع الأوقات لفرق البرمجيات لتطوير الخدمات الفنية لتعزيز موثوقية النظام. إنها مسؤولية SREs لتحديد أي ضعف محتمل قبل أن تتحول إلى مشكلة كبيرة.
DevOps vs SRE: أهم الاختلافات بين DevOps و SRE
من الناحية العملية ، يجب النظر إلى DevOps و SRE على أنهما تخصصات تكميلية حيث تركز SREs كجزء من بنية تتمحور حول DevOps على تحسين موثوقية خدماتها الفنية. لذلك ، لا يوجد شيء مثل DevOps مقابل SRE.
لذلك ، ما نقوم به في هذا القسم هو تقييم الاختلافات الأساسية بين DevOps و SRE.
تنفيذ التغيير
من أجل أن تحدث التحديثات بشكل متكرر ويتمتع المستخدمون بإمكانية الوصول إلى تقنية أحدث وأكثر صلة ، يعتزم كل من DevOps و SRE الإسراع بسرعة. ومع ذلك ، تتحرك DevOps للأمام تدريجيًا ، بحذر ، بينما تأخذ SRE في الاعتبار تكلفة الفشل في التحرك بشكل أسرع.
كل من تنفيذ الأتمتة واستخدام الأدوات لتحقيق هذا الغرض.
فيما يتعلق بالفشل على أنه أمر طبيعي
تعتبر DevOps شركة ضخمة في قبول الإخفاقات واعتبارها اضطهادًا للتعلم. لهذا السبب ، فإنه يشجع ثقافة خالية من اللوم من خلال قبول أن الإخفاقات جزء من العملية ولا تركز على جعل الأنظمة متسامحة بنسبة 100٪. مثال على ذلك Netflix بجيشه Simian.
من ناحية أخرى ، تدعم SRE تشريح الجثة بلا لوم. والغرض من ذلك هو تحديد سبب الفشل وتحديد المساءلة والعمل على تجنب حالات الفشل المماثلة في المستقبل. يتم تضمين عدد حالات الفشل التي يمكن أن يمر بها النظام في ميزانية الخطأ. تحدد مقاييس SLI و SLO و SLA هذا لخفض تكلفة الإنتاج. بشكل أساسي ، تتبنى SRE ممارسات المراقبة والتنبيه الاستباقية لتجنب أي فشل محتمل.
تعلم دورات تطوير البرمجيات عبر الإنترنت من أفضل الجامعات في العالم. اربح برامج PG التنفيذية أو برامج الشهادات المتقدمة أو برامج الماجستير لتتبع حياتك المهنية بشكل سريع.
الأتمتة مقابل الابتكار
تضع DevOps أهمية قصوى على الأتمتة. في بيئة تركز على DevOps ، يُترجم هذا إلى أتمتة الأنظمة قدر الإمكان ، مما يؤدي إلى إصدارات مملة. بعد أن يلتزم المطور بالشفرة ، يجب أتمتة معظم الأنشطة التالية ، إن لم يكن كلها.
لذلك ، فإن سبب DevOps لمتابعة CI / CD هو تطوير أنظمة عالية الجودة بسرعة أعلى.
أسباب SRE لمتابعة CI / CD مختلفة ، فهي تهدف إلى تقليل تكلفة الفشل. تعتبر أي مهام شائعة أو عامة أو متكررة في عمليات مثل النشر والنسخ الاحتياطي أقل جدارة بالاهتمام. لذلك ، خصصت SREs قدرًا محددًا من الوقت لتجنب الكد التشغيلي. يتم ذلك حتى يتمكنوا من متابعة مهام أكثر جاذبية مثل تنفيذ أو ابتكار تقنيات جديدة أو أنشطة متعلقة بالعمارة.
الخروج: مشاريع DevOps للمبتدئين
تحطيم الصوامع التنظيمية
يدخل المطورون والمشغلون في صراع عندما يتعلق الأمر بعملية النشر. بينما سيستفيد المطورون من الميزات التي يتم نشرها بمجرد أن يتم ترميزها ، يركز العاملون في العملية على إتاحة الأنظمة التي تعيق عملية النشر.
يختلف كل من DevOps و SRE في كيفية إزالة الصوامع في المؤسسة.
تتعامل DevOps ، كما هو موضح في دليل DevOps ، مع هذه المشكلة من خلال تضمين ممارسات مثل التشغيل في دفعات أصغر وإدارة التكوينات بشكل أفضل.
لا تهدف SREs إلى تحسين التدفق بين الفرق فحسب ، بل تهدف أيضًا إلى مساعدة الأنظمة في الإنتاج. يفعلون ذلك من خلال الاندماج في الفرق كمستشارين ودعم المطورين من خلال تقاسم مسؤولية أنظمة التشغيل. هذه هي الطريقة التي تقسم بها SREs الصوامع في المنظمة.
قياس التنفيذ الناجح
تدور جميع مقاييس DevOps حول سرعة العمليات ؛ يتضمن ذلك عدد مرات حدوث عمليات النشر ، والوقت المستغرق للقيام بذلك ، ومدى تكرار حدوث مشكلات فيها.
وفقًا لتقرير عام 2017 الصادر عن Puppet و DORA ، يعتمد قياس التنفيذ الناجح في DevOps على ما يلي:
- معدل تكرار حدوث عمليات النشر
- المدة الزمنية بين التزام التعليمات البرمجية ونشرها
- معدل تكرار فشل عمليات النشر
- الوقت المستغرق للتعافي من فشل النشر
يتم وضع حلقات التعليقات هذه لمساعدة DevOps على تحسين جودة النظام مع تسهيل التغيير في التجربة.
من ناحية أخرى ، تعمل SRE على تحسين الأنظمة مع مراعاة موثوقيتها. يأخذ في الاعتبار المقاييس الرئيسية التالية لتحديد التنفيذ الناجح:
- هدف مستوى الخدمة (SLO)
- مؤشر مستوى الخدمة (SLI)
- اتفاقية مستوى الخدمة (SLA)
المقاييس المذكورة أعلاه هي مؤشرات على موثوقية النظام. تحدد هذه المقاييس مسبقًا ما إذا كان إصدار للتغيير سيصل إلى الإنتاج أم لا.
في SRE ، تكون مقاييس السرعة والجودة هذه مفيدة عند إنشاء ميزانية خطأ وتحسين موثوقية الأنظمة بدلاً من العمل على ميزات جديدة.
قراءة: راتب مهندس DevOps في الهند
خاتمة
نشرت Google كتابًا إلكترونيًا حول كيفية تنفيذ هندسة موثوقية الموقع في أنظمة الإنتاج الخاصة بهم حيث أوضح ترينور SRE على أنها ،
"SRE هو ما يحدث عندما تطلب من مهندس برمجيات تصميم فريق عمليات."
عندما يتعلق الأمر بمدى اختلاف DevOps و SRE ، كل ما تحتاج إلى تذكره هو أن SRE يقودها المطورون وليس فريق التشغيل. تخضع كل من الصيانة والمراقبة إلى حد كبير لسيطرة المطورين. هذا هو ما يميز في المقام الأول النظامين عن بعضهما البعض.
إذا كنت مهتمًا بمعرفة المزيد حول DevOps الكبيرة ، وتطوير المكدس الكامل ، فراجع برنامج upGrad & IIIT-B التنفيذي PG في تطوير البرمجيات - التخصص في تطوير المكدس الكامل المصمم للمهنيين العاملين ويقدم أكثر من 500 ساعة من التدريب الصارم ، أكثر من 9 مشاريع ومهام ، وحالة خريجي IIIT-B ، ومشاريع تتويجا عملية ومساعدة وظيفية مع كبرى الشركات.
