25 يونيو 2025·7 دقيقة قراءة

SLOs للأدوات الداخلية: أهداف موثوقية بسيطة وفعالة

SLOs للأدوات الداخلية ببساطة: ضع أهدافًا قابلة للقياس للتوافر والكمون، ثم اربطها بتنبيهات يمكن لفريق صغير إدارتها دون إرهاق.

لماذا تحتاج الأدوات الداخلية إلى SLOs (حتى لو يستخدمها 20 شخصًا فقط)

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

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

SLOs تحل ذلك بوضع توقعات بسيطة قابلة للقياس. تجيب على سؤالين عمليين: ما الذي يجب أن يعمل، وما مستوى الأداء الكافي حتى يتمكن الناس من إنجاز عملهم.

التكلفة المخفية لعبارة "سنحافظ على استقرار معقول" تظهر بسرعة. يتوقف العمل بينما تنتظر الفرق عودة الأداة. تتكاثر رسائل الدعم لأن لا أحد يعرف ما هو الطبيعي. يُجرّ المطورون إلى إصلاحات عاجلة بدلًا من التحسينات المخططة. يتوقف مالكو المنتج عن الثقة بالنظام ويبدؤون بطلب حلول يدوية. تبقى المشكلات الصغيرة لأنّها لا تتجاوز خطًا واضحًا.

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

ينطبق هذا بغض النظر عن كيفية بناء الأداة. إذا كنت تستخدم AppMaster (appmaster.io) لإنشاء تطبيقات داخلية، اختر الإجراءات التي يعتمد عليها الناس، قِس التوافر ووقت الاستجابة، ونبه فقط عندما يؤثر ذلك على العمل.

SLOs و SLIs و SLAs بكلمات بسيطة

هذه المصطلحات الثلاث تبدو متشابهة، لكنها أنواع مختلفة من لغة الموثوقية. الخلط بينها مصدر شائع للارتباك.

SLI (مؤشر مستوى الخدمة) هو قياس. شيء يمكنك عدّه، مثل "نسبة الطلبات التي نجحت" أو "كم استغرقت الصفحة لتحميلها". إذا لم تستطع قياسه بثبات، فليس SLI جيدًا.
SLO (هدف مستوى الخدمة) هو الهدف لذلك القياس. يجيب: ما المستوى الكافي للمستخدمين معظم الوقت؟ SLOs تساعدك على تحديد ما يجب إصلاحه أولًا وما يمكن تأجيله.
SLA (اتفاقية مستوى الخدمة) هو وعد، غالبًا مكتوب ومع عواقب. العديد من الأدوات الداخلية لا تحتاج SLAs. ما تحتاجه هو أهداف واضحة، لا التزامات بنمط قانوني.

مثال سريع:

SLI (التوافر): نسبة الدقائق التي تكون فيها الأداة قابلة للوصول.
SLO (هدف التوافر): 99.9% من وقت التشغيل الشهري.
SLI (الكمون): p95 لوقت تحميل صفحة اللوحة.
SLO (هدف الكمون): p95 أقل من 2 ثانية خلال ساعات العمل.

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

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

اختر القليل من إجراءات المستخدم التي تهم بالفعل

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

ابدأ بتسمية نوع الأداة، لأنه يشير إلى المسارات الحرجة. لوحات الإدارة تتعلق بـ "تغيير شيء بأمان". لوحات العمليات تتعلق بـ "رؤية ما يحدث الآن". البوابات تتعلق بـ "الدخول، إيجاد المعلومات، وإرسال الطلب".

ثم اكتب أهم رحلات المستخدم بلغة بسيطة. مجموعة بداية جيدة:

تسجيل الدخول والوصول إلى الشاشة الرئيسية
البحث أو التصفية والحصول على نتائج
إرسال نموذج (إنشاء/تحديث) ورؤية رسالة نجاح
تحميل عرض اللوحة الرئيسي ببيانات حديثة
تصدير أو تنزيل التقرير الذي يستخدمه الناس يوميًا

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

حافظ على نطاق صغير في البداية. اختر 1 إلى 3 رحلات تطابق ألمًا حقيقيًا ومخاطرة حقيقية. إذا كانت صفحات الاتصال عادةً "لا أحد يستطيع تسجيل الدخول" و"زر الحفظ يتوقف"، ابدأ بتسجيل الدخول وإرسال النموذج. أضف البحث لاحقًا بعد أن تثق في القياسات والتنبيهات.

