دیباگ در production بدون خراب کردن چیزی

باگی دارید که فقط در production رخ می‌دهد، نمی‌توانید بازتولیدش کنید، و کاربران واقعی همین حالا با آن درگیرند. وسوسه می‌شوید چند console.log اضافه کنید و منتشر کنید. این کار گاهی جواب می‌دهد و گاهی وضعیت را بدتر می‌کند.

این مقاله دربارهٔ روش‌هایی است که اطلاعات می‌دهند بدون اینکه ریسک اضافه کنند. برای روش کلی پیدا کردن باگ، راهنمای کامل دیباگ کردن را ببینید.

قاعدهٔ اول: از داده‌ای که دارید شروع کنید

پیش از هر انتشار جدید، بپرسید: چه چیزی همین حالا در دسترس است؟

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

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

Logpoint: لاگ بدون انتشار

کمتر شناخته‌شده‌ترین ابزار مفید. در تب Sources مرورگر، روی شمارهٔ خط راست‌کلیک کنید و «Add logpoint» را بزنید. عبارتی می‌نویسید و هر بار که آن خط اجرا شود، مقدارش در کنسول چاپ می‌شود — بدون تغییر کد و بدون انتشار. این و قابلیت‌های مشابه را در بیست قابلیت کمتر شناخته‌شدهٔ Chrome DevTools مرور کرده‌ایم.

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

وقتی مجبورید لاگ اضافه کنید

گاهی چاره‌ای نیست. در آن صورت این قواعد ریسک را کم می‌کنند:

پشت یک کلید بگذاریدش. لاگ‌های تشخیصی باید بتوانند بدون انتشار جدید خاموش شوند:

const DEBUG = new URLSearchParams(location.search).has('bmdebug');
if (DEBUG) console.log('checkout state', state);

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

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

لاگ را بعداً حذف کنید. «موقتاً می‌گذارم» به معنی همیشگی است. تیکتی برای حذفش بسازید یا در همان کامیت بنویسید که موقتی است.

انتشار تدریجی: مهم‌ترین ابزار

اگر یک عادت را می‌خواهید تغییر دهید، این باشد. به‌جای انتشار برای همهٔ کاربران، ابتدا برای درصد کوچکی منتشر کنید.

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

برای اینکه این کار معنی بدهد، باید نسخهٔ انتشار را به خطاهای ثبت‌شده ضمیمه کنید، وگرنه نمی‌فهمید کدام خطا از کدام نسخه آمده.

پرچم قابلیت

گام بعدی انتشار تدریجی: کد جدید منتشر می‌شود ولی خاموش است، و شما با یک تنظیم روشنش می‌کنید — بدون انتشار دوباره.

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

بازگرداندن، شرم‌آور نیست

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

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

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

کاری که هرگز نکنید

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

در حین بحران، ترتیب کارها

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

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

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

۳. بعد تحقیق کنید. با فشار برداشته‌شده، کیفیت تصمیم‌هایتان بالاتر می‌رود.

۴. یادداشت بردارید همان لحظه. چه دیدید، چه کردید، ساعت چند. بعد از بحران، هیچ‌کس دقیق یادش نمی‌ماند — و همین یادداشت‌ها مادهٔ خام postmortem‌اند.

ارتباط، بخشی از دیباگ است

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

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

یک جملهٔ کوتاه در همان صفحه — «در حال حاضر مشکلی در ثبت سفارش داریم و در حال رفع آن هستیم» — تفاوت بزرگی در تجربهٔ کاربر می‌سازد، حتی اگر باگ همان باگ باشد.

بعد از رفع: کاری که اغلب انجام نمی‌شود

وقتی مشکل حل شد، سه کار باقی می‌ماند که معمولاً به‌خاطر خستگی رها می‌شوند:

• تستی بنویسید که مانع برگشتش شود. اگر این را نکنید، احتمال زیادی هست که همین باگ چند ماه بعد برگردد.
• لاگ‌های تشخیصی موقت را حذف کنید.
• بپرسید چرا این‌قدر طول کشید تا بفهمیم. این سؤال معمولاً مفیدتر از «چرا این باگ رخ داد» است — چون پاسخش به بهبود سیستمی می‌رسد، نه به یک اصلاح موردی.

سرمایه‌گذاری واقعی: پیش از باگ

همهٔ روش‌های بالا وقتی کار می‌کنند که از قبل آماده شده باشید. چهار چیزی که پیش از بحران باید داشته باشید:

• Source map، وگرنه stack trace چیزی جز t:1:24817 نیست.
• نسخهٔ انتشار روی هر خطا، تا بدانید از کجا آمده.
• مسیر کاربر تا لحظهٔ خطا، که تفاوت بین «خطایی هست» و «می‌دانم چطور بازتولیدش کنم» است.
• راهی برای شنیدن حرف کاربر، چون بخشی از مشکلات هیچ خطای فنی تولید نمی‌کنند.

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

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

• Feature Toggles — مارتین فاولر — پرچم قابلیت و انواع آن
• Canary Release — مارتین فاولر — انتشار تدریجی
• Postmortem Culture — کتاب SRE گوگل — یادگیری از حادثه بدون سرزنش
• Breakpoint و Logpoint در Chrome DevTools — لاگ گرفتن بدون تغییر کد