الكشف عن المجهول غير المعروف

تتمتع Meta بمنظومة منتجات متكاملة يستخدمها المليارات من المستخدمين يوميًا، إما للتواصل الاجتماعي أو لتفاعل الأنشطة التجارية. كما يطلب منا هؤلاء المستخدمين الذين تتجاوز أعدادهم المليارات أن نعمل على إدخال وظائف وتحسينات جديدة في منتجاتنا باستمرار وبوتيرة متسارعة. ونظرًا لحجم قاعدة المستخدمين الكبير، فإننا نقدم آلاف التغييرات في الرموز البرمجية كل يوم لتلبية تلك التوقعات.

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

وبينما تتواجد هذه الآليات لتقييم جودة تغييرات الرمز البرمجي قبل دخوله في الإنتاج - وبالتالي تجنب التأثير على المستخدم - فمن الممكن أن تدخل التغييرات التي تؤثر على المستخدم في الإنتاج ومن ثم تحتاج إلى إعادة صياغتها وإدخالها مرة أخرى. من أجل التخفيف من احتمالية حدوث مشكلة تؤثر على عدد كبير من الأشخاص، نستخدم آليات مختلفة لإصدار تغييرات تزايدية للجمهور.

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

لضمان أننا نلبي احتياجات عملائنا ونقوم بذلك في أسرع وقت ممكن - أحيانًا في اليوم ذاته - استثمرت Meta استثمارًا كبيرًا في عدد من برامج وأنظمة الموثوقية لتمكين زيادة معدل الاستجابة على نطاق واسع.

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

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

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

في القسم التالي، سنناقش بالتفصيل كيفية إثبات حدوث التراجع، وكيفية الاستجابة بعد معرفة ذلك.

تحويل المجهول إلى معروف وتحديد كميته

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

• الاختبارات الاصطناعية للأداء السليم لتطبيقاتنا ومنتجاتنا المحددة داخل تلك التطبيقات.
• المستخدمون الداخليون الذين يختبرون بحثًا عن الأخطاء. يمكن أن يتضمن ذلك الفرق الاختبارية المختصة أو قاعدة المستخدمين الأوسع داخل Meta.
• المستخدمون الخارجيون الذين يتعرضون لمشاكل في استخدام مربع حوار تقرير المشكلة في التطبيقات.

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

• "مجهول معروف" - عندما يكتشف الرمز البرمجي المجهز التراجع ويبلغ عنه؛ ولدينا عدد من الأدوات التي تساعد على إنتاج هذه الإشارة
• "مجهول غير معروف" - عندما لا يتم التعرف على التراجع داخليًا، ونعتمد على المستخدم للإبلاغ بالفعل عن التراجع

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

إصدار الإشارات والرؤى

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

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

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

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

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

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

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

التوسع لواجهات المنتجات الأصغر

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

من أجل التوسع، هناك العديد من الشروط التي يجب تلبيتها:

1. يجب أن يكون لدينا تغطية دقيقة وتصنيف مناسب لواجهات المنتج الحالية
2. يجب علينا تقليل ظهور التراجع للمنتجات الحالية (اقرأ: الوقاية)
3. يجب علينا توسيع مدى وصول الخوارزميات إلى واجهات المنتجات الجديدة

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

التوسع لما بعد الأخطاء

مع استمرارنا في تقليل ظهور التراجع (دون أن نوقف إجراءات الحماية)، نزيد من تركيزنا في مجالات مهمة أخرى: الوقاية وسهولة الاستخدام.

الوقاية معنية بما يلي:

1. كيف نتعلم من التراجعات السابقة؟
2. ما أساليب الدفاع التي نطبقها بحيث لا تتكرر هذه التراجعات؟
3. كيف نضمن بمرور الوقت استمرار تناقص ظهور التراجع؟

كما تمت مناقشته من قبل، نقوم بتجميع البيانات من التراجعات السابقة للتعلم منها. قد تكون هذه المعرفة ما يلي:

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

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

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

في النهاية، ينتج عن ذلك تجربة مستخدم تتحسن باستمرار فيما يتعلق بأبعاد الوظائف وسهولة الاستخدام.

تمت كتابة هذا المقال بالتعاون مع بيجان مرجان، مدير البرنامج التقني في Meta.