اختر SLIs يمكنك قياسها بالفعل

الـ SLIs الجيدة مملة. تأتي من بيانات لديك بالفعل، وتطابق ما يشعر به المستخدمون عندما تعمل الأداة أو تفشل. إذا احتجت إعداد مراقبة جديد بالكامل لقياسها، فاختر SLI أبسط.

ابدأ بالتوفر بالمصطلحات التي يفهمها الناس: هل أستطيع فتح الأداة وإنهاء المهمة؟ بالنسبة للعديد من الأدوات الداخلية، يغطي اثنان من SLIs معظم الألم:

توفر الأداة (هل هي قابلة للوصول وتستجيب)
نسبة النجاح لواحد إلى ثلاثة إجراءات رئيسية (تسجيل الدخول، البحث، الحفظ، الموافقة)

ثم أضف الكمون، لكن اجعله ضيقًا. اختر شاشة أو نقطتي نهاية تمثل الانتظار الذي يشتكي المستخدمون منه، مثل تحميل اللوحة أو إرسال نموذج. قياس كل شيء عادةً يُنتج ضوضاء ونقاشات.

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

أخيرًا، اختر مصدر حقيقة واحد لكل SLI وسجّله:

فحوص اصطناعية (بوت يضغط على فحص صحة أو ينفذ سيرًا بسيطًا)
مقاييس الخادم (عدادات الطلبات، الأخطاء، الكمون من الواجهة الخلفية)
السجلات (عدّ أحداث "نجاح" مقابل "فشل" لفعل محدد)

مثال: إذا كان تطبيقك الداخلي مبنيًا على AppMaster، يمكنك قياس التوافر بفحص اصطناعي للنهاية الخلفية، نسبة النجاح من استجابات API، والكمون من توقيتات طلبات الواجهة الخلفية. المفتاح هو الاتساق، لا الكمال.

ضع SLOs واقعية للتوافر والكمون

Build one tool with SLOs

Build an internal tool fast, then set clear SLOs around the user actions that matter.

Try AppMaster

ابدأ باختيار رقم توفر يمكنك الدفاع عنه في أسبوع سيء. لكثير من الأدوات الداخلية، 99.5% هو SLO أول جيد. يبدو عاليًا، لكنه يترك مجالًا للعمل العادي. الانتقال مباشرة إلى 99.9% غالبًا يعني استدعاءات بعد ساعات وإبطاء الإصدارات.

لجعل التوافر محسوسًا، حوّله إلى وقت. شهر 30 يومًا به حوالي 43,200 دقيقة:

99.5% يتيح حوالي 216 دقيقة تعطل شهريًا
99.9% يتيح حوالي 43 دقيقة تعطل شهريًا

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

بالنسبة للكمون، تجنب المتوسطات. فهي تخفي اللحظات البطيئة التي يتذكرها المستخدمون. استخدم نسبة مئوية مثل p95 وحدد حدًا واضحًا مرتبطًا بفعل حقيقي. أمثلة: "p95 تحميل اللوحة أقل من 2 ثانية" أو "p95 الحفظ يكتمل خلال 800 مللي ثانية".

طريقة بسيطة لتحديد الرقم الأولي هي مراقبة أسبوع من الحركة الحقيقية، ثم اختيار هدف أفضل قليلًا من الواقع الحالي لكن ليس خياليًا. إذا كان p95 بالفعل 1.9 ثانية، فهدف 2.0 ثانية آمن ومفيد. هدف 500 مللي ثانية سيولد ضوضاء فقط.

طابق SLOs مع قدرة الدعم لديك. فريق صغير يفضل أهدافًا قابلة للتحقيق على عدد كبير من الأهداف الصارمة. إذا لم يستطع أحد الرد خلال ساعة، فلا تضع أهدافًا تفترض استجابة أسرع.

اجعل المقايضات مرئية: التكلفة، المخاطرة، وميزانية الأخطاء

Replace fragile dashboards

Create an ops dashboard with real backend logic, not spreadsheets and scripts.

Start Building

SLO أدق يبدو مطمئنًا، لكنه له ثمن. إذا رفعت الأداة من 99.5% إلى 99.9%، فأنت تقول أيضًا "نقبل دقائق سيئة أقل بكثير"، مما يعني عادة مزيدًا من التنبيهات والمزيد من الوقت على الموثوقية بدلًا من الميزات الجديدة.

