هزینهٔ پنهان نداشتن سیستم رصد خطا

هزینهٔ داشتن سیستم رصد خطا روی فاکتور نوشته می‌شود. هزینهٔ نداشتنش هیچ‌جا نوشته نمی‌شود — و معمولاً بزرگ‌تر است. این مقاله تلاشی است برای قابل شمردن کردن آن.

۱. کاربرانی که بی‌صدا می‌روند

بزرگ‌ترین هزینه، و نامرئی‌ترین. کاربری که به باگ می‌خورد، معمولاً شکایت نمی‌کند؛ فقط می‌رود.

حساب سرانگشتی‌اش را خودتان بکنید: اگر ماهی ۱۰ هزار بازدیدکننده دارید و نرخ تبدیلتان ۲ درصد است، هر یک درصد از کاربران که به باگی بخورند و برگردند، ماهی چند فروش از دست می‌دهید؟ حالا آن عدد را در ارزش هر مشتری ضرب کنید.

نکتهٔ آزاردهنده این است که هزینهٔ جذب آن کاربر را پرداخته‌اید. تبلیغ دیده، کلیک کرده، تا صفحهٔ پرداخت آمده — و در آخرین قدم به دیواری خورده که شما از وجودش خبر نداشتید.

۲. باگی که دیر پیدا می‌شود، گران‌تر حل می‌شود

همان باگ در لحظه‌های مختلف هزینه‌های متفاوتی دارد:

• همان روز: برنامه‌نویس هنوز در زمینه است. چند دقیقه.
• یک ماه بعد: باید کد را دوباره بفهمد. چند ساعت.
• شش ماه بعد: شاید نویسنده‌اش رفته باشد. چند روز، به‌علاوهٔ ریسک اینکه اصلاحش چیز دیگری را بشکند.

تفاوت بین تیمی که باگ را در ساعت اول می‌بیند و تیمی که در ماه ششم می‌بیند، تفاوت در مهارت نیست — در دیده‌بانی است. مراحل عمر یک باگ، از ورود تا رفع، را در باگ نرم‌افزاری چیست؟ توضیح داده‌ایم.

۳. وقتی که پشتیبانی می‌سوزاند

بدون سیستم رصد، چرخهٔ رسیدگی به هر گزارش این است: کاربر می‌گوید «کار نمی‌کند»، پشتیبانی می‌پرسد چه دیدید، کاربر توضیح مبهمی می‌دهد، پشتیبانی به توسعه‌دهنده می‌گوید، توسعه‌دهنده نمی‌تواند بازتولید کند، دوباره برمی‌گردد به کاربر.

این رفت‌وبرگشت معمولاً چند روز طول می‌کشد و وقت سه نفر را می‌گیرد. با یک اسکرین‌شات خودکار و اطلاعات مرورگر، همین چرخه معمولاً در یک قدم تمام می‌شود.

۴. تصمیم‌گیری بر پایهٔ حدس

وقتی نمی‌دانید کجا خراب است، اولویت‌بندی به بحث سلیقه‌ای تبدیل می‌شود. کسی که بلندتر حرف می‌زند برنده می‌شود، نه کسی که داده دارد.

تیم‌هایی که داده دارند، بحث متفاوتی می‌کنند: «این خطا ۴۱۰ کاربر را در صفحهٔ پرداخت تحت تأثیر گذاشته» جمله‌ای است که بحث را تمام می‌کند.

۵. اعتماد، که برنمی‌گردد

سخت‌ترین هزینه برای اندازه‌گیری. کاربری که یک بار در پرداخت به مشکل خورده، دفعهٔ بعد مردد است. و اگر تجربهٔ بدش را برای دیگران تعریف کند، هزینه چند برابر می‌شود.

این عدد در هیچ داشبوردی نمی‌آید، ولی واقعی‌ترین هزینهٔ فهرست است.

۶. باگ‌هایی که ماه‌ها زندگی می‌کنند

