مصطلح
ما هي هندسة موثوقية المواقع SRE؟ المعنى والأمثلة
ما هي هندسة موثوقية المواقع SRE؟ هي اختصار Site Reliability Engineering، وتعني طريقة في تشغيل الخدمات الرقمية يعامل فيها المهندسون الموثوقية صفةً تُقاس: يتفقون على مستوى الموثوقية الذي تحتاجه كل خدمة، ويقيسونه بما يعيشه المستخدم فعلًا، ثم يستعملون الفرق بين الهدف والكمال، أي ميزانية الأخطاء، ليقرّروا متى يطلقون ميزات جديدة ومتى يتفرغون لإصلاح ما هو هش. وSRE مجموعة ممارسات، وهي في كثير من المنشآت اسم الفريق الذي يطبّقها أيضًا.
Glossary نُشر في 6 دقائق قراءة
الخلاصة
- معنى SRE: هندسة موثوقية المواقع، أي تطبيق أساليب هندسة البرمجيات على أعمال التشغيل حتى تبقى الخدمات موثوقة وهي تكبر.
- الفكرة الأساسية: لا تحتاج أي خدمة إلى موثوقية كاملة. اتفقوا على هدف، وقيسوه، وأنفقوا الباقي عن قصد.
- المصطلحات: SLI ما تقيسونه، وSLO الهدف الذي تضعونه، وSLA الالتزام المكتوب في العقد، وميزانية الأخطاء مقدار الخلل الذي تتحملونه.
- ما الذي ليست هي: ليست أداة تُشترى. فالأدوات تسجّل وتنبّه، أما الممارسة فهي الاتفاقات التي يلتزم بها الفريق.
التعريف
ما هي هندسة موثوقية المواقع SRE بعبارة بسيطة
كل خدمة رقمية تتعطل أحيانًا. وفرق التشغيل تميل إلى إيقاف التغيير لأنه سبب الأعطال، بينما تريد فرق المنتج أن تغيّر بسرعة. وتحسم هندسة موثوقية المواقع هذا الخلاف بالأرقام لا بالآراء.
بدأت هذه الممارسة في Google مطلع الألفية، ثم نشرت Google طريقتها علنًا في موقعها وكتبها عن SRE. وأفكارها تصلح لمنشآت كثيرة غير شركات التقنية الكبرى. ففريق SRE، أو فريق منصة يعمل بهذه الطريقة، يقوم عادةً بما يلي:
اقرأ المزيد
- يحدّد عددًا قليلًا من المقاييس التي تعكس ما يشعر به المستخدم، مثل الطلبات الفاشلة أو الصفحات البطيئة؛
- يضع هدفًا لكل مقياس ويراجعه مع مالك الخدمة ومع الإدارة؛
- يؤتمت أعمال التشغيل المتكررة، وتسمّيها SRE «العمل الروتيني» (toil)، ليجد المهندسون وقتًا للإصلاحات الدائمة؛
- يدير الحوادث بأدوار واضحة، ويكتب بعدها مراجعة لا تلوم الأشخاص؛
- يبقي التنبيهات قليلة وذات معنى، فلا يُوقَظ أحد ليلًا إلا لسبب حقيقي.
روابط ذات صلةموقعها وكتبها عن SRE
SLI وSLO وSLA
SLI وSLO وSLA: المصطلحات الثلاثة التي تقوم عليها SRE
| المصطلح | الاسم الكامل | ما هو | مثال | من يملكه |
|---|---|---|---|---|
| SLI | مؤشر مستوى الخدمة | قياس لسلوك الخدمة كما يعيشه المستخدم | نسبة طلبات الدفع التي تنجح | فريق الهندسة |
| SLO | هدف مستوى الخدمة | الهدف المطلوب للمؤشر خلال مدة زمنية | نجاح 999 من كل 1,000 طلب دفع على مدى 30 يومًا | مالك الخدمة بالاتفاق مع الإدارة |
| SLA | اتفاقية مستوى الخدمة | التزام في عقد تترتب عليه نتيجة إن لم يتحقق | نسبة توافر شهرية في العقد، مع رصيد خدمة للعميل إن لم تتحقق | الفريق التجاري والقانوني |
ويُوضع هدف SLO عادةً أعلى من اتفاقية SLA، فيرى الفريق المشكلة ويتصرف قبل أن يصبح العقد في خطر. وكثير من الخدمات الداخلية لها أهداف SLO دون أي اتفاقية SLA.
ميزانية الأخطاء
ما هي ميزانية الأخطاء، وكيف تستعملها الفرق
ميزانية الأخطاء (error budget) هي مقدار الخلل الذي يسمح به هدف SLO. فإن كان الهدف نجاح 999 طلبًا من كل 1,000 (ويُكتب غالبًا 99.9 في المئة، أو «ثلاث تسعات»)، فالميزانية هي الطلب الواحد من كل 1,000 الذي يجوز أن يفشل. وما دامت في الميزانية بقية، يطلق الفريق الميزات بوتيرته المعتادة. وحين تقترب من النفاد، يكون الإجراء المتفق عليه إبطاء الإصدارات وتوجيه الجهد إلى الموثوقية حتى تعود الخدمة إلى هدفها. وبهذا الاتفاق يصير سؤال «هل نطلق الإصدار يوم الخميس؟» قراءةً لرقم واحد قبله الجميع مسبقًا.
مثال محسوب
مثال محسوب على ميزانية الأخطاء
أرقام توضيحية لخدمة واحدة خلال مدة 30 يومًا، بعد مرور 20 يومًا منها.
| المؤشر SLI | الهدف SLO | ميزانية الأخطاء في 30 يومًا | المستهلك بعد 20 يومًا | المتبقي | ما يفعله الفريق |
|---|---|---|---|---|---|
| الطلبات الناجحة (10 ملايين طلب متوقع) | 999 من 1,000 | 10,000 طلب فاشل | 4,000 طلب فاشل | 6,000 طلب | تستمر الإصدارات كما خُطط لها |
| الطلبات التي يُرد عليها في أقل من 300 ms | 99 من 100 | 100,000 طلب بطيء | 85,000 طلب بطيء | 15,000 طلب | يبطئ الإصدارات ويعالج الواجهة البطيئة |
| دقائق نجاح فحص السلامة (43,200 دقيقة في 30 يومًا) | 999 من 1,000 | 43.2 دقيقة توقف | 30 دقيقة | 13.2 دقيقة | يراجع حادثتي التوقف قبل أي تغيير عالي المخاطر |
ميزانية زمن الاستجابة تُستهلك أسرع من مرور الأيام: مضى ثلثا المدة لكن 85,000 من أصل 100,000 طلب بطيء مسموح بها استُهلكت. وينبّه فريق SRE على معدل الاستهلاك هذا (burn rate)، لأنه ينذر بضياع الهدف قبل وقوعه بأيام.
مقارنة
الفرق بين SRE وDevOps
| DevOps | SRE | |
|---|---|---|
| ما هو | ثقافة وممارسات تجمع التطوير والتشغيل | طريقة محددة لتطبيق هذه الممارسات بأهداف موثوقية |
| التركيز الرئيس | إيصال التغيير بسرعة وأمان | إبقاء الخدمات ضمن الموثوقية المتفق عليها مع استمرار التغيير |
| المقاييس المعتادة | عدد مرات النشر، ومدة التسليم، ونسبة التغييرات الفاشلة، ووقت الاستعادة | SLI وSLO وميزانية الأخطاء والعمل الروتيني وMTTR |
| الأشخاص المعتادون | مطورون ومهندسو تشغيل يتشاركون المسؤولية | مهندسون بمهارات برمجية يتولون موثوقية بيئة الإنتاج |
وهما ليسا متنافسين: DevOps تصف ما يؤمن به الفريق، وSRE طريقة عملية واحدة لتطبيقه. وكثير من الفرق في المملكة تتبنى ممارسات SRE خدمةً بعد خدمة، دون تغيير مسمّى أحد.
الأدوات
الأدوات التي يحتاجها فريق SRE
SRE ممارسة، لكنها لا تقوم على التخمين. وتتكرر أربعة أنواع من الأدوات في كل فريق تقريبًا:
- المراقبة والتنبيه: مقاييس وسجلات وفحوص سلامة لكل خدمة، وتنبيهات تنطلق مما يشعر به المستخدم وتصل إلى الفريق المسؤول.
- التتبع الموزّع: متابعة الطلب الواحد عبر الخدمات، ليُعرف سبب الاستدعاء البطيء أو الفاشل بسرعة.
- إدارة الحوادث والمناوبة: استدعاء الشخص المناسب، وإعلان الحادثة بدرجة خطورة وقائد، وحفظ تسلسلها الزمني، وكتابة المراجعة. ويشرح مصطلح متوسط وقت الإصلاح MTTR كيف يقصّر ذلك وقت التعافي.
- متابعة أهداف SLO: أهداف معرّفة على البيانات نفسها التي تقوم عليها التنبيهات، مع عرض ما بقي من ميزانية الأخطاء وتنبيه حين تُستهلك بسرعة.
وحين تتوزع هذه الأدوات على منتجات منفصلة، تُحسب ميزانية الأخطاء غالبًا يدويًا في آخر الشهر، بعد فوات وقت التصرف.
روابط ذات صلةمصطلح متوسط وقت الإصلاح MTTR
Datadog وإنتركي
كيف تغطي Datadog أدوات SRE، وأين تساعد إنتركي
تجمع Datadog الأنواع الأربعة على منصة واحدة. فالمراقبات (monitors) تنبّه على المقاييس والسجلات والتتبعات، وDatadog APM يتتبع الطلبات عبر الخدمات، وأهداف SLO في Datadog تُعرّف لمدة 7 أو 30 أو 90 يومًا على المراقبات أو المقاييس التي ترسلونها أصلًا وتعرض ما بقي من ميزانية الأخطاء. وتوثّق Datadog أن الحوادث يمكن إعلانها من تنبيهات المراقبات، بدرجة خطورة وقائد للحادثة وأدوار للمستجيبين، مع مسودات مراجعة ما بعد الحادثة في Notebooks. وتتولى Datadog On-Call الاستدعاء. وهذه أوصاف Datadog نفسها لمنتجاتها.
اقرأ المزيد
وتبيع إنتركي تراخيص Datadog في المملكة، وتنفّذ المنصة، وتقدّم الدعم الفني من الرياض. وفي برنامج SRE يعني ذلك عادةً اختيار أول المؤشرات مع مالك كل خدمة، وإعداد مراقبة أهداف مستوى الخدمة SLO وتنبيهات معدل الاستهلاك، وتنظيف التنبيهات التي فقد فريق المناوبة ثقته بها، وضبط إدارة الحوادث في Datadog لتُكتب المراجعات بالطريقة نفسها كل مرة.
روابط ذات صلةمراقبة أهداف مستوى الخدمة SLOإدارة الحوادث في Datadog
في السياق السعودي
هندسة الموثوقية في السياق السعودي
كثيرًا ما تمتد المنصات في المملكة عبر أنظمة في مراكز البيانات وخدمات سحابية وعدة موردين. وتمنح أهداف SLO هذه الأطراف لغة مشتركة واحدة: فيُحاسَب المورّد على المؤشر الذي يشعر به المستخدم، لا على نسبة تشغيل الخادم وحدها. وتطرح بيانات الرصد سؤال إقامة البيانات أيضًا: فـ Datadog منصة SaaS، وحتى نوفمبر 2026 لا تُدرج Datadog أي موقع لها في الشرق الأوسط، فحدّدوا ما يجوز أن يغادر شبكتكم، وأخفوا البيانات الشخصية قبل إرسالها. ويعمل مهندسو إنتركي في الرياض مع فريقكم بالعربية والإنجليزية، من اختيار المؤشرات إلى الدعم الفني.
أسئلة تطرحها الفرق عن SRE
هل SRE مسمّى وظيفي أم طريقة عمل؟
الاثنان معًا. فبعض المنشآت توظّف مهندسي موثوقية المواقع في فريق مستقل، وبعضها يطلب من مهندسي المنصة أو التشغيل الحاليين تبنّي أهداف SLO وميزانية الأخطاء والمراجعات التي لا تلوم الأشخاص.
هل نحتاج إلى فريق SRE مستقل لنبدأ بممارساتها في السعودية؟
لا. تبدأ أغلب الفرق في المملكة بخدمة واحدة مهمة: تتفق مع مالكها على مؤشرين أو ثلاثة، وتضع هدف SLO، وتراجع ميزانية الأخطاء كل أسبوع. ويصبح الفريق المستقل مفيدًا لاحقًا، حين تعمل عدة خدمات بهذه الطريقة وتحتاج المراجعات إلى مسؤول.
كيف نختار أول هدف SLO لخدمة ما؟
ابدؤوا مما يعيشه المستخدمون الآن. قيسوا المؤشر بضعة أسابيع، وضعوا الهدف أدنى قليلًا مما تحققونه اليوم، ولا ترفعوه إلا حين يحتاج المستخدمون أو الإدارة إلى أكثر.
ماذا يحدث حين تنفد ميزانية الأخطاء لخدمة ما؟
ما اتفق عليه الفريق مسبقًا. والسياسة المعتادة إيقاف الإصدارات عالية المخاطر وتوجيه وقت المهندسين إلى الموثوقية حتى تعود الخدمة إلى هدفها. واتفقوا عليها مع الإدارة قبل أن تنفد الميزانية.
كيف تُرخَّص Datadog لأهداف SLO والحوادث والمناوبة؟
تُبنى أهداف SLO على المراقبات والمقاييس التي ترسلونها أصلًا، فتتبع كلفتها منتجات المراقبة التي تقوم عليها. أما Incident Management وOn-Call فتُسعَّر لكل مقعد شهريًا، وتنشر Datadog أسعارها في صفحتها. وتسعّر إنتركي التراخيص مع الإعداد والدعم في المملكة في عرض واحد.
متى تصبح أهداف SLO وميزانية الأخطاء مفيدة لفريقنا؟
لا توجد مدة ثابتة. فالأمر يتوقف على عدد الخدمات التي تبدؤون بها، وهل هي مراقَبة أصلًا، وسرعة اتفاق المالكين على الأهداف. ويمكن أن تحصل خدمة أولى عليها مراقبة قائمة على أهداف SLO خلال أسابيع، لكن ميزانية الأخطاء ذات المعنى تحتاج إلى مدة كاملة واحدة من البيانات على الأقل. وأي مدة نذكرها تقدير مرتبط بهذا النطاق.
من مركز المعرفة
تابعوا في مكتبة المصطلحات
مزيد من المصطلحات التقنية
تعريفات قصيرة وواضحة للمصطلحات التي تمر بالمشتري في مشاريع المراقبة والسحابة والبيانات.
مصطلحMTTR
كيف يُقاس وقت التعافي من الحادثة، وما الذي يقصّره.
حلإدارة الحوادث في Datadog بالسعودية
المناوبة وأدوار الحادثة ومراجعات ما بعدها، والتراخيص والدعم.
حلDatadog APM والتتبع الموزّع
متابعة الطلبات عبر الخدمات للوصول إلى الاستدعاء البطيء أو الفاشل.
صفحات ذات صلة
الخطوة التالية
حدّدوا معنا أول أهداف SLO
أخبرونا بالخدمات الأهم لديكم، وكيف تراقبونها اليوم، وكيف تُدار الحوادث. وسنقترح أول المؤشرات والأهداف، ونسعّر تراخيص Datadog والإعداد والدعم الفني إن كانت Datadog مناسبة لكم.
أو مباشرةً
+966-11-2180999 [email protected]أبراج التعاونية، البرج الشمالي، الطابق السابع، طريق الملك فهد، العليا، ص.ب. ٥٦٨٣٥، الرياض ١١٥٦٤، المملكة العربية السعودية