أسهل طريقة لجعل هذا واقعيًا هي التحدث بميزانية الأخطاء. مع هدف 99.5% شهريًا، يمكنك "إنفاق" حوالي 3.6 ساعة تعطل في شهر 30 يومًا. مع 99.9%، تحصل فقط على حوالي 43 دقيقة. هذا الفرق يغير عدد المرات التي ستوقف فيها عمل الميزات لإصلاح الموثوقية.

كما يساعد مطابقة التوقعات مع أوقات استخدام الأداة فعلاً. هدف 24/7 مكلف إذا كانت الأداة حرجة فقط من 9 صباحًا إلى 6 مساءً. يمكنك وضع SLO واحد لساعات العمل (أكثر صرامة) وآخر أقل صرامة خارج الساعات (حتى ينام الفريق بسلام).

الصيانة المخططة لا يجب أن تُحتسب كفشل طالما أنها مُعلَنة ومحددة. تعامل معها كاستثناء صريح (نافذة صيانة) بدلًا من تجاهل التنبيهات بعد الواقعة.

اكتب الأساسيات ليطلع الجميع على المقايضات:

رقم SLO وما يخسره المستخدم عند فشله
ميزانية الأخطاء للشهر (بالدقائق أو الساعات)
قواعد التنبيه (من، متى، ولماذا)
توقعات ساعات العمل مقابل 24/7 إذا كانت مختلفة
ما الذي يعتبر صيانة مخططة

بعد 4 إلى 6 أسابيع من البيانات الحقيقية، راجع الهدف. إذا لم تنفق ميزانية الأخطاء أبدًا، فقد يكون SLO فضفاضًا جدًا. إذا أُنفِق بسرعة وتوقفت الميزات، فغالبًا هو صارم جدًا.

ربط SLOs بالتنبيهات التي يمكن لفريقك الحفاظ عليها

التنبيهات ليست SLOs. التنبيهات هي إشارة "شيء خاطئ يحدث الآن" التي تحمي SLO. قاعدة بسيطة: لكل SLO، أنشئ تنبيهًا واحدًا ذو مغزى، وامتنع عن إضافة المزيد إلا إذا أثبتت أنها تقلل وقت التوقف.

نهج عملي هو التنبيه على استهلاك سريع لميزانية الأخطاء (كم بسرعة تنفقها) أو على عتبة واضحة واحدة تطابق ألم المستخدم. إذا كان SLO الكموني هو "p95 أقل من 800 مللي ثانية"، لا تُوقِظ أحدًا عند كل قفزة بطيئة. أطلق الإنذار فقط عندما يكون مستمرًا.

تقسيم بسيط يحافظ على ضوضاء منخفضة:

صفحة عاجلة: الأداة مكسورة فعليًا، ويجب أن يتصرف أحد الآن.
تذكرة غير عاجلة: شيء يتدهور، لكن يمكن انتظاره حتى ساعات العمل.

عوائد عتبات ملموسة (عدلها حسب حركة المرور): إذا كان SLO التوافر 99.5% شهريًا، أطلق صفحة عندما ينخفض التوافر عن 99% لمدة 10 دقائق (انقطاع واضح). أنشئ تذكرة عندما ينخفض عن 99.4% على مدار 6 ساعات (حرق بطيء). بالنسبة للكمون، أطلق صفحة عندما يكون p95 فوق 1.5 ثانية لمدة 15 دقيقة؛ واذكر تذكرة عندما يكون p95 فوق 1.0 ثانية لمدة ساعتين.

اجعل الملكية صريحة. قرر من هو المناوب (حتى لو كان "شخص واحد هذا الأسبوع"), ماذا يعني الإقرار (مثلاً خلال 10 دقائق)، وما هو الإجراء الأول. لفريق صغير يدير تطبيقًا داخليًا مبنيًا على AppMaster، قد يكون الإجراء الأول: تفقد النشرات الأخيرة، راجع أخطاء API، ثم الرجوع إلى الإصدار السابق أو إعادة النشر إذا لزم الأمر.

بعد كل تنبيه حقيقي، قم بمتابعة صغيرة: أصلح السبب أو ضبط التنبيه حتى يوقظ أقل لكن لا يزال يلتقط تأثير المستخدم الحقيقي.

أخطاء شائعة تخلق إجهاد التنبيهات

