SLOs Explained

في أي نظام حقيقي، السؤال مش بيكون: “هل السيستم شغال؟”
لأن غالبًا الإجابة آه… بس السؤال الأهم هو: شغال قد إيه بشكل يعتمد عليه؟

هنا بتيجي فكرة الـ SLO — Service Level Objective.

ما هي الـ SLOs؟ وليه تهمك كمهندس؟

ببساطة، الـ SLO هو هدف واضح للموثوقية.
يعني بدل ما نقول: “عايزين السيستم يبقى stable”، بنقول حاجة قابلة للقياس:

99.9% من طلبات الدفع لازم تنجح خلال آخر 30 يوم.

أو:

95% من صفحات البحث لازم تفتح في أقل من 500ms.

الفكرة هنا إننا بنحوّل الإحساس العام إلى رقم واضح الفريق كله فاهمه.

الـ SLO غالبًا بيتكوّن من 3 حاجات أساسية:

SLI: الحاجة اللي بنقيسها فعلًا، زي نسبة النجاح، latency، أو availability.
Target: الهدف المطلوب، زي 99.9%.
Time Window: الفترة اللي بنقيس عليها، زي أسبوع، شهر، أو آخر 30 يوم.

وفيه مفهوم مهم جدًا اسمه Error Budget.

لو هدفك إن 99.9% من الطلبات تنجح، فده معناه ضمنيًا إنك سامح بـ 0.1% فشل. النسبة الصغيرة دي هي الـ Error Budget: المساحة اللي تقدر “تغلط” فيها من غير ما المستخدمين يتأثروا بشكل كبير.

وده بيخلي القرارات أوضح جدًا.

لو عندك Error Budget كفاية، ممكن تتحرك بسرعة، تعمل releases، وتجرب features جديدة. لكن لو قربت تخلصه، يبقى لازم تهدي شوية وتركّز على إصلاح الاستقرار بدل إضافة حاجات جديدة.

مثال عملي:

تخيل عندك خدمة تسجيل دخول، والـ SLO بتاعها:

99.95% من login requests لازم تنجح خلال 30 يوم.

لو حصلت مشاكل متكررة، بدل ما الفريق يدخل في نقاشات عامة زي: “السيستم بقى وحش؟” أو “المشكلة كبيرة؟”

يبقى عندك رقم واضح يقولك: هل لسه جوه الـ margin والهدف بتاعنا ؟ ولا بدأنا نكسر الوعد اللي بيننا وبين المستخدمين؟

علشان كده الـ SLOs مش مجرد monitoring زيادة ولكن هي طريقة تخلي الفريق يوازن بين حاجتين مهمين جدًا: السرعة و الموثوقية.

وده لأن النظام مش لازم يكون مثالي طول الوقت، بس لازم يكون موثوق للمستخدمين اللي بيعتمدوا عليه.