گزارش خرابی: از استک‌تریس تا نسخهٔ مقصر
یک واقعیت ناخوشایند دربارهٔ اپلیکیشن موبایل: وقتی برنامه بسته می‌شود، کاربر به شما خبر نمی‌دهد. یک بار دیگر امتحان می‌کند، و اگر باز بسته شد، حذفش می‌کند و می‌رود. نظر یک‌ستاره را هم شاید بگذارد، شاید نگذارد.
یعنی بدون گزارش خرابی خودکار، شما از بیشتر خرابی‌های محصولتان هیچ‌وقت خبردار نمی‌شوید. نه اینکه دیر خبردار شوید؛ اصلاً نمی‌شوید.
این با مدیریت خطا فرق دارد
تفکیکی که زیاد قاطی می‌شود: مدیریت خطا دربارهٔ خطاهایی است که پیش‌بینی کرده‌اید — اتصال قطع شد، سرور ۵۰۰ داد، فایل نبود. کد شما می‌گیردشان و تصمیم می‌گیرد.
گزارش خرابی دربارهٔ آن‌هایی است که پیش‌بینی نکرده بودید. اشاره‌گر تهی، آرایه از محدوده بیرون، خطای بومی در یک کتابخانهٔ شخص ثالث. برنامه همان‌جا می‌میرد و تنها شانس شما این است که پیش از مردن، چیزی نوشته باشد.
استک‌تریس خام، بی‌فایده است
اینجا اولین جایی است که تیم‌ها گیر می‌کنند. بستهٔ اندرویدی که منتشر می‌کنید فشرده و مبهم‌سازی شده است، و بستهٔ iOS نمادهایش جدا شده. پس چیزی که از دستگاه می‌آید شبیه این است:
at a.b.c.d(Unknown Source:2)
at a.b.e.f(Unknown Source:11)که دقیقاً هیچ نمی‌گوید.
برای اینکه این به نام کلاس و شمارهٔ خط واقعی تبدیل شود، باید فایل‌های نگاشت را
نگه دارید و به ابزار بدهید: روی اندروید فایل mapping — و اگر کد بومی دارید فایل
.so — و روی iOS فایل dSYM.
🔴 این فایل‌ها مخصوص همان بیلد هستند. یک بیلد دیگر با همان کد، نگاشت دیگری دارد. اگر فرایند انتشارتان این‌ها را جایی نگه نمی‌دارد، خرابی‌های نسخه‌های گذشته‌تان برای همیشه ناخوانا می‌مانند. این را قبل از انتشار بعدی درست کنید، نه بعد از اولین خرابی — و جایش در CI/CD است تا دستِ آدم.
دسته‌بندی: چرا ده هزار خرابی، ده مسئله است
ابزار خوب خرابی‌های هم‌ریشه را یکی می‌کند. پنج هزار گزارش تبدیل می‌شود به هشت دستهٔ مجزا، مرتب‌شده بر اساس اینکه چند دستگاه را زده‌اند.
این تفاوت بین «فهرستی که نمی‌شود نگاهش کرد» و «فهرستی که می‌شود امروز صبح رویش کار کرد» است. همان منطقی که در رسیدگی به باگ برای گزارش‌های انسانی گفته‌ایم، اینجا ابزار خودکار انجامش می‌دهد.
و یک هشدار: دسته‌بندی خودکار گاهی دو مسئلهٔ متفاوت را یکی می‌کند یا یکی را دو تا. اگر دسته‌ای دارید که نمی‌شود بازتولیدش کرد، قبل از اینکه ساعت‌ها رویش وقت بگذارید، نمونه‌های داخلش را با هم مقایسه کنید.
عددی که باید نگاه کنید
تعداد خرابی، سنجهٔ بدی است — با رشد کاربر بالا می‌رود حتی اگر کیفیت ثابت باشد.
عدد درست، نرخ نشست بدون خرابی است: چند درصد از نشست‌ها بدون کرش تمام شدند. این نسبت است، پس با رشد کاربر حرکت نمی‌کند، و می‌شود بین نسخه‌ها مقایسه‌اش کرد.
۹۹٪ به نظر عالی می‌آید. نیست. یعنی از هر صد بار باز کردن برنامه، یک بار خراب می‌شود؛ کاربری که روزی سه بار استفاده می‌کند، ماهی یک بار کرش می‌بیند. ۹۹٫۹٪ نقطهٔ شروع قابل دفاع است.
نسخه‌به‌نسخه خواندن این عدد، موضوع سلامت انتشار است و آنجا کامل‌تر نوشته‌ایم.
ANR: خرابی‌ای که خرابی نیست
دستهٔ بزرگی از تجربه‌های بد اصلاً کرش نیستند. برنامه باز است، چیزی هم خراب نشده، ولی جواب نمی‌دهد. کاربر همان‌قدر ناراضی می‌شود — شاید بیشتر، چون منتظر می‌ماند.
این‌ها در گزارش خرابی معمولی نمی‌آیند و سنجه و ابزار خودشان را دارند؛ در ANR و فریز اپلیکیشن جدا نوشته‌ایم.
گزینه‌ها، و چرا فهرست ما کوتاه است
بیشتر ابزارهای مشهور این حوزه از ایران نه قابل ثبت‌نام‌اند و نه قابل پرداخت. می‌شود نامشان را برد، ولی توصیه کردنشان یعنی فرستادن شما دنبال دری که باز نمی‌شود.
دو گزینه‌ای که عملاً کار می‌کنند:
AppMetrica از یاندکس. حساب رایگان دارد، خرابی را روی اندروید و iOS جمع
می‌کند، و رمزگشایی سمت سرور انجام می‌دهد — یعنی فایل mapping یا .so یا
dSYM را بالا می‌دهید و گزارش خوانا تحویل می‌گیرید. ANR را هم پوشش می‌دهد.
Sentry خودمیزبان. اگر داده باید روی زیرساخت خودتان بماند، این جواب است. مجوزش FSL است: رایگان استفاده می‌کنید، بعد از دو سال هر نسخه Apache 2.0 می‌شود، و اجازه ندارید آن را به‌عنوان سرویس بفروشید. هزینهٔ واقعی‌اش سخت‌افزار است — حداقل ۴ هسته و ۱۶ گیگابایت رم به‌علاوهٔ ۱۶ گیگابایت swap. این عدد را جدی بگیرید؛ روی ماشین کوچک‌تر بالا می‌آید و بعد زیر بار می‌ماند.
کنار هم گذاشتنشان — با اینکه کدام‌شان برای چه تیمی درست است — در ابزارهای گزارش خرابی، کنار هم آمده.
دو نکته دربارهٔ حریم خصوصی
گزارش خرابی داده می‌فرستد و لحظهٔ خرابی، بدترین لحظه برای فرستادن داده است: چون هر چیزی که در حافظه بوده ممکن است در گزارش بیاید.
قبل از انتشار، یک گزارش واقعی را باز کنید و بخوانید. شمارهٔ تلفن، شناسهٔ ملی، توکن نشست — اگر آنجا هستند، باید فیلترشان کنید. برای داده‌های حساس‌تر مثل حوزهٔ سلامت، تکلیف را امنیت دادهٔ بیمار روشن کرده و قاعده‌اش ساده است: چیزی که نباید از دستگاه خارج شود، در گزارش خرابی هم نباید باشد.
و کلیدها و توکن‌ها را در کد جاسازی نکنید — این فقط مسئلهٔ گزارش خرابی نیست، مدیریت اسرار است، ولی گزارش خرابی جایی است که معمولاً لو می‌روند.
اگر امروز هیچ ابزاری ندارید، کاری که بیشترین ارزش را دارد این نیست که بهترین ابزار را انتخاب کنید؛ این است که همین هفته یکی را وصل کنید. تقریباً در هر پروژه‌ای که این کار را کرده‌ایم، هفتهٔ اول حداقل یک خرابی پرتکرار پیدا شده که تیم اصلاً نمی‌دانست وجود دارد.