Make reliability measurable

Model your data in PostgreSQL and generate a Go backend you can monitor confidently.

Build Backend

إجهاد التنبيهات عادةً يبدأ بحسن نية. فريق صغير يضيف "تنبيهات قليلة"، ثم واحدة كل أسبوع. قريبًا، يتوقف الناس عن الثقة بالإشعارات وتُفوّت الانقطاعات الحقيقية.

فخ كبير هو التنبيه عند كل قفزة. الأدوات الداخلية غالبًا ما تكون لديها حركة متقطعة (تشغيل الرواتب، تقارير نهاية الشهر). إذا نادى التنبيه على وميض لمدة دقيقتين، سيتعلم الفريق تجاهله. اربط التنبيهات بإشارات تأثير المستخدم، لا بضوضاء المقاييس الخام.

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

الأخطاء التي تولد معظم الضوضاء:

التنبيه على الأعراض (CPU، الذاكرة) بدلًا من تأثير المستخدم (أخطاء، كمون)
لا مالك للتنبيه، فيظل بلا تعديل أو إزالة
لا دليل إجراءات (runbook)، فتتحول كل تنبيه إلى لعبة تخمين
الاعتماد على لوحات المعلومات كبديل للتنبيهات (اللوحات للتشخيص، التنبيهات للفعل)
اختراع عتبات لأن النظام غير مُؤشر جيدًا

لوحات المعلومات لا تزال مهمة، لكنها يجب أن تساعد على التشخيص بعد إطلاق التنبيه، لا أن تحل محله.

إذا لم تكن لديك قياسات نظيفة بعد، لا تتظاهر بأن لديك. أضف أدوات قياس أساسية أولًا (نسبة النجاح، p95 للكمون، و"هل يمكن للمستخدم إكمال المهمة"), ثم ضع العتبات بناءً على أسبوع أو أسبوعين من البيانات الحقيقية.

فحوص سريعة قبل تفعيل التنبيهات

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

قائمة تحقق عملية لفريق صغير:

أكد 1 إلى 3 إجراءات مستخدم رئيسية (مثال: فتح اللوحة، حفظ تحديث تذكرة، تصدير تقرير).
احتفظ بـ 2 إلى 4 SLIs يمكنك قياسها اليوم (التوفر/نسبة النجاح، p95 للكمون، معدل الأخطاء للنقطة الحرجة).
قصر التنبيهات على 2 إلى 4 فقط للأداة.
اتفق على نافذة القياس، بما في ذلك ما الذي يعنيه "سيء" (آخر 5 دقائق للكشف السريع، أو آخر 30 إلى 60 دقيقة لتقليل الضوضاء).
عيّن مالكًا (شخص واحد، ليس "الفريق").

بعد ذلك، تأكد من أن التنبيه قابل للفعل فعليًا. التنبيه الذي ينطلق عندما لا يتوفر أحد يدرب الناس على تجاهله.

قرر هذه التفاصيل التشغيلية قبل أول صفحة:

ساعات التنبيه: فقط ساعات العمل، أم 24/7 حقيقيًا
مسار التصعيد: من التالي إذا لم يرد الأول
ماذا تفعل أولًا: خطوتان لتأكيد التأثير والتراجع أو التخفيف
عادة مراجعة شهرية بسيطة: 15 دقيقة للنظر في التنبيهات التي انطلقت، الحوادث المفقودة، وهل لا يزال SLO مناسبًا

إذا بنيت أو غيرت الأداة (بما في ذلك في AppMaster)، أعد تشغيل قائمة التحقق. قد تغير الكود المُعاد توليده والتدفقات الجديدة الكمون وأنماط الأخطاء، ويجب أن تواكب التنبيهات ذلك.

مثال: لوحة عمليات صغيرة مع SLOs اثنين و3 تنبيهات

Start small, improve weekly

Prototype the tool first, then tighten SLOs once you have real usage data.

Start Prototype

فريق عمليات مكون من 18 شخصًا يستخدم لوحة داخلية طوال اليوم للتحقق من حالة الطلب، إعادة إرسال الإشعارات الفاشلة، والموافقة على الاستردادات. إذا تعطلت أو كانت بطيئة، يتوقف العمل بسرعة.

اختاروا SLOs اثنين:

