Avito تكشف كيف تحتسب الموثوقية وبماذا تختلف ميزانية الأخطاء لديها عن Google

شرحت إحدى أكبر المنصات الروسية على الإنترنت علنًا كيف تحوّل «الموثوقية» من شعار إلى أرقام. فقد استعرض إيفان تاراسوف، TUL Architecture Governance في المنصة التقنية لدى Avito، على موقع Habr السلسلة كاملة: من SLI وSLO وSLA وصولًا إلى المتطلبات غير الوظيفية (NFR) لخدمات REST/RPC وقنوات البيانات والعمليات المخصصة. وتركز المادة بصورة خاصة على أن ميزانية الأخطاء في Avito تختلف عن الوصف المعتمد في كتاب Google SRE. وبحسب المؤلف، فهذا قرار متعمد.

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

ما الذي تتضمنه المنظومة

يقود تاراسوف عدة فرق، إحداها فريق SLA الذي يهيئ الظروف لرفع الموثوقية التقنية ويطوّر أدوات NFR وسيناريوهات الاستقرار. ويتضح من الإعلان أن المنظومة تضم العناصر التالية:

• SLI وSLO وSLA كتسلسل هرمي أساسي: ما الذي نقيسه، وأي هدف نضعه، وما الذي نتعهد به.
• Stability Rate وUptime كمقياسين مختلفين، يخصص المؤلف جزءًا مستقلًا لشرح الفرق بينهما.
• NFR لخدمات REST/RPC، أي متطلبات التفاعل المتزامن.
• NFR لقنوات البيانات، حيث تُقاس الموثوقية بطريقة تختلف عن قياسها في الطلب الذي يتبعه رد.
• NFR للعمليات المخصصة التي لا تتلاءم مع القوالب القياسية.
• ميزانية أخطاء تختلف عمدًا عن نسخة Google SRE.

تُبرز هذه القائمة الخلاصة الأهم: Avito لا تكتفي برقم واحد من «التسعات» لكل خدمة. فكل نوع من الواجهات يحصل على طريقة قياس مختلفة.

لماذا لم تعتمد Avito نهج Google كما هو

في كتاب Google SRE تساوي ميزانية الأخطاء واحدًا ناقص SLO. فعند هدف 99,9% خلال 30 يومًا يعادل ذلك نحو 43 دقيقة من انقطاع الخدمة المسموح به. وما دامت الميزانية لم تُستنفد، يطرح الفريق الإصدارات بحرية. وحين تنفد، تنتقل الأولوية إلى تحقيق الاستقرار. الآلية بسيطة، وهي تنهي الجدل الدائم بين التطوير والتشغيل.

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

Stability Rate مقابل Uptime

يُظهر Uptime تقليديًا نسبة الوقت الذي عُدّت فيه الخدمة متاحة. هذا المقياس مناسب لإعداد التقارير، لكنه فظّ: فقد تستجيب الخدمة وتُرجع في الوقت نفسه أخطاء لجزء من المستخدمين. أما اسم Stability Rate فيشير إلى التقييم بحسب نتائج العمليات، لا بحسب التقويم. وتورد Avito التعريف الدقيق في المقال، لكن مجرد الفصل بين المقياسين يدل على نهج ناضج. فدقائق التوقف ونسبة العمليات الفاشلة تصفان أمرين مختلفين، وتتوقف ميزانية الأخطاء على أيهما نتخذه أساسًا.

كيف تطبّق ذلك في شركتك

حتى من دون تفاصيل التنفيذ، يمكن استخلاص عدة نتائج عملية من المنشور:

• افصلوا بين أنواع الواجهات. تحتاج الاستدعاءات المتزامنة وقنوات البيانات والعمليات الخلفية إلى SLI مختلفة. القالب الموحد يعطي لوحة مؤشرات جميلة وصورة سيئة للواقع.
• لا تخلطوا بين الإتاحة والنجاح. إذا اكتفى الفريق بالإبلاغ عن Uptime فقط، فسيبقى جزء من حالات التدهور غير مرئي.
• دوّنوا الانحرافات عن النهج المعتمد كتابةً. إذا غيّرتم نموذج ميزانية الأخطاء، فسجّلوا الأسباب والقيود، وإلا فلن يتذكر أحد بعد عام سبب ما جرى.
• اربطوا NFR بالعملية المعمارية. تتولى Avito ذلك ضمن Architecture Governance. فالمتطلبات التي تُراجع في مرحلة التصميم أقل كلفة من الإصلاحات بعد وقوع الحادثة.

يستحق المقال الأصلي على Habr القراءة لمن يبني ممارسات SRE في نظام موزّع كبير، فمثال Avito لافت تحديدًا لأن الشركة تشرح علنًا أين ابتعدت عن المخطط المتعارف عليه ولماذا.