أذكر جيداً تلك الليلة، كانت الساعة تقارب الثانية صباحاً بتوقيت القدس. رنين الهاتف الحاد اخترق سكون الليل، وعلى الطرف الآخر كان صوت زميلي “خليل” المنهك: “أبو عمر، الحقني! السيرفر الرئيسي لخدمة الدفع وقع مرة ثانية!”. لم تكن تلك المرة الأولى، ولا الثانية. كانت تلك الفترة من حياتنا المهنية عبارة عن سلسلة لا تنتهي من المكالمات الليلية، إطفاء الحرائق، وحلول مؤقتة بالكاد تصمد حتى شروق الشمس.
كنا نشعر بأننا في حلقة مفرغة. فريق المنتج يضغط لإضافة ميزات جديدة، والإدارة تريد رؤية نمو سريع، ونحن في قسم الهندسة غارقون في الديون التقنية ومشاكل الموثوقية. كل ميزة جديدة كانت بمثابة إضافة وقود على النار. النقاشات بيننا وبين فريق المنتج كانت دائماً متوترة: “لا يمكننا إطلاق هذه الميزة الآن، النظام غير مستقر!”، وكان الرد يأتي سريعاً: “لكن المنافسين أطلقوها، يجب أن نلحق بالركب!”.
في إحدى جلسات العصف الذهني المليئة بالقهوة والإرهاق، صرخ خليل من يأسه: “يا زلمة، شو القصة؟ لازم يكون في طريقة أحسن من هيك! طريقة تخلّينا نحكي معهم بلغة يفهموها، لغة الأرقام، مش لغة التعب والصريخ!”. كانت تلك الصرخة هي بداية بحثنا عن مخرج، المخرج الذي وجدناه في فلسفة هندسة موثوقية المواقع (SRE) ومن قلبها النابض: ميزانيات الخطأ (Error Budgets).
ما هي “ميزانيات الخطأ”؟ دعنا نبسطها
ببساطة شديدة، ميزانية الخطأ هي “الكمية المسموح بها من عدم الموثوقية”. أعرف، قد تبدو الجملة غريبة. كيف نسمح بالخطأ؟ الفكرة هي أنه لا يوجد نظام مثالي بنسبة 100%. السعي وراء الكمال المطلق (موثوقية 100%) هو أمر مكلف جداً، بطيء، وشبه مستحيل. بدلاً من ذلك، نتفق مع أصحاب المصلحة (المنتج، العمل) على مستوى “جيد بما فيه الكفاية” من الموثوقية، ونستخدم “الهامش” المتبقي كميزانية للخطأ.
فكر فيها مثل ميزانيتك المالية الشهرية. لديك دخل محدد، وتخصص جزءاً منه للنفقات الأساسية (إيجار، فواتير)، وجزءاً للادخار، وجزءاً للترفيه. “ميزانية الخطأ” هي ميزانية “الترفيه” الهندسية. هي المقدار الذي يمكنك “إنفاقه” على شكل أخطاء، بطء، أو حتى توقف مؤقت للخدمة، قبل أن تبدأ في انتهاك أهداف الموثوقية التي وعدت بها المستخدمين.
الركائز الثلاث: SLI, SLO, SLA
لفهم ميزانيات الخطأ، يجب أن نفهم ثلاثة مصطلحات أساسية من عالم SRE:
- مؤشر مستوى الخدمة (SLI – Service Level Indicator): هذا هو المقياس الكمي لأحد جوانب خدمتك. إنه رقم حقيقي تقيسه. أمثلة:
- نسبة الطلبات (requests) الناجحة.
- زمن استجابة الطلب (latency) للـ 95% من المستخدمين.
- نسبة الأخطاء في الخادم (server-side error rate).
- هدف مستوى الخدمة (SLO – Service Level Objective): هذا هو الهدف الذي تضعه لـ SLI الخاص بك خلال فترة زمنية. إنه التزام داخلي بين الفرق. مثال:
- “يجب أن يكون زمن استجابة صفحة تسجيل الدخول أقل من 300 مللي ثانية لـ 99% من الطلبات على مدار 30 يوماً”.
- “يجب أن تكون نسبة الطلبات الناجحة لواجهة برمجة التطبيقات (API) للدفع 99.95% على مدار 28 يوماً”.
- اتفاقية مستوى الخدمة (SLA – Service Level Agreement): هذا هو العقد الرسمي مع العميل. يحدد الـ SLO ويضيف إليه “عواقب” إذا تم انتهاكه، مثل استرداد جزء من المال أو غرامات. عادة ما يكون الـ SLA أقل صرامة من الـ SLO لترك هامش أمان داخلي.
نصيحة من أخوكم أبو عمر: ركز على SLOs أولاً. هي الأداة التي ستحول فريقك. الـ SLAs هي مسألة قانونية وتجارية تأتي لاحقاً. الـ SLO هو وعدك لنفسك ولفريقك، أما الـ SLA فهو وعدك التعاقدي للعميل.
الحسابات البسيطة خلف الفكرة العظيمة
حساب ميزانية الخطأ بسيط بشكل مدهش. إنه الفرق بين الكمال (100%) وهدفك (SLO).
المعادلة: ميزانية الخطأ = 100% - SLO
دعنا نأخذ مثالاً عملياً. لنفترض أن لدينا خدمة تسجيل المستخدمين، ووضعنا لها SLO بنسبة 99.9% من الطلبات الناجحة خلال شهر (30 يوماً).
- SLO: 99.9% Availability
- Error Budget: 100% – 99.9% = 0.1%
الآن، لنترجم هذا الرقم (0.1%) إلى شيء ملموس. ما معنى 0.1% من الوقت خلال شهر؟
مجموع الدقائق في الشهر = 30 يوم * 24 ساعة/يوم * 60 دقيقة/ساعة = 43,200 دقيقة
ميزانية الخطأ بالدقائق = 0.1% * 43,200 دقيقة = 43.2 دقيقة
هذا الرقم هو الذهب! الآن لدينا 43.2 دقيقة شهرياً يمكن أن تكون فيها الخدمة غير متاحة (أو لا تلبي معايير النجاح) دون أن نخرق الـ SLO. هذه الدقائق هي “ميزانيتنا” التي يمكننا “إنفاقها”.
كيف غيّرت ميزانيات الخطأ طريقة عملنا؟
بمجرد أن بدأنا في تطبيق هذا المفهوم، تغير كل شيء. لم تعد النقاشات عاطفية، بل أصبحت مبنية على البيانات.
1. لغة مشتركة بين الهندسة والمنتج
بدلاً من قول “النظام متعب”، أصبحنا نقول: “لقد استهلكنا 80% من ميزانية الخطأ لهذا الشهر في الأسبوع الأول فقط. إذا أطلقنا الميزة (س) الآن، والتي تحمل مخاطرة عالية، فإننا نضمن تقريباً خرق الـ SLO الخاص بنا، مما سيؤثر على تجربة كل المستخدمين. يجب أن نتوقف عن إطلاق الميزات الجديدة ونركز على تحسين الموثوقية حتى يعود الرصيد إلى مستوى آمن”.
فجأة، أصبح لدى مدير المنتج مقياس واضح للمخاطرة. أصبح القرار مشتركاً ومبنياً على بيانات يتفق عليها الجميع.
2. من الإطفاء الارتجالي إلى المراقبة الاستباقية
بدلاً من انتظار مكالمة الساعة 2 صباحاً، قمنا ببناء لوحات متابعة (Dashboards) تعرض لنا معدل “حرق” ميزانية الخطأ (Error Budget Burn Rate). قمنا بإعداد تنبيهات ذكية:
- “تنبيه: إذا استمر معدل حرق الميزانية الحالي، فسنستهلكها بالكامل في غضون 3 أيام!”.
هذا أعطانا وقتاً للتحرك قبل وقوع الكارثة. أصبحنا نرى الدخان قبل أن تشتعل النار.
3. تشجيع الابتكار المحسوب
وهذا هو الجزء الأجمل. عندما تكون الخدمة مستقرة وميزانية الخطأ ممتلئة، ماذا نفعل؟ هذا هو الوقت المثالي لإطلاق الميزات الجديدة، وتجربة تقنيات مختلفة، والقيام بعمليات تحديث جريئة. ميزانية الخطأ الممتلئة هي ضوء أخضر للابتكار.
القاعدة أصبحت واضحة:
- ميزانية الخطأ على وشك النفاد؟ ⬅️ تجميد إطلاق الميزات الجديدة. كل الجهود تتوجه نحو الاستقرار والموثوقية.
- ميزانية الخطأ ممتلئة؟ ⬅️ انطلقوا يا شباب! أطلقوا الميزات، جربوا، وابتكروا. لدينا هامش لتحمل بعض الأخطاء غير المتوقعة.
كيف تبدأ رحلتك مع ميزانيات الخطأ؟ (دليل عملي)
حسناً يا أبو عمر، أقنعتني. من أين أبدأ؟
الخطوة 1: اختر خدمة واحدة ومهمة
لا تحاول تطبيق هذا على كل شيء دفعة واحدة. اختر خدمة واحدة بالغة الأهمية للمستخدمين، مثل تسجيل الدخول، أو البحث، أو عملية الدفع.
الخطوة 2: حدد مؤشراتك (SLIs) بعناية
اسأل نفسك: “ما الذي يهم المستخدم حقاً؟”. المستخدم لا يهتم بنسبة استخدام الـ CPU. هو يهتم بـ:
- التوفر (Availability): هل الخدمة ترد على طلبي أم تعطيني خطأ؟ (مثال SLI: نسبة الطلبات ذات الكود 2xx أو 3xx من إجمالي الطلبات).
- السرعة (Latency): هل الصفحة أو النتيجة تظهر بسرعة؟ (مثال SLI: نسبة الطلبات التي يتم الرد عليها في أقل من 500ms).
- الجودة (Quality): هل الرد صحيح وكامل؟ (هذا أصعب قياساً، لكن يمكن أن يكون مثلاً نسبة عمليات البحث التي لم ترجع نتائج فارغة بشكل خاطئ).
الخطوة 3: أتمتة القياس والمراقبة
هذا هو الجزء التقني. ستحتاج إلى أدوات لمراقبة (Observability) وجمع المقاييس (Metrics). الأدوات الشائعة تشمل Prometheus مع Grafana، أو Datadog، أو New Relic.
على سبيل المثال، باستخدام Prometheus، يمكنك كتابة استعلام (PromQL) لحساب معدل الأخطاء لخدمة ما:
# حساب معدل الطلبات التي تفشل (status code 5xx) خلال آخر 5 دقائق
sum(rate(http_requests_total{job="my-api-service", code=~"5.."}[5m]))
/
sum(rate(http_requests_total{job="my-api-service"}[5m]))
يمكنك بعد ذلك استخدام هذا المقياس في لوحة المتابعة الخاصة بك لتتبع استهلاك ميزانية الخطأ في الوقت الفعلي.
الخطوة 4: اجعلها مرئية للجميع
قم بإنشاء لوحة متابعة (Dashboard) كبيرة وواضحة، ربما على شاشة تلفاز في المكتب (أو قناة Slack مخصصة في عالم العمل عن بعد). يجب أن تظهر هذه اللوحة:
- الـ SLO المحدد.
- ميزانية الخطأ المتبقية لهذا الشهر/الربع.
- معدل حرق الميزانية الحالي.
عندما تصبح هذه الأرقام جزءاً من الثقافة اليومية للشركة، تكون قد نجحت.
الخلاصة: من الفوضى إلى الثقة
ميزانيات الخطأ لم تكن مجرد أداة تقنية بالنسبة لنا، بل كانت تحولاً ثقافياً. لقد نقلتنا من عالم الإرهاق والمكالمات الليلية والقرارات المبنية على “من صوته أعلى”، إلى عالم من الهدوء النسبي والقرارات المدروسة المبنية على البيانات. لقد أعطتنا طريقة موضوعية لموازنة السرعة مع الموثوقية، وهو التحدي الأزلي في عالم تطوير البرمجيات.
نصيحتي الأخيرة لك: لا تخف من الخطأ، بل تعلم كيف تديره. ابدأ اليوم، ولو بخطوة صغيرة، في قياس ما يهم حقاً، وحدد أهدافك، وامنح فريقك القوة التي تأتي مع الوضوح والبيانات. ستنام بشكل أفضل في الليل، أعدك بذلك. 👍
