مؤشر مستوى الخدمة، هدف مستوى الخدمة، اتفاقية مستوى الخدمة

ثلاثة أحرف تدير بيئة الإنتاج

الموثوقية بدون قياس هي مجرد تمثيلية. تجعل SRE الموثوقية رقمًا متفقًا عليه مسبقًا يمكن للجميع التحقق منه.

مؤشر مستوى الخدمة (SLI): قياس لسلوك الخدمة. أمثلة: زمن استجابة الطلب، معدل الأخطاء، معدل النقل، عمق الصف. مؤشر مستوى الخدمة هو شيء يمكن رسمه بيانيًا.

هدف مستوى الخدمة (SLO): قيمة أو نطاق مستهدف لمؤشر مستوى الخدمة. مثال: "99.9% من طلبات HTTP تنجح خلال نافذة متجددة مدتها 28 يومًا." هدف مستوى الخدمة هو وعد تقطعه لنفسك وللمستخدمين حول جودة الخدمة المقبولة.

اتفاقية مستوى الخدمة (SLA): التزام تعاقدي، عادةً مع عقوبات مالية عند انتهاكه. مثال: "نرد 10% إذا انخفض التوافر الشهري عن 99.9%." اتفاقية مستوى الخدمة هي وعد يفرضه المحامون.

التمييز الحاسم: يجب أن تكون اتفاقية مستوى الخدمة (SLA) دائمًا أوسع من هدف مستوى الخدمة (SLO). إذا كنت تستهدف 99.9% داخليًا وتتعاقد على 99.9% خارجيًا، فليس لديك أي هامش. عادةً ما يشغّل مهندسو الموثوقية (SREs) أهداف مستوى الخدمة بتسعة واحد أضيق من الاتفاقية: هدف 99.95%، واتفاقية 99.9%. يمتص هذا الفارق الأسبوع السيئ الحتمي.

ميزانيات الأخطاء: SLO المعكوس

من أهداف الموثوقية إلى قرارات الهندسة

يحدد SLO هدف الموثوقية. أما ميزانية الأخطاء فهي ما يتبقى: مقدار الفشل الذي يمكنك إنفاقه قبل تجاوز الهدف.

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

تعيد ميزانيات الأخطاء صياغة الصراع بين التطوير والعمليات. بدون ميزانية، يبدأ كل انقطاع جدالًا حول من أطلق التغيير السيئ وكيفية منع التالي. مع وجود ميزانية:

- الميزانية متبقية: أطلق أسرع، خذ مخاطر أكبر، أجرِ تجارب. الميزانية تدفع ثمن ذلك.

- الميزانية مستنفدة: توقف عن إطلاق ميزات جديدة، جمّد التغييرات الخطرة، ركز على أعمال الموثوقية حتى تُعاد بناء الميزانية.

هذا يحول الموثوقية من جدال عاطفي إلى مورد قابل للقياس. يستطيع المهندسون إنفاق الميزانية عمدًا، مثل أي مدخل إنتاجي آخر.

تعريف الجهد اليدوي

ما يُعد جهداً يدوياً

ليس كل مهمة تشغيلية تُعد جهداً يدوياً. يعرّف SRE الجهد اليدوي بدقة: العمل الذي يكون يدوياً، متكرراً، قابلاً للأتمتة، تكتيكياً، خالياً من القيمة المستدامة، ويتوسع خطياً مع نمو الخدمة.

يجب أن تتحقق الخصائص الست جميعها. فترحيل البيانات لمرة واحدة هو عمل يدوي لكنه غير متكرر: لا يُعد جهداً يدوياً. ومهندس أول يصمم بنية خدمة جديدة يتخذ قراراً تكتيكياً لكنه يضيف قيمة مستدامة: لا يُعد جهداً يدوياً.

أمثلة تُعد جهداً يدوياً:

- إعادة تشغيل خدمة يدوياً بعد تعطلها بسبب تسرب في الذاكرة

- لصق أجزاء من السجلات في قناة دردشة أثناء معالجة حادثة

- ملء نموذج تذكرة لطلب توفير قاعدة بيانات جديدة

