تصور کنید یک مهندس SRE باشید که به‌جای ساعت‌ها گشتن در تپه‌های داده، در کمتر از ۴ ثانیه دلیل دقیق یک خرابی را روی میز داشته باشد. این دیگر یک رویای عملیاتی نیست، بلکه خروجی MIB (Men in Backend) است؛ پلتفرم خودگردانی که هزینه‌ی هر تحلیل ریشه‌ای (RCA) را به ۰.۰۰۱۲۸ دلار رسانده است.
طبق اعلام تیم توسعه‌دهنده در هکاتون SigNoz در ۲۵ ژوئیه ۲۰۲۶، MIB برخلاف چت‌باتی که منتظر دستور کاربر می‌ماند، مانند یک نیروی کار فعال عمل می‌کند که به‌طور مستقل نظارت، بازرسی و گزارش می‌دهد. همان‌طور که در تحلیل قبلی ما درباره‌ی اتوماسیون تحلیل‌ها با Llama 3.1 اشاره کردیم، MIB حالا یک گام فراتر رفته و پلتفرم مشاهده‌پذیری را نه یک پایگاه داده، بلکه یک محیط کار دیجیتال می‌بیند. این رویکرد در واقع تکامل‌یافته‌ی استفاده از کدهای اصلاحی خودکار در برابر داشبوردهای نظارتی سنتی است تا تحلیل‌ها را از حالت دستی به خودکار تبدیل کند. این سیستم با بهره‌گیری از پروتکل زمینهٔ مدل (Model Context Protocol یا MCP) — که شبیه به یک استاندارد مشترک برای اتصال ابزارهای مختلف به مغز هوش مصنوعی است — می‌تواند به‌طور خودکار با ۴۱ ابزار مجزا برای مدیریت لاگ‌ها و هشدارها تعامل کند.
معماری این سیستم که Neuralyzer نامیده شده، در سه لایه طراحی شده است تا هر بخشی از اپلیکیشن تا خودِ هوش مصنوعی زیر نظر باشد:
- لایه ۱ (اپلیکیشن هدف): شامل ۱۴ میکروسرویس که تریس‌ها و متریک‌های استاندارد را تولید می‌کنند.
- لایه ۲ (عامل‌ها): لایه‌ای که عملیات بررسی و هزینه‌های توکن را ثبت می‌کند.
- لایه ۳ (سرور MCP): لایه‌ای که زمان اجرای ابزارها و فراخوانی‌های مدل را مانیتور می‌کند.
قلب این عملیات، Agency HQ است؛ برنامه‌ای که هشدارها را از Alertmanager دریافت کرده و آن‌ها را به‌عنوان وظایف پس‌زمینه اجرا می‌کند تا پاسخ به وب‌هوک‌ها آنی باشد.
در این ساختار، عامل J نقش پاسخ‌دهنده اول را دارد. طبق مستندات پروژه، Agent J به‌جای «فکر کردن» در یک حلقه باز، از یک دستورالعمل قطعی پنج‌مرحله‌ای پیروی می‌کند: ابتدا تریگر هشدار را تأیید می‌کند، سپس تریس‌های خطاآلود را می‌یابد، گلوگاه را شناسایی کرده، لاگ‌های مربوطه را استخراج می‌کند و در نهایت دلتای متریک را اندازه می‌گیرد. این روش باعث می‌شود پیش‌بینی‌ناپذیری عامل‌ها حذف شود.
برای بهینه‌سازی، تیم از مدل gemini-2.5-flash استفاده کرد. نکته کلیدی اینجا غیرفعال کردن Reasoning Effort بود. مدل‌های استدلالی — مثل شطرنج‌بازی که چند حرکت جلوتر را می‌بیند و قبل از جواب درنگ می‌کند — در اینجا باعث هدررفت توکن‌ها و افزایش تأخیر تا ۱۶ ثانیه می‌شدند. با حذف این قابلیت، تأخیر به ۲ ثانیه کاهش یافت و خطاها صفر شدند. نتیجه این است که کارت حادثه در ۳.۷ ثانیه به Slack ارسال می‌شود.
در مقابل، عامل K به‌عنوان بازرس بهره‌وری عمل می‌کند. او با یک چک‌لیست چهارمرحله‌ای، اتلاف داده‌ها را شناسایی می‌کند: از بررسی حجم داده‌های ورودی و کاردینالیتی گرفته تا شناسایی متریک‌های بلااستفاده. بر اساس بررسی این تیم، ۱۵ مورد از ۳۹ متریک برتر هیچ استفاده‌ای در داشبوردها نداشتند؛ یعنی ۳۸.۵٪ از هزینه‌های ذخیره‌سازی داده‌ها کاملاً بیهوده بود.
برای جلوگیری از خطاهای فاجعه‌بار، Agent K دارای یک «گیت انسانی» است. او پیشنهاد اصلاح را می‌دهد (مثلاً ساخت یک داشبورد جدید)، اما اجرای آن منوط به کلیک دکمه Approve در Slack توسط انسان است.
بخش دیگر سیستم، Mission Control++ است که هر ۲۵ ثانیه یک امتیاز روند (Trend Score) بر اساس تأخیر p95، نرخ خطا و تعداد تلاش‌های مجدد (Retry) محاسبه می‌کند. اگر امتیاز به ۵۵ برسد، سیستم یک پیش‌بینی با سطح اطمینان (بین ۶۶٪ تا ۹۷٪) و زمان تخمینی تا وقوع خطا (ETA) صادر می‌کند.
پس از پایان هر بررسی، یک موتور اطمینان بر اساس تطابق تریس‌ها و همبستگی لاگ‌ها، نمره نهایی را تعیین کرده و یک گزارش پس‌مرگ (Post-mortem) در قالب Markdown یا PDF تولید می‌کند که دقیقاً توضیح می‌دهد چرا این نتیجه به دست آمده است.
توسعه این سیستم بدون چالش نبود. تیم گزارش داد که ClickHouse Keeper روی Docker Desktop در ویندوز دچار Segfault می‌شد که آن‌ها را مجبور کرد به WSL2 و اوبونتو ۲۴.۰۴ مهاجرت کنند. همچنین برای جلوگیری از خوابیدن WSL، یک Task زمان‌بندی شده در ویندوز ایجاد کردند تا محیط لینوکس همیشه زنده بماند.
در لایه یکپارچگی MCP، سه مشکل اصلی وجود داشت: جایگزینی URLهای داخلی داکر با آدرس‌های مرورگر (Localhost)، مدیریت خروجی‌های JSON که گاهی با متن‌های اضافی همراه بودند، و اصلاح Healthcheck تصاویر Distroless که دستور wget نداشتند.
در نهایت، با استفاده از ابزارهای اندازه‌گیری هزینه، تیم ثابت کرد که یک اجرای واقعی برای رفع خطای Redis، تنها ۱۷۳۳ توکن ورودی و ۳۰۵ توکن خروجی مصرف کرده است که مجموعاً ۰.۰۰۱۲۸ دلار هزینه داشت. این شفافیت مالی نشان می‌دهد که هوش مصنوعی می‌تواند بودجه مشاهده‌پذیری را مدیریت کند، نه اینکه فقط لاگ‌ها را بخواند.
گام بعدی شما
- اگر از SigNoz استفاده می‌کنید، پروتکل MCP را برای تبدیل داشبوردهای غیرفعال به رابط‌های برنامه‌پذیر بررسی کنید.
- متریک‌های پرهزینه خود را با متد Agent K بازبینی کنید تا داده‌های بلااستفاده را حذف کنید.
- برای کاهش تأخیر در عامل‌های عملیاتی، قابلیت Reasoning را در مدل‌های Flash غیرفعال کنید.
اما تأثیر این اتوماسیون بر هزینه‌های کلی زیرساخت‌های ابری حتی تکان‌دهنده‌تر است — به تحلیل ما درباره‌ی بهینه‌سازی GPUهای استنتاج مراجعه کنید.
گفتگو