هندسة موثوقية المواقع (SRE)

ميزانيات الأخطاء

18 دقيقة الدرس 3 من 29

ميزانيات الأخطاء

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

عقد ميزانية الأخطاء

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

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

حساب ميزانية الأخطاء

الصيغة مباشرة. بفرض هدف SLO يساوي T على نافذة زمنية W:

  • الميزانية (نسبة) = 1 − T
  • الميزانية (بالدقائق، نافذة 30 يومًا) = (1 − T) × 30 × 24 × 60

لأهداف SLO الشائعة على نافذة 30 يومًا (43,200 دقيقة إجمالًا):

  • 99 % → 432 دقيقة (~7.2 ساعات) من التوقف المسموح به
  • 99.9 % → 43.2 دقيقة
  • 99.95 % → 21.6 دقيقة
  • 99.99 % → 4.32 دقيقة

في Prometheus، تتابع الميزانية المتبقية على شكل كسر:

# الميزانية المتبقية كنسبة مئوية لـ SLO بنسبة 99.9 % # SLI = نسبة الطلبات الناجحة خلال نافذة 30 يومًا 1 - ( sum(increase(http_requests_total{job="api",status=~"5.."}[30d])) / sum(increase(http_requests_total{job="api"}[30d])) ) / 0.001

قيمة 1.0 تعني أن الميزانية كاملة. 0.0 تعني نفادها. قيمة سالبة تعني تجاوز حد SLO.

معدلات الحرق

مراقبة الميزانية المتبقية مباشرةً أبطأ من أن تفيد في الاستجابة للحوادث — لن تلاحظ المشكلة إلا بعد حدوث ضرر كبير. معدل الحرق يخبرك بمدى سرعة استهلاك الميزانية قياسًا بالمعدل الطبيعي.

معدل حرق 1 يعني أن الخدمة تستهلك ميزانيتها بالضبط بالمعدل الذي ينفدها عند نهاية النافذة. معدل حرق 14.4 خلال ساعة واحدة يعني أن الخدمة تحرق ميزانية شهر كامل في ساعتين فقط — وهو حادث P0 بأي معيار.

يوصي دليل Google SRE باستراتيجية تنبيه متعدد النوافذ ومتعدد معدلات الحرق لتحقيق التوازن بين الدقة والاستدعاء:

  • حرق سريع (نافذة 1h / 5m): معدل الحرق > 14.4 → تنبيه فوري (2% من الميزانية في ساعة)
  • حرق متوسط (نافذة 6h / 30m): معدل الحرق > 6 → تنبيه (5% من الميزانية في 6 ساعات)
  • حرق بطيء (نافذة 1d / 2h): معدل الحرق > 3 → تذكرة (10% من الميزانية في يوم)
  • تنبيه اتجاهي (نافذة 3d / 6h): معدل الحرق > 1 → تحذير (الميزانية تنفد أسرع مما تتجدد)
استخدم دائمًا نافذتين لكل حد من حدود معدل الحرق (نافذة طويلة لاكتشاف الاتجاه المستمر، ونافذة قصيرة للتأكد من استمرار المشكلة). هذا يمنع عواصف التنبيهات من الارتفاعات العابرة التي زالت بالفعل.

في Prometheus / Alertmanager بصيغة YAML:

groups: - name: slo.error_budget rules: # حرق سريع — استدعاء فوري - alert: ErrorBudgetFastBurn expr: | ( sum(rate(http_requests_total{job="api",status=~"5.."}[1h])) / sum(rate(http_requests_total{job="api"}[1h])) ) > (14.4 * 0.001) and ( sum(rate(http_requests_total{job="api",status=~"5.."}[5m])) / sum(rate(http_requests_total{job="api"}[5m])) ) > (14.4 * 0.001) for: 2m labels: severity: page team: sre annotations: summary: "حرق سريع للميزانية على api (معدل > 14.4x)" runbook: "https://wiki.internal/runbooks/api-error-budget" # حرق متوسط — استدعاء - alert: ErrorBudgetModerateBurn expr: | ( sum(rate(http_requests_total{job="api",status=~"5.."}[6h])) / sum(rate(http_requests_total{job="api"}[6h])) ) > (6 * 0.001) and ( sum(rate(http_requests_total{job="api",status=~"5.."}[30m])) / sum(rate(http_requests_total{job="api"}[30m])) ) > (6 * 0.001) for: 15m labels: severity: page team: sre annotations: summary: "حرق متوسط للميزانية على api (معدل > 6x)" # حرق بطيء — تذكرة - alert: ErrorBudgetSlowBurn expr: | ( sum(rate(http_requests_total{job="api",status=~"5.."}[1d])) / sum(rate(http_requests_total{job="api"}[1d])) ) > (3 * 0.001) and ( sum(rate(http_requests_total{job="api",status=~"5.."}[2h])) / sum(rate(http_requests_total{job="api"}[2h])) ) > (3 * 0.001) for: 1h labels: severity: ticket team: sre annotations: summary: "حرق بطيء للميزانية على api — مطلوب عمل موثوقية"

