DevOps مقابل SRE: الفروق الجوهرية والتداخل ومتى تستخدم كلاً منهما

الإجابة السريعة: يهدف كلٌّ من DevOps وSRE (هندسة موثوقية الموقع) إلى تسليم البرمجيات بسرعة وموثوقية، لكنهما يعملان على مستويين مختلفين. فـ DevOps ثقافة ومجموعة ممارسات واسعة تهدم الجدار بين التطوير والعمليات لتسريع التسليم. أما SRE، الذي نشأ في Google، فتخصّص هندسي محدّد يطبّق تلك الأهداف باستخدام أدوات ملموسة وقابلة للقياس: مؤشرات مستوى الخدمة (SLIs)، وأهداف مستوى الخدمة (SLOs)، وميزانيات الخطأ. وخلاصة مفيدة هي أن SRE طريقة واحدة معرّفة جيداً لممارسة DevOps، تُقاس فيها الموثوقية بصرامة قياس أي ناتج هندسي آخر.

ما هو DevOps؟

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

ما هو SRE؟

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

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

مؤشرات وأهداف مستوى الخدمة وميزانيات الخطأ: جوهر SRE

المفاهيم التي تميّز SRE أكثر من غيرها عن DevOps العام هي مقاييس الموثوقية لديه. فهي تحوّل سؤال “ما مقدار الجودة الكافية؟” إلى رقم يستطيع الجميع التصرّف بناءً عليه.

• مؤشر مستوى الخدمة (SLI): نسبة مرصودة للأحداث الجيدة إلى إجمالي الأحداث، مثل حصة الطلبات التي تُرجَع بنجاح ضمن زمن استجابة مستهدف.
• هدف مستوى الخدمة (SLO): الهدف المنشود لمؤشر مستوى خدمة خلال نافذة زمنية، مثل نجاح 99.9% من الطلبات خلال 30 يوماً. ويحدّد هدف مستوى الخدمة العتبة المقبولة.
• ميزانية الخطأ: المقدار المسموح به من اللاموثوقية، ويُحسب بطرح هدف مستوى الخدمة من 100%. فهدف مستوى خدمة 99.9% يعطي ميزانية خطأ 0.1%، وهي عبر ملايين الطلبات مقدار ملموس وقابل للعدّ من حالات الفشل.

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

من النقاط الدقيقة لكن المهمة أن ميزانيات الخطأ تثني عن السعي وراء الموثوقية المثالية. فرفع خدمة من توافر 99.9% إلى 99.99% مكلف للغاية وغالباً غير مرئي للمستخدمين، لذا يسأل SRE عمداً “ما مدى الموثوقية اللازمة لهذا؟” بدلاً من “ما أقصى موثوقية نستطيع تحقيقها؟” ووضع هدف مستوى الخدمة أدنى قليلاً من الكمال يترك متّسعاً لشحن الميزات والمخاطرة المعقولة. وتلك العقلية، أي التعامل مع بعض الفشل بوصفه مقبولاً ووضع ميزانية له، من أكثر إسهامات SRE مخالفةً للبديهة وأشدّها قيمة.

DevOps مقابل SRE: مقارنة مباشرة

أين يتداخل DevOps وSRE؟

التداخل كبير ومتزايد. فكلاهما يعتمد على الأسس التقنية ذاتها: التحكّم في الإصدارات، الذي يمكنك التعرّف عليه في دليلنا حول ما هو Git؛ والبنية التحتية بوصفها شيفرة، المشروحة في مقالنا حول ما هو Terraform؛ وخطوط أنابيب CI/CD؛ والحاويات والتنسيق؛ والمراقبة القوية. وكلاهما يقدّم الأتمتة على العمل اليدوي الممل، وكلاهما يعامل حالات الفشل بوصفها فرص تعلّم عبر تحليلات ما بعد الحوادث الخالية من إلقاء اللوم، وكلاهما يتقاسم المسؤولية عبر التطوير والعمليات. ويجسّد فريق SRE مبادئ DevOps دائماً تقريباً؛ والفرق أن SRE يضيف فوقها نموذجاً صارماً ومُقدَّراً كمّياً للموثوقية.

متى يناسب كل نهج أكثر؟

يعتمد الاختيار الصحيح على حجم مؤسستك ونضجها واحتياجاتها.

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

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

ما الممارسات التي يتقاسمها الاثنان بعيداً عن الفروق؟

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

مثال ملموس على عمل الاثنين معاً

تخيّل فريقاً يشغّل خدمة مدفوعات. تمنح ثقافته في DevOps المطوّرين خطّ أنابيب CI/CD سلساً كي يستطيعوا شحن تغييرات صغيرة مرات عديدة في اليوم بثقة. وتعرّف ممارسته في SRE هدف مستوى خدمة بنسبة 99.95% من المعاملات الناجحة وتتعقّب ميزانية الخطأ إزاءه. وفي معظم الشهر تكون الميزانية صحية، فيشحن الفريق الميزات بحرية. ثم يستنزف إصدارٌ سيئٌ جزءاً كبيراً من الميزانية في ظهيرة واحدة. فتفعَّل قاعدة ميزانية الخطأ: يتوقّف عمل الميزات الجديدة، ويتحوّل اهتمام الفريق إلى تحصين الخدمة إلى أن تتعافى الموثوقية. هنا يتيح DevOps السرعة ويوفّر SRE السياج الواقي، ولن ينتج أيٌّ منهما وحده هذه النتيجة المتوازنة.

DevOps مقابل SRE كاختيار مهني

من منظور مهني، تتداخل مجموعتا المهارات بما يكفي ليعزّز بناء إحداهما الأخرى. فإن كنت مبتدئاً، فتعلّم الأساسيات المشتركة أولاً: التحكّم في الإصدارات، وCI/CD، والبنية التحتية بوصفها شيفرة، والمنصات السحابية، وبرمجة الأتمتة النصية. ومن هناك، يركّز المسار المائل إلى DevOps على خطوط الأنابيب والتسليم وأدوات المنصات، بينما يضيف المسار المائل إلى SRE قابلية مراقبة عميقة، وهندسة أداء، ونموذج القرار القائم على أهداف مستوى الخدمة. وكلا اللقبين مطلوب ومجزيٌّ جيداً، مع أجر يحدّده أكثرَ الخبرةُ وصاحبُ العمل والموقع لا المسمّى نفسه؛ ويمكن أن تميل أدوار SRE المتمركزة في شركات التقنية الكبرى إلى الأعلى في المستويات الكبيرة، لكن النطاقات تتداخل بشكل كبير، لذا تعامل مع أي رقم محدّد على أنه تقريبي. وينتقل كثير من المهندسين بسلاسة بين الاثنين خلال مسيرتهم، وتتغذّى مهارات بنية السحابة، المفصّلة في دليلنا حول كيف تصبح مهندس بنية سحابية، في كليهما بشكل طبيعي.

الخلاصة

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