- تشغيل تقرير سعة ربع سنوي يدويًا

- الموافقة على طلبات النشر الروتينية واحدًا تلو الآخر

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

لا يقتصر الأتمتة على توفير الوقت فقط. بل تزيل فئة كاملة من الأخطاء البشرية. فالسكربت الذي يُعدّ قاعدة بيانات لا ينسى الخطوات بعد نوبة عمل طويلة.

منطق تدقيق الـ Toil

يتتبع فريقك كيفية إنفاق وقته. في الربع الأخير كان التوزيع كالتالي: 30% عمليات النشر، 25% الاستجابة للحوادث، 20% أعمال السعة، 15% هندسة الميزات، 10% طلبات لمرة واحدة من فرق المنتج.

On-Call Hygiene

Engineers, Not Pagers

يحمل المناوبة تكلفة حقيقية. يتعطل النوم، وتتقطع عطلات نهاية الأسبوع، ويزداد الضغط الناتج عن المشكلات غير المتوقعة. تتعامل SRE مع المناوبة كمورد محدود يجب أن يبقى مستدامًا، وليس عبئًا بطوليًا يتحمله من يهتم أكثر.

تتبع دورات المناوبة الصحية عدة مبادئ:

- وقت معوض: تُقابل ساعات المناوبة بإجازة تعويضية أو راتب إضافي أو ميزة مماثلة. المناوبة المجانية تؤدي إلى احتراق الفريق.

- عمق دوران معقول: فريق مكون من ستة أشخاص يدير مناوبة أساسية وثانوية يعني أن كل مهندس يتولى مناوبة واحدة كل ثلاثة أسابيع. دورات الشخصين تدمر المهن.

- ميزانية حجم التنبيهات: يوصي كتاب SRE من Google بحد أقصى حدثين تنبيهيين لكل مناوبة مدتها اثنتا عشرة ساعة. فوق هذا الحد، يجب على الفريق استثمار وقت هندسي لتقليل حجم التنبيهات، وليس مجرد تحمله.

- تنبيهات قابلة للتنفيذ فقط: يجب أن تتطلب كل صفحة إجراءً بشريًا. إذا كان من الممكن تجاهل الصفحة أو أتمتتها أو تكرارها أثناء التشغيل الطبيعي، فلا يجب أن تكون موجودة. إرهاق التنبيهات عيب في الموثوقية.

- تسليمات متابعة الشمس: تُسلّم الفرق الموزعة عالميًا المناوبات عند حدود المناطق الزمنية حتى لا يتلقى أحد تنبيهات في الثالثة صباحًا إلا إذا كان النظام لا يستطيع الانتظار حتى الصباح.

تحليلات ما بعد الحادث بدون إلقاء اللوم

كيف تتحول الأعطال إلى تحسينات

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

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

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

عادةً ما يغطي تحليل ما بعد الحادث:

- الملخص: وصف من فقرة واحدة للحادثة وتأثيرها

- الجدول الزمني: إعادة بناء دقيقة بدقيقة مع الطوابع الزمنية

- تحليل السبب الجذري: العوامل التقنية والعملية التي سمحت بحدوث الفشل

- الاكتشاف: كيف تعلّم الفريق بالحادث، والمدة التي استغرقها ذلك

- الحل: الإجراءات التي اتُخذت لاستعادة الخدمة

- الدروس المستفادة: ما نجح وما لم ينجح

- عناصر الإجراء: مهام هندسية ملموسة، محددة المالك، ومحددة زمنياً

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

الإشارات الذهبية الأربع

ما يجب على كل خدمة قياسه

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

زمن الاستجابة: المدة التي تستغرقها الطلبات. تتبع التوزيعات وليس المتوسطات. يصف p50 (الوسيط) التجربة النموذجية. ويصف p99 أسوأ 1% من المستخدمين. يخفي المتوسط وحده الذيول الطويلة: خدمة بوسيط 50 مللي ثانية وp99 5,000 مللي ثانية تبدو جيدة على المتوسط لكنها تُفسد تجربة مستخدم واحد من كل مائة.

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

