تصور کنید یک قطعی در سیستم پرداخت ۴۰ دقیقه بدون شناسایی باقی بماند، صرفاً چون خطای مربوطه زیر کوهی از هشدارهای تکراری پنهان شده است. این یک شکست رایج در تیم‌های فنی است؛ جایی که تیم‌ها به دلیل حجم عظیم داده‌ها، لاگ‌ها را نادیده می‌گیرند. اما یک اسکریپت ۶۰ خطی پایتون از MonkeyCode با فشرده‌سازی ۲.۳ گیگابایت لاگ شبانه به یک گزارش کوتاه Markdown، این بحران را حل می‌کند.
بسیاری از تیم‌های مهندسی بین دو راه سخت گیر کرده‌اند: یا لاگ‌ها را کاملاً نادیده بگیرند یا دچار «خستگی از هشدار» (Pager Fatigue) شوند؛ یعنی هر کلمه کلیدی را به یک اعلان تبدیل کنند و سپس به دلیل حجم زیاد هشدارها، سیستم اعلان را به‌طور کلی خاموش کنند. این ابزار راه سومی را پیشنهاد می‌دهد: یک خلاصه‌ساز شبانه که ساعت ۶ صبح از طریق cron job اجرا می‌شود، دقیقاً پیش از آنکه تیم روز کاری خود را آغاز کند. این سیستم یک تسک سه ساعته‌ی خواندن لاگ را به یک جلسه ۵ دقیقه‌ای برای اولویت‌بندی (Triage) تبدیل می‌کند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی اتوماسیون‌های کوچک و کاربردی اشاره کردیم، قدرت واقعی هوش مصنوعی در جایگزینی ابزارهای پیچیده با اسکریپت‌های هدفمند است.
زمینه و پیاده‌سازی
این سیستم به‌گونه‌ای طراحی شده است که بتوان آن را ویرایش کرد، نه اینکه صرفاً به آن اعتقاد کورکورانه داشت. این ابزار برای تیم‌هایی در نظر گرفته شده که دایرکتوری لاگ و قهوه صبحگاهی دارند، اما فاقد یک پلتفرم اختصاصی نظارت (Observability) هستند. کل این فرآیند روی یک گزینه سرور رایگان میزبانی می‌شود که مدیریت cron job را بر عهده دارد.
طبق راهنمای ۲۵ اوت ۲۰۲۶ در وب‌سایت dev.to، این سامانه در سه مرحله متمایز عمل می‌کند: استخراج، خلاصه‌سازی و تحویل.
۱. استخراج خام
فرآیند استخراج به‌طور عمدی ساده و «خام» طراحی شده تا اطمینان حاصل شود که روی فرمت‌های مختلف کار می‌کند. اسکریپت از بررسی زیررشته‌ها (substring check) بدون استفاده از regex استفاده می‌کند که روی متن ساده، خطوط JSON و stack traceها به‌طور یکسان جواب می‌دهد.
- کلمات کلیدی: اسکریپت هر فایل لاگ را برای یافتن خطوط حاوی
ERROR،WARN،ExceptionیاTracebackاسکن می‌کند. - کنترل حجم: تنها ۲۰۰ مورد آخر حفظ می‌شوند. این سقف مانع از سرریز شدن پنجره متنی (Context Window) — مثل میز کاری که جا برای چند ورق دارد، نه برای کل کتابخانه — شده و مدل را مجبور می‌کند روی تازه‌ترین فعالیت‌ها تمرکز کند. این مدیریت دقیق توکن‌ها برای جلوگیری از بحران‌هایی است که یک اشتباه در شمارش توکن می‌تواند کل سیستم را متوقف کند.
- بهای پذیرفته‌شده: در حالی که این روش خطوطی را که مثلاً می‌گویند «something went wrong» اما فاقد کلمات کلیدی هستند نادیده می‌گیرد، اما در عوض خطوط حیاتی مورد نیاز برای تریاژ صبحگاهی را شکار می‌کند.
۲. خلاصه‌سازی با مدل زبانی
خطوط استخراج‌شده به یک لایه‌ی رایگان از مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — ارسال می‌شوند. برای جلوگیری از توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که وجود ندارد — مقدار دمای (Temperature) مدل روی ۰.۲ تنظیم شده است تا خروجی‌ها دقیق‌تر و پیش‌بینی‌پذیرتر باشند. این رویکرد برای اجتناب از شکست‌های رایج در خلاصه‌سازی اسناد بلند در مقیاس صنعتی است که اغلب به دلیل توهمات انتهایی رخ می‌دهد.
پرامپت (دستور) به‌طور صریح به مدل دستور می‌دهد که خطوط را بر اساس «علت ریشه‌ای» (Root Cause) گروه‌بندی کند، یک توضیح تک‌خطی ارائه دهد و یک گام بعدی برای رفع مشکل پیشنهاد کند، در حالی که کل متن زیر ۲۰۰ کلمه باقی بماند.
- تنظیم پرامپت: کاربران می‌توانند دستورات را برای نتایج بهتر بهینه کنند. برای مثال، اضافه کردن خطی که ذکر کند نام سرویس
payment-workerاست، به مدل کمک می‌کند تا از نام‌های صحیح در گزارش استفاده کند. - کاهش نویز: اگر هشدارهای
WARNبیش از حد پرحرف و مزاحم باشند، حذف کلمهWARNاز الگوی استخراج، نویز گزارش را کاهش می‌دهد. - محدودیت‌ها: دستور صریح داده شده که مدل نباید جزئیاتی را اختراع کند که در خطوط استخراج‌شده وجود ندارد.
۳. تحویل گزارش
خلاصه نهایی در فایلی نوشته می‌شود که تیم همراه با قهوه می‌خواند. یک ورودی cron روی سرور رایگان، اسکریپت را هر روز اجرا می‌کند:0 6 * * * cd /opt/log-brief && python nightly_log_brief.py >> /var/log/log-brief.log 2>&1.
در یک تست کنترل‌شده، مدل توانست ۱۶۳ خط خطا را با موفقیت در سه علت ریشه‌ای متمایز دسته‌بندی کند:
- خطاهای Timeout در payment worker (۱۴۲ مورد): ورکر با یک تایم‌اوت ۳۰ ثانیه‌ای در API پرداخت بالادستی مواجه شده بود. گام بعدی پیشنهادی، بررسی صفحه وضعیت (Status Page) و افزایش زمان انتظار به ۴۵ ثانیه بود.
- اتصال به دیتابیس (۱۸ مورد): اندازه استخر اتصالات (Connection Pool) برای اجرای کارهای دسته‌ای (Batch Job) صبحگاهی بسیار کم بود. پیشنهاد شد
max_connectionsاز ۱۰ به ۲۰ افزایش یابد. - یک stack trace تکراری در سرویس auth (۳ مورد): یک خطای null pointer در تمدید نشست (Session Renewal) شناسایی شد که نیاز به یک وصله (patch) برای بررسی null داشت.
این رویکرد بار عملیاتی را از «جست‌وجوی دستی» به «تأیید انسانی» منتقل می‌کند. به‌جای گشتن دنبال سوزن در انبار کاه، هوش مصنوعی سوزن احتمالی را علامت می‌زند و مهندس فقط وجود آن را تأیید می‌کند. این سیستم اولویت را به یک «اتوماسیون کوچک و محدود» می‌دهد تا یک پلتفرم پیچیده نظارت که ممکن است هرگز به‌طور کامل پیاده‌سازی نشود.
برای کاربر، این یعنی کاهش ریسک قطعی‌های شناسایی‌نشده بدون سرمایه‌گذاری در ابزارهای سازمانی گران‌قیمت. البته باید توجه داشت که این یک سیستم هشدار لحظه‌ای (Real-time) نیست، بلکه ابزاری برای تریاژ تیم‌هایی است که لاگ دارند اما پهنای باند لازم برای خواندن آن‌ها را ندارند.
کاربران باید درباره حریم خصوصی داده‌ها محتاط باشند. چون لاگ‌ها به یک مدل خارجی ارسال می‌شوند، نویسنده توصیه می‌کند مرحله‌ای برای حذف (Redaction) ایمیل‌ها و آدرس‌های IP قبل از ساخت پرامپت اضافه شود. این دقت در کنترل ورودی‌ها برای جلوگیری از خطاهای سیستمی حیاتی است، مشابه مواردی که یک تیکت پشتیبانی ساده منجر به تایید غیرقانونی بازگشت وجه شد.
همچنین تیم‌هایی که هیچ لاگ خطایی ندارند، باید پیش از استقرار یک خلاصه‌ساز، روی اصلاح زیرساخت لاگ‌گیری خود تمرکز کنند.
گام بعدی شما
- اسکریپت را روی یک دایرکتوری نمونه تست کنید تا خروجی را بسنجید و سپس آن را روی سرور رایگان زمان‌بندی کنید.
- برای یکپارچگی بیشتر، جایگزین کردن نوشتن در فایل با یک وب‌هوک (Webhook) اعلان چت، گزارش را مستقیماً وارد جریان کاری تیم می‌کند.
- کلمات کلیدی استخراج را بر اساس متداول‌ترین خطاهای سیستم خودتان شخصی‌سازی کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو