قِس الموثوقية عند رحلة المستخدم لا عند الخادم

قد تعرض الخدمة Uptime بنسبة 99.99% بينما يفشل العملاء مرارًا في إكمال الفعل الذي يصنع القيمة. استجابت API، وعملت Queue، وبقيت قاعدة البيانات متاحة، لكن تأكيد الدفع لم يظهر، أو أنشأ Retry سجلًا مكررًا، أو وصلت النتيجة بعد أن فقدت فائدتها. صحة البنية التحتية ضرورية، لكنها ليست نتيجة المنتج.

تحتاج Product Engineering إلى حد للموثوقية يتبع نية المستخدم عبر الواجهة والنظام الخلفي. يحقق SLO لرحلة المستخدم ذلك؛ فهو يحدد المحاولات التي تُحتسب، ومعنى النتيجة الجيدة، والزمن المقبول، ومقدار الفشل الذي يمكن للمنتج تحمله قبل أن تتغير سياسة الإطلاق.

يفصل تعريف Google للـSLO بين مؤشر القياس SLI والهدف SLO. والخطوة المفيدة للمنتج هي تطبيق هذا الفصل على رحلة مثل إنشاء طلب، أو إطلاق حملة، أو استيراد ملف، أو الحصول على إجابة AI؛ لا على Endpoint منفردة فقط.

اختر رحلة واحدة بنتيجة يمكن التحقق منها

ابدأ برحلة ذات قيمة، ومتكررة بما يكفي للقياس، ويملك الفريق القدرة على تغييرها. عبارة «التطبيق يعمل» ليست رحلة. أما «يرسل التاجر حملة صالحة ويراها مجدولة مرة واحدة خلال 30 ثانية» فهي رحلة قابلة للتعريف.

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

في Checkout مثلًا، قد تبدأ المحاولة الصالحة عندما يقبل الخادم أمر الدفع مع Idempotency Key ثابت. وقد يتطلب النجاح معرف طلب، وحالة دفع مخزنة، وتأكيدًا ظاهرًا للعميل. رفض البطاقة ليس عدم توفر للمنصة إذا شرحه النظام وأتاح التعافي؛ أما Timeout بلا تفسير فهو فشل.

لا تبدأ بكل الرحلات. اختر رحلة يغيّر فشلها الإيراد أو الثقة أو حمل الدعم، وثبّت العقد، ثم أعد استخدام المنهج.

عرّف SLI من المحاولات الصالحة والنتائج الجيدة

أبسط مؤشر لتوفر الرحلة هو نسبة:

journey_availability = good_terminal_outcomes / valid_journey_attempts

good = completed exactly once
       AND result is visible
       AND correctness checks pass
       AND duration <= promised threshold

المقام قرار منتج. استبعد Synthetic Probes واختبارات الضغط والطلبات المرفوضة قبل أن يقبل المنتج المسؤولية عنها. لا تستبعد فشلًا حقيقيًا لأنه يزعج الأرقام. خزّن سبب كل استبعاد وراجع حجمه؛ قد يخفي تضخم فئة «غير صالح» شرطًا مسبقًا معطوبًا أو تكامل عميل مكسورًا.

استخدم Buckets لا المتوسطات في الزمن. يستخدم مثال SLO من Google نسب الطلبات الواقعة تحت حدود زمنية صريحة. ويمكن لرحلة المنتج مثلًا أن تشترط 95% تحت 3 ثوانٍ و99.5% تحت 10 ثوانٍ. قد يخفي متوسط 1.8 ثانية Tail مؤلمة تؤثر في شريحة مهمة.

أدخل صحة النتيجة في المؤشر. إنشاء الطلب مرة واحدة، واكتمال صفوف Import، وصحة Entitlement، ووجود مصادر في إجابة AI هي Predicates مختلفة. إذا تعذر فحص الصحة، فقد عرّف الفريق حدث إكمال لا نتيجة موثوقة.

اربط المتصفح والخلفية بهوية رحلة واحدة

أنشئ journey_id عندما يقبل المنتج المحاولة، ومرره عبر حدث المتصفح وأمر API ورسالة Queue وكتابة قاعدة البيانات والرد النهائي. افصله عن trace_id؛ فقد تمتد الرحلة عبر Retries وJobs غير متزامنة وأكثر من Trace.

تصف OpenTelemetry Traces مسار الطلب عبر مكونات التطبيق، بينما تتيح Context Propagation ربط الإشارات المولدة من خدمات موزعة. أضف Attributes قليلة التعدد مثل journey_name وrelease_version وresult_class وtenant_tier. أبعد معرفات العميل والمدخلات الحرة عن Metric Labels وBaggage؛ واستخدم مراجع مضبوطة داخل Logs محمية عندما يحتاج التحقيق إليها.

أصدر انتقالات الحالة بدل Counter نجاح واحد: accepted وprocessing وwaiting_on_dependency وcompleted وrejected_expected وfailed_system وexpired. أضف occurred_at وتسلسلًا أحادي الاتجاه أو Version. يجب أن يعد Projector النهائي الرحلة مرة واحدة حتى عندما تكرر Retries الأحداث.

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

ضع زمن التجربة بجانب زمن النظام

يجيب Backend Duration عن مدة عمل الخادم. أما Journey Duration فيجيب عن مدة انتظار المستخدم للقيمة. قِس من قبول النية إلى النتيجة المتحققة، وقسّم الانتظار إلى عمل الخادم وتأخير Queue وزمن Dependency وتأخير العرض.

للرحلات على الويب، تقدم Core Web Vitals إشارات معيارية للتجربة: LCP للتحميل، وINP للاستجابة، وCLS للاستقرار البصري. لكنها ليست بديلًا عن SLO للرحلة. اربطها بإصدار الواجهة وعائلة الصفحة والرحلة، لا بهوية المستخدم الخام، حتى يمكن التحقيق في تراجع التحويل بجانب الأداء الميداني.

استخدم التوزيعات وقسّم البيانات بمسؤولية. قد تكشف فئة الجهاز أو الدولة أو Tenant Tier فشلًا مركزًا تخفيه النسبة العامة. لا تحوّل كل Dimension إلى Label دائم؛ فـHigh Cardinality ترفع الكلفة والمخاطر التشغيلية. احتفظ بالأبعاد العامة في Metrics، وحقق في التفاصيل داخل Traces أو المستودع.

يعرض دليل web.dev عن دمج Web Vitals مع GA4 وBigQuery مثالًا مفيدًا للاستعلام عن الأداء الميداني بجانب أبعاد العمل. يبدأ Correlation تحقيقًا، لكنه لا يثبت أن الزمن سبب النتيجة التجارية.

حوّل الهدف إلى Error Budget

يصبح SLO بلا نتيجة عملية مجرد زينة في Dashboard. إذا كان الهدف 99.5% خلال 28 يومًا، فـ0.5% المتبقية هي Error Budget. تنفقها كل محاولة صالحة سيئة. تابع الميزانية المتبقية وBurn Rate، لا نسبة النجاح الحالية وحدها.

يتعامل Google SRE Workbook مع SLO كأساس لقرارات موثوقية مبنية على البيانات. ويركز دليل التنبيه على استهلاك الميزانية المهم بدل كل خطأ عابر. استخدم نافذة Fast Burn للتراجع المفاجئ ونافذة Slow Burn للتدهور التدريجي.

اكتب السياسة قبل التجاوز. عندما تكون الميزانية سليمة، يمكن للفريق توسيع Rollout. وعندما يتسارع الاستهلاك، أوقف زيادة Cohort وافحص الرحلة المتضررة. وعندما تنفد الميزانية، أوقف التغييرات الخطرة غير المرتبطة، واستعد الموثوقية، واطلب دليلًا قبل الاستئناف. يقدم مثال سياسة Error Budget السياسة كوسيلة لحماية المستخدم وإعادة موازنة العمل، لا لمعاقبة الفريق.

اجعل الاستثناءات صريحة: إصلاح أمني، أو Incident على مستوى Dependency، أو فئة اختبار مستبعدة، أو خلل قياس تم إثباته. يحتاج الاستثناء إلى مالك ودليل وتاريخ انتهاء.

اجعل بوابة الإصدار تعتمد على نتيجة المستخدم

أرفق release_version وflag_variant وrollout_cohort بسجل الرحلة. ابدأ بحركة داخلية أو Cohort صغيرة من العملاء. قارن الإصدار الجديد بخط أساس مستقر في توفر الرحلة وTail Duration والنتائج المكررة ومعدل التعافي وإشارات الدعم.

لا ترقِّ الإصدار لأن «لا تنبيهات موجودة». اطلب حدًا أدنى من المحاولات الصالحة وزمن مراقبة يغطي الإكمال غير المتزامن. ثلاث عمليات Checkout ناجحة لا تثبت الكثير. للرحلات قليلة الحجم، ادمج دليل الإنتاج مع Contract Tests حتمية وFixtures معاد تشغيلها ومراقبة أطول.

لا تؤتمت إلا القرارات التي يدعمها Metric. يمكن لتجاوز Fast Burn واضح أن يسبب Rollback أو إيقاف التوسيع. أما فرق صغير غامض فيحتاج مراجعة، لا تحريك Traffic ذهابًا وإيابًا. أضف Cooldown بعد التراجع، وتأكد أن الإصدار السابق وSchema وQueue Consumers ما زالت متوافقة.

سجّل القرار: التعرض قبل وبعد، وحالة SLO، ونافذة الدليل، والمنفذ، والسبب. يحوّل هذا التاريخ أتمتة الإصدار إلى نظام منتج قابل للمراجعة.

صمّم التنبيه حول ضرر العميل

أيقظ المهندس عندما تستهلك رحلة حرجة الميزانية بسرعة ويمكن لفعل مباشر تقليل الضرر. أنشئ Ticket أو مراجعة يومية للـSlow Burn وتضخم الاستبعادات وتأخر Jobs غير المتزامنة وتراجع شريحة ضيقة. احتفظ بتنبيهات البنية التشخيصية، لكن تعامل معها كدليل مساعد ما لم تهدد رحلة أو حدًا صلبًا مشتركًا.

يجب أن يحتوي التنبيه اسم الرحلة وCohort المتضررة وإصدار النشر ونوافذ Burn والتغييرات الأخيرة وروابط Traces مأخوذة من النتائج السيئة. لا تجبر المستجيب على استخراج أثر المنتج من رسوم CPU.

احذر فشل Telemetry الصامت. راقب النسبة بين الأوامر المقبولة وبدايات الرحلات الصادرة والأحداث النهائية. SLO مثالية مع مقام ينهار ليست موثوقية، بل قياس مفقود.

راجع العقد بين Product وDesign وEngineering

يحدد Product النتيجة الموعودة والفشل المقبول. ويحدد Design شكل النجاح والتعافي للعميل. ويحدد Engineering الحالة الدائمة وPredicates الصحة والقياس. وتضيف Operations قابلية التنبيه والسعة والاستجابة للحوادث. وقد يحدد Finance أو Compliance متطلبات المصالحة والدليل.

راجع SLO عندما تتغير الرحلة أو الجمهور أو الوعد، لا كلما جعل أسبوع سيئ الهدف غير مريح. احتفظ بالتعريف السابق قابلًا للاستعلام حتى لا يختلط تغير Trend بتغير العقد.

يجب أن تسأل كل مراجعة: هل يُستبعد عملاء صالحون؟ هل يمكن أن يحدث النجاح بلا قيمة؟ هل يمكن عد المحاولة مرتين؟ هل يطابق الحد وعد العميل؟ هل يستطيع الفريق التصرف عند التجاوز؟ وهل Telemetry نفسها قابلة للمراقبة؟

تسلسل عملي للتنفيذ

أولًا، سمِّ رحلة حرجة وارسم حالتي القبول والنهاية. ثانيًا، عرّف المحاولات الصالحة والنتائج الجيدة والرفض المتوقع والانتهاء. ثالثًا، أضف journey_id وأحداث حالة Idempotent عبر الواجهة والخلفية. رابعًا، ابنِ Query للـSLI وقارنه بعينات فُحصت يدويًا. خامسًا، اختر هدفًا أوليًا من الأداء الحقيقي وتوقعات المنتج، ثم اكتب سياسة Error Budget. سادسًا، اربط SLO بإطلاق مرحلي من دون تمكين Rollback تلقائي حتى تفهم False Positives وتأخر البيانات.

شغّل فترة Shadow. صالح العد النهائي مع سجلات العمل الرسمية. خذ عينات من الرحلات الجيدة والسيئة إلى Traces. اختبر فقدان Telemetry والأحداث المكررة والـJobs المتأخرة وتوافق التراجع. وانشر التعريف بجانب Dashboard حتى لا يضطر أحد لتخمين معنى «موثوق بنسبة 99.5%».

قرار Product Engineering

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

يجعل SLO رحلة المستخدم هذا الوعد قابلًا للتنفيذ. يمنح Design حدًا للتعافي، وEngineering عقد قياس، وProduct ميزانية مخاطر، وOperations إشارة مرتبطة بضرر العميل. وعندما يتحكم العقد نفسه في Rollout، تتوقف الموثوقية عن كونها تقريرًا بعد الإطلاق وتصبح جزءًا من طريقة بناء المنتج.

إعداد: Noor Yasser