تجربهٔ تقریباً همهٔ تیم‌هایی که برای اولین بار رصد خطا راه می‌اندازند یکسان است: خطاهایی می‌بینند که ماه‌ها وجود داشته‌اند و هیچ‌کس خبر نداشته.

معمولاً چند تایشان جدی‌اند و در مسیرهای مهم رخ می‌دهند. سؤال طبیعی بعدش این است: «چند نفر در این مدت به این خورده‌اند؟» — و پاسخش را هرگز نخواهید دانست.

یک حساب سرانگشتی

فرض کنید فروشگاهی دارید با این اعداد — آن‌ها را با اعداد خودتان عوض کنید:

• ماهی ۲۰٬۰۰۰ بازدیدکننده
• نرخ تبدیل ۲ درصد → ۴۰۰ سفارش
• میانگین ارزش هر سفارش ۸۰۰٬۰۰۰ تومان

حالا فرض کنید باگی در صفحهٔ پرداخت فقط یک درصد از کاربرانی که تا آنجا رسیده‌اند را متوقف می‌کند. یک درصد عدد محافظه‌کارانه‌ای است؛ باگ‌های مخصوص یک مرورگر معمولاً بیشتر از این‌اند.

یک درصد از ۴۰۰ سفارش یعنی ۴ سفارش در ماه، یعنی حدود ۳٬۲۰۰٬۰۰۰ تومان درآمد از دست رفته — در ماه. اگر آن باگ سه ماه زنده بماند، حدود ده میلیون تومان.

و این فقط درآمد مستقیم است. هزینهٔ جذب آن کاربران، وقت پشتیبانی، و اعتمادی که از دست رفته در این عدد نیست.

حالا این را با هزینهٔ ماهانهٔ یک سرویس رصد خطا مقایسه کنید. برای اکثر کسب‌وکارها، یک باگ که یک ماه زودتر پیدا شود، هزینهٔ چند سال سرویس را پوشش می‌دهد.

وقت تیم را هم بشمارید

حساب بالا فقط درآمد را می‌شمرد. ستون دوم، ساعت‌هایی است که تیم صرف دنبال کردن گزارش‌های مبهم می‌کند. این بار هم همهٔ اعداد زیر فرضی‌اند و فقط روش حساب را نشان می‌دهند؛ آن‌ها را با اعداد خودتان عوض کنید:

• فرض: ماهی ۲۰ گزارش از نوع «کار نمی‌کند» به پشتیبانی می‌رسد.
• فرض: هر کدام حدود ۳۰ دقیقه وقت پشتیبانی می‌گیرد تا اطلاعات کافی از کاربر جمع شود.
• فرض: هر کدام حدود ۹۰ دقیقه وقت برنامه‌نویس می‌گیرد تا بفهمد چه اتفاقی افتاده، پیش از آنکه اصلاح را شروع کند.

با این فرض‌ها، هر گزارش دو ساعت وقت می‌برد و ۲۰ گزارش یعنی ۴۰ ساعت در ماه — تقریباً یک هفتهٔ کاری کامل یک نفر، فقط برای فهمیدن مشکل، نه حل کردنش. حالا آن را در هزینهٔ ساعتی تیمتان ضرب کنید.

رصد خطا این عدد را صفر نمی‌کند، ولی بخش «فهمیدن» را کوتاه می‌کند: پیام خطا، صفحه و مرورگر از قبل جلوی برنامه‌نویس است. اینکه چقدر کوتاه می‌شود به تیم و محصول شما بستگی دارد؛ پس خودتان اندازه‌اش بگیرید، نه اینکه عددی را از جایی قرض کنید.

چرا این حساب معمولاً انجام نمی‌شود

دلیلش سوگیری شناختی ساده‌ای است: ما چیزی را که نمی‌بینیم، صفر فرض می‌کنیم.

