ما هو SRE؟

ما هو SRE؟

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

بن ترينور سلوس، مدير هندسي في Google آنذاك، استلم فريقاً صغيراً من مهندسي البرمجيات وطُلب منه إدارة الإنتاج. حله لم يكن توظيف مزيد من مديري النظم التقليديين — بل كان التعامل مع مشكلة العمليات بالطريقة ذاتها التي يتعامل بها المهندسون مع أي مشكلة صعبة أخرى: بالبرمجيات، والقياس، والأتمتة، وحلقات التغذية الراجعة. وهكذا وُلد Site Reliability Engineering.

نموذج Google SRE: المبادئ الأساسية

نموذج Google، المُقنَّن في كتاب Site Reliability Engineering عام 2016، يرتكز على عدد صغير من الأفكار القوية التي تُعيد صياغة تفكيرك في الموثوقية بشكل جذري:

1. توظيف مهندسي برمجيات لأداء العمليات

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

في Google، معيار التوظيف لـ SREs هو تقريباً 85% من معيار هندسة البرمجيات، مع تركيز إضافي على معرفة الأنظمة: دواخل أنظمة التشغيل، والشبكات، والأنظمة الموزعة، والقدرة على التفكير في أوضاع فشل معقدة على نطاق واسع. عملياً في شركات التقنية الكبرى اليوم، تتطلب أدوار SRE قدرة قوية في البرمجة بلغة أنظمة واحدة على الأقل (Go، Python، Java)، وإتقان عميق لـ Linux، وخبرة عملية في الأنظمة الموزعة — المهارات التي بنيتها عبر هذه الدورة.

2. الموثوقية تُقاس، لا تُفترض

أحد أهم مساهمات نموذج SRE هو إدخال أهداف مستوى الخدمة (SLOs) بوصفها العملة الأساسية في محادثات الموثوقية. بدلاً من الالتزامات الغامضة مثل "يجب أن يكون النظام متاحاً بشكل عالٍ"، يطالب SRE بالدقة: "99.9% من طلبات الصفحة الرئيسية ستُعيد استجابة ناجحة خلال 300ms، مقاساً على نافذة متحركة مدتها 28 يوماً."

هذا الرقم مشتق من مؤشر مستوى الخدمة (SLI) — القياس الفعلي — ويعيش ضمن اتفاقية مستوى الخدمة (SLA) التي تحدد العواقب التعاقدية إذا فشلت في تحقيقه. يقع SLO بين SLI وSLA: هو هدفك الداخلي، يُضبط بشكل محافظ بما يكفي لأن يكون لديك هامش قبل خرق SLA.

لماذا تهم الدقة؟ لأنها تحول الموثوقية من حجة نوعية إلى حجة كمية. حين يريد مدير المنتج شحن ميزة محفوفة بالمخاطر ولدى SRE مخاوف، تتحول المحادثة من "أعتقد أن هذا قد يكسر أشياء" إلى "استهلكنا 60% من ميزانية الأخطاء الشهرية في أسبوعين — شحن هذا يرفع احتمال الخرق إلى 85%." إحدى هاتين المحادثتين قابلة للتنفيذ. الأخرى ليست كذلك.

3. ميزانيات الأخطاء: الموثوقية كمورد مشترك

ميزانية الأخطاء هي أكثر اختراعات نموذج SRE أناقةً. إذا كان SLO الخاص بك 99.9% توفر، فإن ميزانية الأخطاء هي عكسه: 0.1% من الطلبات يمكن أن تفشل لكل نافذة قياس دون خرق SLO. على نافذة 28 يوماً، هذا يعادل تقريباً 43 دقيقة من التوقف، أو حوالي 4.3 مليار خطأ لكل مليار طلب.

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

SRE مقابل DevOps: متعلقان لكن مختلفان

العلاقة بين SRE وDevOps من أكثر الأمور التي يُساء فهمها في الصناعة. إنهما ليسا فلسفتين متنافستين — بل متكاملتان، وفهم الفرق بينهما مهم لكيفية هيكلة الفرق والمسؤوليات.

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

SRE هو تطبيق متحيز لمبادئ DevOps. كما يقول كتاب Google SRE: "SRE هو ما يحدث حين تطلب من مهندس برمجيات تصميم وظيفة العمليات." يوفر SRE آليات محددة: SLOs، ميزانيات الأخطاء، حد التوليد 50%، مراجعات جاهزية الإنتاج، تحليلات لا ومية بجداول زمنية منظمة، ونماذج تعاون محددة بين فرق SRE وفرق المنتج. حيث يقول DevOps "أتمت كل شيء"، يقول SRE "حدد التوليد بـ 50% من وقت الهندسة وتابعه فصلياً."

حد التوليد 50%

من أكثر السياسات ملموسية وتطبيقاً في نموذج Google SRE هو حد التوليد: يجب ألا يقضي SREs أكثر من 50% من وقتهم في التوليد — العمل التشغيلي اليدوي المتكرر القابل للأتمتة. النصف الآخر يجب أن يذهب إلى عمل هندسي يقلل التوليد المستقبلي أو يحسن موثوقية الخدمة.

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

لماذا يهم هذا على نطاق الشركات الكبرى؟ لأن التوليد ذاتي التضاعف. كل خدمة جديدة تُضاف إلى محفظة فريق SRE تجلب توليداً جديداً. إن لم يُؤتمت الفريق باستمرار، ينمو التوليد أسرع من قدرة الفريق على التوظيف، وفي نهاية المطاف يكون كل مهندس 100% توليداً وصفراً هندسةً — عندها يمتلك الفريق فريق عمليات لا فريق SRE، وتتدهور الموثوقية فيما ترتفع التكاليف.

لماذا يعمل هذا النموذج (وأين يفشل)

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

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

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

ما يغطيه بقية هذا الدرس التعليمي

يبني هذا الدرس التعليمي ممارسة SRE الخاصة بك من المبادئ الأولى بشكل منهجي. الدرس التالي يتعمق في SLIs وSLOs — كيف تختار المؤشرات الصحيحة لأنواع مختلفة من الخدمات، وكيف تضع أهدافاً واقعية، والأخطاء الشائعة التي تنتج SLOs لا يثق بها أحد. ثم ميزانيات الأخطاء، وقياس التوليد، وهندسة الإصدار، وتخطيط السعة، ومراجعات جاهزية الإنتاج، وأخيراً — في المشروع الختامي — ستكتب سياسة SLO كاملة وميزانية أخطاء لخدمة إنتاج واقعية. كل درس يرتبط بالنموذج الذي تعلمته للتو: العمليات كمشكلة برمجيات، والموثوقية كمسؤولية مشتركة قابلة للقياس.