مخطط معدل الحرق

Error budget burn rate scenarios over 30 days 0 % 50 % 100 % Budget Remaining Day 0 Day 7.5 Day 15 Day 22.5 Day 30 Burn 1x (ideal) Burn 3x (ticket) Burn 14.4x (page!) Legend Rate 1x — budget lasts 30d Rate 3x — exhausted day 10 Rate 14.4x — exhausted day 2
معدلات حرق ميزانية الأخطاء: مدى سرعة نفاد الميزانية في كل سيناريو خلال 30 يومًا.

ماذا يحدث حين تنفد الميزانية

استنزاف ميزانية الأخطاء يُطلق سياسة تصعيد محددة — وليس مجرد استياء غامض. تفرض مؤسسات SRE الناضجة ما يلي تلقائيًا:

  1. تجميد النشر — تمنع أنابيب CI/CD أي نشر جديد للإنتاج (بوابة سياسة تتحقق من ميزانية الأخطاء قبل السماح بالنشر). يُستثنى من ذلك الإصلاحات العاجلة وعمليات التراجع.
  2. سبرينت الموثوقية — يُفرَّغ الباك لوج للسبرينت التالي ويُملأ حصريًا بعناصر الموثوقية من قائمة إجراءات ما بعد الحوادث وبنود الدين التقني وأعمال التصليب.
  3. التصعيد للقيادة — يُرفع تجاوز SLO في التقرير الأسبوعي التنفيذي مع تحليل السبب الجذري وجداول زمنية للمعالجة.
  4. مراجعة الميزانية — إذا كانت الميزانية تنفد باستمرار بنفس نمط الفشل، فقد يحتاج SLO نفسه إلى مراجعة (تشديد أو تخفيف)، أو تحتاج بنية الخدمة إلى تغيير جذري.
لا تسمح أبدًا للفرق بـ"الاقتراض" من ميزانية الشهر القادم. كل نافذة تُعاد إلى 100%. الاقتراض المستقبلي يُدمّر آلية المساءلة — إذ يعاني المستخدمون من عدم الموثوقية المتراكمة حتى لو أُعيد ضبط المقياس.

أنماط الفشل الشائعة في الإنتاج

أكثر الأخطاء التي ترتكبها الفرق مع ميزانيات الأخطاء في الإنتاج:

  • قياس SLI الخاطئ — حصر العد في أخطاء 5xx يُفوّت انتهاكات الزمن الكامن، والإخفاقات الجزئية (انتهاء مهلة خدمة طرف ثالث)، والأخطاء من جانب العميل. عرّف SLIs على مستوى رحلة المستخدم.
  • عدم استثناء نوافذ الصيانة المخططة — إذا استنزفت الميزانية خلال نافذة صيانة أُخطر بها المستخدمون ووافقوا عليها، فهذا الإنفاق مُضلِّل. حدّد نوافذ الصيانة في أدوات SLO واستثنِها من حسابات الميزانية.
  • التنبيه على نافذة واحدة فقط — التنبيه المبني على الميزانية المتبقية لـ 30 يومًا فقط يُسبّب تأخيرًا هائلًا. انقطاع كارثي يستنزف 100% من الميزانية في ساعة لن يُطلق تنبيهًا إلا بعد فوات الأوان. اقرن دائمًا تنبيهات معدل الحرق بنوافذ قصيرة.
  • غياب القوة التنفيذية للسياسة — ميزانيات الأخطاء لا قيمة لها إذا كان بإمكان مدير هندسي تجاوز التجميد "هذه المرة فقط". قوّن السياسة في بوابات الأنابيب، لا في صفحة Confluence.
على نطاق Google، تُعرض حالة ميزانية الأخطاء على لوحة معلومات في الوقت الفعلي مرئية لكل مهندس ومدير في المؤسسة. الشفافية هي ما يمنح الميزانية قوتها الاجتماعية. فكّر في نشر لوحة معلوماتك على صفحة حالة داخلية إلى جانب لوحة SLO.