وقتی گزارش باگی نمی‌رسد، حس می‌کنیم مشکلی نیست. ولی نبود گزارش، شواهد نبود مشکل نیست — شواهد نبود گزارش است. و با توجه به اینکه اکثریت کاربران هرگز گزارش نمی‌دهند، این دو چیز بسیار متفاوتند.

تیم‌هایی که برای اولین بار رصد راه می‌اندازند، تقریباً همیشه همین را تجربه می‌کنند: عددی که صفر فرض می‌کردند، صفر نبود.

طرف دیگر ترازو

هزینهٔ داشتنش چیست؟ برای تیم کوچک، معمولاً کمتر از یک ساعت کار برنامه‌نویس در ماه است — و پلن رایگان بیشتر ابزارها برای شروع کافی است. برای مقایسهٔ قیمت‌ها، مقایسهٔ ابزارهای رصد خطا برای تیم‌های ایرانی را ببینید.

تقریباً هر مقایسه‌ای بین این دو ستون، به یک نتیجه می‌رسد. و برخلاف بیشتر سرمایه‌گذاری‌های فنی، این یکی از هفتهٔ اول نتیجه می‌دهد: چیزهایی می‌بینید که نمی‌دانستید.

این حساب در نرم‌افزارهای سازمانی سنگین‌تر هم می‌شود. وقتی کاربران یک سامانه، کارمندان همان سازمان‌اند، کسی «نمی‌رود»؛ فقط با راه‌حل‌های موقت کار را جلو می‌برند و هزینه، بی‌صدا در ساعت‌های کاری از دست‌رفته پنهان می‌شود. ما در طراحی نرم‌افزارهای سازمانی در ژابیز پردا، شرکتی که BugMug را ساخته، بارها دیده‌ایم که یک خطای کوچکِ گزارش‌نشده ماه‌ها در یک سامانه دولتی زنده مانده است.

چطور موضوع را به مدیرتان بگویید

اگر تصمیم خرید با شما نیست، استدلال فنی معمولاً کافی نیست. چند نکته که گفت‌وگو را ساده‌تر می‌کند:

• از مسیر درآمد شروع کنید، نه از ابزار. به‌جای «به یک سرویس رصد خطا نیاز داریم» بگویید «نمی‌دانیم صفحهٔ پرداخت برای چند نفر کار نمی‌کند».
• اعداد خود کسب‌وکار را بیاورید. حساب‌های بالا را با اعداد واقعی خودتان پر کنید و فرض‌ها را صریح بنویسید. عددی که فرضش معلوم است، قابل بحث است؛ عددی بی‌منبع، اعتماد را از بین می‌برد.
• یک آزمایش کوتاه پیشنهاد کنید، نه یک تعهد. «دو هفته با پلن رایگان نصب می‌کنیم و بعد نتیجه را نشان می‌دهیم» تصمیم کوچک‌تری است از «یک ابزار جدید بخریم».
• از قبل بگویید چه خواهید دید. هفتهٔ اول احتمالاً خطاهایی پیدا می‌شود که ماه‌ها بوده‌اند. اگر مدیر آماده نباشد، ممکن است آن را نشانهٔ بدتر شدن محصول بداند، نه دیده شدن چیزی که از قبل بود.

از کجا بفهمید جواب داده

بعد از راه‌اندازی، این چند عدد را از همان ماه اول ثبت کنید تا بعداً چیزی برای مقایسه داشته باشید:

• زمان تا فهمیدن: از لحظهٔ انتشار یک تغییر تا لحظه‌ای که تیم از خطای ناشی از آن باخبر می‌شود.
• منبع کشف باگ: چه سهمی از باگ‌ها را اول ابزار دید و چه سهمی را اول کاربر یا پشتیبانی؟ هرچه سهم دوم کمتر شود، یعنی زودتر می‌بینید.
• خطاهای مسیرهای مهم: تعداد کاربرانی که در ثبت‌نام، ورود یا پرداخت به خطا خورده‌اند. این عدد باید با رفع باگ‌ها پایین بیاید.
• تیکت‌های مبهم پشتیبانی: تعداد گزارش‌هایی که برای فهمیدنشان چند بار رفت‌وبرگشت با کاربر لازم بوده است.

