تقارير الأعطال: ما الذي يستحق تنبيهًا وما لا

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

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

ما الذي يستحق تنبيهًا فوريًا؟

أربع حالات فقط، وما عداها يُقرأ لا يُوقظ.

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

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

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

ما الذي لا يستحق تنبيهًا؟

خمس فئات تُشكّل أغلب الضجيج في تقارير الأعطال.

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

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

كم تكلّف الأعطال فعلًا؟

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

نسبة المستخدمين المتأثرين. عطل يصيب 0.5% من المستخدمين في تطبيق له 20,000 مستخدم شهريًا يعني 100 شخص، وهو رقم يستحق أسبوعًا من العمل. النسبة وحدها تخفي الحجم، والعدد المطلق وحده يخفي الخطورة.

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

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

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

ماذا تحتاج في التقرير ليكون قابلًا للإصلاح؟

أربعة أشياء، وغياب الأول يُلغي الباقي.

الرموز (Symbols). بدونها يصل التقرير كعناوين ذاكرة لا تعني شيئًا. رفعها آليًا مع كل بناء في خط التكامل المستمر هو الحل، لا يدويًا عند الحاجة.

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

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

رقم البناء الدقيق. يجب أن يعيدك إلى التزام محدد في المستودع في ثوانٍ. ربط رقم البناء برقم تشغيل التكامل المستمر يحقق ذلك.

التجميع: حين يخدعك الترتيب

الأدوات تجمّع الأعطال المتشابهة تلقائيًا، والتجميع الآلي يخطئ في اتجاهين.

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

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

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

عملية أسبوعية تكفي

فريق صغير لا يحتاج نظام مناوبة، بل نصف ساعة منتظمة.

1. رتّب بعدد المستخدمين المتأثرين في آخر سبعة أيام.
2. صنّف أعلى خمسة: إصدار النظام، والجهاز، وجديد أم قديم، ومستخدم جديد أم قائم.
3. افتح عيّنتين من كل واحد للتحقق من صحة التجميع.
4. قرّر لكل واحد: أصلح الآن، أو أجّل، أو تجاهل عمدًا. والخيار الثالث قرار مشروع يجب تسجيله لا تركه معلّقًا.
5. راجع ما قرّرت تجاهله كل شهر، فبعضه يكبر.

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

الخطوة الرابعة هي التي تحوّل القائمة من عبء إلى أداة. قائمة فيها مئتا عطل «مفتوح» لا يقرأها أحد؛ قائمة فيها خمسة مفتوحة والباقي مغلق بقرار واضح تُقرأ كل أسبوع.

أعطال لا تظهر أصلًا

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

التجمّد. التطبيق حي ولا يستجيب، فيغلقه المستخدم قسرًا. لا يُسجَّل عطلًا، وهو أسوأ من العطل عند المستخدم لأن العطل على الأقل يعيد التشغيل.

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

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

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

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

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

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

مزيد في أدوات المطوّر والموبايل والبرمجة. ووثائق تشخيص الأعطال من آبل تشرح قراءة التقارير من جهة النظام.

الخلاصة

تقارير الأعطال تفيد حين تُصفّى: نبّه على ما يتغيّر — عطل جديد مع إصدار، أو قفزة مفاجئة، أو عطل عند الإقلاع، أو عطل في مسار الدفع — واقرأ الباقي أسبوعيًا.

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