SLO التوافر: 99.9% تحميل صفحات ناجح خلال 30 يومًا (حوالي 43 دقيقة "وقت سيء" شهريًا)
SLO الكمون: p95 لوقت تحميل الصفحة أقل من 1.5 ثانية خلال ساعات العمل

الآن أضافوا ثلاث تنبيهات يمكن لفريق صغير التعامل معها:

تنبيه الانقطاع التام (فشل تحميل الصفحات): ينطلق إذا انخفضت نسبة النجاح إلى أقل من 98% لمدة 5 دقائق. الإجراء الأول: تحقق من النشر الأخير، أعد تشغيل التطبيق، تأكد من صحة قاعدة البيانات.
تنبيه لوحة البطء: ينطلق إذا كان p95 للكمون فوق 2.5 ثانية لمدة 10 دقائق. الإجراء الأول: ابحث عن استعلام واحد بطيء أو مهمة خلفية معلقة، ثم أوقف مؤقتًا التقارير الثقيلة.
تنبيه استهلاك ميزانية الأخطاء: ينطلق إذا كانوا على المسار لاستهلاك 50% من ميزانية الأخطاء الشهرية في الأيام السبعة القادمة. الإجراء الأول: أوقف التغييرات غير الأساسية حتى تستقر الأمور.

ما يهم هو ما يحدث الأسبوع القادم. إذا انطلق تنبيه ميزانية الأخطاء مرتين، يتخذ الفريق قرارًا واضحًا: تأجيل ميزة جديدة وقضاء يومين في إصلاح أكبر سبب للكمون (مثلاً، فحص جدول بدون فهرس). إذا بنوا الأداة في AppMaster، يمكنهم تعديل نموذج البيانات، إعادة التوليد، وإعادة النشر بكود نظيف بدلًا من تكديس إصلاحات سريعة.

كيف تحافظ على SLOs حية دون تحويلها لمشروع كبير

Automate the noisy steps

Use visual business processes to reduce manual work and cut the alerts that waste time.

Automate Now

SLOs تفيد فقط إذا ظلت مرتبطة بالعمل الحقيقي. الحيلة هي معاملتها كعادة صغيرة، لا كمشروع جديد.

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

عملية خفيفة الوزن تتحمل:

أسبوعيًا (10 دقائق): افحص مخطط SLO وآخر التنبيهات، ثم أكد أن لا شيء يزداد سوءًا بصمت.
بعد أي حادث (15 دقيقة): ضع علامة على السبب واذكر أي فعل مستخدم تأثر (تسجيل الدخول، البحث، الحفظ، التصدير).
شهريًا (30 دقيقة): راجع نمط الحادث المتكرر واختر إصلاحًا واحدًا للشهر القادم.
شهريًا (10 دقائق): أزل أو اضبط تنبيهًا واحدًا يسبب ضوضاء.

اجعل التحسينات صغيرة ومرئية. إذا ظهر "بطء تحميل الصفحة كل صباح اثنين" ثلاث مرات، قم بتغيير محدد (تخزين مؤقت لتقرير واحد، إضافة فهرس، جدولة مهمة ثقيلة لاحقًا)، ثم راقب SLI الأسبوع التالي.

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

احتفظ بالتوثيق بسيطًا: صفحة واحدة لكل أداة. تضمّن إجراءات المستخدم الرئيسية، أرقام SLO، التنبيهات المرتبطة بها، والمالك. إذا بنيت الأداة على AppMaster، أضف مكان عرض السجلات/المقاييس ومن يمكنه نشر التغييرات، ثم اكتفِ بذلك.

الخطوات التالية: ابدأ صغيرًا، ثم حسّن أداة واحدة في كل مرة

أسهل طريقة لجعل الموثوقية حقيقية هي إبقاء الإعداد الأولي صغيرًا. اختر أداة داخلية تسبب ألمًا حقيقيًا عند تعطلها (تسليم المناوبات، الموافقات، الاستردادات، تعديلات المخزون)، وضع أهدافًا حول القليل من الإجراءات التي يقوم بها الناس يوميًا.

أصغر إعداد عملي يمكن للفرق نسخه:

