تصور کنید مهندس On-call شما در ۲۹ سپتامبر ۲۰۲۶ با یک خطای پرداخت مواجه شده است؛ به‌جای حدس زدن اینکه آیا یک API شخص ثالث در حال اعمال محدودیت نرخ (Rate-limiting) روی ترافیک آن‌هاست یا خیر، او از OnCall Memory استفاده می‌کند. این عامل هوشمند فوراً حادثه‌ای مشابه از ماه گذشته را به یاد می‌آورد و به‌جای ارائه فهرستی کلی از مراحل عیب‌یابی، دقیقاً همان راهکاری را پیشنهاد می‌دهد که پیش از این جواب داده بود.
بیشتر دستیارهای هوش مصنوعی هر بار با یک صفحهٔ سفید شروع می‌کنند. آن‌ها می‌توانند لاگ‌های فعلی را تحلیل کنند، اما فاقد تجربه سازمانی هستند تا بدانند کدام راهکارهای امتحان‌شده در گذشته شکست خورده‌اند. این شکاف باعث می‌شود تیم‌های فنی ساعت‌ها وقت خود را صرف تست فرضیاتی کنند که پیش از این توسط تیم رد شده‌اند و در واقع زمان ارزشمندی را در محیط تولید تلف کنند.
برای حل این مشکل، OnCall Memory برای یک شرکت فین‌تک فرضی به نام Northwind Pay طراحی شده است. این سامانه یک مقایسهٔ مستقیم و در کنار هم پیش روی مهندس قرار می‌دهد: یک پاسخ که بدون حافظه تولید شده و پاسخی دیگر که با «حافظهٔ بازنگری» (Hindsight Memory) تقویت شده است. این رویکرد تضمین می‌کند که هوش مصنوعی صرفاً پاسخی طولانی‌تر ندهد، بلکه پاسخی ارائه کند که بر اساس تاریخچهٔ واقعی و تجربیات تیم استوار باشد.
زمینه: چالش الگوهای تکراری
حوادث محیط تولید به‌ندرت کاملاً جدید هستند. برای مثال، استخر اتصالات (Connection Pool) یک دیتابیس می‌تواند دوباره اشباع شود، یک پیکربندی استقرار (Deployment) می‌تواند دوباره باعث خرابی سرویس شود، یا یک ارائه‌دهنده پرداخت می‌تواند دوباره محدودیت نرخ درخواست اعمال کند. در حالی که علائم بیرونی ممکن است تغییر کنند، اما الگوهای زیربنایی اغلب تکرار می‌شوند.
بدون حافظهٔ پایدار، یک دستیار هوش مصنوعی پیشنهاداتی ارائه می‌دهد که از نظر فنی بر اساس لاگ‌های موجود منطقی هستند، اما به‌طور خودکار نمی‌داند در آخرین حادثه چه اتفاقی افتاده یا کدام راهکار خاص منجر به حل مشکل شده است. OnCall Memory با تبدیل تجربیات سازمانی به یک منبع دادهٔ درجه‌یک، این نقص را برطرف می‌کند تا دانش تیمی از بین نرود.
معماری فنی سامانه
این سیستم از یک پشتهٔ نرم‌افزاری سبک برای تبدیل تاریخچهٔ حوادث به یک منبع قابل جست‌وجو استفاده می‌کند:
- Hindsight: لایهٔ حافظهٔ پایدار که وظیفهٔ عملیات ذخیره (Retaining)، بازیابی (Recalling) و بازنگری (Reflecting) روی داده‌ها را بر عهده دارد.
- Groq: لایهٔ مدل زبانی با سرعت بسیار بالا برای استنتاج (Inference) و تشخیص خطا، که سرعت پاسخ‌دهی را در لحظات بحرانی افزایش می‌دهد.
- FastAPI: مدیریت جریان کاری بک‌اند، عملیات حافظه و ارسال درخواست‌ها به مدل زبانی.
- Frontend: یک داشبورد تک‌صفحه‌ای ساخته شده با HTML/CSS/JS برای تعامل مستقیم مهندسان با سیستم.
برای حفظ امنیت و انعطاف‌پذیری، این پروژه پیکربندی‌ها را از کد برنامه جدا کرده است. اعتبارنامه‌های API به‌جای کدنویسی سخت (Hardcoded)، به‌صورت محلی در متغیرهای محیطی (Environment Variables) ذخیره شده‌اند و یک فایل .env.example ساختار مورد نیاز برای تنظیمات را فراهم می‌کند.
یادگیری از داده‌های واقعی تولید
این پروژه از مجموعه‌ای شامل ۱۳۹ حافظه از شکست‌های زیرساختی رایج استفاده می‌کند تا دقت مدل را بسنجد. این موارد شامل موارد زیر است:
- اشباع استخر اتصالات PostgreSQL
- حذف داده‌ها در Redis (Eviction)
- انقضای گواهینامه‌های TLS
- پیکربندی نادرست استقرار (Deployment)
- تأخیر در مصرف‌کنندگان Kafka (Consumer Lag)
- خطای OOMKilled در پادهای کوبرنتیز
- محدودیت نرخ APIهای پرداخت شخص ثالث
هر حافظه فراتر از یک خلاصه ساده است. این سیستم علائم، لاگ‌ها، علت ریشه‌ای (Root Cause)، مراحل حل مشکل و نتیجه نهایی را ثبت می‌کند. نکتهٔ حیاتی این است که سیستم به‌طور مشخص ثبت می‌کند کدام راهکارهای امتحان‌شده «عمل نکردند»، زیرا دانستن اینکه چه چیزی جواب نداده است، به اندازه دانستن راهکار درست ارزشمند است.
سازوکار Hindsight
به نقل از گزارش dev.to، هستهٔ مرکزی این معماری سه عملیات اصلی را انجام می‌دهد:
۱. ذخیره (Retain): تبدیل اطلاعات مفید یک حادثه به یک حافظهٔ دائمی برای استفاده در آینده.
۲. بازیابی (Recall): فراخوانی حوادث مشابه از تاریخچه زمانی که یک هشدار جدید دریافت می‌شود تا تشخیص خطا تقویت شود.
۳. بازنگری (Reflect): تحلیل کل تاریخچه برای پاسخ به سؤالات گسترده‌تر؛ مثلاً اینکه کدام الگوها مدام باعث ایجاد حادثه می‌شوند و چه چیزی باید به‌طور دائمی اصلاح شود.
این سیستم یک حلقهٔ بازخورد مستمر ایجاد می‌کند: حادثه $
ightarrow$ بازیابی $
ightarrow$ تشخیص $
ightarrow$ رفع خطا $
ightarrow$ بازخورد $
ightarrow$ ذخیره. وقتی مهندس تأیید می‌کند که یک راهکار جواب داده است، این نتیجه دوباره به Hindsight تزریق می‌شود تا عامل هوشمند در طول زمان دقیق‌تر شود.
این تغییر، نقش هوش مصنوعی را از یک مشاور عمومی به یک پایگاه دانش سازمانی تبدیل می‌کند. برای مثال، بدون داشتن زمینه، یک AI ممکن است برای خطای پرداخت پیشنهاد کند که اتصالات شبکه، اعتبارنامه‌ها و تلاش‌های مجدد (Retries) را بررسی کنید. اما با Hindsight، اگر حادثه قبلی مربوط به محدودیت نرخ API بوده باشد، این تاریخچه خاص مستقیماً بخشی از تشخیص فعلی می‌شود.
برای توسعه‌دهنده، این یعنی هوش مصنوعی دیگر یک جعبهٔ سیاه نیست. داشبورد به‌طور شفاف نشان می‌دهد کدام حوادث بازیابی‌شده بر پیشنهاد فعلی اثر گذاشته‌اند تا مهندس بتواند پیش از اجرای هر تغییر، ارتباط و صحت زمینه تاریخی را تأیید کند.
با این حال، اثربخشی سیستم کاملاً به کیفیت حافظه وابسته است. سازندهٔ پروژه اشاره کرده که صرفاً افزایش تعداد حافظه‌ها به‌طور خودکار دستیار را بهبود نمی‌بخشد؛ داده‌ها باید شامل زمینهٔ معناداری مثل «تلاش‌های ناموفق» و «نتایج نهایی» باشند تا واقعاً کاربردی شوند.
این پیاده‌سازی، پاسخ به حوادث را به یک مدل «تأمل‌گر» (Reflective) تبدیل می‌کند. فراتر از حل تک‌تک هشدارها، سیستم می‌تواند کل بانک حافظه را تحلیل کند تا نقاط ضعف معماری را که باعث شکست‌های تکراری می‌شوند، شناسایی کند.
اگرچه در حال حاضر از داده‌های فرضی Northwind Pay استفاده شده و نه داده‌های واقعی تولید، اما این سیستم جریان کاری را نشان می‌دهد که در آن دستیار AI می‌تواند به‌طور فزاینده‌ای بگوید: «ما قبلاً چیزی شبیه به این دیده‌ایم».
در آینده باید منتظر ادغام این لایه‌های حافظهٔ پایدار در ابزارهای مشاهده‌پذیری (Observability) جریان اصلی مانند Datadog یا New Relic باشیم، که می‌تواند خط لولهٔ «گزارش پس از حادثه به حافظه» (Post-mortem to Memory) را کاملاً خودکار کند.
گفتگو