هزینهٔ پنهان نداشتن سیستم رصد خطا
در این مقاله میخوانید
هزینهٔ داشتن سیستم رصد خطا روی فاکتور نوشته میشود. هزینهٔ نداشتنش هیچجا نوشته نمیشود — و معمولاً بزرگتر است. این مقاله تلاشی است برای قابل شمردن کردن آن.
۱. کاربرانی که بیصدا میروند
بزرگترین هزینه، و نامرئیترین. کاربری که به باگ میخورد، معمولاً شکایت نمیکند؛ فقط میرود.
حساب سرانگشتیاش را خودتان بکنید: اگر ماهی ۱۰ هزار بازدیدکننده دارید و نرخ تبدیلتان ۲ درصد است، هر یک درصد از کاربران که به باگی بخورند و برگردند، ماهی چند فروش از دست میدهید؟ حالا آن عدد را در ارزش هر مشتری ضرب کنید.
نکتهٔ آزاردهنده این است که هزینهٔ جذب آن کاربر را پرداختهاید. تبلیغ دیده، کلیک کرده، تا صفحهٔ پرداخت آمده — و در آخرین قدم به دیواری خورده که شما از وجودش خبر نداشتید.
۲. باگی که دیر پیدا میشود، گرانتر حل میشود
همان باگ در لحظههای مختلف هزینههای متفاوتی دارد:
- همان روز: برنامهنویس هنوز در زمینه است. چند دقیقه.
- یک ماه بعد: باید کد را دوباره بفهمد. چند ساعت.
- شش ماه بعد: شاید نویسندهاش رفته باشد. چند روز، بهعلاوهٔ ریسک اینکه اصلاحش چیز دیگری را بشکند.
تفاوت بین تیمی که باگ را در ساعت اول میبیند و تیمی که در ماه ششم میبیند، تفاوت در مهارت نیست — در دیدهبانی است. مراحل عمر یک باگ، از ورود تا رفع، را در باگ نرمافزاری چیست؟ توضیح دادهایم.
۳. وقتی که پشتیبانی میسوزاند
بدون سیستم رصد، چرخهٔ رسیدگی به هر گزارش این است: کاربر میگوید «کار نمیکند»، پشتیبانی میپرسد چه دیدید، کاربر توضیح مبهمی میدهد، پشتیبانی به توسعهدهنده میگوید، توسعهدهنده نمیتواند بازتولید کند، دوباره برمیگردد به کاربر.
این رفتوبرگشت معمولاً چند روز طول میکشد و وقت سه نفر را میگیرد. با یک اسکرینشات خودکار و اطلاعات مرورگر، همین چرخه معمولاً در یک قدم تمام میشود.
۴. تصمیمگیری بر پایهٔ حدس
وقتی نمیدانید کجا خراب است، اولویتبندی به بحث سلیقهای تبدیل میشود. کسی که بلندتر حرف میزند برنده میشود، نه کسی که داده دارد.
تیمهایی که داده دارند، بحث متفاوتی میکنند: «این خطا ۴۱۰ کاربر را در صفحهٔ پرداخت تحت تأثیر گذاشته» جملهای است که بحث را تمام میکند.
۵. اعتماد، که برنمیگردد
سختترین هزینه برای اندازهگیری. کاربری که یک بار در پرداخت به مشکل خورده، دفعهٔ بعد مردد است. و اگر تجربهٔ بدش را برای دیگران تعریف کند، هزینه چند برابر میشود.
این عدد در هیچ داشبوردی نمیآید، ولی واقعیترین هزینهٔ فهرست است.
۶. باگهایی که ماهها زندگی میکنند
تجربهٔ تقریباً همهٔ تیمهایی که برای اولین بار رصد خطا راه میاندازند یکسان است: خطاهایی میبینند که ماهها وجود داشتهاند و هیچکس خبر نداشته.
معمولاً چند تایشان جدیاند و در مسیرهای مهم رخ میدهند. سؤال طبیعی بعدش این است: «چند نفر در این مدت به این خوردهاند؟» — و پاسخش را هرگز نخواهید دانست.
یک حساب سرانگشتی
فرض کنید فروشگاهی دارید با این اعداد — آنها را با اعداد خودتان عوض کنید:
- ماهی ۲۰٬۰۰۰ بازدیدکننده
- نرخ تبدیل ۲ درصد → ۴۰۰ سفارش
- میانگین ارزش هر سفارش ۸۰۰٬۰۰۰ تومان
حالا فرض کنید باگی در صفحهٔ پرداخت فقط یک درصد از کاربرانی که تا آنجا رسیدهاند را متوقف میکند. یک درصد عدد محافظهکارانهای است؛ باگهای مخصوص یک مرورگر معمولاً بیشتر از ایناند.
یک درصد از ۴۰۰ سفارش یعنی ۴ سفارش در ماه، یعنی حدود ۳٬۲۰۰٬۰۰۰ تومان درآمد از دست رفته — در ماه. اگر آن باگ سه ماه زنده بماند، حدود ده میلیون تومان.
و این فقط درآمد مستقیم است. هزینهٔ جذب آن کاربران، وقت پشتیبانی، و اعتمادی که از دست رفته در این عدد نیست.
حالا این را با هزینهٔ ماهانهٔ یک سرویس رصد خطا مقایسه کنید. برای اکثر کسبوکارها، یک باگ که یک ماه زودتر پیدا شود، هزینهٔ چند سال سرویس را پوشش میدهد.
چرا این حساب معمولاً انجام نمیشود
دلیلش سوگیری شناختی سادهای است: ما چیزی را که نمیبینیم، صفر فرض میکنیم.
وقتی گزارش باگی نمیرسد، حس میکنیم مشکلی نیست. ولی نبود گزارش، شواهد نبود مشکل نیست — شواهد نبود گزارش است. و با توجه به اینکه اکثریت کاربران هرگز گزارش نمیدهند، این دو چیز بسیار متفاوتند.
تیمهایی که برای اولین بار رصد راه میاندازند، تقریباً همیشه همین را تجربه میکنند: عددی که صفر فرض میکردند، صفر نبود.
طرف دیگر ترازو
هزینهٔ داشتنش چیست؟ برای تیم کوچک، معمولاً کمتر از یک ساعت کار برنامهنویس در ماه است — و پلن رایگان بیشتر ابزارها برای شروع کافی است. برای مقایسهٔ قیمتها، مقایسهٔ ابزارهای رصد خطا برای تیمهای ایرانی را ببینید.
تقریباً هر مقایسهای بین این دو ستون، به یک نتیجه میرسد. و برخلاف بیشتر سرمایهگذاریهای فنی، این یکی از هفتهٔ اول نتیجه میدهد: چیزهایی میبینید که نمیدانستید.
این حساب در نرمافزارهای سازمانی سنگینتر هم میشود. وقتی کاربران یک سامانه، کارمندان همان سازماناند، کسی «نمیرود»؛ فقط با راهحلهای موقت کار را جلو میبرند و هزینه، بیصدا در ساعتهای کاری از دسترفته پنهان میشود. ما در طراحی نرمافزارهای سازمانی در ژابیز پردا، شرکتی که BugMug را ساخته، بارها دیدهایم که یک خطای کوچکِ گزارشنشده ماهها در یک سامانه دولتی زنده مانده است.
یک آزمون ساده
اگر مطمئن نیستید به این نیاز دارید، به این سه سؤال پاسخ دهید:
- آخرین باگی که کاربران دیدند، چطور فهمیدید؟ اگر جواب «کسی زنگ زد» است، یعنی همهٔ باگهایی که کسی زنگ نزده را نمیدانید.
- همین حالا چند خطا در سایتتان رخ میدهد؟ اگر نمیدانید، پاسخ صفر نیست.
- اگر انتشار امروزتان چیزی را بشکند، چقدر طول میکشد تا بفهمید؟
سؤال درست «آیا به رصد خطا نیاز داریم؟» نیست. سؤال این است که «الان چند باگ داریم که نمیبینیم؟» — و تنها راه فهمیدنش، نصب کردن و یک هفته تماشا کردن است.
منابع و مطالعهٔ بیشتر
- The Cost of Poor Software Quality in the US — CISQ، ۲۰۲۲ — برآورد هزینهٔ کیفیت پایین نرمافزار
- گزارش NIST دربارهٔ هزینهٔ آزمون ناکافی نرمافزار — مطالعهٔ کلاسیک ۲۰۰۲
- Embracing Risk — کتاب SRE گوگل — سنجیدن هزینهٔ خرابی در برابر هزینهٔ پیشگیری
باگماگ را رایگان امتحان کنید
خطاهای سایتتان را خودکار ثبت کنید و بگذارید کاربران با یک کلیک باگ گزارش دهند.
شروع رایگان