یک هشدار: در هفته‌های اول تعداد خطاهای ثبت‌شده بالا می‌رود، چون تازه دارید می‌بینیدشان. روند را از وقتی بسنجید که عدد پایه معلوم شده است.

چک‌لیست هفتهٔ اول

1. اسکریپت رصد را روی سایت اصلی نصب کنید، نه فقط روی محیط تست؛ خیلی از باگ‌ها فقط در production دیده می‌شوند.
2. یک خطای آزمایشی بسازید و مطمئن شوید در داشبورد دیده می‌شود و هشدارش به جای درست می‌رسد.
3. مسیرهای پول‌ساز را فهرست کنید: ثبت‌نام، ورود، سبد خرید، پرداخت.
4. هر روز چند دقیقه خطاهای جدید را مرور کنید و آن‌هایی را که در این مسیرها رخ می‌دهند جدا کنید.
5. آخر هفته، مهم‌ترین یافته‌ها را در چند خط برای تیم و مدیر بنویسید.

پرسش‌های رایج

آنالیتیکس همین کار را نمی‌کند؟

ابزارهای آنالیتیکس می‌گویند کاربران کجا رفتند و کجا ماندند، ولی معمولاً نمی‌گویند چرا. اگر خروج از صفحهٔ پرداخت بالاست، آنالیتیکس نشانش می‌دهد؛ رصد خطا می‌گوید آیا پشت آن یک خطای جاوااسکریپت روی مرورگری خاص هست یا نه. این دو مکمل هم‌اند.

اگر تست خودکار داریم، باز هم لازم است؟

بله. تست نرم‌افزار چیزهایی را می‌سنجد که از قبل به فکرشان رسیده‌اید. رصد خطا چیزهایی را نشان می‌دهد که به فکر کسی نرسیده: مرورگرهای قدیمی، افزونه‌های مرورگر، اینترنت ناپایدار و داده‌هایی که در محیط تست وجود ندارند.

رصد خطا اطلاعات شخصی کاربران را جمع نمی‌کند؟

بستگی به ابزار و تنظیماتش دارد و باید پیش از نصب بررسی‌اش کنید. ابزار مناسب باید اجازه دهد فیلدهای حساس را پنهان کنید. در باگ‌ماگ، مثلاً، فیلدهای رمز عبور خودکار پوشانده می‌شوند و هر فیلد دیگری را هم می‌توانید با data-bug-mask علامت بزنید تا پوشانده شود.

یک آزمون ساده

اگر مطمئن نیستید به این نیاز دارید، به این سه سؤال پاسخ دهید:

• آخرین باگی که کاربران دیدند، چطور فهمیدید؟ اگر جواب «کسی زنگ زد» است، یعنی همهٔ باگ‌هایی که کسی زنگ نزده را نمی‌دانید.
• همین حالا چند خطا در سایتتان رخ می‌دهد؟ اگر نمی‌دانید، پاسخ صفر نیست.
• اگر انتشار امروزتان چیزی را بشکند، چقدر طول می‌کشد تا بفهمید؟

سؤال درست «آیا به رصد خطا نیاز داریم؟» نیست. سؤال این است که «الان چند باگ داریم که نمی‌بینیم؟» — و تنها راه فهمیدنش، نصب کردن و یک هفته تماشا کردن است.

منابع و مطالعهٔ بیشتر

• The Cost of Poor Software Quality in the US — CISQ، ۲۰۲۲ — برآورد هزینهٔ کیفیت پایین نرم‌افزار
• گزارش NIST دربارهٔ هزینهٔ آزمون ناکافی نرم‌افزار — مطالعهٔ کلاسیک ۲۰۰۲
• Embracing Risk — کتاب SRE گوگل — سنجیدن هزینهٔ خرابی در برابر هزینهٔ پیشگیری