اختر أداة واحدة و2 إجراء مستخدم رئيسي (مثال: فتح اللوحة وإرسال موافقة).
حدّد 2 SLI يمكنك قياسهما الآن: توافر النقطة/الصفحة، وp95 للكمون للفعل.
ضع 2 SLO بسيطة (مثال: 99.5% توفر شهريًا، p95 أقل من 800 مللي ثانية خلال ساعات العمل).
أنشئ 2 إلى 3 تنبيهات إجمالًا: واحدة للانقطاع التام، واحدة للكمون المستمر، وواحدة لاستهلاك سريع لميزانية الأخطاء.
راجع مرة في الأسبوع لمدة 10 دقائق: هل ساعدت التنبيهات أم كانت مجرد ضوضاء؟

بمجرد استقرار ذلك، وسّع ببطء: أضف إجراء واحد آخر، أو أداة واحدة إضافية في الشهر. إذا لم تستطع تسمية من سيتولى ملكية التنبيه، فلا تنشئه بعد.

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

جرّب بناء أداة داخلية واحدة وإضافة SLOs أساسية من اليوم الأول. ستحصل على توقعات أوضح، مفاجآت أقل، وتنبيهات يستطيع فريقك الصغير مواكبتها.

الأسئلة الشائعة

SLOs تحول عبارة "مستقر إلى حد ما" إلى هدف واضح يمكن قياسه. حتى مع 20 مستخدمًا، يمكن أن يسبب توقف الأداة توقف الطلبات أو تباطؤ الدعم أو منع الموافقات، لذا الأدوات الصغيرة قد يكون لها تأثير كبير.

اختر بعض مسارات المستخدم التي يقوم بها الناس يوميًا وتعرقل العمل عند فشلها. بدايات شائعة: تسجيل الدخول، تحميل لوحة القيادة الرئيسية ببيانات حديثة، البحث/الفلترة، وإرسال نموذج إنشاء/تحديث بنجاح.

SLI هو المقياس الذي تقيسه (مثل نسبة النجاح أو p95 للكمون). SLO هو الهدف لذلك المقياس (مثل 99.5% نجاح على مدى 30 يومًا). SLA هو وعد رسمي مع عواقب، ومعظم الأدوات الداخلية لا تحتاجه.

SLO قابل للتحقيق بدون بطولات. بداية جيدة لكثير من الأدوات الداخلية هي 99.5% شهريًا، لأنها قابلة للتحقيق دون عمل مستمر بعد ساعات. إذا كانت الأداة حرجة فعلاً أثناء ساعات العمل يمكن تشديد الهدف لاحقًا بعد جمع بيانات حقيقية.

حوّل نسبة التوافر إلى وقت حتى يفهم الجميع المقايضة. في شهر 30 يومًا، 99.5% تسمح بحوالي 216 دقيقة من التوقف، بينما 99.9% تسمح بحوالي 43 دقيقة — وهذا غالبًا يعني مزيدًا من التنبيهات والعمل على الموثوقية.

استخدم مئوية مثل p95 وليس المتوسط، لأن المتوسط يخفي اللحظات البطيئة التي يتذكرها المستخدمون. ضع الهدف على فعل حقيقي (مثلاً «p95 تحميل لوحة القيادة أقل من 2s أثناء ساعات العمل») واختر حدًا يمكنك الحفاظ عليه بهدوء.

ابدأ بمقاييس الخادم والسجلات الموجودة: التوفر (هل الأداة قابلة للوصول وتستجيب)، نسبة النجاح للإجراءات الرئيسية، وp95 للكمون لنقطة نهاية أو شاشة حرجة واحدة أو اثنتين. أضف اختبارات اصطناعية فقط للعمليات الأكثر أهمية للحفاظ على اتساق القياس وبساطته.

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

غالبًا ما تبدأ حالة الإرهاق التنبيهي بحسن نية: إضافة تنبيهات "قليلة" ثم واحدة أخرى كل أسبوع. تجنب التنبيه عن كل قفزة أو التنبيه على أعراض (CPU، الذاكرة) بدلًا من تأثير المستخدم (الأخطاء والكمون). قلل التنبيهات، أعطِ كل واحدة مالكًا، وبعد كل تنبيه حقيقي أصلح السبب أو ضبط التنبيه.

اختر الإجراءات الرئيسية في تطبيقك، ثم قِس التوافر، نسبة النجاح، وp95 للكمون لتلك الإجراءات باستخدام مصدر واحد موثوق. إذا بنيت الأدوات الداخلية في AppMaster، ركز الأهداف على ما يفعله المستخدمون (login, save, search)، واضبط القياسات والتنبيهات بعد تغييرات كبيرة أو إعادة توليد حتى تطابق السلوك الحالي.