الأخطاء: معدل الطلبات الفاشلة. تشمل الأخطاء الصريحة (HTTP 500)، والأخطاء الضمنية (HTTP 200 مع بيانات تالفة)، وأخطاء السياسة (الاستجابة بطيئة جدًا بحيث لا تفي بـ SLO). التمييز بين هذه الأنواع مهم: غالبًا ما يؤذي رمز 200 مع حمولة سيئة المستخدمين أكثر من رمز 500 صريح.

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

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

مسارات مهنة SRE

أين تُدفع مهارات SRE

تتفرع مسارات مهنة SRE بناءً على الجانب الذي يستمتع به المهندس أكثر من التخصص:

مهندس موثوقية المواقع - البنية التحتية: يبني المنصات التي تعمل عليها الفرق الأخرى. Kubernetes، شبكات الخدمات، السحابة الداخلية. هندسة أنظمة ثقيلة، نظرية الأنظمة الموزعة، وتصميم المنصات. يدفع رواتب عالية جداً في الشركات الكبيرة لأن العمل يتوسع: يدعم مهندس موثوقية مواقع البنية التحتية الواحد مئات مهندسي المنتجات.

مهندس موثوقية المواقع - المدمج: يعمل مع فريق هندسة المنتج لتحسين موثوقية خدمة معينة. نصف مهندس، نصف مدرب. مهارات التواصل القوية ومراجعة الكود مهمة بقدر العمق التقني. غالباً ما يكون أفضل مسار للمهندسين الذين يحبون التدريس.

أدوات الموثوقية: يبني حزمة المراقبة: المراقبة، التنبيهات، لوحات المعلومات، أدوات ما بعد الحوادث، منصات إدارة الحوادث. عمل ثقيل في الواجهة الأمامية وهندسة البيانات. يستخدم كل فريق آخر المخرجات.

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

الشهادات التقنية المفيدة: شهادة Google Cloud Professional Cloud Architect، وشهادة AWS Solutions Architect Professional، وشهادات CNCF (Kubernetes Administrator، Kubernetes Application Developer) تدل على إتقان التقنيات السحابية الأصلية. أما شهادات Linux Foundation فتشير إلى عمق في الأنظمة. لا تغني أي من هذه الشهادات عن العمل على المحفظة، لكنها تساعد في تجاوز فلاتر مسؤولي التوظيف.

الختام

ما تعرفه الآن

بدأت هندسة موثوقية المواقع كحل من جوجل لمشكلة التوسع، ثم تطورت لتصبح تخصصًا يُمارس على مستوى الصناعة. لقد غطيت:

- التحول من العمليات اليدوية إلى الموثوقية المُهندسة

- مؤشرات مستوى الخدمة (SLIs)، وأهداف مستوى الخدمة (SLOs)، واتفاقيات مستوى الخدمة (SLAs)، ومفهوم ميزانيات الأخطاء المرتبط بعكس SLO

- تعريف الجهد الروتيني (Toil)، وقاعدة الـ 50%، والتقليل منه بطرق هندسية

- دورات المناوبة المستدامة وممارسة التحليلات اللاحقة للحوادث بدون إلقاء اللوم

- الإشارات الذهبية الأربع كنقطة بداية لرصد الخدمات

- مسارات مهنة SRE والشهادات التي تفتح الأبواب

فكرتان هما الأهم. الموثوقية رقم متفق عليه مسبقًا. والجهد اليدوي عيب، وليس وصفًا وظيفيًا. احمل هاتين الفكرتين معك وستتبع بقية ممارسات SRE بشكل طبيعي.

القراءات الموصى بها: كتاب SRE من Google (متاح مجانًا عبر الإنترنت: sre.google/books/)، وكتاب SRE Workbook للتمارين العملية، وكتابات Charity Majors حول الرصد. يتعمق درس geometry-of المصاحب في البنية البصرية التي تقوم عليها ممارسات SRE: توزيعات زمن الاستجابة، مخروط ميزانية الأخطاء، رسوم الاعتماديات، وتخطيطات لوحات المعلومات.